Why do overlays take so much longer on single-precision grayscale images

[comrade]

Hello,

I've come across a rather curious problem. In a visual inspection machine we create some 8-bit 16MPixel images. These are then computed into single-precision images. After image processing we display some kinds of result images to the user. Here the user can use the mouse over the image display and gets a reading for the current image sector where the mouse is currently positioned. If the displayed image is U8 or RGB everything is fine.

However, if the display holds one of the 32bit grayscale images things become quite slow, by a factor of 5 to 10 approximately. Now I can see that 32 bit is quite a bit larger than 8bit, so I would assume an increase in overlay time by a maximum factor of 4.

Since the images are quite big, one update takes about 90-100ms with the 32bit image, whereas the same action requires hardly more than 10 to 20 ms with U8 and even RGB. Because the mouse movement is caught by an event structure all movements are processed and finally queuing up to cause a lock of the software until all those events are dealt with. This leads to ridiculously long "freeze" times of the software, sometimes as long as 20 sec, as I witnessed via an event log a implemented for this purpose.

Attached is an example code which shows the unusually long processing time for overlays on SGL-images. If there is any suggestion I'd be happy to read them. Thanks in advance.

Falk

[mkais]

Hi comrade.

I saw in your VIs, a Path, did you use a special Sample for this Issue?

Can you send us also the Images that you use and the Steps to reproduce this Issue?

i will try it with my System and tell you the results.

Best regards

[comrade]

In order to reproduce the behaviour no special image is needed. Take any 8bit picture you like, the larger the better, as the absolute difference in computation time will be greater.

I attached a random example picture in 8Bit PNG format. Feel free to resample to 16MP 😉

[comrade]

Forgot the steps for reproducing the behaviour.

Load the image and see how long the overlay update takes in 8 Bit
switch to single precision representation and again check the time it take for the overlay to build.

Notice the difference being somewhat between factor 5 and 10. This is best recognisable on larger images where there is a significant drag of the overlay trailing behind the mouse arrow

[comrade · Accepted solution]

After an in-depth discussion with the German NI support we figured out that it is not mainly the Overlay action that's consuming the time but rather my image display update after every event action. As my goal was to provide the user with the most current image information available as close to the mouse position as possible there doesn't seem another way to do this while not compromising the goal I explained.

Several alternative ideas we had (some don't work though) are briefly explained below:

1. Use the tip strip property instead of creating an overlay
• PRO: ultra fast response since no image display update is required, easy to implement
• CONs: Tip strip remains stationary, takes a while to show up, requires the user to stay on one spot of the image display for some time, strip vanishes unpredictably (in my test) and reappears only after leaving and reentering the image display plus again keeping the mouse still for a couple of seconds
2. Use an extra (classic style) string indicator to display the desired text at the desired position
• PRO: also very fast
• CON: kind of a hassle to code, as it involves the correct calculation of the desired position of the string indicator using the positions of the frontpanel window, the image display indicator and the mouse position. Actually not difficult I expect, but nothing you do with your mind on your dinner...You'll need a bunch of different types references here to acquire the necessary position properties from VI window, Image display indicator and mouse
3. Like 2 but without moving the indicator
• PRO: fast and easy to implement
• CON: not as user-friendly since the indicator is stationary somewhere around the image display and not at the mouse position.
4. copy/typecast the SGL image into an U8 image and proceed with the overlays
• PRO: response is improved to the level I was used to
• CON: "problem" with image display update remains and so increases the response time the larger the image gets
5. Use the Image Information String property instead of creating an overlay
• PRO: would be as fast as 1., since no image display update required
• k.o.-CON: The property seems to be Read-Only, so no user defined alteration of the text is possible

I guess my choice will be 2.

If anyone has other ideas about this I'll still be glad to hear about them.

[ADagli]

Dear comrade,

thank you very much for the close and constructive cooperation.

Best regards,