IMAQ WindDisplayMapping...for Vision Image Display Control?

The IMAQ WindDisplayMapping operates on an IMAQ window display. Is there an equivalent fx that will operate on the Vision Image Display Indicator that can be placed on LabVIEW front panel? (Or do I need to code up the equivalent fx?)
Thanks,
Don

Use a property node and select 16 bit image mapping. You can create a control for this or whatever you need. If you select the individual elements, you can get enumerated controls.
Bruce
Bruce Ammons
Ammons Engineering

Similar Messages

Using IMAQ Image Display control vs IMAQ WindDraw for large image files

Hello All;
I am designing an application that is currently using IMAQ Image Display control to view large images (5K x 3K and larger). My problem is that these images take 10-20 seconds to load and display, whereas if I use IMAQ WindDraw to display my image in a separate window, it only takes a couple of seconds. My application is designed such that I am making use of the Subpanels in LabVIEW 8.0, and to make it pleasant for the user, the interface is such that my line profile, histograph and image viewer displays are contained within the same GUI (panel).
I read the National Instruments application note regarding displaying of large images, and it did not seem to make a difference. For example, I switched the 'modern' IMAQ Image Display control with the classic Image Display control, since the 'classic' does not contain any of the 3D rendering tools which might slow the process down.
Why is there such a huge difference in loading times if I am trying to do exactly the same thing with both methods? How can I bring the IMAQ Image Display control up to the same speed as the IMAQ WindDraw tool?
I am currently using LabVIEW 8.0 with the latest IMAQ/NI Vision package from NI (IMAQ v7.1?). Thanks.
DJH

Use a property node and select 16 bit image mapping. You can create a control for this or whatever you need. If you select the individual elements, you can get enumerated controls.
Bruce
Bruce Ammons
Ammons Engineering

Any way for one VI to dynamically update images shown in another VI's Image Display control?

I've just discovered (in LV v7.0) that, while I can wire to it, I cannot write image data to a "value" input terminal of a property node associated with an Image Display. When the VI runs I get this error:
"IMAQ Vision: (Hex 0xBFF6051A) The Image Display control does not support writing this property node."
(I must admit that I have to wonder why we are allowed to wire to it, if all it does is generate this error)
Is there any way for one VI to dynamically update images shown in another VI's Image Display control?
I am not interested in using IMAQWindDraw windows.

OK, I have found one way to simultaneously access one VI's image data within another VI without the use of globals. I don't know if it makes use of a known feature of image data that will be with us forever or if it is a bug that will disappear sometime in the future...
It seems that if I create an image data stream in one VI using IMAQ CREATE and name the data stream "ABC" and then create an image data stream in another VI using IMAQ CREATE and also name that data stream "ABC" then in fact they are both the same data streams and they can be read or written by either VI.
Using this feature I can write the common data stream in one VI and using a shared occurrence or semaphore let the other VI know when it is OK to display the data from the common stream.
This method requires that the displaying VI needs to have a while loop around the image display which is not nearly as simple as a display that is updated automagically by another VI writing to a VALUE input that is referenced back to the Image Display. I'd still like to know if there is some way to make that work.
One corollary to this is that if you have several image data streams in use in a system (they can be in totally separate VI's, running independently) and you don't want them tromping on each other's image data then you need to make sure that they (the image data streams) get created with different names. An example of a place where this might bite you (and where I discovered this "feature") is to have multiple copies of the same VI with different names to do image acquisition and display from multiple cameras. Being copies of the same VI, they all had the same image data stream names, defined as constants, within them. When they were run simultaneously, the image data from all of the multiple cameras randomly appeared in all of the image displays. I don't know if this feature would hold up if the separate VI's were turned into separate executables and then run. Do any of you know if this sharing of image data streams with common names works across executables running on the same machine?

Imaq Image Display Control - Zoom tool - zoom factor changes slowly

Hi at all,
we have a strange behavior with the zoom factor of the Image Display Control in an Labview executable.
Ususally by clicking into the image with the zoom tool activated, the zoom factor changes from 1,2,4,8,16, ... ("x2")
Now we have one PC, where it changes from 1,2,3,4,5,... ("+1")
Has anyone an idea on which windows setting this behavior depends on? The PC runs with Windows XP SP3, the LV-Exe was built
with LabVIEW 8.5.1 and the Vision Development Module 8.5.0. Is there any regsitry setting where I can adjust the "click intensity" or
something like that? Or can I set a property of the image control to force a specific behavior?
Actually I have never seen this behavior before, I only know the half/double mode.
In the software the operator has to search for fiducials on PCBs what means he has to click several times into the image.
Changing in the Mode "+1" instead of "x2" is not acceptable for him.
Thanks for your help!
Stefan

Hello Stefan,
thank you for posting at the National Instruments forum. The "Zoom Behaviour" was changed due to customer requests. I totally agree with you, that it is not the best solution to click 24-times to get the desired region of interest.
I created a small example for LabVIEW 2010, which uses a property node and event structure, to perform the zoom programmatically.
Best regards
MarianO
Attachments:
Calculate Zoomfactor.vi ‏21 KB
Image Example.vi ‏63 KB

When I buid an application, the vision image display is black.

Hello !
I have made an application using "vision image display". I have labview 7 express and vision builder 6.0. On labview, my application run very well and my image is displayed.
I create an application with application builder 7 and I run it on a client computer with labview runtime engine 7.0 and IMAQ Vision 6.0 run-time engine. And my image is never displayed but stay black.
Why ?

Hello,
I have a few questions concerning the problem. Where does the image come from, is it read in or is it from the harddisk. When the image is read in, which hardware do you use? I think you taked off the lens aperture and checked the contrast!? Check if the "vision image display" is correct licensed. Which Version is used from the "vision image display"? You can also check, when there is used any hardware if the drivers are the same on both systems. The current version is 2.6. With your answers, we should get a solution for the problem.
ThomasD

Image display control scrolling does not work properly when zoomed in

I am using a ROI on an image in the image display control. When zooming into the image to fine-adjust the positioning of the ROI, the image scrolling does not work properly. As far as I understand, the image should scroll automatically when the ROI is leaving the visible area. However, the scrolling behaviour seems to depend on the origin of the Labview panel, not the origin of the image display control, which might require to move the ROI way out of the visible area before the scrolling takes place. In other words: the coordinate system of the image display control is shifted with respect to the true visible image area, depending on where you place it on the front panel. As a consequence, when clicking on a ROI which is in the visible area, but is outside of what Labview thinks is the visible area, it might immediately jump to the left border of the image, making the positioning of the ROI really difficult.
Has anyone noticed this behaviour, and what would be a reliable solution to avoid this?
Dirk

Hello,
no, I am not talking about the tools palette. Just place an image control with some image in it on a new VI front panel. Then, use the rectangle from the tools and select a ROI in the image. If you zoom in (using the magnification glass), and then grab the ROI and move it around, the image scroll with the ROI. So far, so good. If you now place the image control elsewhere on the panel, or add new control above it, resize the panel, etc. , this scrolling when moving the ROI will not work correctly if the origin (0,0) of the panel is far away from the image control.
I have attached a VI for simplicity (although there is hardly any code in it).
If you make a ROI and try to move it down, you will notice that scrolling starts if you move the mouse out to about 10cms below the image (depens on your screen, of course). After that, if you click on the ROI, the scroll bars and ROI might jump up to the upper end of the image. Imagine how annoying this is if you try to finely adjust the ROI position.
I think it is a bug in the implementation of the image display control.
Thanks,
Dirk
Attachments:
scrolling.vi ‏818 KB

The IMAQ-Vision image display function seems to use two processors automatically

Because the IMAQ-Vision function to display an image was slow for large images I wrote my own routine using the Windows SDK and it was much faster.
However, now that the application has been moved to a dual processor PC the opposite is true, i.e. the application runs much faster if I use the IMAQ-Vision function. Inspection reveals that this is due to equal loading on the two processors, whereas if I use my SDK routine all the load is on the first processor.
Is there some explanation for this? Do the IMAQ-Vision routines have built in multi-threading?

Sir,
Naturally, the IMAQ Vision display function does use multi-threading. Whether it uses the second CPU for this thread is operating system dependant.

Can a Vision image display's "zoom to fit" action be seen by an event structure?

The "Image Display" indicator from the "Vision" palette has a right-click (context) menu option of "Zoom to Fit".
Is there any way to capture the selection/execution of this action with an event structure?

I don't believe there is a way to do this with an event structure. However, there is an image window property node for the zoom to fit option. You can wire the output boolean into the input of a case structure and execute a different set of code depending on whether or not the zoom to fit option is selected. This should give you the same functionality as an event structure. Please let me know if you have any further questions.
Regards,
Chris L
Applications Engineer
National Instruments
Certified LabVIEW Associate Developer

Vision: Image Display within TypeDef breaks palette update

Came across it while debugging my vision application, where I need to display different representations of various bounding rectangles cropped from a large image. So I created a TypeDef with an array of ImageDisplays along with the bounding rectangle coordinates.
While using it I noticed that the palette update (runtime menu on inmage display->palette) within the image display array didn't work. When explicitly setting the palette via property node on the array element, everything is fine. Also, when disconnecting the cluster containing the image display array and the bounding rectangle array from said TypeDef, the paletteupdate via runtime menu works again. Now, the TypeDef is non-strict. So I wonder this is intended behaviour or a bug?
I've attached an example showing the different behaviour of with and without TypeDef.
Attachments:
TestChangePaletteMain.llb ‏114 KB

Is it possible to explain a bit more about why your are of this opinion? With a strict TypeDef I'd agree, but it's a non-strict one here. Therefore I'm not aware of a reason why this should be intended.

How can I implement IMAQ correlation for 16bit image?

Hi
When using IMAQ correlate. vi in Machine vision Filter catergory, the vi only works for 8 bit source and template image case.
16 bit source image case makes error.
But I need 16 bit source image without losing image information, I want to use full 16 bit image correlation with 8 bit template.
How can I implement the code in labview?
Need help.
Many thanks.

Unfortunately you can't do so.
There are some functions in the Vision Lib that only accept 8bit images. In order to use them you have to convert your image to an 8bit Image.
Keep in mind that converting an Image to 8bit will not necessary result in a loss of data. Check your Images, it might be that you are not using the full range of a 16bit value. you might be able to use a mixture of dynamic shifting and bit shifting in order to convert an image to an 8 bit, then embedding these criterias in the image and use them to convert back to a 16bit at a later time without losing any data, or in most cases minimal precision loss.
If you would like to attach one of the images you are using, I can take a look at it to see if this is possible in your case.
Good luck,
Dan,
www.movimed.com - Custom Imaging Solutions

Labview IMAQ VI for capturing images and saving with incremental file names

Hello,
I am using LabView 7.1(IMAQ) to capture images with NI's PCI 1426 card, and a JAI CV-M2 camera. Now, with the example VI's like LL Grab, or LL Sequence, or Snap and Save to File.vi, I can capture the images. But what I actually want is to capture images continuously and keep saving them with a sequentially incrementing file name.
I have tried to modify the Snap and Save to File.vi by adding a 'for loop', so as to run this for required number of images. This works okay, but I can't really change the file name after every image. However, I'm not confident with this method either. I think it would be better to use the buffer itself, as is given in LL Grab.vi and somehow save images from the buffer. I think this would be faster ?
In any case, any ideas as to how I should go about implementing auto-incrementing of the file name ?
Any help will do.
Thanks.
- Prashant

Hi,
Thanks a lot for replying.
I tried using this in the VI i was working with, but using the "build path" vi doesnt seem to work. If I use just the base path from user's input, it works, but then again it keeps overwriting the images into one file rather than giving each file a new name. I'm attaching the vi.
Please take a look and tell me where i'm going wrong.
Thanks again.
Attachments:
LL Sequence_mod.vi ‏62 KB

Why does moving the mouse over an IMAQ image display slow the GUI down so much?

I have a large application with several vi's running simultaneously under labview 8.6.1. When I mouse over an image display control in one of the vi's, everything slows down a shocking amount in all the other vi's. The windows task manager does not show a large increase in CPU use. My pc is has a quad cpu with 4GB of RAM, and the CPU and memory loads do not appear to be terribly taxing to the system. However, many of my vi's apparently come almost to a standstill if I just move the mouse in a circle around my image control.
This looks like it is largely a GUI display issue. If I make a new vi and put a while loop in it that only displays the iteration loop number to an indicator, I can see the iterating occurring, then stopping totally when I mouse inside the image display control. When I stop moving the mouse inside the control, or when I move it outside the control, the interation loop number jumps up, as if it had been incrementing behind the scenes the whole time. So only display of the interating was halted.
This problem occurs even if the vi with the image control is not executing. If the vi with the image control is open but not running, and I mouse over the image on it, the other guis all come to a screeching halt.
Does mousing in the image display control really utterly crush all other guis in all other labview windows? Is this an issue inherent to the image display control? If so, is there anything I can do about this?
Also, this issue is not entirely limited to display. I started looking at it in greater detail because this issue also exposed what I think is a race condition in my code. I have a vi that acquires an image from a ccd and puts it into an IMAQ image.ctl. This image then gets passed up to a vi up the call chain, and is put on a queue and sent over to be de-queued by a vi that has the image display control. Here's the kicker: when I mouse over the image display control, the image successfully gets acquired inside the subvi, and if I probe the wire leading to the output IMAQ image display.ctl, I see the image. If I simultaneously probe the wire coming out of the subvi one level up the call chain, the image gets lost about half the time. This only happens if I am mousing in the image display control IN A TOTALLY DIFFERENT AND SEPARATE VI. If I bump up the priority of the ccd image acquisition vi to 'highest priority', the problem only happens about 1% of the time, and I really have to mouse around to make it happen. Still, it's disturbing that mousing in the GUI in one window results in a failure of a separate subvi to simply pass an image up the call chain. I understand that IMAQ images are referenced rather than passed by value, but I don't see why there should be a failure to pass the image up the call chain. I've looked for a race condition, but can't find one.
Eric

I have finally been able to replicate the behavior that you are seeing on another computer once the image was large enough. Here are a few notes about this behavior:
First. The UI only slows down when the images are large, 16 bit images. The reason why this is unique to 16 bit images is that they can only be displayed on the front panel as 8 bit images. The workaround that Weiyuan suggested to change the 16 bit display mapping hints towards the root of the problem...that any time a mouse runs over the indicator, Windows asks the entire image to re-draw (having a separate indicator overlapping the image will create the same behavior). With a 16 bit image, not only does the image have to re-draw on the screen but the 16 bit pixels need to be mapped to 8 bits. When setting the 16 bit display mapping to Full Dynamic, this requires mor computation/pixel than 90% dynamic or one of the other mapping schemes.
This is expected behavior if your program is running and you're trying to display a large 16 bit image. To fix this behavior there are a couple options:
Change the 16 bit display mapping to something other than full dynamic. You can choose which 8 bits to display or if you want to map the bits.
Resize the image just for viewing purposes on your front panel (since you aren't going to view every single pixel of you image on the screen). You can use the IMAQ Resample.vi to do this. This will allow you to take your 1500x1500 pixel image and only display a 500x500 pixel version.
If you are interested in viewing small details of the large image, consider just displaying a smaller region of interest at a time.
Let me know if any of these solutions work for you. Good luck on your application.
Zach C.
Field Engineer
Greater Los Angeles

How do you change the location of a small image within an IMAQ image display?

I have an image that exactly fills the display. But then I want to extract a portion of the image and display that small piece, but have it be in the same location as it was before, not centered in the display (essentially I want to crop the image but leave it in the same location). I tried the 'Image Center Position' property node for the image display, but is resets itself to the center of the display. Can anyone offer any suggestions?
Thanks,
Marty
Attachments:
Crop_Pic_Test.vi ‏102 KB

Marty_M wrote:
I have an image that exactly fills the display. But then I want to extract a portion of the image and display that small piece, but have it be in the same location as it was before, not centered in the display (essentially I want to crop the image but leave it in the same location). I tried the 'Image Center Position' property node for the image display, but is resets itself to the center of the display. Can anyone offer any suggestions?
You misused the Image Center position property : it works only on images larger than the display area. Have a look at the simplified version of your sample vi.
One way to achieve your objective will be to create a black (or white) background image, with the same size as the original image and to paste the small piece over this BG.
Happy New Wires
CC
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Crop_Pic_Test[2].zip ‏22 KB

Tips for a better Looping image display?

I have a rather simple and large (file size) image display
here for a website in sacramento:
www.norcaldesigns.com/cLandscapes
the image loop is just one image that moves on the timeline
and returns to frame one at the end. I would love some advice or
links to examples of better ideas for looping image display.
Thanks!
-Jesse

Assuming that this is a valid concept (sorry, as a user I
find it quite annoying and dizzying after awhile), one of the
approaches to speed it up in the beginning - split the image into
several ones and load them one by one or in groups so that first
few to show load, naturally, first. Then you will need to append
them to the strip.
It would be much more scalable to keep the reference to the
images in an XML so that should you remove or add images -
everything is done in the XML and you don't have to recompile every
time.
Also, I would set a higher frame rate (around 30fps) -
animation looks a bit jerky.
If the presentation of many images is important - perhaps
another type of transition should be considered (not scrolling but,
say, blending via alphas or something). In addition to the movement
being dizzying, there is very little time to appreciate the
images.

How to programmatically control the Image display size

I wonder if
it is possible to let the Vi adapt the size of the VISION image display if the
user zooms in the displayed picture (as can be done in other graphical software
like Photoshop or ImageI). Is there something prepared?

If you are using LV 7.1, there is a property node that let you define the size of the image display.
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Image size.vi ‏64 KB

IMAQ WindDisplayMapping...for Vision Image Display Control?

Similar Messages

Maybe you are looking for