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.
possible bug in -contrast-stretch 0 in IM 6.4.2-4
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
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.
To get all zeros you need to stretch each channel separators.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
That was my first thought also, but I cannot figure out any meaningful algorithm to generate my result.Not a bug. By default the color channels are 'linked' so the error marked test is actually correct.
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?
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
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...
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!
See my (old) examples on IM Examples, in Color Modification
http://www.imagemagick.org/Usage/color/#normalize
NOTE the warning...
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.Normalise is really a grayscale operator,
caution is needed when used with color images.
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 Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
Anthony,
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
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.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.
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
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
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.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
-
- Posts: 2
- Joined: 2016-07-23T00:59:42-07:00
- Authentication code: 1151
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
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.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug in -contrast-stretch 0 in IM 6.4.2-4
Please supply your IM version and platform. Also a simple test case that the developers can use to test that it fails.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.