02-15-2018 12:09 PM
Greetings all,
I've done a couple projects now with actor framework and video acquisition, but I haven't settled on what I think is the "best" way to move a captured frame of video from one actor to another. I was wondering if anyone had any opinions on what the best way is. I've used the actor framework messaging to pass IMAQ frame references and that seems to work fine. I know that using the framework messaging for data acquisition is usually frowned upon, but I figure that most frame rates with the video I'm working with is 30-60hz, and that should be OK for the actor messaging infrastructure. I do a IMAQ copy though before sending the frame so I don't overwrite the frame on the next acquisition.
The actor system i'm looking at is something like this:
acq actor -> processing actor -> upper level actor
Where the acq actor is acquiring frames of video as fast as it can. The "->" is a framework message to the processing actor (using no-coupling messaging). The processing actor would do some sort of image processing to the video and then the processed video (or results) would be sent to an application level actor which displays it to the user.
Would this scheme benefit from some form of buffering between stages? Should I be using notifiers/queues between actors to pass video? Just wondering if anyone has any experience.
Thanks!
02-15-2018 12:48 PM
As long as the actors keep up, passing data via the built in messaging is fine. There is a limit though, and it depends on the size of you data set per message, the message rate, what other messages those actors are handling, and what else is going on in the system. There's no hard rule about how many messages you can send.
I use actors to acquire medium sized data sets at medium rates (and I have several going on at once). I opted to use basic queues to send raw data sets from the acquisition actor to the processing actor and then again to the logging actor because I found the system wasn't able to keep up with the incoming data when passing the data with messages. I had to cut out as much middle man as possible. That said, I still like using the actors because it encapsulates well each of the functions (for reuse) as well as provides a way to manage each process (update settings, scales, and so on) on the fly.
I do however use messages to transmit my reduced data, results, redline trips, CVT updates, and other things to the main app.
02-19-2018 05:41 AM
I work with images in a big laser laboratory. My architecture is:
IMAQdx Camera Actor -> Display Actor -> Analysis Actor -> User Application Actor.
My users want to see each image from the camera, but not each image must be processed.
First I started with AF messaging and without loss of images, but if the processing rate of analyse actor was lower as image acquisition rate, I got message overflow. Because users can define own analysis classes, I could not guaranty quick enough processing. So I was enforced to outsource the image processing from actor message loop in a parallel loop in actor core. When analysis actor receives a "new image" message it creates a copy of the image and sends a notification to the loop. The processing runs still so fast as possible, but without blocking of AF message loop.