Legacy ImageMagick Discussions Archive

Testing IM 6.4.2-4 Q16 non-hdri on Mac OSX 10.4.11 Tiger

Convert rose to gif for testing:
convert rose: rose.gif

Get channel statistics:
convert rose.gif -separate -format "%[min]" info:
10794
6682
7453
convert rose.gif -separate -format "%[max]" info:
65535
65278
65535

Test1: Does not work fully!

convert rose.gif -contrast-stretch 0 rose_cs0.gif

convert rose_cs0.gif -separate -format "%[min]" info:
257
0
0
convert rose_cs0.gif -separate -format "%[max]" info:
65535
65535
65535

Test2: Works fine

convert rose.gif -channel rgb -contrast-stretch 0 rose_cs0.gif

convert rose_cs0.gif -separate -format "%[min]" info:
0
0
0
freds-mac-mini:~ fred$ convert rose_cs0.gif -separate -format "%[max]" info:
65535
65535
65535

In case 1, if, for some reason, the code is using the composite histogram of all channels to do the stretch, then I would expect that it should be using the smallest minimum of r,g,b and the largest maximum of r,g,b as the extremes. But it does not seem to be doing that.

Not a bug. By default the color channels are 'linked' so the error marked test is actually correct.

To get all zeros you need to stretch each channel separators.

Not a bug. By default the color channels are 'linked' so the error marked test is actually correct.

That was my first thought also, but I cannot figure out any meaningful algorithm to generate my result.

If this is not a bug, please explain the algorithm for combining the channels such that it does explain the resulting values.

As far as I can see, it is not using the min(min r,min g, min b) to make black and max(max r, max g, max b) to make white, which would make sense if it used the composite histogram from all 3 channels.

In the case above, the min(min r,min g, min b) comes from the green (6682), therefore if stretched to black, it would leave the min r and min b at higher than 0, which is not happening. Likewise, the max(max r, max g, max b) is max r = max b = 65535. Therefore the max b would end up less than 65535, but is not.

On the other hand, if the algorithm for some odd reason takes max(min r,min g, min b), which is min r = 10794, then all 3 min values would end up at 0 as the other two would be clipped at 0. Similarly, if it took the min(max r, max g, max b), which is max g = 65278, then all 3 max values would end up 65535 as the max r and max b would be clipped at 65535.

So what algorithm is producing this strange result?

It may not make pure black or pure white. It uses the MIN,MAX value from all the given color channels, then uses that to 'stretch' the contrast over all the channels. As such you will get at least one '0' value as a minimum and one 'QuantumRange' value as maximum, but not necessarily all channels 0 and all channels QuantumRange.

See my (old) examples on IM Examples, in Color Modification
http://www.imagemagick.org/Usage/color/#normalize
NOTE the warning...

Normalise is really a grayscale operator,
caution is needed when used with color images.

It only does this for the default RGB channel setting, Setting -channel ALL will also unlink the channels. The reason for the linkage is to prevent RGB color distortion when using the default settings.

Of course, as you well know, the better way would be to convert to HSL colorspace and only 'stretch' the image brightness (blue channel in HSL).

-contrast-stretch (and thus -normalize) is not the only operator that has special handling modes for the default case. -threshold is another. For the default RGB channel setting -threshold will automatically gray-scale the image first!

Anthony,

It may not make pure black or pure white. It uses the MIN,MAX value from all the given color channels, then uses that to 'stretch' the contrast over all the channels. As such you will get at least one '0' value as a minimum and one 'QuantumRange' value as maximum, but not necessarily all channels 0 and all channels QuantumRange.

If that is true, then it is not working as I tested that by looking at the min and max values from each channel and could not find any meaningful way to get that to work. I tried the min of mins and max of maxs. I tried the min of maxs and max of mins. (Read my last note carefully). I also tried the red channel. I tried to convert to intensity (gray) as the code seemed to indicate that. Then I looked at the min and max values and tried to use -level to stretch to black and white on the color image. But none of these would lead to the result I got. I tested converting rose: to 256 color gif and also to 1024 color gif as that is the max number of colors that will get a histogram. I don't know what number of colors are being used in -contrast-stretch histogram.

I understand how to do it correctly by separating channels. That is not the issue. It is trying to understand what it is doing for the default case when no channel is specified. I understand that one or two channels may not get to pure black and pure white, but the min and max values do not lead to the result I got.

Perhaps you and I should take this offline to private mail and look into it further as I am puzzled what it is doing.

Fred

P.S. what do you make of my post about histogram and miff inconsistency viewtopic.php?f=3&t=11752

It does seem to be acting strange, but then I have never been happy with -normalize or -contrast-stretch, or even -linear-stretch. I would in fact prefer them to be re-written.

The contrast-stretch is just broken in the present version. If the parameters are continuously changed, the result changes in jumps. There is no subtle problem with the algorithm, it is just a problem with number conversion or uninitialized variables.

petersteier wrote:The contrast-stretch is just broken in the present version. If the parameters are continuously changed, the result changes in jumps. There is no subtle problem with the algorithm, it is just a problem with number conversion or uninitialized variables.

Please supply your IM version and platform. Also a simple test case that the developers can use to test that it fails.