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?
possible bug write linear gray formats IM 6.8.7.2
-
- 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
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.
I know nothing about PGM.
snibgo's IM pages: im.snibgo.com
- 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
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
-
- 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
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).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.
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)]
-
- 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
Ah, yes, "-intensity" is supposed to change the meaning of "-colorspace gray". Sorry, I had missed that.
snibgo's IM pages: im.snibgo.com