Legacy ImageMagick Discussions Archive

Increase the contrast in an image by stretching the range of
intensity values. While doing so black-out at most black-point
pixels and white-out at most white-point pixels. Or, if percent is
used, black-out at most black-point % pixels and white-out at most
100% minus white-point% pixels.

*** wand/mogrify.c.orig	Fri Oct  3 21:34:27 2008
--- wand/mogrify.c	Sat Oct 11 00:06:51 2008
***************
*** 914,919 ****
--- 914,922 ----
              if ((flags & SigmaValue) == 0)
                white_point=(MagickRealType) (*image)->columns*(*image)->rows-
                  black_point;
+             else if ((flags & PercentValue) == 0)
+               white_point=(MagickRealType) (*image)->columns*(*image)->rows-
+                 geometry_info.sigma;
              (void) ContrastStretchImageChannel(*image,channel,black_point,
                white_point);
              InheritException(exception,&(*image)->exception);

However, -contrast-stretch 0x0 whites-out all pixels in the image I
tried to convert, not 0 as the doc leads me to expect. This is 6.4.4-3
under Mac OS X 10.4.11.

Note that 0x0 will take the min and stretch to black and the min again and stretch to white, so you will get all white

agss wrote:

Note that 0x0 will take the min and stretch to black and the min again and stretch to white, so you will get all white

Indeed, but my point was that this isn't what the documentation says it should do. It says that 0x0 will black-out at most 0 pixels, which it does, and white-out at most 0 pixels, which it doesn't.

Admittedly, 0x0 isn't the most interesting example and isn't what I tried at first. Instead, I tried something like 0x1000 expecting at most 1000 pixels to be whited-out but saw that this wasn't the case. Either the documentation is wrong is saying that white-point is the maximum number of pixels that will be whited-out (which seems to me the more useful semantics) or convert isn't behaving as documented.

Anders

agss wrote:I've constructed an example to try and figure out what the argument to -contrast-stretch actually is: an artificial image with three shades of gray in 100x100 pixel squares.

Code: Select all

convert -size 100x100 'xc:rgb(192,192,192)' \
        -bordercolor 'rgb(128,128,128)' -border 100 \
        -bordercolor 'rgb(64,64,64)' -border 100 \
        -crop 300x100+0+200 \
        test.ppm

(Possibly there's a better way to construct this?) Do -contrast-stretch 0:

Code: Select all

convert test.ppm -contrast-stretch 0 x:

The darkest gray has now gone black and the lightest one white. That's what I expected. Now, say I replace 0 by an integer black-point in percent form. For 0% through 33% the result is the same: the darkest gray goes black, the lightest goes white, the middle gray is unchanged. From 67% through 99% the two darkest grays both go black and the lightest goes white. At 100% the entire image goes black. This speaks for the black-point actually being a pixel count since one third of my image is in each shade of gray. However, I can't say I understand why the result for 34% through 66% is that the image is completely unchanged: nothing goes black or white. I would have expected the same result as for either 33% or 67%, depending on how aggressive -contrast-stretch is. (That said, doing nothing in every case arguably satisfies the documented requirements on its behaviour. :^)

I get the same results if I use a non-percent form given the fact that my image has 10000 pixels in each shade of gray: with a contrast stretch of 9999 I get black gray white; 10000 and 19999 give an unchanged image; 20000 and 29999 give black black white; 30000 gives all black.

So black-point and white-point do seem to represent pixel counts as documented but I'm still a little confused by the behaviour I see and my initial observation that a non-percentage white-point doesn't behave in the documented manner still seems to hold.

Hopefully someone can clarify matters.

Anders