"Get Image" method with ActiveX container

[DianeS]

Hello LabVIEW gurus,

Is it possible to use the "Get Image" method to capture the contents of an ActiveX container on the front panel of a VI?

I am using a third-party OCX to obtain a CCD image and display it on my VI's front panel.  My customer wants to do some post-processing on the image.  Rather than use the OCX to read in the image pixel by pixel, which takes an obnoxiously long time, I'd like to just grab the image as a jpeg (or bitmap), then use the picture functions in LabVIEW to convert the jpeg image back to a pixel array.  (The OCX does not have a method for grabbing the entire pixel array at once, so that's not a solution, nor does it properly export the image to any kind of standard format.  It's a bit limited.)

When I use the "Get Image" method, I find that instead of writing the image I see on the front panel, it writes a blank image.  (it does the same thing for bitmaps and png files)  I have tried changing the image depth, and background color, to no avail.

Is it simply not possible to use this method to grab an image of an ActiveX container?  Or am I just screwing this up somehow?   I've attached an image of what I see on the front panel, and an image of the code I'm using to try to perform this function.

Thanks!

d

[Coq_Rouge]

Without your exact setup it hard to say. But I tested it by using the activex version of the mediaplayer in the container, and that worked well. So your approach is correct. In the worst case you could perhaps use a a VI reference and use the Front Panel:Get Image Method. I have seen something similar not so long ago. I tried use the print screen button to take a fullscreen snapshot then I was using  divx mediaplayer. Then I pasted the picture into paint everything was OK. But then I saved the picture and opened it again. The picture was a black square

[DianeS]

I used the same code to capture images of other ActiveX objects (as you did) and the method worked fine, so clearly it's something about this particular OCX that is a problem.  Many things about this particular OCX are a problem, so I suppose I shouldn't be surprised.  😛  I guess I'll keep searching for workarounds.  I'll fool around with using a front panel image capture instead...good idea as long as I don't lose image depth or resolution.

Thanks for the reply!

[Coq_Rouge]

If the get front panel diagram method works well, you could perhaps use the "Get Image Subset VI" and select the square with the active x container. Have you also inspected  the data output from the  CCD getimage invoke node. Is it some useful data or is the data just blank.  Perhaps you can post the "image data" cluster a constant.

just some tip 🙂

[Ben]

THis seems od since there appears to be data in your image.

 

Try probing the image wire to see if you can see the top left part of your image in the probe.

Ben

[DianeS]

Well guys, the "Get Front Panel Image" method didn't work either -- it also returned a blank gray image of that ActiveX container.  I stuck some other controls and indicators on the front panel, just to see if they'd show up in the resulting image, and they did.  So it definitely appears to be something fishy about this OCX.

I put an indicator on the image array returned by that method (I also did that earlier with the "Get Image" data), and the array is the correct size and contains actual data -- it's just that the data is the 24-bit representation of the particular shade of gray that I'm seeing in my image.  So the array is not empty and it does not contain nonsense.  It appears to contain exactly what I see in my Picture indicator.  Fooling with the image depth merely causes the array to contain the 8-bit or the 4-bit representation of gray.

I tried programmatically doing a <Ctl+PrtScrn> to capture the image.  That does save the image as a .bmp that LabVIEW can work with, but it also appears to change the data enough that the post-processing code can't find a solution.

It's possible that I could use the OCX to export the pixel data as a .tif file, but I'm not sure how to process that format in LabVIEW.  And for all I know, the OCX will use some kind of funny algorithm to export it, the same way it does if I try to export a .bmp, .jpg, or .png.

I think I'm striking out here.  Drat!  Thanks for the replies, though.  I really do appreciate your trying to help!

[Coq_Rouge]

Hi

You will find a tiff tool here http://forums.lavag.org/TIFF-Reader-t10250.html

Also I am a little curious about your problem. Can you create a constant of the image data cluster, and post it here?

[DianeS]

Thanks for the link!  Much appreciated!

Here's some code for you to look at...of course, you don't have the OCX so you won't be able to run it, but I converted the image data cluster to a constant after I ran it, so you can still fool around with that. 

Thanks again for your interest and your help.  Hopefully you will immediately see something completely obvious that I'm just missing, and then I can go on to have my forehead-slapping moment.  🙂

d

[Ben]

Hi Diane,

There must be an issue with what it in the container because I was able to grab an image using the same method when using the CW 3-d graph (in an ActiveX container) without any issue.

Ben

[DianeS]

Hi Ben,

Yes, I agree...the problem is definitely with the data that's in the container.  I, too, have been able to use the "Get Image" method successfully on other types of data in ActiveX containers.  (I thought I said that in a previous post, but knowing me, maybe all I did was think it as I was typing.)  I went through and played with it fairly extensively as I was trying to figure this out.  The only time the method DIDN'T work was with ActiveX containers which contained objects from the third-party OCX that I'm using.  So I must conclude that the problem is with the OCX and not with the LabVIEW method.

Drat. 

Thanks for checking in!

Diane