01-26-2016 09:20 AM
This is my first real attempt at using the NI Vision suite (2014). So you'd think I would have picked something a bit simpler. Of course not. And what I'm about to describe is only steps A & B out of a huge undertaking. You'll probably see me around here more often. Anyway...
I'm attempting to perform object tracking on a large AVI file in post-processing. Interesting fact: I've already discovered that I needed to use the older versions of the AVI handler functions becuse the AVI read frame VI has a 2GB size limit. The object tracking in and of itself functions. I also have set up a progress bar at the bottom of the video on the front pannel. If you're unsure what I'm talking about- think of that red line at the bottom of a Youtube video that you can drag to different frames to get to what ever time you want to start watching. This, independant of the object tracking, also works. However, if I use the progress bar (drag it to a different frame) while the object is being tracked, my program will loose the object.
My suspicion is that this occors because the object tracking depends on information from the previous frame to find the object in the subsequent frame. Perhaps it expects the object to be near it's previous location and defines the ROI to search to be near that area? I would think a better way to track an object that has the potential to jump anywhere in the frame (as it could if I move the progress bar) would be to define the ROI as the entire frame. This is just my speculation as I don't have a very complete understanding.
Unfortunately, I cannot legally upload my code because of where I work. Fortuately I can piece together what I've done based on a couple of examples that are open-source and avialable thanks to NI.
The Progress bar is set up to work as in this post:
http://forums.ni.com/t5/LabVIEW/video-scrub-bar/td-p/3242642
And the obect tracking works almost exactly like the Object Tracking.vi example for LabVIEW 2014. The only changes I made were to replace the new AVI2 functions with the old AVI functions so that I could handle a 60GB AVI file. Also, I needed to add an IMAQ Clear Overlay function before the IMAQ Overlay Multiple Lines 2 function becuase somewhere allong the way, the overlay boxes started to hang around instead of dissappearing like they were supposed to. It may have been a feature of the new functions to delete them automatically. Not sure.
01-27-2016 10:00 AM
Grasshopper,
You nailed it:
My suspicion is that this occors because the object tracking depends on information from the previous frame to find the object in the subsequent frame. Perhaps it expects the object to be near it's previous location and defines the ROI to search to be near that area? I would think a better way to track an object that has the potential to jump anywhere in the frame (as it could if I move the progress bar) would be to define the ROI as the entire frame. This is just my speculation as I don't have a very complete understanding.
It absolutely relies on the previous frame data to find the next occurence by using either the Mean Shift or EM-based Mean Shift algorithms. A high level explanation of exactly what that means can be found in the Vision Concepts Manual, as well as a low level explanation of the math behind it.
Looking at the code you linked, it appears that it jumps to the selected frame directly; the only way to make a scrub bar work would be to still load and process each image sequentially during the transition. Depending on proccessor speed and image complexity, this might be reasonable but it would largely depend on how much lag is acceptable.
With regards to the overlay functions you describe, I don't have an immediate answer for that. Changing the AVI functions shouldn't have any effect, so my guess is that there is something else going on. It sounds like you have a solution, but if you want to dig deeper we could do so.
01-27-2016 10:31 AM
So I need to load and process each image sequentially during the transition... but somehow do it faster than the rate at which the video would normally play... and I'm not concerned about displaying the image while this occurs (actually I'd prefer NOT to display the image while this occurs to give the illusion that it's not occurring at all). The speed needs to be limited only by the CPU or GPU (Whatever's faster) of my computer during this process. Thankfully my workplace has some pretty kick ass computers even though my issued laptop isn't one of them. So I won't bother to test it out on the actual 60GB files until I turn it into an executable and run it on those. Also the rest of the process that occurs later will depend on the user to have paused the video before it collects some data so if there is some lag it shouldn't affect that process.
Now the only question is how.... What jumps to mind without too much in-depth though so far is event structures. I need to handle the regular operation of the VI and the background operation when the scrub bar is moved until it catches up to the jumped-to frame. I'm not exactly sure how to speed up the operation of my while loop. Obviously I could take out the delay features but beyond that?
In regards to the overlay functions, as you stated, I have a solution and I'm not concerned. I simply found it curious.
01-27-2016 02:50 PM
I haven't looked at the examples you mentioned, but from what you've posted, you need to split the image processing and image display into seperate loops
01-29-2016 08:56 AM
@Grasshoper wrote:
Now the only question is how.... What jumps to mind without too much in-depth though so far is event structures. I need to handle the regular operation of the VI and the background operation when the scrub bar is moved until it catches up to the jumped-to frame. I'm not exactly sure how to speed up the operation of my while loop. Obviously I could take out the delay features but beyond that?
I haven't put a lot of in-depth thought in to this either, but I think you're right that an event structure might be useful here. Maybe you could use the timeout case for playback timing and then some kind of loop inside another event that will keep running until the actual frame count matches the scrubber location.
01-29-2016 09:01 AM
That is exactly what I attempted to do. My only issue now, from what I can tell, is that I can't seem to get the event with the other loop in it (the one not meant for playback) to run fast enough to catch up. I don't know what I can do to get a while loop to run faster than normal execution.
01-29-2016 10:00 AM
Assuming you don't have any loop timing in the "catch up" loop, you might just be hitting processor limitations. Can you post a snippet or image of your code?