possible bug write linear gray formats IM 6.8.7.2

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 write linear gray formats IM 6.8.7.2

Post by fmw42 »

I am getting saved output images in various formats from a linear gray image that all show gamma=0.4545 rather than gamma=1.

Do JPG, TIFF, GIF store a gamma value in their formats?

convert rose: -colorspace sRGB -intensity rec709luminance -colorspace gray rose1.jpg
Gamma: 0.454545


convert rose: -colorspace sRGB -intensity rec709luminance -colorspace gray rose1.gif
Gamma: 0.454545


convert rose: -colorspace sRGB -intensity rec709luminance -colorspace gray rose1.tiff
Gamma: 0.454545


Even PGM shows gamma=0.4545. I was under the impression that PGM was a linear gray format.

convert rose: -colorspace sRGB -intensity rec709luminance -colorspace gray rose1.pgm
Gamma: 0.454545

Should that not show gamma=1?
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug write linear gray formats IM 6.8.7.2

Post by snibgo »

Is it a bug? "-colorspace gray" makes the image non-linear. If it is followed by "-colorspace sRGB", that will do nothing.

I know nothing about PGM.
snibgo's IM pages: im.snibgo.com
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug write linear gray formats IM 6.8.7.2

Post by fmw42 »

snibgo wrote:Is it a bug? "-colorspace gray" makes the image non-linear. If it is followed by "-colorspace sRGB", that will do nothing.

I know nothing about PGM.

As I understand it -colorspace gray (by itself) no longer makes the image linear (since the inception of -intensity). It seems to be the same as -colorspace rec709luma, except when preceded by -intensity.


convert rose: -colorspace sRGB -colorspace gray rose1.png
0.45455


convert rose: -colorspace RGB -colorspace gray rose2.png
0.45455


convert rose: -colorspace sRGB -intensity rec709luminance -colorspace gray rose3.png
1
Dabrosny
Posts: 111
Joined: 2013-10-02T10:49:39-07:00
Authentication code: 6789
Location: New York, US

Re: possible bug write linear gray formats IM 6.8.7.2

Post by Dabrosny »

snibgo wrote:Is it a bug? "-colorspace gray" makes the image non-linear. If it is followed by "-colorspace sRGB", that will do nothing.

I know nothing about PGM.
The -intensity rec709luminance means -colorspace gray result will be linear (i.e. luminance), and now flagged by gamma=1 (unfortunately still not by the colorspace itself like we do with color images).

I disagree that PGM is a "linear format" I've used pbmplus and netpbm for 24 years and I'd never heard or seen any reason to convert to or from linear just because I'm converting between netpbm formats and others. It's simply unspecified, so, traditionally, it would be sent straight to your monitor and thus displayed with a gamma of around 1.8 to 2.6.

Today most software would treat it as sRGB when displaying it -- certainly any software I've ever used with it -- just like any obscure image format with an undefined colorspace.

This may be a good time to add:

It would be much better if we avoided storing linear-coded image data (such as linear RGB) in any file format unless it stores it as float (which is not really linear because it stores logarithmic coding for its exponent).

Especially at 8 bits, linear coding is disastrously lossy for most images. It loses a lot of visible tonal resolution near the bottom end and gains mostly invisible resolution at the top end, decreasing the image's maximum dynamic range by over two orders of magnitude from what it would have been (255/1 = 255 for linear coding vs 255^2.2/1^2.2 ~ 64000 for gamma of roughly 2.2 that your system will apply to determine how much light to ultimately produce on your monitor.)

Not to mention that a linear png (and probably tiff but I'm not as familiar) is likely to be decoded incorrectly by all software except very technical color-managed software, thus not displaying the image as intended.

Internally to IM, you might very well get away with linear coding in 16- bit (Q16) IM, but I would recommend using an HDRI build instead in order to take advantage of floating point (or maybe use Q32?), so that there is practically no loss of precision during processing. But in my opinion it should be converted back to nonlinear (say sRGB) automatically for writing it to a file, especially for 8-bit output, unless it's to a floating point (or logarithmic) format like the HDR formats themselves (EXR, HDR,...).

There's no reason that a file format should store the numbers in a linear encoding simply because you were doing so internally to IM during some processing, so long as the software reading the file will interpret its encoding correctly.
Last edited by Dabrosny on 2013-10-24T14:15:35-07:00, edited 1 time in total.
-Dabrosny [Using IM7.0.6 or higher, Q16 HDRI x64 native executable, command line, often invoked from cygwin bash/sh (as of Aug. 2017)]
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug write linear gray formats IM 6.8.7.2

Post by snibgo »

Ah, yes, "-intensity" is supposed to change the meaning of "-colorspace gray". Sorry, I had missed that.
snibgo's IM pages: im.snibgo.com
Post Reply