Hi,
The design goal is to insert the last sub-image into the next frame.
But I don't know exactly how to configure the buffer.
Please give me some advice.
Thanks.
Jesse Lin
Hi,
The design goal is to insert the last sub-image into the next frame.
But I don't know exactly how to configure the buffer.
Please give me some advice.
Thanks.
Jesse Lin
Hi Jesse,
if you just want to insert the previous image above the current image, I would go for a more simple approach. Just double the input image in front of the InsertIamge and remove the first image in the second path. A buffer is needed in the first path while waiting for the insertion of path two.
But I'm not sure if this is the answer to your question, since you have some modulo counts with divisor 15 or 16 in your design that I don't understand. So, if my approach doesn't fit your task, please give me some feedback with more details.
Best regards,
Oliver
Hi,
you can find the solution for removing unwanted deadlock as a screenshot below and design here: mE5MA_VCL_Overlap_fixBRudde.va
Since InsertImage will only forward on a single channel, the others are in wait (blocked, inhibit, stop, ...) state and require buffering, cause by all channels being sourced by the same M-Type: "Sync" in here.
So the RAM1 needs to be in fron of module 13.
Please be aware that a following image is required to run the second (lower) channel of "module26".
Best regards,
Björn
Hi Jesse,
Please be aware that a following image is required to run the second (lower) channel of "module26".
Taken from:
https://docs.baslerweb.com/liv…nization.InsertImage.html
"The operator InsertImage multiplexes a number of n input links I[0] .. I[n-1] into the output link O. Thus the operator outputs the input images of all inputs in sequential order at O.
The operator forwards the input images to the output one after the other. First, input link I[0] is processed, next link I[1]. After link I[n-1] the operator starts with the next image at I[0] again etc. The operator waits until an image at a currently selected input is present. Therefore it is not possible to skip inputs."...
Best regards,
Björn
Hi Björn Rudde
Therefore it is not possible to skip inputs."...
This is helpful information.
And I try to use other methods to remove unwanted frames ,but the buffer will overflow. Camera line rate = 10k Hz.
Please give me some advice.
Thanks.
Hi Jesse Lin,
Thank you for your feedback.
And I try to use other methods to remove unwanted frames ,but the buffer will overflow. Camera line rate = 10k Hz.
Please give me some advice.
Based on your input the line width is 8k = 8192 pixels per line and you can see a FillLevel at a linerate of 10 kHz of 75%.
A certain FillLevel is OK, but we need to look into it based on the resulting/required bandwidth.
One possible bottle-neck is the parallelism within the links, and especially:
The CXP camera interface is focussing up to 2 GB/s:
Since you nearly double the bandwidth due to the overlap, please consider to use a higher(up to double) paralleism in the links.
The DMA will accept a connection of up to 16x 8 bit = theoretical 2 GB/s, practically it will be limited to 1800 MB/s.
The memory interface can handle up to 11.2 GB/s (shared between all RAM-modules) and read/write access will add up.
When I look into your design I would recommend the approach below to generate an overlap on basis of a single RAM:
That would save RAM modules/FPGA ressources and you do not need to write the same data twice...
Related VA design: LineScan_OverlappingAreaImages.va
Based on the ROI settings within BufferX2 you can reduce the overlapping part easily...
I have seen that you use a more complex approach on when to overlap, but that is something you can adopt into this design.
Just consider using DynamicROI operator if you require a more dynamic approach into the above functionality.
ImageBufferMultiROIdyn would be a second valid candidate.
Enjoy.
Best regards,
Hi Jesse Lin,
Related VA design: LineScan_OverlappingAreaImages.va
Based on my above posts you can use:calulations-made-easy-and-google-is-a-friend
thread for getting bandwidth details caluclated.
Best regards,
Hi Björn Rudde
Thank for your support that let me learn something.
The VA design LineScan_OverlappingAreaImages.va saves a lot of buffer resources.
Hi Oliver
Thank for your approach.
We find a better way without InsertImage that can reduce the consideration of synchronization.
You can refer this design LineScan_OverlappingAreaImages_simulation.va and simulation it.
Hope it will be helpful to your future application.
Jesse
Hi Oliver and Jesse,
It was a pleasure to discuss the VA design approach with both of you.
One additional hint:
One application would be auto-follow of a certain region of image.
Best regards,