IMAQ for IEEE 1394 problem

[Ben Herzberg]

Hi.

I'm new to LV and am using version 7.0 with NI IMAQ for IEEE 1394 ver 2.0.1

I'm trying to write a front end to allow recording of a sequence of raw images captured in format 7 mode 0 (1360*1024, 12bit monochrome) from a Prosilca EC1380.

I've started based on the example for "Grab and Save to AVI" provided with the IMAQ 1394.

I'm having a few problems:

1) is there a limitation on writing frames of type 16-bit grayscale (1360*1024px) to uncompressed AVI? I get an error "Incompatible Image Type" from the IMAQ AVI write frame.vi whenever I try running in full screen 16 bit mode.

2) is there a way to make a histogram appear/disappear on button click (for interface reasons - screen real estate).

3) The property nodes seem to have little effect on the captured image. For example, I try to change the shutter speed while vi is runing and it has no effect. Anyone has any ideas?

I'm adding a screen shot of my VI.

Thanks a lot for any input.

Ben.

ADMIN EDIT: Re-attached Thumbnailed Image

Please see here for proper image attachment.

[Catweazle]

Hi Ben,

1. It think that the "IMAQ Avi write frame"-VI can

[Ben Herzberg]

Thank you very much markus.

Regarding point 1: would you suggest I store each frame in a seperate file (say tiff)? What would be a convenient way to do this? (how do I implement incremental file names?)

Thanks again.

Ben.

[Mike Ashe]

3) The property nodes seem to have little effect on the captured image. For example, I try to change the shutter speed while vi is runing and it has no effect. Anyone has any ideas?

Many attributes for some camera's cannot be changed on the fly, only before or after an acquisition.

I'm adding a screen shot of my VI.

You usually get more help, quicker, if you post the actual VI.

[Ben Herzberg]

Many attributes for some camera's cannot be changed on the fly, only before or after an acquisition.

You usually get more help, quicker, if you post the actual VI.

I haven't tried yet, but I think putting the property node inside the while loop should help. Silly me not thinking about that beforehand.

Thank you. I will put the VI in the future.

Ben.

[Catweazle]

Mike is right, you cannot change some attributes on the fly, but "easy" stuff like framerate, brightness, gain, and other "easy" stuff that is supported by your cam is possible.

Regarding 1: It depends on your application. I have an application were I just save the images in RAM (in array of images) and save them afterwards file by file in a folder. You can later display the files like a movie inside your vi or export it in a converted and compressed avi. File names for the images could be ordinary increment or e.g. millisec value when shoot was done.

markus

[Mike Ashe]

<snip> I just save the images in RAM (in array of images) and save them afterwards file by file in a folder.

Once upon a time I did something like this where we created a RAM Drive and stored the files there for processing, then only select files were copied to a physical drive. Very fast, but special circumstances.

[Ben Herzberg]

Well, I'm still trying to make this work, and I'm supposed to finish this very soon (well, I haven't been working on it full time...)

I managed to get (sort of ) what I wanted, and I'm clocking around 10FPS on a strong machine, writing each 16 bit frame onto a seperate TIFF file. This is inefficient, but the only way I could figure to capture "video" in 16-bit greyscale.

1) I'm trying to put in an ROI control, and make it work in real-time, i.e. without needing to stop and restart the VI. I get an error saying "capture already in progress" or somthing of that sort whenever I try to modify the ROI properties within the main capture loop (one grab, one write per loop).

2) I need to think up a way to enter a couple of letters so the user could choose a file name for the images, that should be VERY easy (think "with gloves on using some silly joystick insted of a mouse" easy). I was thinking an enumerated control, but these only seem to allow numeric output, and I need letters. Ideas?

Many many thanks for anyone answering.

Ben.

[crelf]

Ideas?

Show us your code.

[Ben Herzberg]

Show us your code.

Oh, right. Sorry. :-)

Download File:post-6675-1169475762.vi

[crelf]

Oh, right. Sorry.

The first you need to do is learn how to use an event structure, so that parts of your code are only called when then are needed to be called. Clean your code up into more managable chunks, and then repost it.

[Ben Herzberg]

The first you need to do is learn how to use an event structure, so that parts of your code are only called when then are needed to be called. Clean your code up into more managable chunks, and then repost it.

Well, I know I'm green. Thank you again. What parts should I put into an event structure? Also, is it a good idea to split this into sub-VIs or is this still ok?

thanks. Ben.

[crelf]

What parts should I put into an event structure?

If you learn about the event structure, the parts that need to go in there (and where they go) should become obvious. Bascially, if something changes due to a user event (eg: camera properties controlled from the FP) then you don't need to do that every time you go around the loop - put it in an event case that only executes when the FP control value changes (there's a big hint ). At the moment, you're setting the camera properties every loop which takes time, thus the loop will run slower, and, as a consquence, all the other things in there will run slower.

[Neville D]

2) I need to think up a way to enter a couple of letters so the user could choose a file name for the images, that should be VERY easy (think "with gloves on using some silly joystick insted of a mouse" easy). I was thinking an enumerated control, but these only seem to allow numeric output, and I need letters. Ideas?

Many many thanks for anyone answering.

Ben.

Ben,

use a Combo-Box control found in the String Controls subpallet. This allows output of strings as well.

Also, as Chris pointed out, use an event structure to change camera properties. Writing properties every time to the camera will definitely bog things down.

You can look at the IMAQ examples where they have the same idea going, except that they look at the value of the control. If its "changed" (compared to its prev value frm a shift register), then the control property is written to. This is a bit cruder way of doing things, but works even when you are using the code with LabVIEW RT (which doesn't support the event structure).

Sorry, I cant modify your VI, I have LV 8.2, Imaq 3.x on my PC.

Neville.

[Ben Herzberg]

If you learn about the event structure, the parts that need to go in there (and where they go) should become obvious. Bascially, if something changes due to a user event (eg: camera properties controlled from the FP) then you don't need to do that every time you go around the loop - put it in an event case that only executes when the FP control value changes (there's a big hint ). At the moment, you're setting the camera properties every loop which takes time, thus the loop will run slower, and, as a consquence, all the other things in there will run slower.

I think my problems are sorted now, thanks to your advice. I'm posting my current version of the VI, just in case anyone feels like commenting and pointing out some of my mistakes, the number of which is probably very large.

Thank you all very much once more.

Ben.

Download File:post-6675-1169492814.vi

[Ben Herzberg]

I think my problems are sorted now, thanks to your advice. I'm posting my current version of the VI, just in case anyone feels like commenting and pointing out some of my mistakes, the number of which is probably very large.

Thank you all very much once more.

Ben.

Also, I'm getting 10 FPS (with full frame) while the added time I get from the "Profile VI" tool only adds up to 50ms, which should get me 20FPS, as far as I understand. Can anyone perhaps see what I am missing?

Thank you.

Added: Profile VI output.

Download File:post-6675-1169540509.txt