Legacy ImageMagick Discussions Archive

Now the options for "-intensity" have settled down, could someone do the necessary for "-list intensity" to show the list? Thanks.

Can we please remove -intensity rec601luminance rather than setting it in stone? There is really no such thing as "rec601 luminance", and certainly not one using these rec601 *luma* coefficients, which aren't intended to be applied to a *linear* RGB at all; doing so does not make sense and does not make the result a luminance or a "rec601 luminance".

Luminance is already well-defined in terms of linear RGB, and its coefficients are codified, for example, in the sRGB spec, in all of ICC color management, and in the definition of the candela as the unit of luminance in the SI standard (in effect since 1970s if I recall). This is also used in the w3c SVG spec, which in turn is used by the CSS spec, and is therefore performed correctly by default, for example, by a number of firefox addons and user scripts and user styles that invoke css to transform an image or a whole web page to grayscale.

Nobody I'm aware of has proposed a different definition or type of "luminance" using these coefficients, or even stated a preference or a reason why it would make sense to do so, when applying coefficients to *linear* RGB values.

(BTW, please keep intensity rec709luminance, though ideally one would rename it to simply luminance or cieLuminance or similar, because it correctly calculates the *luminance* Y from linear R,G, and B *if* the linear R,G,B are using the rec709 *primaries* & whitepoint; I've verified this numerically for some example values in a spreadsheet. Actually, applying -grayscale rec709luminance *directly* on a linear RGB image produces meaningless numeric values that aren't in any known colorspace, but you can apply it to an sRGB image, which it apparently converts to linear RGB as an intermediate step; -intensity rec709luminance -colorspace gray *does* work correctly for sRGB, RGB(assuming it is using rec709 primaries, as it should be at least if converted from another colorspace that uses rec709 primaries like sRGB or is independent of the primaries like XYZ), and presumably any colorspace that can be accurately converted to linear RGB(using rec709 primaries). <moreTechnicalGobbledyGook>Many or most ICC profiles for colorspaces using rec709 or rec601 primaries, e.g. PAL_SECAM or sRGB profile, explicitly contain the relationship of these colorspaces to the luminance Y because Y is a component of the CIE 1931 XYZ colorspace which is one of only two valid pcs colorspaces in terms of which everything else is defined in icc profiles. This calculation does not involve the rec601 Luma coefficients in any way, even in a correct rec601 icc profile. The "rec709 luma" *coefficients* are and were originally the linear luminance coefficients that follow uniquely from the definition of the primary chromaticities &whitept adopted by rec709 (irrespective of how they defined their gamma function or luma); they are not a matter of choice. The only reason the rec709 *luma* coefficents are numerically the same is that they were *chosen* ("arbitrarily" as the wikipedia article points out) when defining the rec709 *luma*. Luma is not a colorimetric quantity so its coefficients can indeed be be declared by anyone or by any standard by fiat. In contrast, *luminance* is a well-defined linear colorimetric/photometric quantity whose coefficients are pre-determined by the choice of primaries and whitepoint, rather than being arbitrary or subject to definition independently by a standard. There is a unique set of linear coefficients for any standard that defines a colorspace colorimetrically, which includes sRGB, XYZ, Lab, and probably any colorspace that can have a valid ICC profile.</moreTechnicalGobbledyGook>)

Perhaps more importantly than my previous post, I'm not sure why -grayscale rec709luma won't in general produce a rec709luma, and why the user has to know to make sure their image is specifically in the sRGB colorspace before they invoke this, or before they invoke *any* -grayscale operator, if they want the result to be similar to what the name implies (e.g. rec601luma, rec709luminance). In fact if you have a linear RGB colorspace image and apply -grayscale rec709luma, I'm pretty sure the result will ironically be a luminance instead of a luma, i.e. the same result as applying -grayscale rec709luminance to the sRGB version of the same image. Can somebody clarify the philosophy behind the -grayscale operator *not* in general producing what its argument name implies, unless the user restricts himself to only ever using one colorspace (sRGB)?

But what worries me even more than that is the *other* operations that are affected by the -intensity setting. If they work like the -grayscale operator, they won't produce what their name implies, unless the user only uses one colorspace (sRGB). On the other hand, if they work more like -intensity rec709luminance -colorspace gray, then that should be okay, because this construction *does* attempt to produce what the intensity name implies by transforming appropriately from the current colorspace. Can someone clarify the effect of the -intensity setting on various operations on an image when the image is in a colorspace other than sRGB? E.g. will -intensity rec709luminance actually calculate a luminance to be used in the operation, or even any linear quantity at all, as opposed to a weighted sum of a nonlinear quantity, if the current colorspace of the image happens to be RGB or Lab or XYZ or YUV etc., like -colorspace gray would?

dabrosny wrote:Can someone clarify the effect of the -intensity setting on various operations on an image when the image is in a colorspace other than sRGB? E.g. will -intensity rec709luminance actually calculate a luminance to be used in the operation, or even any linear quantity at all, as opposed to a weighted sum of a nonlinear quantity, if the current colorspace of the image happens to be RGB or Lab or XYZ or YUV etc., like -colorspace gray would?

Give me an example of some kind of process to test and what you expect for the result and I will try some tests. For example, is -resize a good function? If not, what function should I test.

fmw42 wrote:

dabrosny wrote:Can someone clarify the effect of the -intensity setting on various operations on an image when the image is in a colorspace other than sRGB? E.g. will -intensity rec709luminance actually calculate a luminance to be used in the operation, or even any linear quantity at all, as opposed to a weighted sum of a nonlinear quantity, if the current colorspace of the image happens to be RGB or Lab or XYZ or YUV etc., like -colorspace gray would?

Give me an example of some kind of process to test and what you expect for the result and I will try some tests. For example, is -resize a good function? If not, what function should I test.

I'm not sure why -resize in itself would be affected by -intensity (unless combined with other operations that are affected). The ones listed in the docs are:
-adaptive-blur
-adaptive-sharpen
-black-threshold
-clut (when mapping greyscale CLUT image to alpha channel if set by -channels)
-colors for gray colorspace
-compose {LightenIntensity, DarkenIntensity, CopyOpacity, CopyBlack}
-contrast-stretch
-distort {ErodeIntensity, DilateIntensity}
-normalize
-random-threshold
-selective-blur
-shade
-threshold
-tint
-white-threshold

It's not clear to me exactly in what way the -intensity setting is intended to affect each of these, so it's hard to make an example and say that it does what it's intended to in one colorspace and doesn't in the other. For some of the operations the colorspace may legitimately affect the result in a *different* way, other than whether the way the -intensity setting is applied reflects the name of the setting (e.g. rec709luminance involving applying something to this calculated luminance, etc.) in one colorspace but not in another.

So if someone can explain how these operations are intended to use the -intensity setting, that would be a good start.

Yes, you are right. -intensity only works on processing that converts the image to grayscale internally (or externally). Those listed functions convert the image to grayscale and then use the grayscale image to get statistics before thresholding or histogram processing.

I will try -intensity ... -threshold tomorrow as a simple case to test.

fmw42 wrote:Yes, you are right. -intensity only works on processing that converts the image to grayscale internally (or externally). Those listed functions convert the image to grayscale and then use the grayscale image to get statistics before thresholding or histogram processing.

I will try -intensity ... -threshold tomorrow as a simple case to test.

When I tried -intensity ... -white-threshold on at least one test image, the -intensity setting didn't seem to have any effect at all, so I'm not sure in what situations -intensity is intended to affect this operator and in what way.
I even tried doing -channel gray -white-threshold but still saw no effect of the -intensity setting.(edit:added)

Can anyone find documentation, or ask the person who designed or coded this feature, or reverse-engineer the code to see what it does (or to infer what it's trying to do)?

Here are some simple tests using a gradient: in 6.8.7.5 beta Q16

# create test image
Testing with -colorspace gray. These appear to be correct to me

Testing with -threshold 50%. Do these make sense. Seems to me that the third should have gamma=1
I think the gamma issue was fixed for -colorspace gray, but not for any of the other functions affected by -intensity

snibgo wrote:Now the options for "-intensity" have settled down, could someone do the necessary for "-list intensity" to show the list? Thanks.

Seems to be fixed in 6.8.7.4

fmw42 wrote:Here are some simple tests using a gradient: in 6.8.7.5 beta Q16

You're doing a lot of tests but not testing the actual effect of the -intensity setting on the resulting image (the mean of the data at least), for starters because the image is *already* grayscale.

And you can't really compare final images anyway unless you convert them all to a common colorspace (probably sRGB) at the end before comparing. Then you can see what was done the same or differently to the *image* rather than just the effects of still being in a different colorspace.

Testing with -threshold 50%. Do these make sense. Seems to me that the third should have gamma=1

fmw42 wrote: imb convert grad.png -intensity rec709luminance -threshold 50% -format "%[fx:mean] %[gamma]\n" -write info: grad_irec709luminance_t50.png
0.265624 0.45455

No, having an -intensity of rec709luminance should not change the colorspace of the image itself (nor the gamma). Anyway, -intensity changes nothing related to -threshold as far as I can tell.

Dabrosny wrote:
You're doing a lot of tests but not testing the actual effect of the -intensity setting on the resulting image (the mean of the data at least), for starters because the image is *already* grayscale.

And you can't really compare final images anyway unless you convert them all to a common colorspace (probably sRGB) at the end before comparing. Then you can see what was done the same or differently to the *image* rather than just the effects of still being in a different colorspace.

I disagree. I am not trying to compare final images. Only to find out if the data was changed and the gamma correct. Using a grayscale image is a very basic thing to start with.

Dabrosny wrote: No, having an -intensity of rec709luminance should not change the colorspace of the image itself (nor the gamma). Anyway, -intensity changes nothing related to -threshold as far as I can tell.

I disagree again. I believe it should end up with gamma=1 and that -intensity rec709luminance should convert the data to linear, which means that -threshold will process it differently. The final result should maintain the gamma=1. So I believe this is a bug.

Note that the PNG encoder consults the "intensity" setting to determine the value of gamma that it should write in a grayscale output image.

glennrp wrote:Note that the PNG encoder consults the "intensity" setting to determine the value of gamma that it should write in a grayscale output image.

It is doing that for -colorspace gray, but not the other functions that are affected by -intensity. See my other bug report. -intensity rec709luminace should be linear gamma=1. -intensity rec709luma is non-linear gamma=0.4545