[Proposed docs for "-intensity" now in thread for approval.] When converting a grayscale image to color...

[Dabrosny]

Storing the same data, or metadata, in multiple places isn't a good idea. What happens when the multiple values disagree with each other?

Pixel values may represent linear data, or not. This information is currently represented by metadata (a) colorspace, (b) gamma and (c) profile. Fairly recently we now have (d) intensity. Yikes. Four places!

I couldn't agree more.

Dabrosny asks: How should I flag a grayscale image as linear? It's a fair question.

I would add the converse question: When IM has an image in memory, what metadata tells me whether it is linear?

I'll add an important condition: the answer to the questions should not depend on whether the image happens to be grayscale. The image might have come from anywhere, or it might have been created as part of an IM command or program. Colourfullness is independent of linearity. Whether an image has one channel or three, and whether the three RGB channels happen to contain the same values or not, the data can be linear or non-linear.

If the answers do depend on whether the image happens to be grayscale, that raises difficulties about when the metadata is updated. Does this happen automatically, internally within IM? Whenever a pixel is updated in memory, does IM have to check whether the gray/colour status has changed so it can update the linear flag? That would be absurd. Or do we have to add this to all our scripts, to check whether each created file happens to be grayscale so we can set the metadata correctly? Also absurd.

So I conclude that a four-valued colorspace ("linear-colour", "non-linear-colour", "linear-gray", "non-linear-gray") is a bad idea, and would be a bad answer to either question.

I'd be fine with not having separate grayscale colorspaces, so long as it was clear what the colorspace means when there happens to be a single channel. For example if a single-channel image has what I would call a "nonhomogeneous" colorspace such as Luv, Lab, or LCh, how should we interpret that channel? For LChuv or LCHab, we could interpret it as, L, C, or H, which mean completely different things; in fact H is a hue angle ("linear" I suppose) and not compatible at all with being treated like L (a nonlinear luminance but not the same as the sRGB nonlinearity). If we going to truly support single-channel colorspaces corresponding to these, we'd probably want to start with "Lab_L" or "Luv_L" (if they're different -- I forget).

But I'm happy to ignore those "advanced" colorspaces for the moment and focus on homogeneous colorspaces like RGB and sRGB, where all three channels can be treated in a similar way and all have the same [non]linearity.

I agree that if a single channel image has colorspace RGB or sRGB then it should be treated like a linear or nonlinear(sRGB-like) grayscale image.
I'm not sure if we should completely do away with grayscale colorspaces, because that would be a huge change (of mindset for one thing), but I understand that this would have benefits in terms of simplicity.

(If other colorspace-aware image software uses this scheme, I'd like to know how it is managed. What software sets the value of the colorspace?)

I don't want to go too far on this question, but as far as I know, a colorspace, or at least an ICC profile, would normally specify the number of channels and the interpretation of each channel. Usually defining each channel in terms of transformations in relation, ultimately, to XYZ (or possibly Lab). In the case of a single-channel colorspace or color profile like adobe's sGray.icc, that single channel's interpretation would probably be defined in terms of the linear luminance Y in CIE XYZ (could be L in Lab but I doubt it).

It follows for example from the formulas relating linear RGB and XYZ (CIE) that when you transform RGB to linear luminance Y, if you then replicate Y into three channels you can call it a linear RGB image and the transformation back to Y will indeed preserve the value of Y in round trip.
A linear RGB image having R=G=B literally represents the same image as a linear grayscale image with linear luminance ("Y" of XYZ if you like) having that same value, which means that if either of those images is transformed into a "reference" colorspace like XYZ or Lab, the result will literally be identical.
[edit: in this paragraph i corrected linear vs nonlinear]
Similarly, an sRGB image having three identical channels literally represents the same image as a nonlinear "sGray" image (same as what's stored in true single-channel jpeg) having that same value in its single channel.


I understand that you want to take advantage of relationships like this to use the same RGB and sRGB colorspaces to identify a grayscale image, understanding that they are the same as the multichannel images that you get by replicating the single channel.

The original "source" of of an image sets the colorspace or profile to one that matches the number of channels in the image.

I don't claim IM's current scheme is good. It isn't. But I don't want to make a bad situation worse.
...
"How should I flag a grayscale image as linear?" Answer: the same way as for a colour image, use "-set colorspace RGB". I advise not to use "-intensity" except for specific operations, and unset it afterwards.

Okay, but you will have to remember to -set colorspace RGB manually every time after you do "-grayscale rec709luminance: or "-intensity rec709luminance -colorspace gray", unless we modify these operations to do so for you.

"When IM has an image in memory, what metadata tells me whether it is linear?" Check the colorspace. If it is RGB or sRGB, that answers the question. If it is "gray", then examine the gamma. If it is or isn't 1.0, that answers the question.

As far as I know, these methods work. If they don't, that's a bug.

This doesn't work in general currently. In the simple case of an image that was created by "-intensity rec709luminance -colorspace gray" (or -grayscale rec709luminance), it makes no difference to IM what you might set the grayscale image's gamma to -- the interpretation of that grayscale image when you do something like -colorspace sRGB (including implicitly when writing to jpeg) will depend solely on the current intensity setting on that image (which will have been set by the grayscale operation to indicate linear or nonlinear), which is apparently by design. The result of -colorspace sRGB is completely unaffected by the gamma setting on the grayscale image.

[fmw42]

A linear RGB image having R=G=B literally represents the same image as an sGray

I do not agree with that. There are many ways to convert a color image to grayscale and any or all may be useful as desired by the user for different circumstances. See my script, color2gray, http://www.fmwconcepts.com/imagemagick/ ... /index.php, which shows only non-linear variations. Linear variations are also possible, typically from rec709luminance or -colorspace RGB and recombining channels.

But I note that for (non-linear) sgray, I used your method that you discussed a year or so ago to create it.

Code: Select all

convert color.png -colorspace sRGB -intensity rec709luminance -colorspace gray -set colorspace RGB -colorspace sRGB sgray.png

Perhaps I misunderstand and you want a linear sgray.

[snibgo]

Yes, a linearity flag strictly has at least three values: "linear", "non-linear" or "not applicable", and perhaps "unknown". The concept of linearity only applies when the channel measures an additive quantity of light, which is not true of the a* or b* channels of Lab, for example.

(Of course, a related concept applies to subtractive quantities of light, as in CMYK.)

Yes, I'd like metadata for single-channel images to say what the channel represents. This would enhance "-separate" and "-combine", making them less dependent on the order of images, and capable of warning when we accidently combine L* with a* and a* again.

Yes, if software uses profiles to define channels, that takes care of the problem. Or, at least, it transfers the problem to the profile management software.

I understand that you want to take advantage of relationships like this to use the same RGB and sRGB colorspaces to identify a grayscale image ...

It's not exactly what I want, but I think it makes the most sense unless we re-define the concept of colorspaces. One problem with the current scheme is that colorspace and profile can contradict each other. An image encoded as AdobeRGB will have colorspace metadata of "sRGB", but the image isn't sRGB.

Okay, but you will have to remember to -set colorspace RGB manually every time after you do "-grayscale rec709luminance: or "-intensity rec709luminance -colorspace gray", unless we modify these operations to do so for you.

Yes, indeed. I note that "-grayscale rec709luminance" and the other three all leave the gamma unchanged at 0.454545. In my opinion, the conversions to luma should set gamma to 1.0. But they do set the intensity settings.

Perhaps IM is moving away from the use of gamma, towards the use of intensity settings. I don't know.

[Dabrosny]

A linear RGB image having R=G=B literally represents the same image as an sGray

I do not agree with that.

My mistake, I should have said that a linear RGB image having R=G=B literally represents the same image as an linear grayscale image with linear luminance ("Y" of XYZ if you like) having that same value.
Or that an sRGB image having R'=G'=B' literally represents the same image as a nonlinear "sGray" image having that same value in its single channel.

[fmw42]

A linear RGB image having R=G=B literally represents the same image as an sGray

I do not agree with that.

My mistake, I should have said that a linear RGB image having R=G=B literally represents the same image as an linear grayscale image with linear luminance ("Y" of XYZ if you like) having that same value.
Or that an sRGB image having R'=G'=B' literally represents the same image as a nonlinear "sGray" image having that same value in its single channel.

Great! We agree.

[Dabrosny]

I note that "-grayscale rec709luminance" and the other three all leave the gamma unchanged at 0.454545. In my opinion, the conversions to luma should set gamma to 1.0. But they do set the intensity settings.

Perhaps IM is moving away from the use of gamma, towards the use of intensity settings. I don't know.

IM didn't move from gamma to intensity -- rather it moved from multiple grayscale colorspaces to intensities instead.

Internally, IM generally uses colorspaces (except Gray) to define what the numbers mean, not the gamma value. When you transform to a different colorspace it ignores the current gamma and it usually resets it to the value consistent with the target colorspace.
Presumably it did the same for the linear and nonlinear grayscale colorspaces, back in the days when these existed.
These grayscale colorspaces were abandoned and combined into the single Gray colorspace, but the intensity property was introduced as a replacement for the multiple grayscale colorspaces.

The thinking seemed to be that there was a proliferation of grayscale colorspaces, and it would be better instead to replace them all by "Gray" and move this grayscale managerie into something separate (the intensity).

As far as I can tell, nothing was gained by moving this colorspace info into "intensity" (for only grayscale images), and a lot of simplicity, consistency, predictability, and completeness was lost. There are many operations that are affected by colorspace, and only some of them were re-implemented for "intensity".

For example, how do we directly convert a linear grayscale image to a nonlinear grayscale image or vice-versa? This was easy when there were multiple grayscale colorspaces. Now you need a workaround involving converting to a color image, transforming, and then converting back to grayscale. This is because we have "-intensity" which is the equivalent of the "-set colorspace" operation, but we have no equivalent for the "-colorspace" operation that would operate on a grayscale image to convert between linear and nonlinear grayscale.

And how do we tag a raw grayscale image that we've created as linear or nonlinear, when this use of "intensity" is undocumented?

And then there's reading and writing various file formats when the IM image and/or the file is grayscale, only some combinations of which are handled correctly with respect to the intensity setting, others propagate or use the gamma setting instead and ignore intensity, and others simply don't work, or they don't work for intensities other than the default (nonlinear) or in combination with colorspaces other than the default (sRGB).

A better solution would have been to do away with those multiple grayscale colorspaces in favor of just two: one linear and one nonlinear.
Then the various intensities would have merely specified a particular color-to-gray operation, and after applying any of them, the grayscale image is either in the nonlinear or linear colorspace -- it no longer matters which coefficients (rec709, 601, or anything else) were used when creating the image!

It makes no sense that there would ever need to be more grayscale colorspaces than corresponding color (multichannel) colorspaces.
Grayscale images are simpler, not more complex!
There was a misunderstanding in thinking that just because there were multiple ways of converting from color to grayscale, there would need to be just as many grayscale colorspaces. Similarly, there are many ways of creating a linear RGB image, but we certainly don't need more than one such colorspace just because we create them in different ways.
Colorspace isn't about the details of how an image was created, but rather just how it should currently be interpreted and ultimately displayed.

[fmw42]

I note that "-grayscale rec709luminance" and the other three all leave the gamma unchanged at 0.454545

On my Mac OSX Sierra in IM 6.9.9.9 and 7.0.6.9, I get results for all saved miff images that have gamma=1

Code: Select all

convert rose: -grayscale Rec709luminance -write rosegray.miff -separate  rosegrayRGBseparated.miff
convert rosegrayRGBseparated.miff rosegrayRGBseparated.miff rosegrayRGBseparated.miff -set colorspace RGB -combine roseRGBseparated_combined.miff

Code: Select all

magick rose: -grayscale Rec709luminance -write rosegray.miff -separate  rosegrayRGBseparated.miff
magick rosegrayRGBseparated.miff rosegrayRGBseparated.miff rosegrayRGBseparated.miff -set colorspace RGB -combine roseRGBseparated_combined.miff

Perhaps you need to upgrade; otherwise, there is an issue with Windows versions of IM in this regard.

[Dabrosny]

Fred, what would you think about the idea of something being added to the current documentation of "-intensity" just to at least state the fact that it tags the resulting Gray image as linear or nonlinear (so that IM knows how to correctly convert it back to a non-Gray colorspace)? I'd even be willing to write a first draft of a couple of sentences.

[fmw42]

I would be able to modify the documentation. Feel free to write a draft. But I am not sure I understand. The only way it "tags" the image as linear if via the gamma for external formats. With MIFF, you can look at the header to see if it linear or not, as I recall.

[Dabrosny]

I would be able to modify the documentation. Feel free to write a draft.

Okay, will do.

But I am not sure I understand. The only way it "tags" the image as linear if via the gamma for external formats. With MIFF, you can look at the header to see if it linear or not, as I recall.

Okay, I did some more tests and here's what I found. When a Gray image is converted using -colorspace sRGB, the Gray image is always treated as sRGB-nonlinear-grayscale (simply replicated into three channels and labeled as sRGB), except when the current intensity setting on the Gray image is rec709luminance (or rec601luminance) and the current gamma setting on the Gray image is exactly 1.0.

Here's the evidence with 15 different combinations of intensity and gamma. Note that the only time that the mean numeric value changes is in the very last case, which is with both rec709luminance and gamma=1.0. Even gamma=0.99 had the same effect as gamma=.2 -- the only thing that mattered was whether or not it was 1.0 in combination with a linear intensity. All the resulting output images look the same as the original input image except 'myrosesgray-intensity rec709luminance_gamma1.jpg' which is lighter because the original grayscale image is being treated as linear and therefore the data gets nonlinearized by IM when converted to sRGB.

This behavior should be reproducible on any Gray image, but if you want to reproduce my exact numeric results you could get myrosesgray.jpg from my original post in this thread.

We should probably document this behavior (unless this behavior were to be considered a bug and fixed, in which case I'm not certain what the new behavior would be).

Code: Select all

$ magick -verbose myrosesgray.jpg +intensity -set gamma Undefined -identify -colorspace sRGB -identify myrosesgray+intensity_gammaUndefined.jpg | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Intensity: Undefined; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545;      Intensity: Undefined;

Code: Select all

$ magick -verbose myrosesgray.jpg +intensity -set gamma 0.2 -identify -colorspace sRGB -identify myrosesgray+intensity_gamma0.2.jpg | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.2;      Intensity: Undefined; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Undefined;

Code: Select all

$ magick -verbose myrosesgray.jpg +intensity -set gamma 0.454545 -identify -colorspace sRGB -identify myrosesgray+intensity_gamma0.454545.jpg | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Undefined; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Undefined;

Code: Select all

$ magick -verbose myrosesgray.jpg +intensity -set gamma 0.99 -identify -colorspace sRGB -identify myrosesgray+intensity_gamma0.99.jpg | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.99;     Intensity: Undefined; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Undefined;

Code: Select all

$ magick -verbose myrosesgray.jpg +intensity -set gamma 1 -identify -colorspace sRGB -identify myrosesgray+intensity_gamma1.jpg | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 1;        Intensity: Undefined; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Undefined;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luma -set gamma Undefined -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luma_gammaUndefined.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Intensity: Rec709Luma; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545;       Intensity: Rec709Luma;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luma -set gamma 0.2 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luma_gamma0.2.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.2;      Intensity: Rec709Luma; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luma;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luma -set gamma 0.454545 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luma_gamma0.454545.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luma; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luma;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luma -set gamma 0.99 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luma_gamma0.99.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.99;     Intensity: Rec709Luma; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luma;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luma -set gamma 1 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luma_gamma1.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 1;        Intensity: Rec709Luma; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luma;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luminance -set gamma Undefined -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luminance_gammaUndefined.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Intensity: Rec709Luminance; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545;            Intensity: Rec709Luminance;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luminance -set gamma 0.2 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luminance_gamma0.2.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.2;      Intensity: Rec709Luminance; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luminance;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luminance -set gamma 0.454545 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luminance_gamma0.454545.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luminance; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luminance;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luminance -set gamma 0.99 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luminance_gamma0.99.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973); Gamma: 0.99;     Intensity: Rec709Luminance; 
Colorspace: sRGB; mean: 109.581 (0.42973); Gamma: 0.454545; Intensity: Rec709Luminance;

Code: Select all

$ magick -verbose myrosesgray.jpg -intensity rec709luminance -set gamma 1 -identify -colorspace sRGB -identify 'myrosesgray-intensity rec709luminance_gamma1.jpg' | myformatting
Colorspace: Gray; mean: 109.581 (0.42973);  Gamma: 1;        Intensity: Rec709Luminance; 
Colorspace: sRGB; mean: 171.145 (0.671156); Gamma: 0.454545; Intensity: Rec709Luminance;

[fmw42]

try these commands and then open the miff files in a text editor and see how they show colorspace, type, pixel-intensity and gamma.

Code: Select all

convert rose: -colorspace gray rose_nl1.miff

convert rose: -grayscale rec709luma rose_nl2.miff

convert rose: -grayscale rec709luminance rose_l1.miff

convert rose: -colorspace gray -colorspace RGB rose_l2.miff

convert rose: -colorspace gray -set colorspace RGB rose_l3.miff

The last one is probably not proper, since it is non-linear but I overrode the gamma to 1 by using -set colorspace RGB and not -colorspace RGB. So l2 will display as linear, but l3 will display as non-linear.

This points out Imagemagick's philosophy. IM's philosophy is to give the user control, so that if they know what they want they can achieve it. IM does not want to force only one standard behavior on the user. But if they do not know commands well enough they could get unexpected things.

[Dabrosny]

So l2 will display as linear, but l3 will display as non-linear.

I'm not sure precisely how you're defining "display as linear" (gamma=1? colorspace=RGB? intensity=rec*luminance? behavior of im display app?), but what I'm most interested in is how an image "displays" after IM has converted it to any universal format like jpeg, since a jpeg should "display" the same in any viewing software.

As far as I know, IM internally treats an "sRGB" image as nonlinear irrespective of gamma, and an "RGB" image as linear irrespective of gamma.
And as my previous post showed, it internally treats a Gray image as nonlinear (in the sRGB sense) in all cases except when it has both gamma=1.00 and intensity=rec*luminance.
If this is indeed its behavior then I think it should be documented so we are all aware of this.

[fmw42]

My point is that most external format do not keep track of linear vs non-linear and many do not even store the gamma. I simply wanted to show that internally, IM keeps track of that. Once it is written to other formats, all bets are off. In fact, JPG does not keep track of gamma and assumes non-linear colors/gray or so I am told.

[Dabrosny]

My point is that most external format do not keep track of linear vs non-linear and many do not even store the gamma. I simply wanted to show that internally, IM keeps track of that.

Absolutely, and IM is very good at keeping track of that metadata.
I just want to make sure we know what the expected results are when IM interprets and uses that metadata itself.

Once it is written to other formats, all bets are off.

Fortunately, IM is pretty good at simply transforming the image data into a colorspace that can be unambiguously represented in the target format, and then most bets are back on

In fact, JPG does not keep track of gamma and assumes non-linear colors/gray or so I am told.

True, jpeg is always considered nonlinear, specifically sRGB, regardless of whether it's color or single-channel grayscale -- there's no ambiguity. AFAIK, IM correctly transforms any image in any colorspace to sRGB in order to write it to jpeg, just as it should. It will do the same with Gray images, so long as they are correctly identified internally, which apparently means that if they are in fact linear then they must have both gamma=1.0 and intensity=rec*luminance in order to be correctly treated as such and thus get "delinearized" by IM to sRGB in order to write to jpeg; otherwise Gray images are assumed to already be nonlinear "sRGB Grayscale" and could be written directly to jpeg as-is.

If I do draft a bit of text for the documentation, should I PM it to you, or post it here?

[fmw42]

If I do draft a bit of text for the documentation, should I PM it to you, or post it here?

I think it would be best to post it here and let others comment or add to it before I insert it into the documentation. I would want to get approval anyway to be sure the IM developers agree with what you provide.