possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

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
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

Post by 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
User avatar
glennrp
Posts: 1147
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

Post by 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.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

Post by 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
Posts: 111
Joined: 2013-10-02T10:49:39-07:00
Authentication code: 6789
Location: New York, US

Re: possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

Post by Dabrosny »

glennrp wrote: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 [Using IM7.0.6 or higher, Q16 HDRI x64 native executable, command line, often invoked from cygwin bash/sh (as of Aug. 2017)]
Dabrosny
Posts: 111
Joined: 2013-10-02T10:49:39-07:00
Authentication code: 6789
Location: New York, US

Re: possible bug -intensity IM 6.8.7.3 Q16 Mac OSX

Post by 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.
-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