[became suggest/request: write PNG as sRGB by deflt for DynamRng&Compat -edit] image gets darker&darker every round-trip

[Dabrosny]

On converting an image back and forth between a linear file format and a png format, it gets darker and darker (and btw has fewer and fewer unique colors) every round-trip due to spurious compound colorspace transformations / gamma operations.

Code: Select all

magick rose: rose.hdr  (okay)
magick rose.hdr rose.hdr.jpg (okay)
magick rose.hdr rose.hdr.png  (too dark unless you account for the gamma=1 and ignore colorspace)
magick rose.hdr.png rose.hdr.png.hdr (too dark)
magick rose.hdr.png.hdr rose.hdr.png.hdr.png (still too dark)
. . . (getting darker and darker...)
. . .

Below are the properties of the resulting images (Mean is %[fx:mean], etc.).
If you view any of the images near the bottom of this list, you'll see that most of the image is lost to near-blackness.

Code: Select all

 CSpc     Gam  Fmt Dep     Mean       Min Max  Name
 sRGB .454545  PPM   8  .412342  .0862745   1  rose:
 sRGB  .45455  PNG   8  .412342  .0862745   1  rose.png
 sRGB .454545 JPEG   8  .412056  .0823529   1  rose.jpg
 sRGB .454545 JPEG   8  .410574  .0823529   1  rose.hdr.jpg
  RGB       1  HDR  16  .218564  .0078125   1  rose.hdr  (this one looks fine in an hdr viewer as it was correctly linearized by IM)
 sRGB       1  PNG  16  .218564  .0078126   1  rose.hdr.png  (looks too dark, but allegedly "correct" because it has GAMA=1)
  RGB       1  HDR  16  .123177         0   1  rose.hdr.png.hdr  (too dark)
 sRGB       1  PNG  16  .123177         0   1  rose.hdr.png.hdr.png  (still too dark regardless of gamma=1 or not)
  RGB       1  HDR  16  .078639         0   1  rose.hdr.png.hdr.png.hdr  (getting darker and darker as you go down this list)
 sRGB       1  PNG  16  .078638         0   1  rose.hdr.png.hdr.png.hdr.png
  RGB       1  HDR  16  .054094         0   1  rose.hdr.png.hdr.png.hdr.png.hdr
 sRGB       1  PNG  16  .054094         0   1  rose.hdr.png.hdr.png.hdr.png.hdr.png
 sRGB .454545 JPEG   8  .057767         0   1  rose.hdr.png.hdr.png.hdr.png.hdr.png.jpg

My understanding is that this is a symptom of IM's attempt to write linear images to png files as "linear png" files by default, using a GAMA=1 chunk to ostensibly indicate this.

As far as I can tell, just about all software including imagemagick itself considers the image data in a png file to be in sRGB colorspace, irrespective of the GAMA chunk.
So when IM reads back in the "linear png" file that it just wrote, it treats the data as sRGB, and it thus becomes "too dark".

What if we were to stop trying to write "linear png" files, and instead implicitly convert linear (or other non-sRGB) images to sRGB by default in order to write them to png, just like when we write them to jpeg?
In my opinion there's very little downside to doing this.

I can't think of any real necessity for creating a linear png -- usually one would use tiff or any of the hdri or floating-point (or linear-only) formats to store a linear image.
But if anyone really finds that the ability to write a linear png is important, perhaps there could be another way to do so, such as format PNGLINEAR: or PNGGAMMA: wherein the gamma value would be preserved and the image not converted to sRGB -- but in my opinion this behavior should not be the default for ordinary PNG format(s) like it is today.

What do you think -- am I off base here?

[snibgo]

When reporting a problem, please always say what version of IM you have tested on. (Also the platform, though that probably doesn't matter.)

On v6.9.5-3, Windows 8.1, the round-trip from png to hdr and back doesn't work properly UNLESS I "-set colorspace sRGB" on reading the hdr:

Code: Select all

convert rose: r.png
convert r.png r.hdr
convert r.hdr -set colorspace sRGB r2.png
convert r2.png r2.hdr
convert r2.hdr -set colorspace sRGB r3.png

I can keep doing this for as long as I want.

I don't know if the problem is writing HDRs or reading them, or both.

[magick]

HDR requires a linear colorspace. If the image is not linear, it automatically converts it to linear.

[snibgo]

But when reading HDR (in v6.9.5-3), the data ends up in IM as sRGB space, but IM doesn't recognise this, so it then converts "from RGB to sRGB".

I have to prevent this by telling IM to "-set colorspace sRGB". I shouldn't need to do this.

[Dabrosny]

I am using ImageMagick-7.0.6-3-Q16-HDRI-x64-dll. HDR files are always linear. IM is reading and writing HDR correctly as colorspace RGB. Using -set colorspace sRGB on reading HDR would set incorrect colorspace.

The problem is not with the hdr files. The problem is writing colorspace RGB (linear) data (which it happens to have gotten from hdr file) directly to png file without first converting it to srgb. When IM reads back in this png file it assumes the dAta is in srgb colorspace, just as any other software would assume.

If you repeat my examples above with all jpeg files in place of the png files, you will see that the problems do not occur. This is because im always converts to srgb when writing to jpeg file. IM should do same for writing to png and then everything will work correctly!

The workaround is to insert -colorspace sRGB right before writing a png file. If image happened to already be in srgb then this would have no effect.

But my point is that this should be automatic implicit default for png output just as it is for jpeg output.

Edit: snibgo, instead of

Code: Select all

convert r.hdr -set colorspace sRGB r2.png

try this:

Code: Select all

convert r.hdr -colorspace sRGB r2.png

This will make r2.png look the same as r.png .

[snibgo]

This will make r2.png look the same as r.png .

Not for me, no. But my version is old.

[Dabrosny]

Does anyone agree or disagree that we should consider *not* writing "linear png" files anymore by default (i.e. instead we should convert to sRGB upon writing to them, just as when writing jpeg or other sRGB file formats), to avoid the problems associated with having png files that have linear data but are assumed to contain sRGB data by practically all software including imagemagick itself?

[fmw42]

I do not understand why we should force it. Linear PNG are fine, I think. If the format supports it, then allow IM to preserve as best it can the input to the output. The user should control whether or not to keep it linear or convert back to sRGB. Perhaps I do not understand the issue. I am not rigid on this and will go with whatever the decision. I do not think JPG supports linear data, but I could be wrong.

[snibgo]

If ImageMagick thinks it is writing linear data to PNG but, when IM reads it back, IM thinks the data is sRGB -- that is an internal inconsistency within IM that should be fixed.

If PNG supports linear data, then I think IM should support it. Perhaps with the caution that other software may think the data is sRGB.

[Dabrosny]

Png standard defines a gamma chunk but this is a poor and incomplete substitute for specifying a colorspace (like tiff's photometric interpretation) and is generally ignored.

I've never seen an image viewer etc that actually uses this gama and modifies the data accordingly when displaying it or writing to a specific colorspace like srgb.

I'm not opposed to having the *ability* to explicitly create a linear png but the problem is that this is being done silently by default just because the image happens to currently be stored in linear RGB for reasons that the user is often unaware of and have nothing to do with the user wanting to create a png in an obscure and seldom intentionally created (also seldom created unintentionally except by IM) and seldom-correctly-read variant.

Even if we were to change IM so that it would read it "correctly" as linear this wouldn't make it a good default for writing. When reading an image like hdr the user should not have to know that its colorspace (which happens to be harmless in the hdr) is going to unexpectedly carry over into png which may lead to unexpected results when displayed or used by other software.

Much perceptual detail can be lost to quantization when going from a float or logarithmic or gamma format to linear version of integer format like png even at 16 bits.

There is a reason that most (non-logarithmic) integer file formats are seldom used with linear gamma (except perhaps when it is an engineering necessity in a device) -- and certainly never with 8-bit which would be extremely lossy via quantization.

What is the harm in treating default PNG: format as an sRGB (de facto standard) format but provide something like PNGLINEAR: or PNGGAMMA: if there are sometimes use cases for explicitly non-sRGB png files?

(Edited for clarity)

[fmw42]

I think the best thing is to wait to hear back from the PNG developer, glennrp and the ImageMagick developer, magick.

[Dabrosny]

Okay, let's split the solution into three parts, from most important (uncontroversial?) to least:

1) At a bare minimum, when IMv7 reads in a png file having gamma=1, it should consider this to be in RGB (linear) colorspace, not sRGB as it (at least IM 7.0.6-2 Q16 HDRI) does today. How can it make sense to mark it as sRGB when in fact it's explicitly marked as linear?

2) In my opinion IM should always write a PNG file using sRGB colorspace by default (automatically convert from current colorspace to sRGB just as when it is writing a jpeg file), unless the user has explicitly indicated (in some setting or something like PNGGAMMA:) that they want to write a "linear png" or "non-sRGB" PNG even though these are not read correctly by most viewers, browsers, and other software (nor by IM 7 until part 1 above is implemented).
Aside from compatibility, quantization to even 16-bit linear values leads to a drastic loss of dynamic range even compared to 16-bit sRGB (or 16-bit logarithmic...) even if the source image or current processed image is "medium dynamic range" rather than high dynamic range. And please, please, *NEVER* write an 8-bit linear PNG by default as its dynamic range is absurdly low.

3) If IM reads in a png file with gamma that is neither 1 nor approximately 0.4545, in my opinion it should remove the gamma from the data and transform the data to sRGB colorspace before marking the image as sRGB. The sRGB standard prohibits "alternative" gamma values and so what is doing now (preserving alternative gamma value while marking it as sRGB colorspace) violates the sRGB standard and leads to incorrect colorspace transformations. Another alternative would be to transform it to gamma=1 and mark the colorspace as RGB, although in my opinion this is less preferable since this is likely to lead to undesirable loss of dynamic range if it is stored or written as an 8-bit or even 16-bit integer while keeping it linear. A third alternative would be to mark it as RGB but preserve the gamma value, but this is likely to lead to incorrect colorspace transformations unless IM applies a gamma transformation to gamma=1 before transforming to any other colorspace. Do we need an RGBgamma colorspace that *explicitly* has a nonlinear gamma as given in the gamma setting of the image, as an alternative to the current RGB which is usually assumed to be linear?

[glennrp]

It appears that the HDR reader is applying the gamma. If I convert rose.hdr to txt, it's dark. So what is happening
is that the PNG is being written in sRGB but labeled with a gAMA=1 chunk. Then the decoder uses the gAMA=1
to convert the image (already sRGB) to sRGB again.

[glennrp]

Hear's another test case that I'm using to see what's going on.

Code: Select all

echo one:
im7magick -size 1x1 xc:"#ff8000" txt:- | tail -1

echo one.hdr:
im7magick -size 1x1 xc:"#ff8000" one.hdr
im7magick one.hdr txt:- | tail -1

echo one.hdr.png:
im7magick one.hdr one.hdr.png
im7magick one.hdr.png txt:- | tail -1

echo one.hdr.png.hdr:
im7magick one.hdr.png one.hdr.png.hdr
im7magick one.hdr.png.hdr txt:- | tail -1

echo one.hdr.png.hdr.png:
im7magick one.hdr.png.hdr one.hdr.png.hdr.png
im7magick one.hdr.png.hdr.png txt:- | tail -1

with result:

Code: Select all

one:
0,0: (65535,32896,0)  #FFFF80800000  srgb(255,128,0)
one.hdr:
0,0: (65535,13823.8,0)  #FFFF36000000  rgb(100%,21.0938%,0%)
one.hdr.png:
0,0: (65535,13824,0)  #FFFF36000000  srgb(100%,21.0941%,0%)
one.hdr.png.hdr:
0,0: (65535,2047.97,0)  #FFFF08000000  rgb(100%,3.125%,0%)
one.hdr.png.hdr.png:
0,0: (65535,2048,0)  #FFFF08000000  srgb(100%,3.12505%,0%)

Notice the green
channel getting reduced each time around, but the reduction is happening
in the HDR decoding, not in the PNG encoding.

[fmw42]

Glenn, HDR files are expected to be linear.