[RESOLVED]possible bug -grayscale rec709luminance 6.8.7.0

[fmw42]

Code: Select all

convert -version
Version: ImageMagick 6.8.7-0 2013-09-26 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC
Features: DPC
Delegates: bzlib fftw fontconfig freetype gslib jbig jng jp2 jpeg lcms lqr ltdl lzma openexr png ps png tiff x xml zlib

There appears to be an inconsistency between the IM reported gamma in the verbose information and the PNG gamma. This goes back as far as I can test to 6.8.7.9.


convert rose: -grayscale rec709luminance rose_tmp.png
gamma=0.4545 <---- should be 1

But the PNG info shows gamma=1

Properties:
date:create: 2013-10-04T15:11:22-07:00
date:modify: 2013-10-04T15:11:22-07:00
png:bKGD: chunk was found (see Background color, above)
png:gAMA: gamma=1 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 0
png:IHDR.color_type: 0 (Grayscale)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 70, 46
png:text: 2 tEXt/zTXt/iTXt chunks were found
signature: b9e4563ff80920640476d2955c0d9e962912a4af5571fe3056b56f1e167d2ea2


Note that using miff output produces the correct gamma=1

convert rose: -grayscale rec709luminance rose_luminance.miff
Gamma: 1

[glennrp]

As I said in the developers forum on this topic, There is no Rec709LuminanceColorspace defined in magick/colorspace.h
It might help to add that to the enumeration list of colorspaces there, and then handle that case in coders/png.c. Sorry,
I cannot test that idea tonight.

[fmw42]

As I said in the developers forum on this topic, There is no Rec709LuminanceColorspace defined in magick/colorspace.h
It might help to add that to the enumeration list of colorspaces there, and then handle that case in coders/png.c. Sorry,
I cannot test that idea tonight.

Is there more to it than having the code for -grayscale rec709luminance or rec601luminance pass gamma=1 both to the IM gamma value and the PNG gamma value for the PNG writer so that both have the same value of 1?

-grayscale arguments are not colorspaces but simply argument names. So I would not think one needs to create pseudo-colorspaces to handle this.

[glennrp]

Verified the behavior you observed.

The PNG reader contains this, when the image is gray:
coders/png.c line 3656:
SetImageColorspace(image,GRAYColorspace);

Previously that would set image->gamma to 1 but now it sets image->gamma to 1/2.2

The comment in colorspace.h indicates that it should be 1 not 1/2.2
GRAYColorspace, /* greyscale (linear) image (faked 1 channel) */

SetImageColorspace() now contains this:
if ((image->intensity == Rec601LuminancePixelIntensityMethod) ||
(image->intensity == Rec709LuminancePixelIntensityMethod))
image->gamma=1.0;
(otherwise image->gamma = 1/2.2)

Adding
image->intensity = Rec709LuminancePixelIntensityMethod;
just before the SetImageColorspace() seems to fix the problem.

[glennrp]

The above-mentioned fix is checked in to SVN revision 13368 (which will be IM-6.8.7-1).

[fmw42]

The above-mentioned fix is checked in to SVN revision 13368 (which will be IM-6.8.7-1).

Thanks Glenn. If/when it is in beta, I can test it, if someone lets me know.

Fred

[Dabrosny]

I'm the OP of the discussion this apparently came out of.

I'm not clear on whether this solves the colorspace problem. I wasn't aware that an image has a gamma property (how do I see it on the command line?), but this shouldn't be a substitute for setting a colorspace that accurately indicates what the pixel values represent.

Today, we have this:

Code: Select all

$ convert xc:#44440006FFFF -grayscale Rec709Luminance  txt:-
# ImageMagick pixel enumeration: 1,1,65535,gray
0,0: (8.4483735432402529142%,8.4483735432402529142%,8.4483735432402529142%)  #15A115A115A1  gray(8.4483735432402529142%)

$ convert xc:#44440006FFFF -grayscale Rec709Luminance -colorspace sRGB txt:-
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (8.4483735432402529142%,8.4483735432402529142%,8.4483735432402529142%)  #15A115A115A1  srgb(8.4483735432402529142%,8.4483735432402529142%,8.4483735432402529142%)

$ convert xc:#44440006FFFF -grayscale Rec709Luminance -colorspace RGB txt:-
# ImageMagick pixel enumeration: 1,1,65535,rgb
0,0: (0.77812732089126990243%,0.77812732089126990243%,0.77812732089126990243%)  #01FE01FE01FE  rgb(0.77812732089126990243%,0.77812732089126990243%,0.77812732089126990243%)

Note that IM treats the grayscale image resulting from -grayscale Rec709Luminance as if it is sRGB gamma-encoded, as evidenced by the fact that -colorspace sRGB does not change the data values while -colorspace RGB performs an sRGB-->RGB linearization on the (already-linear!) data.

Does the fix you checked in change this behavior?

I don't think this can be solved unless -grayscale Rec709Luminanance sets a linear colorspace --preferably a grayscale one like LinearGray (but even RGB would do the trick in the meantime since IM 6 stores the grayscale in 3 channels anyway).

-Dabrosny

[fmw42]

As of the current 6.8.7.1 Q16 beta (hdri), this has been fixed

convert rose: -grayscale rec709luminance rose_tmp.png
gamma=1

and the PNG: gamma=1

[fmw42]

This fix seems to have lost the bug fix in the latest beta.


imbh convert rose: -colorspace sRGB -grayscale rec709luminance rose_luminance.png

Image: rose_luminance.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: PseudoClass
Geometry: 70x46+0+0
Units: Undefined
Type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 8/1-bit
Channel depth:
gray: 8-bit
Channel statistics:
Gray:
min: 5 (0.0196078)
max: 255 (1)
mean: 49.9761 (0.195985)
standard deviation: 53.9087 (0.211407)
kurtosis: 6.59421
skewness: 2.5889
Colors: 200
.
.
.
Rendering intent: Perceptual
Gamma: 0.454545 <====== should be 1
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Background color: gray(255)
Border color: gray(223)
Matte color: gray(189)
Transparent color: gray(0)
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 70x46+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2013-10-08T10:18:30-07:00
date:modify: 2013-10-08T10:18:30-07:00
png:bKGD: chunk was found (see Background color, above)
png:gAMA: gamma=1 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 0
png:IHDR.color_type: 0 (Grayscale)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 70, 46
png:text: 2 tEXt/zTXt/iTXt chunks were found
signature: b9e4563ff80920640476d2955c0d9e962912a4af5571fe3056b56f1e167d2ea2
Artifacts:
filename: rose_luminance.png
verbose: true
Tainted: True
Filesize: 2.79KB
Number pixels: 3.22K
Pixels per second: 322KB
User time: 0.000u
Elapsed time: 0:01.009
Version: ImageMagick 6.8.7-0 2013-09-26 Q16 http://www.imagemagick.org
Fred-Weinhauss-Mac-mini:desktop fred$

[fmw42]

CORRECTION:

The following works fine if using the 6.8.7.1 beta to read the verbose information. Older versions of IM still show gamma=0.4545 in the verbose information.


imbh convert rose: -colorspace sRGB -grayscale rec709luminance rose_luminance.png

imbh identify -verbose rose_luminance.png
gamma=1

identify -verbose rose_luminance.png
gamma=0.4545

[fmw42]

This appears to be fixed in 6.8.7.1