Interpreting data from Bumblebee Stereo Camera (PointGrey)?

[Lost And Found]

Hi, first to note that I have read the discussion at http://forums.ni.com/ni/board/message?board.id=200&message.id=11236

I'm able to access the above stereo camera through my CVS just fine (using IMAQdx) and configure it through MAX. I'm also able to access either of the cameras individually using the Pan option in MAX (I believe I could configure this on-the-fly programmatically, but I'll leave that for another time, less important currently.

This is based on the information from PointGrey Research Inc. at http://www.ptgrey.com/support/kb/index.asp?a=4&q=312&ST=bumblebee

The same page also shows that if I setup the Bumblebee Stereo Camera to use Format_7 Mode 3, the resulting 16-bit image contains 8-bits from the left camera and 8-bits from the right camera. I have verified (I think) that this is the case, since when I run a grab in MAX with that mode, I am able to 'white-out' the display from the right camera by covering the LEFT camera. And no, this camera doesn't do light-balancing or any such, as confirmed by covering the right camera.

My question, then, is how do I extract such data? A simple data manipulation question, I believe, but I'm stumped. For now I understand I probably can't do it using the IMAQ VIs, would it be necessary to have a for loop go through the binary bits and separate them? What about the additional image info, how will I know what to NOT separate?

So, conclusion, I have an Image data-type wire containing a 16-bit image, and I'd like to separate that into 2 8-bit images based on the above.

[Lost And Found · Accepted solution]

Based on advice from the camera's manufacturers, I have successfully extracted the appropriate data, but now have a new problem, which I will submit as a new thread.

For the record, I used the IMAQdx Get Image Data VI to extract the raw image data (16-bit uint) and split the resulting array with Decimate 1D Array to two arrays, resizing them to the appropriate 2D array size (640x480 for my case).

[BruceAmmons]

There is another way you could do it that might be easier.

There is a vi "IMAQ Cast Image" that converts a 16 bit image to an 8 bit image.  You can make it shift the image a fixed number of bits.  To get the first image, you convert with a shift of 0.  For the second image, use a shift of 8.  Just make sure you are using different images for the source and target images.

Another improvement to your existing method would be using Split Number to convert the U16 array to two U8 arrays.  It would maintain the array structures and just separate the high and low bytes.

Bruce

[Lost And Found]

Thanks Bruce, I will try your first method when I get into the office. However, the fact that that's an IMAQ VI leads me to believe that its unavailable for the CVS.

And as for the second method, the raw data returned from Get Image Data is always 8-bit, therefore decimate 1D array makes more sense than split number (which I tried previously.

[BruceAmmons]

I think you are assuming a lot of routines are not available on the CVS when they really should be.  I haven't worked with a CVS so I am not sure, but there must be a way to get most of these functions to work on it.  I know you can't acquire images using IMAQ drivers, but I don't think that excludes the large number of IMAQ routines available.

I would probably get the image returned instead of the raw data, then try to split it using the first method.  For the second method, I thought you were using ImageToArray since I didn't read your message completely.

Bruce

[Lost And Found]

Sorry, I have actually tried loading it to the CVS prior to this and received errors about imaq.dll not existing on the CVS. I should have said as much.

Whether this means it is not possible (my searches on the interweb seem to indicate this) or that I just don't know how to do it, I'm not sure. From my perspective, it would of course look the same either way. It seems to me any methods which load from imaq.dll do not work on the CVS. Given that these include not just acquisition methods but also conversion and other routines, I'd consider this a design problem, if true.

EDIT: This link was what gave me this impression http://forums.ni.com/ni/board/message?board.id=200&thread.id=10831

I'm not sure if it would be possible for me to just copy imaq.dll from my machine to the appropriate location in the CVS?

Message Edited by Lost And Found on 10-29-2009 10:54 PM

[BruceAmmons]

Most of the RT targets give you the option of installing different drivers.  I think you do this through MAX.  You might want to try installing any vision or IMAQ related drivers on the CVS, and see if that works.  This is usually a better approach than blindly copying files to the RT system.

Other than that, I don't know what will or won't work on a CVS.  Can somebody with more CVS experience chime in?

Bruce

[Lost And Found]

I previously checked that, just in case I checked it again. The only software I have which is not installed is Modbus I/O Server, NI-Simulation Interface Toolkit, Network Variable Engine, and Variable Client Support for Labview RT.

I have NI Vision RT, NI-1394 External Drive Support, NI-IMAQ I/O, NI-IMAQ Server, NI-IMAQ for IEEE 1394 RT, and IN-IMAQdx RT which are IMAQ related. It certainly seems to me that IMAQ isn't included in this list because IMAQdx/IMAQ-1394 is the ones needed for firewire (which is the interface the CVS has) but through some oversight or conscious decision the IMAQdx dll does not expose the same functionality in all situations as the IMAQ dll.