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

[dre99gsx]

All those methods help.  Unfortunately, I actually need to read every pixel's true information (12 bit only though).  It is interesting that if I twirl my mouse round and round just over the IMAQ display, I can essentially halt my entire program from doing anything for seconds or minutes on hand!

Any way to have windows not redraw as you've mentioned?

[JtotheB]

What information do you need to read from the pixels? There may be an easier way to go about it.

[dre99gsx]

1.  I like to display the real gray value of the pixel as the user hovers over the image.  In theory, I can just display an 8-bit version and have a separate indicator plucking out the pixel value from the image array.  Conversion from 16bit to 8bit real-time may hurt a bit in processing time...

2.  User can draw a line over features and get a real line histogram.

3.  Some images are dark and I need to use a manual-adjust pixel value to remap the pixels.  I could also do array math on the image array itself on an 8-bit converted image, but again, not sure if I will save time or not from doing this at the current frame rate.

[JtotheB]

Your suggestion for getting the true gray value from the image array is probably the best way to go. Do you get the same slowdowns if you try to use this histogram example? The most efficient way to adjust the brightness would probably be to add a control to a BCGLookup table in your acquisition while loop, rather than doing array operations.

[andyscott93]

Hi, I am having the same problem after a decade this was posted. The IMAQ image display is slowing down the whole GUI. The interesting part is that less than 20% of my CPU is in use, and almost nothing of my GPU. Hasn't LabVIEW improved the implementation of this after all these years. There is no way my lab computer can't handle that conversion from 16 bits to 8 bits in microseconds, it's just a one-decade-plus unmodified bad implementation. Sorry for mentioning the decade that has past over and over again, I'm just frustrated with this issue that I've had for so long. Is there a new way to deal with images in LabVIEW that I'm not aware about yet? Is there a way of contacting a LabVIEW employee that can address my problem?

[rolfk]

There is not a lot to improve on this. The bottleneck is in the GUI part and there is no easy (not even a complicated) way to speed that up as it is by nature single threaded, so only one CPU core can be used. Of course there might be a possibility to shave of a few percentages by doing some pre-processing in some other thread at the cost of memory consumption but it wouldn't dramatically speed up things and we don't talk of a few MB here but at least another copy of your entire image, which supposedly is rather large or you wouldn't see this behavior. Windows can't display 16 -bit color images directly, as the normal graphic drivers don't support that (and most graphic controllers neither), so for every screen update the data has to be rescaled to an 8-bit color image before it can be sent to the Windows graphics subsystem. To possibly change this more fundamentally, NI would have to completely rewrite LabVIEW to allow multithreading even in UI stuff, and you can better wait for hell freezing over than this happening again. The last LabVIEW rewrite was canceled after about 10 years of development and many many million dollars sunk into the project. And it wasn't about speeding up GUI drawing, that would just have added even more to the non-feasibility of that project.

One other workaround I recently saw myself, other than making the image that you display 8-bit rather than 16-bit, was to disable the Image Information Display (the box that shows by default under the left lower border of the image control). As long as that is visible, the loop processing the events in my application somehow gets stuck in the Call Library Node accessing my frame grabber interface, as soon as I move with the mouse over the image. I'm fairly sure the IMAQdx driver would be similarly affected, as my framegrabber interface is fully reentrant (but I can't exclude the possibility that the third party driver underneath my library somehow hooks the Windows message queue and doesn't like some tight mouse capture loop that LabVIEW might enter while moving the mouse over the image when the Image Information Display is visible). When stopping the mouse moving the loop works normal again. With the Image Information Display invisible my loop keeps running normal too, even with the mouse moving over the image area. And this was with both 8-bit and 16-bit images too.

So try to make that invisible and see if it makes any difference. If it does and you need that information you could also do your own mouse move tracking where you hook the Mouse Move event and use the location to retrieve the pixel value.

[andyscott93]

Hi rolfk. I didn't know LabVIEW works in one core. I thought when they talk about parallelizing while loops etc. they were referring to open  threads in several cores. That's a shame. 

Yes, I also noticed some time ago about the Image Information Display. Just can't understand how they have everything so poorly optimized. I haven't thought about making my own mouse move event to get the pixel intensity, I thought that would cause the same problem again.

Thanks,

Andy.