09-24-2011 01:11 AM - edited 09-24-2011 01:15 AM
Hi everyone,
I'm using an AF-1501 framegrabber from MoviMed to capture real-time video. I've also synchronized an array of LEDs to the acquisition rate. Half of the LEDs are in the visible light range, and the other half are near-infrared. The LED array switches between visible and near-IR between each video frame. One image is taken under visible light, then the next is taken under near-IR light, and so on. However my images show two artifacts (see attached) that I need to remove:
1. Cross-talk (though I may be wrong on this). Part of the previous frame shows up on the current frame, and the delineation is made very clear by a boundary line going across the image. This boundary starts at the top of video and then slowly moves downward until it reaches the bottom. Then it appears at the top again, and the cycle continues. The darker of of the two halves is the the near-IR image from the previous frame.
2. Horizontal stripes that run across the image. These are present whether or not I am using the switching LED array or just regular continuous light.
I've tried increasing or decreasing frame-rate and it didn't seem to make a difference with either issue. I've also tried dropping from an 8-bit image (8 gray levels) to a 4-bit image. When I did this, I noticed that while the horizontal patterns were still there, the cross-talk issue went away. Unfortunately 8-bit resolution is a requirement, so I can't use this as a solution.
Does anybody have an idea of what the sources of these two image artifacts may be? And if so, what are some things we could try to remove them? Attached is an example screenshot.
Thanks in advance,
Alvin Chen
09-26-2011 01:58 AM
I've had this problem when I started Vision development in LabVIEW, I think there is nothing wrong with your hardware, the issue probably comes from your code, can you show it please?
How many image buffers are you using for your acquisition?
Tryin' to help
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
09-26-2011 05:21 PM
I agree that this is reminiscent of the kind of problem that would occur if you have allocated only 1 image buffer and you're acquiring images too fast. How many image buffers do you have, and approximately how often is this acquisition occurring?
As far as the horizontal lines, this may be introduced by your camera or the framegrabber itself. This question might be better addressed by the manufacturer of your camera, or by MoviMed. Any additional information you can provide would be great.
09-28-2011 11:06 AM
Thanks for the replies.
Attached are screenshots of my Acquisition and Snap VIs. If you have any questions from the pics, let me know and I'll explain what is going on. If it would be more helpful to have the entire LabView file, I can attach that, though it will require a lot of SubVIs and hardware (cRIO) to actually run.
Way it works: I have two cameras running simultaneously, from two slots of a cRIO, each with its own image buffer (this part of the code was written by the manufacturers). My modification was to create two buffers per slot (four total). Thus, I have:
IMAQ Images:
Slot 1 VIS
Slot 1 NIR
Slot 2 VIS
Slot 2 NIR
And depending on the case structure inputs, the current image will be saved into the respective buffer space. At least, this is how I'd like it to work, as my code could be wrong somewhere.
I also added a Wait command in the Acquisition_VI. I've tried putting a 1s delay in there to see if the images would clear, but had the same problems. Perhaps this isn't the place to add the delay? Currently I'm running at 10 FPS when both slots are grabbing.
Finally, for the horizontal lines, I've reached out to both the camera and framegrabber manufacturers, and I'll let you guys know what they say when they respond.
Thanks again for your time,
Alvin
09-29-2011 05:21 PM - edited 09-29-2011 05:21 PM
It seems like each time you call the "snap" function, it allocates a new image buffer. This seems to rule out the possibility of the images colliding in the same buffer. Are you saying that everything works fine when you run it at a rate of 10 frames per second?
10-05-2011 06:33 AM
Hi Kyle,
Changing the FPS did not seem to have an effect, as the break still appears every 20 or so frames. And, like before, the break will occur at the top of the image, and then gradually move downward with each successive frame until it disappears at the bottom (see attached). This occurs regardless of whether I'm at the normal acquisition rate (10 FPS) or a slower rate. EDIT: In case it is relevant, I'm changing the FPS using a Wait command in the main loop (see the "Dual_acquisition_VI.gif" attached to my previous post).
I've been probing the Snap VI and everything seems to be working correctly. It sets up 4 image buffers (Slot1 VIS, Slot1 NIR, Slot2 VIS, and Slot2 NIR). The two slots represent the two cameras. The images from each camera are allocated into their respective VIS and NIR buffers in alternating fashion with each pass through the main loop.
Is it possible that two buffers per camera aren't enough, and I need more to prevent the overlap?
If it isn't a buffer issue, what other causes do you think could be possible?
Thanks,
Alvin
10-06-2011 06:41 PM
Four image buffers should be adequate for these 4 images. It actually seems like the image being loaded into that buffer is incorrect, though. I think the best thing to do at this point would be to defer the issue to MoviMed. I can help give pointers for the best way to acquire images, but MoviMed will be able to better tell you what might be going on behind-the-scenes. I don't have access to what these functions are doing, but it seems to me that the framegrabber is passing incorrect frames into LabVIEW. Have you gotten in touch with MoviMed yet, and did they give any advice?