Error 1074396154 from IMAQ Write TIFF File 2 - occurs when saving from one camera, but not two

[tm473]

Hi all,

I have a program I've customized based on LabVIEW example programs (e.g. Triggered Grab, producer-consumer loops).  The VI allows the user to choose the number of cameras they'd like to use for acquisition (between 1 and 4), as well as the trigger source -- either a constant hardware counter, or a manual trigger that is wired to a digital input.

Acquisition works fine with any number of cameras (using a producer loop), however I'm running into an issue saving images in the consumer loop.  Frames are dropped during the saving process when I have the 1, 3, or 4-camera option selected.  I receive Error 1074396154: Image Is Not Large Enough for The Operation.  This issue is somewhat ameliorated by hard-coding the image size to 1280 x 1024 (as suggested here), however frame dropping is still intermittent.  I have never run into this issue using the 2-camera option.

I've attached my code here.  Does anyone have any advice on why this error would occur for only some cases?  Is there a setting I need to configure for IMAQdx?

Many thanks in advance,

Tracy

[udka · Accepted solution]

Unfortunately code is too big and can't look into each and every corner.

-Please try to use SubVIs to make code simpler : http://www.ni.com/white-paper/7593/en/

-Coming to other question, IMAQ Create(User Buffer) creates reference to image. 

-You create one image reference and copy image to that location you get from IMAQdx Grab.

->You are able to see image in Camera1 indicator?

->Use your Get image size vi after grab and inside case structure just before enqueueing and see if it's having valid image size.

-Now let's say if you get another image before you save that image, then that image will be overwritten.

-So if your writing process is too slow you should create enough user buffers.

->In your consumer loop inside case strucuture after unbundling image wire : https://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/using_the_probe_tool/

[Bob_Schor]

The Good News is that you should be capable of streaming images from multiple cameras to disk.  About 5 years ago (meaning an older version of LabVIEW, Windows, PC), we developed an application that monitored 24 subjects, looking for "events" (also monitored with 24 different sensors).  We had 24 cameras (transmitting over Ethernet) running at 30 fps, and the goal was to "capture" 5-10 second videos starting 2-3 seconds before the Event and continuing until the Event finished (another 3-4 seconds).  Needless to say, since each channel was running asynchronously, LabVIEW had to be recording 24*30=720 images per second, and we potentially had to write that many images to disk (in fact, most times only two or three cameras were "capturing an event" at the same time).  Since we were taking basically independent videos from our 24 cameras, each video went into its own file, one file per event per camera, which simplifies the File I/O.

A followup to uday's comment about Block Diagram size:  If you are trying to write "non-trivial" LabVIEW Programs, one of the most important things you should practice is Good LabVIEW Style.  The second LabVIEW book I read (about 4-5 times, cover-to-cover) when I was starting out was "The LabVIEW Style Book", by Peter Blume.

Oh, dear, after writing for at least another half hour, with lots more tips and other information, when I hit "Post", I got "Authentication Failed", and when I got back in, only this much was preserved.  So I'm going to stop here, but if I can, I'll come back and try to recreate the (rather long) additional stuff, including specific suggestions on how to proceed (warning -- somewhere in there I say "Start Over") to come up with Really Good LabVIEW Code.

Bob Schor

[tm473]

Uday and Bob -- thank you both for your helpful posts.  Always appreciate tips on LabVIEW style.  Bob, I'll look into that book; sounds like it would be great as a reference book for our lab.

I think Uday was on the right track with this:

->Use your Get image size vi after grab and inside case structure just before enqueueing and see if it's having valid image size.

-Now let's say if you get another image before you save that image, then that image will be overwritten.

-So if your writing process is too slow you should create enough user buffers.

I changed my code so that it assigns a different file name to each image that is created using IMAQ Create (e.g. "cam1im1", "cam1im2", ... "cam1im539" instead of "cam1image" for all), and I think that solved the issue of images being overwritten before they were saved from the buffer.

However, now I recall why I didn't do this when I first wrote the code: I eventually run out of memory and get this error.  So, my questions are:

(1) Do I have cause/effect correct in why I'm getting this error message?

(2) Would this be solved by prudent usage of IMAQ Dispose?  Where would you recommend placing this within the given flow (images captured in producer loop, which may or may not be fed into the consumer loop to be saved)?

I've attached the most recent version of the code -- did plenty of cleaning up but beyond this bug, would appreciate any pointed feedback on the style/organization if you feel so inclined.  I understand modularity, subVI's, etc conceptually but am the only LabVIEW programmer in our lab so rarely get exposure or feedback on actual implementation.

Thanks again,

Tracy

EDIT:  The "2cam" case of camera mode is adequate for anyone looking at this code --- the "4cam" option may appear unwieldy at first (and second) glance.

[udka]

Yes, you should dispose images reference once you are done processing(here in your case file saving) in consumer loop.

-IMAQ Create is a user created memory and the user is responsible to clear it by using IMAQ dispose at appropriate location.

-One more suggestion would be using project in labview especially when your code becomes big with multiple subvis it'll help a lot to bind together: https://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_lv_projects/

[tm473]

Thanks for the quick reply, Uday!

In the consumer loop, would this be the appropriate use of IMAQ Dispose?  The output of IMAQ Write Tiff is "Image Out (Duplicate)" so wasn't sure if this would be properly free up the memory from that specific image grab.

[udka]

-When you use IMAQ create you create an image reference with name you provide to the input image name.
- when you dequeue the image reference is passed to consumer Loop.
- when you use write function it gets the image in the respective memory location and writes to disk.
- Same way disposal works with the reference which you created by using IMAQ create.
- image out( duplicate) is reference to same original image so it will be disposed.