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
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.)