Using the CVB driver for sherlock, is it possible to have a bit of an overlap in images generated by a linescan camera?
What I am trying to obtain is described in the image below;
As I’m not using a framegrabber, I’d like to be able to configure this in the driver, so that my frames allready have this overlap built into them. This isn’t easy to do with sherlock, so perhaps it can be configured in the cvb driver.
I am sorry, but something like this cannot be achieved easily and will unfortunately not be possible inside the Sherlock CVB Driver as it is today.
In :cvb: (meaning outside Sherlock) you could implement something like that if the *.vin driver you are using supports the IRingBuffer interface by implementing the following steps:
Configure the number of buffers that you intend to use.
Modify the VPAT of the individual buffers in such a way that the first x lines of each buffer point to the last x lines of the previous buffer (and as it is a ring buffer, the preceding buffer of the first buffer is the last buffer).
This will of course lead to the first x lines of each buffer being inaccessible as no VPAT entries point to those lines any more. In other words: It’ll look like the first x lines of each buffer are silently discarded and instead the last x lines of the previous buffer will be used - if that does not fit your use case then it’ll be difficult to come up with an alternative…
For these modifications to work properly, it’ll of course be necessary to fill the buffers strictly in rising index order (i.e. acquisition fills 0, 1, 2, …, N-1, 0, 1, … without skipping an index). Now, :cvb: does not make any guarantees that this will be the case! An with manual locking, it is easy to see how a driver may deviate from this scheme as soon as it encounter a locked buffer. So for the above modification to work properly, it is essential that you refrain from using manual locking.
Another thing that :cvb: does not guarantee is the way the VPATs are allocated. If you are using a ring buffer with N segments, a driver may either
a) allocate N VPATs and use 1 or N base pointers or…
b) use 1 VPAT and N base pointers (which is effectively the same as calculating the base pointer based on the buffer index).
With a driver that takes approach a) the VPAT modifications as described previously will work. With a driver that takes approach b) it will not and is in fact likely to lead to access violations on accessing the first and/or last buffer.
Note that it is not uncommon for a driver to take a different approach to the driver image (i.e. the image that you call G2Grab) on and the ring buffer images (i.e. the images that you access through RBGetBufferImage). For example the GenICam.vin will allocate just one VPAT it uses for the driver image, but N VPATs for the buffer images - so the described approach would work with the GenICam.vin. All the VPATs are generated just once, so any modifications made to them will persist (if e.g. the RBGetBufferImage call would generate a new VPAT each time - which would be valid behavior - the aforementioned modifications would have to be applied repetitively).
However, honestly I don’t know if all that actually helps you or whether it is just of theoretical value because - as I already pointed out - the Sherlock driver will not do any of that…
Paint.net is amazing! Having a good image is half the battle.
Thanks for the possible approach, I don’t think it’ll be directly helpfull for the issue at hand, but it is useful info anyhow. Surely, it will save me a frustrating afternoon if I have to implement something like this in the future.
It’s possible to do this with sherlock (got some help to get it working), but I’d rather have done it in the driver. But, beggers can’t be choosers; it works, albeit not as elegant as I would’ve liked.
Sherlock can be used to generate an overlap of image data. The size of the resulting image would be the size of the frame delivered by the camera and in addition the needed image lines of overlap. The size of the Sherlock image object can be easily maipulated by initializing the image object with an image file in the desired size. Beside the two image objects needed to store the input image and resulting output image a third image object is needed to buffer and delay the overlap image data.