possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

[fmw42]

I believe there may be a bug when trying to convert a linear gray image to non-linear using -intensity rec709luma -colorspace gray. It does no recognize the input as linear unless -set colorspace RGB is used before -intensity. I would think that having gamma=1 in the input image would be enough for -intensity to know it is linear and do the proper conversion to non-linear.


# create comparison non-linear gray
convert -size 100x100 xc:gray -format "%[fx:mean] %[gamma] %[colorspace] %[type]\n" -write info: nonlineargray.png
0.494118 0.454545 sRGB Grayscale

# convert non-linear gray to linear gray (works fine)
convert -size 100x100 xc:gray -intensity rec709luminance -colorspace gray -format "%[fx:mean] %[gamma] %[colorspace] %[type]\n" -write info: lineargray.png
0.208637 1 Gray Grayscale


# attempt to convert linear gray to non-linear (fails)
convert lineargray.png -intensity rec709luma -colorspace gray -format "%[fx:mean] %[gamma] %[colorspace] %[type]\n" -write info: nonlineargray2.png
0.208637 1 Gray Grayscale


# attempt again convert linear gray to non-linear but add -set colorspace RGB (works)
convert lineargray.png -set colorspace RGB -intensity rec709luma -colorspace gray -format "%[fx:mean] %[gamma] %[colorspace] %[type]\n" -write info: nonlineargray3.png
0.494118 0.454545 Gray Grayscale

# convert linear gray to non-linear gray using -colorspace sRGB
convert lineargray.png -colorspace sRGB -format "%[fx:mean] %[gamma] %[colorspace] %[type]\n" -write info: nonlineargray4.png
0.494118 0.454545 sRGB Grayscale

[glennrp]

I reproduced the behavior on Ubuntu.

Debugging shows that the PNG encoder receives
image->gamma=1.0
image_colorspace=2 (GRAY)
image->intensity=6 (Rec709Luma)

The gamma and intensity are not consistent, and
the PNG encoder chooses to use the supplied
image->gamma and ignore the image->intensity.

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.7-4 Beta available by sometime tomorrow. Thanks.

[Dabrosny]

I reproduced the behavior on Ubuntu.

Debugging shows that the PNG encoder receives
image->gamma=1.0
image_colorspace=2 (GRAY)
image->intensity=6 (Rec709Luma)

The gamma and intensity are not consistent, and
the PNG encoder chooses to use the supplied
image->gamma and ignore the image->intensity.

Can you clarify, how is a grayscale image *supposed* to be recognized as nonlinear vs linear? By Intensity, gamma, or in which order? When reading a single-channel png file, gamma=1 may be the only indication that the values are linear -- does this mean IM will (or should) automatically set the image's image->intensity=(Rec709Luminance) in order to identify this image as linear? Or is it the image->gamma=1 in *combination* with the *lack* of image->intensity the thing that indicates linear grayscale data?

Is image->intensity really a property of the image (and should be part of the interpretation of the image), or does it just indicate the -intensity *setting* of IM currently or whent the image was created or saved?

[Dabrosny]

Is the following bug related? Otherwise I'll post it separately.

The rose: pseudoimage in its defauilt sRGB has a mean of 0.41, and as linear it has a mean of about 0.2.

Code: Select all

imh convert -intensity rec709luminance -format "%[fx:mean] %[channels] %[gamma]\n" rose: -depth 16 -write info: -colorspace rgb -write info: rose_rgb.png
0.412342 srgb 0.454545
0.219619 rgb 1

Above is correct and writes *linear* file rose_rgb.png (gamma=1).

But now when reading that file back into IM, it treates it as sRGB despite the gamma=1:

Code: Select all

imh convert -intensity rec709luminance -format "%[fx:mean] %[channels] %[gamma]\n" rose_rgb.png -write info:  -colorspace gray -write info:  /dev/null
0.219619 srgb 1
0.104677 gray 1

(Above from Fred who helped confirm this behavior.)

The numeric mean of the data values remains about 0.2 but labeled as "sRGB" and gamma=1 (contradictory).

Then the final rec709luminance grayscale transformation apparently treats it as nonlinear and tries to "linearize" it a second time, leading to a quite incorrect mean of 0.1 rather than about 0.2 as it was when the png file was written as linear.