How do I eliminate (minimize) display quantization with imshow?

I see extra quantization when displaying a grayscale uint8 image. For example:

inRamp = uint8 ( round ( repmat( linspace(0,60,1200), 600, 1 ) ) );
imshow ( inRamp)
imwrite ( inRamp, 'inputRamp.tif' )

If I display this tif image in another display application, I see a series of steps. The image displayed in MATLAB using imshow has a couple of steps that are double-wide and double-deep. I have verified this using Windows screen captures of the image as displayed by other software and as displayed in MATLAB. The plots of this data show a clear stairstep pattern, with the MATLAB showing a couple of steps (near pixel value 10 and 40) that are double width and double height. I can email plots to anyone interested in seeing them.

Answer 1

[Bruce Pillman]

After discussing this with Mathworks technical support, I tried changing the renderer used from "painters" to "opengl". This appears to solve the quantization problem.

Answer 2

[DGM]

I don't really know why the renderer would change it that significantly, but maybe it depends on settings or drivers I don't have. That said, I do tend to see extra bands, and it's for reasons that nobody tends to mention.

You have a single-channel image displayed with imshow(). Depending on the usage, the discrete levels in the image are mapped to the rows of a colormap. In the given usage, there are 61 graylevels, the colormap is a uniformly-spaced 256-level ramp. In this case, each unique value in the image maps to one unique row in the colormap. If you had called imshow() with a nondefault 'DisplayRange' parameter, or if you specified a different colormap (e.g. different length or nonuniform), the mapping may not be 1:1.

So your image values have been mapped to colors. They're then subject to another uniform 256-level quantization. If the colormap were not uniform, or if it were a different length, there may be subtle aliasing effects.

That much is complicated enough, and that's usually where everyone stops scratching their head, but it's not where the complication actually stops. There are still system-level and hardware-level transformations that get applied. If you have any system-level tools that allow you to manipulate display brightness/contrast/gamma, those will cause patterns in the mach bands.

Many monitors also offer similar controls which again manipulate integer data. Most monitors I've ever used come with a default "vivid" profile with absurd contrast boosting. Right from the box, they'll render everything wrong. Many LCD panels do not even actually render 8b depth. They fake it with dithering. How that's implemented is typically not disclosed, but occasionally not unnoticeable.

In my case, I have some display gamma settings dynamically set using xcalib, so I always see a geometric progression of steps in the mach bands. On my old laptop, I see extra bands because the LCD panel is a worse piece of junk than old panels made 20 years prior.

The point is that there are a number of points where the data gets quantized/remapped/transformed. It's not always MATLAB, and it's not always even fixable from within MATLAB.

[Bruce Pillman]

Thanks for additional insight.

Answer 3

[Image Analyst]

You may be observing aliasing, possibly compounded by the Mach effect. Post your plots and images to snag.gy.

[Bruce Pillman]

Thanks for the response. My ramp steps are aobut 20 pixels wide (1200 pixels, 60 code values). I'm aware of the Mach effect and expect to see bands that are about 20 pixels wide, with perhaps a +/- a pixel variation. My concern is that I see a couple of steps that are roughly 40 pixels wide.

My company blocks snag.gy and every other site I've tried in the last 10 minutes. I will explore ways I can make these example plots available to you. Do you have any other suggestions? Thanks!

[Image Analyst]

If you look at the digital numbers in the Variable Editor, are the steps that wide? Or they just appear to be but really aren't? When I ran your code, the numbers actually looked okay - no double wide bands in the actual digital numbers.

[Bruce Pillman]

The image I generated into the variable imRamp looks just fine analytically. The problem comes when I use imshow to display that image. The display appears to have a couple double-wide bands, which I confirmed by doing Windows screen captures and then reading those images and analyzing those code values. Did you do screen captures and examine those second generation images? I've asked around about making my example available to you, but haven't gotten approval yet. Sad face. Thanks for your help!

[Image Analyst]

Is your display adapter set up for 24 or 32 bits of color (16.7 million colors, true color), or less? I think windows may use some values for system colors and so might shift some colors if they would use a reserved intensity and you're using indexed color (8 or 16 bit adapter).

[Bruce Pillman]

My display control panel is set for true color (32 bits).

[Image Analyst]

I did alt-printscreen and pasted into Photoshop and then saved out as PNG. Then I read it into MATLAB and extracted a line and plotted it. The plotted line (staircase ramp) did show some random jitter of plus or minus one gray level. I don't know why.

[Bruce Pillman]

Thanks for doing that test. That is interesting, since my results don't seem random. I am running 64-bit Windows 7. What are you running?

[Image Analyst]

The same.