Legacy ImageMagick Discussions Archive

For comparison, I'll start by showing a few of the related cases where IM automatically does the necessary conversion to the [non]linearity of the target output format.

IM automatically (and correctly) converts linear RGB images to nonlinear when writing to a nonlinear sRGB format like JPEG: test.jpg (ORIGINAL, using a very low saturation image just for easier comparison to grayscale later)

testLinearRgb.jpg (OKAY)

Also, when a linear RGB colorspace image is in fact "grayscale" (three equal channels), it automatically (and correctly) converts from linear RGB to a nonlinear Grayscale JPEG (single channel in the file): testLinearGrayLinearRgb.jpg (OKAY)

testNonlinearGrayLinearRgb.jpg (OKAY)

And it even automatically (and correctly) converts nonlinear Gray images to linear when writing to a linear file format like HDR: Those HDR files can be verified as looking correct by directly viewing them (for example in IM Display 7.0.6-2 x64) or by further converting them to JPEG:
testLineargray.hdr.jpg (OKAY)

testNonlineargray.hdr.jpg (OKAY)

But it seems that IM(7.0.6) does not convert a linear Gray image to nonlinear when writing it to a jpeg file, so the result becomes darker: testLineargray.jpg (too dark)

testLinearRgbLinearGray.jpg (too dark)
(Same problem should occur with Rec601Luminance as with Rec709Luminance since both produce a linear result.)
(The same problem might occur with at least some other nonlinear-only or even nonlinear-by-default file formats but I wanted to keep this bug report simple and see what the response might be.)

This is with IM 7.0.6-2 Q16 HDRI (x64 under Windows 7).

(Of course once the user realizes that this problem occurs just when you write a Gray colorspace linear image to a nonlinar format like JPEG, he can work around it with an explicit -colorspace sRGB for example {using a non-Gray colorspace since IM does not support conversion between linear Gray and nonlinear Gray}, but no such explicit colorspace transformation by the user is required for any of the other related examples above, where the conversion between linear and nonlinear is done by IM automatically and transparently without the user having to know the linearity/nonlinearity of the image and/or the linearity/nonlinearity of the target file format.)

The linearity of the colorspace is problematic with most image formats because there is no associated metadata to distinguish the linear from non-linear colorspace. Our guidance is that lacking evidence otherwise, we assume a nonlinear colorspace unless the colorspace is RGB, XYZ, or xyY. For grayscale we assume linear if the intensity option is Rec601Luminance or Rec709Luminance. Certain image formats (e.g. PNG) assumes linear if the gamma is 1.0. JPEG is color blind. Any color interpretation is left to any embedded color profiles. JFIF does not support the gamma metadata. Without color linearity info, we follow best practices which is to assume non-linear since most images are web optimized. The user can override these assumptions with the -set option, e.g. image.jpg -set colorspace RGB.

ImageMagick does not have this ambiguity for the HDR format because its assumed linear.

Thanks for your timely response.

magick wrote: ↑2017-09-10T15:02:27-07:00 we assume a nonlinear colorspace unless the colorspace is RGB, XYZ, or xyY.
For grayscale we assume linear if the intensity option is Rec601Luminance or Rec709Luminance.

Exactly, so when a Gray image has intensity attribute Rec601Luminance or Rec709Luminance internally you could simply transform the data to nonlinear when writing the jpeg file!

You already do this for a linear RGB (etc.) image, so is there any reason not to do so for these Gray images when they are clearly marked as linear (Rec*Luminance)?

When *reading* a JPEG or HDR image the linearity is unambiguous in each case (JPEG always assumed nonlinear, HDR linear).
The issue is writing to these file formats.
In all cases currently a nonlinear Gray image is converted to linear when writing it to HDR, and by the same token a linear Gray image could be converted to nonlinear when writing it to JPEG!

JPEG is color blind. Converting to a non-linear colorspace could be an unexpected transformation for our users whom might expect their linear image to remain linear when they write to a JPEG image. We instead take the raw pixel values and just pass them to the JPEG compressor.

magick wrote: ↑2017-09-10T19:40:26-07:00 JPEG is color blind. Converting to a non-linear colorspace could be an unexpected transformation for our users whom might expect their linear image to remain linear when they write to a JPEG image. We instead take the raw pixel values and just pass them to the JPEG compressor.

In practice and according to IM's own assumptions, JPEG is nonlinear, and this is what you assume when you automatically convert the data from a linear RGB image to nonlinear for jpeg. Why should this assumption be made for color images and not for equivalent grayscale images? In either case it's *possible* that this isn't what the user wanted, and if so, they need to learn to use the -intensity or -set colorspace operations to mark the image differently (perhaps even one or both as Undefined ?).

It's a great feature of IM that colorspace transformations are done automatically as needed without the user having to know about it unless they specifically want to do something *unusual*. This works great for color images (all colorspaces except Gray), but then when we have a Gray image, why would the behavior be different and it no longer does such transformations automatically?

For example an image might have originally been RGB with three identical channels and it might be grayscale only because IM itself therefore automatically converted it to grayscale when it wrote a file. Then when we read this file back in and write it to jpg the result is different (no transformation of the data to nonlinear) simply because IM itself converted it to grayscale earlier -- if it were still marked as RGB then it would have been automatically converted to nonlinear (sRGB) in order to write the jpeg.

As snibgo has been saying, he considers a linear Gray image to be the same as a linear RGB image except that it happens to only have one channel (equivalent to three identical channels). This is why it's very confusing when Gray behaves so differently than color.

If IM automatically converts linear colour images to non-linear when writing to JPEG, it should do the same thing for non-colour images. (Unless there is a very good reason not to. I can't see any reason at all.)

When processing an image, it may lose its colour. Or a colourless image may gain colour (eg as a result of a clut). But I would expect IM to be consistent about automatic conversions between linear and non-linear, whether the image happens to have colour or not.

And it should be consistent between the two directions, reading and writing. If it assumes that any images read from JPEG that don't have profiles are non-linear sRGB, then it should write non-linear sRGB data to JPEG, whether the data has colour or not.