Legacy ImageMagick Discussions Archive

IM 6.8.2.5 Q16 Mac OSX Snow Leopard

-threshold may have a colorspace issue that does not appear in -black-threshold or -white-threshold

These shows the threshold more like at 50% rather than the specified 25%
convert -size 1x500 gradient: -rotate 90 -depth 8 -threshold 25% -scale 500x50! show:
convert -size 1x500 gradient:"white-black" -rotate 90 -depth 8 -threshold 25% -scale 500x50! show:


These work fine:
convert -size 1x500 gradient: -rotate 90 -depth 8 -black-threshold 25% -scale 500x50! show:
convert -size 1x500 gradient:"gray(255)-gray(0)" -rotate 90 -depth 8 -threshold 25% -scale 500x50! show:

In 6.7.9 on Windows 7, I get the same results: "-threshold 25%" actually thresholds at about 50%. However, I think this is a natural consequence of IM's handling of colorspace.

I have pointed out before that "-set colorspace RGB" is needed before operators such as "-threshold", "-equalize" and "-contrast-stretch" to get the results we might expect.

Your image is sRGB, however, the gamma function is removed before it is thresholded. If your gradient was grayscale you would get the expected results.

Yes. All of Fred's examples contain only gray colours, but only the last one -- gradient:"gray(255)-gray(0)" -- is recognised by IM as "grayscale".

Why does it recognise this as grayscale, but not the others? I don't know. But in every case, "-set colorspace RGB" prevents the removal of gamma.

And I don't know why "-black-threshold" doesn't need "-set colorspace RGB".

magick wrote:Your image is sRGB, however, the gamma function is removed before it is thresholded. If your gradient was grayscale you would get the expected results.

Yes, using gradient:"gray(255)-gray(0)" worked fine as I showed.

But why does it work fine for gradient: with -black-threshold and -white-threshold?

Does threshold actually deal with colorspace. It shouldn't. It should threshold the image in whatever colorspace the image is in. Doing anything else to me is nonsensical.

Most likely the other two thresholds does no colorspace changes, just as -threshold should.

This is a case where handing IM doing something that is visually correct is wrong. threshold is a mathematical operatator and needs to treat images as such.

The threshold value is compared to the pixel intensity of each pixel. To compute the pixel intensity the gamma must first be removed per Lindbloom:

• Another relevant fact is that these weightings must be made in a linear RGB space, that is, after the gamma companding function has been removed. It is very common to see the weightings applied bluntly to the companded RGB values, which is wrong.

If we threshold individual channels (red, green, blue), colorspace is not considered, a simple comparison of the pixel value against the threshold is all that is required. However, if we threshold against the pixel intensity, the gamma function must be removed to properly return the correct intensity for a RGB triple.

Okay. so it would use a 'grayscaling' function that I have proposed to be a option provided to the user.

Two options. one setting the greyscaling method to be used by other operators, and another just directly using the method function to grayscale an image.
-define greyscaling {method}
-greyscaling {method}

EG: the proposed grayscaling method would be used by quite a number of operators and users can set it to use

intensity -- includes colorspace
Rec601Luma -- includes colorspace
some specific channel -- colorspace ignored
average (R+G+B)/3 -- colorpace ignored
squared (R^2+G^2+B^2)/3
vector sqrt( (R^2+G^2+B^2)/3 )
and some methods that include 'alpha scaled colors'

Note that in this scheme, Rec601Luma is NOT a colorspace, it is a grayscaling method!
The last few are more for mathematical conversions, especially of difference images (image comparing)

The -greyscale operator will leave alpha as-is, so resulting images may be in GreyscaleAlpha colorspace appropriate for user define alpha handling.

Options that would use the define include:
[*] -threshold* functions (when no channel is defined),
[*] -clut,
[*] -compose CopyOpacity (when source image has no alpha)
[*] -compose CopyBlack (when source image has no black channel - IE it is NOT CMYK - currently not done)
[*] -compose LightenIntensity and DarkenIntensity,
[*] Morpology Intensity methods,
[*] and probably many other operators, that need a grayscale value as part of there working, rather than a color.

See my script color2gray for what I have done.
http://www.fmwconcepts.com/imagemagick/ ... /index.php

my rms is your vector

Note that average is just the first channel of OHTA.

Note that Rec601Luma is just the normal grayscale. You probably want to add Rec709Luma (formula)

Other common definitions (possibly included in Anthony's list):

max(R,G,B)
(min(R,G,B) + max(R,G,B)) / 2
0.298839*R + 0.586811*G + 0.114350*B
0.21260*R + 0.71520*G + 0.07220B
Perhaps user-defined factors for R,G and B. (It's a convenient way to simulate putting a coloured filter in front of a camera lens when using B&W film.)

I assume you would always do this calculation from RGB space. If the image is sRGB, you would first convert to RGB.

snibgo wrote:max(R,G,B)
(min(R,G,B) + max(R,G,B)) / 2
0.298839*R + 0.586811*G + 0.114350*B
0.21260*R + 0.71520*G + 0.07220B

FYI (though perhaps you know this):

The first is just Brightness from HSB
The second is Lightness from HSL
The third is grayscale, intensity, Rec601Luma, Y from YUV, etc, and L from HCL (they all use the same formula)
The fourth is Rec709Luma

see
http://www.imagemagick.org/script/comma ... colorspace

Though I believe that Anthony simply wants to use these formula to convert to grayscale in other routines or a new function or define.

Specifying RGB weights would require parameters, which would be nice, but probably not what he wants to do at this point.

The only new one in Anthony's list is the vector or rms average, which I found works quite well.

Yup.

It would be convenient to have a way of specifying which "convert to gray" formula will be used in the variety of operations. I hope "-set colorspace RGB" (or equivalent) will be available for those times that IM thinks the image is sRGB but I know it isn't.

As two of the formulae already involve weights, allowing the user to specify them might add no cost at execution time but provide a very useful flexibility.

Look for the -intensity method option in the next point release of ImageMagick. The methods include Rec601Luma, Rec709Luma, Brightness, Lightness, RMS, and average.

So is -intensity a operator, or a setting, or is it both (which should never be the case!)

Setting.