linear gray images are transformed incorrectly to "other" colorspaces

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
Dabrosny
Posts: 111
Joined: 2013-10-02T10:49:39-07:00
Authentication code: 6789
Location: New York, US

linear gray images are transformed incorrectly to "other" colorspaces

Post by Dabrosny »

When performing "-colorspace RGB" on a linear (gamma=1) Gray image, the result changes the data values (while replicating them to three channels) to nonlinear values (as if the result were going to be marked as sRGB?) even though it sets the image as linear RGB and preserves the gamma=1 setting of the image.

When performing "-colorspace sRGB" on a linear (gamma=1) Gray image, the resulting data values are unchanged (they are merely replicated to three channels) even though they are now marked as nonlinear sRGB with gamma=0.454545.

[Edit: I'm using IM 7.0.6-2 HDRI x64 (Windows 7).]

Code: Select all

$ magick rose: -colorspace gray -set gamma 1  gamma1.miff
$ magick  gamma1.miff    -colorspace RGB gamma1.miff.RGB.miff
$ magick  gamma1.miff    -colorspace sRGB gamma1.miff.sRGB.miff
$ magick identify -format  '%M  %[colorspace]  %[gamma]  %[mean]\n'    gamma1.miff*
gamma1.miff  Gray  1  25864.7
gamma1.miff.RGB.miff  RGB  1  11134
gamma1.miff.sRGB.miff  sRGB  0.454545  25864.7
[Edit: I'm using IM 7.0.6-2 HDRI x64 (Windows 7).]

Just BTW (not part of the bug report per se), none of these bugs would be happening if we had some proper grayscale colorspaces that transformed to and from the other colorspaces (and one another) just like any other colorspace. Because we don't, we end up having to simulate them using the image's gamma value instead. We should have at least one linear grayscale colorspace (when we -combine 3 of them the result would be RGB by default), and one nonlinear one (nonlinear in the same sense that sRGB channels are nonlinear, so that when we -combine 3 of them it would be marked as sRGB by default).
I tried to argue for this here in a post in 2013 but without success.
Just for example, the linear one could be called LinearGray or GrayLuminance, and the nonlinear one could be called sGray (I believe this is what Adobe calls it and they even have an icc color profile for it by the same name).
When we -separate an sRGB image the resulting images would be sGray, but when we -separate linear RGB (or presumably XYZ etc.) the result would of course be LinearGray.
As for color-to-grayscale operations, even if there are multiple formulas for this (as in -intensity) it *should* at least always be clear whether the result represents linear or nonlinear values -- for example if going from sRGB to grayscale using any of the simple linear combinations (like c1*sR + c2*sG + c3*sB, regardless of which coefficients might be used depending on -intensity) then the result is clearly nonlinear just as the sRGB channels were. If the -intensity setting ultimately leads to linearizing or delinearizing before or after the linear combination, that will of course affect whether the result is marked as linear or nonlinear in the expected way.
Of course there could still exist a generic/unspecified single-channel colorspace for those times when it isn't clearly one or the other -- perhaps we should use the existing -set colorspace Undefined in these cases, or possibly even a new colorspace. (We could use the existing Gray to represent a generic single channel, but Gray is already interpreted and used in specific ways with specific assumptions (for better or worse) and I'm not sure we'd want these to change unnecessarily.)
-Dabrosny [Using IM7.0.6 or higher, Q16 HDRI x64 native executable, command line, often invoked from cygwin bash/sh (as of Aug. 2017)]
Post Reply