Image display: origin of brightness changes?

[Grabhopser]

Hi community!

I encountered a strange problem (at least from my perspective).
I want to reduce the flicker in my camera images by computing the average pixel values and subtracting them from the respective images. This works fine as long as I handle the images as 2d (SGL) arrays and display them in an intensity graph (auto Z-scale option disabled).

However, as soon as I convert the “brightness stabilizes” 2d arrays and display them in an image display I get constant changes in the displayed image brightness. As far as I know, there is however, no auto-contrast/brightness adjustment in the image display.

Can anybody tell me the rookie mistake I made?

Many thanks!

[ng1902]

Could you post the VI(s) you're using?

Could it be that you're using the same image reference at different points in your VI? For instance if you store the image from your camera in image ref "img0", perform the brightness calculation and then store than on "img0" as well, there could be the chance that "img0" will get overwritten by the camera again.

[altenbach]

---

@Grabhopser wrote:

I get constant changes in the displayed image brightness.!

---

The term "constant changes" sounds like a contradiction 😄

I assume this is greyscale. Images are typically integers, not SGL. What is the range of your z-axis?

I wonder if if would be better to move your question to the vision forum. Let us know and we can move it.

[Grabhopser]

Thank you both for the quick reply!

Well the fact that the changes are happening is constant, but i get your point 😉

I am using a pco.pixelfly (14bit, grayscale). The raw images arrive as 2d arrays (U16), are converted to SGL (to avoid dealing with overflows etc.). Every image(array) is subtracted from then one before to get the difference image, then I apply the average subtraction and display the image as an intensity graph. 

As a comparison, the same SGL (from the intensity graph) is converted to an image and directly displayed (with non-constant shifts in the overall brightness levels compared to the intensity graph). I can exclude race conditions, as I removed everything image related from the program but the reference, the conversion.vi and the display.

When I convert the image back to a 2d array the problem disappears again....

I don't have exact numbers right now (I will get some), but assume that it is low (difference image of magnetic contrast).

I the moment I don't reall understand how the Image display maps the brightness values to image data. 

I will try to build an example.vi ....

I was unsure where to place the topic, so if you think its better placed there, then yes please move it 🙂

[Grabhopser]

I built a short example with five Frames stored inside the vi. (probably not the most efficient way, but certainly the simplest).

[ng1902 · Accepted solution]

I noticed a few things:

1. Scaling

The Intensity Graph scale is always +/-2000. However, the min/max values in the image don't necessarily reach these values. The minimum value can be as low as -2145.4, and the max can be as high as 2139.2.

When you do your scaling calculation, you take the min/max values of that image and scale it to 0-4000. Since the images have different min/max values, this means that the scaling applied to each image is different. The first image has a range of -1959.84 to 2139.2 (total range of 4099.05), and the fourth image has a range of -1761.65 to 1971.68 (total range of 37.33), but both of these images are then scaling the image to 0-4000. A pixel value of 2000 in the first image corresponds to an original of 89.7, but a pixel value of 2000 in the fourth image corresponds to an original value of 104.91.

Since the scaling factors are always changing, the appearance of the resulting image is always going to change. Try adding another intensity graph after you apply the scaling factor, when I run the VI this second Intensity graph changes apparent brightness just like the image. Also try enabling Autoscale Z on the original Camera Image, you'll see that apparent brightness changes just as the Image display does.

If you know the absolute min/max pixel values you are expecting, you should have a standard scaling factor to convert from SGL to a normalized range, and apply the same scaling factor to every image. If it's just for display, converting to U8 should be good.

2. Color Ramp / Palette

In an intensity graph, pixel values that are outside of your Z-axis range are just colored white/black. This is the reason why the brightness of the image doesn't change in the intensity graphs. For the first image, all pixels with a value of 2000 are all displayed as the same color.

With SGL images, the color palette automatically scales to the min/max values of the image. I think this is the case with U16 and I16 images as well, but I don't have much experience using them. Inconsistent value ranges doesn't effect on the intensity graph much, but has a big effect on how the image display looks.

U8 images don't have this auto-scaling, which is another good reason to display the images as U8. A value of 128 on a U8 image will always look the same, regardless of the value of the other pixels.

3. Downsampling for Display

Image Displays and Intensity Graphs apparently use different functions when determining the how to display data when the image is downsampled. I duplicated the image display and intensity graph a bunch of times and put them at different sizes. At different zoom factors, the Intensity Graph seems to get brighter, while the Image Display seems to stay the same. I wonder if the Intensity Graph picks the max pixel value in when downsampling while the image display takes the average.

Not sure if there's anything that can be done about this, other than knowing it's a thing and expecting it.

[Grabhopser]

Thank you for the detailed response! 

"U8 images don't have this auto-scaling, which is another good reason to display the images as U8. A value of 128 on a U8 image will always look the same, regardless of the value of the other pixels."

I wasn't aware of that thank you!

The problem will be to select the right Bits, containing the magnetic information.