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

[glennrp]

Glenn, HDR files are expected to be linear.

Right. But IM seems to be decoding it (as linear) and converting it to sRGB in coders/hdr.c, but then
setting image->gamma=1.0 which means it is still linear.

[fmw42]

Understood, now. Thanks

[Dabrosny]

Glenn, it looks to me like the image data is correctly getting transformed from sRGB to linear RGB in order to write it to HDR, as HDR is a linear-only format.

The sG(i.e. G in sRGB)=128/255=50.2% in sRGB is transformed to linearG(i.e. G in RGB)=21.09% in RGB and this value is written to one.hdr and read back correctly from one.hdr as RGB with gamma=1 and printed as 21.09%.

Then you are writing it to one.hdr.png, which does not trigger any colorspace or gamma transformation (in my opinion it *should* have converted to sRGB in order to write to png just like it does to write jpg) so it writes the same 21.09% to the png file and marks the png file as gamma=1 in a png GAMA chunk.

Then you are reading back the values directly from one.hdr.png which IM considers to be in sRGB colorspace (even though in fact it was in RGB when IM wrote one.hdr.png) although it preserves the gamma=1 setting. When you print it you still see 21.09% but this is being treated as sG when in fact it was originally linearG. (Almost any colorspace transformation we do next will create incorrect results in the target colorspace unless the gamma=1 setting is considered and used directly in the transformation.)

Next you write to one.hdr.png.hdr which is a linear-only format so IM transforms the data from the current colorspace (sRGB) to the target colorspace (RGB) and writes this data (linearG=3.125%) correctly to the hdr file and then reads it back correctly and prints it.

So the HDR is being read and written correctly. The problem is that we are writing linear RGB data to png and then reading it back as if it were sRGB data (although the gamma=1 is preserved it is thereafter ignored and lost when converting the colorspace again).

So again, at a minimum, reading a png file having GAMA=1 should be interpreted as a linear RGB colorspace image (not sRGB as today).

In addition, in my opinion, we shouldn't have written a "linear png" to begin with, because (1) this is generally very lossy in terms of decreased dynamic range, and (2) a linear png is incompatible with almost all other software that might read it (including IM 7.0.6 although hopefully not IM 7.0.8 or so).

[Dabrosny]

But IM seems to be decoding it (as linear) and converting it to sRGB in coders/hdr.c, but then
setting image->gamma=1.0 which means it is still linear.

Nope... on reading the HDR file it looks to me like it correctly sets the colorspace to linear RGB (not sRGB) initially, in 7.0.6-2 Q16 HDRI at least:

Code: Select all

magick identify rose.hdr
rose.hdr HDR 70x46 70x46+0+0 16-bit RGB 11657B 0.000u 0:00.000

EDIT: now if only IM could do the same upon reading a png file with GAMA=1

[glennrp]

In addition, in my opinion, we shouldn't have written a "linear png" to begin with, because (1) this is generally very lossy in terms of decreased dynamic range, and (2) a linear png is incompatible with almost all other software that might read it (including IM 7.0.6 although hopefully not IM 7.0.8 or so).

Well, the PNG Developers recommend using 16-bit samples with linear colorspace; in fact, the libpng "simplified API" switches back and forth between 8-bit sRGB and 16-bit linear pixels.

And they recommend exporting images as 8-bit sRGB for use by the world, because, as you say, not many apps can handle 16-bit samples.

[Dabrosny]

Most software can handle 16-bit png just fine, so long as it's sRGB: [edit] even ordinary web browsers like chrome, firefox, IE, and opera.

The PNG developers are perhaps pointing out that if you insist on using a linear colorspace with an integer format, you better not use 8 bits -- 16 bits is much better.

But the dynamic range of a 16-bit linear PNG is still at least an order of magnitude (or about 3.5 f-stops) less than that of a 16-bit sRGB PNG -- how do the PNG developers (or we) know that it's harmless to lose this amount of dynamic range, unless they/we happen to know that the dynamic range of the source image is low to begin with?

Adobe recommends using at least 32 bits if you want to use a linear colorspace with an integer format -- and even then you could get more dynamic range in the same bytes if you instead used a nonlinear 32-bit format.

It's especially ironic that the very fact that I'm reading in a high-dynamic range image (which typically use a linear colorspace) causes IM to write a png with less dynamic range by default than if I had read in a typical non-hdr image (sRGB colorspace).

How can it possibly make sense to write an HDRI image by default with lower dynamic range than an LDR image?

Also we should understand that hdri image formats do not actually store the image data in a linear integer encoding like a linear png does -- that would be foolish because it would be impossible to store a high dynamic range image without taking up several times as many bytes!

Quite the contrary they very intentionally use storage formats that are *more* nonlinear than sRGB: either a format having an explicit exponent (very nonlinear!) as in HDR (RGBE where E is the exponent), or using native floating point format with its own built-in exponent as in PFM and others, or a "logarithmic" (really exponential as well) encoding as in LOGLUV Tiff.

The fact that the floating-point numbers that we get from the decoder for hdri file formats are typically in a linear colorspace is completely different from whether this is a good physical format to store them in bytes as plain integers for storage or transmission purposes. The reason they can be in a linear colorspace is that there is no need to use gamma when you're using floating point numbers because they already have achieved a high dynamic range per byte by virtue of storing the nonlinear exponent that's inherent in all floating-point encoding formats; a gamma transformation of 2.0 or 0.5 for example would merely add or subtract one from the binary exponent. On the contrary with integers there almost always *is* a need to use gamma or another nonlinearity if you're trying to get a good amount of dynamic range per stored byte.

EDIT: Adobe and others use the concept of a working colorspace, which may be chosen as linear for various reasons, but this doesn't mean that you should therefore necessarily *store* the image as linear integers -- the considerations are completely different. If the image is in a linear colorspace as a good working colorspace for certain operations, or merely because that's the way it was read in by the decoder from some source format (e.g. HDR), that shouldn't imply that you would want to store it in linear 16-bit integers.

[Dabrosny]

... And they recommend exporting images as 8-bit sRGB for use by the world, ...

Okay, so, at least if we're writing an 8-bit per sample PNG file would you agree that sRGB should be the default, rather than whatever-colorspace-the-image-just-so-happens-to-already-be-in-for-whatever-reasons?

[glennrp]

... And they recommend exporting images as 8-bit sRGB for use by the world, ...

Okay, so, at least if we're writing an 8-bit per sample PNG file would you agree that sRGB should be the default, rather than whatever-colorspace-the-image-just-so-happens-to-already-be-in-for-whatever-reasons?

The libpng developers' recommendation that I mentioned was of course in the context of writing a PNG in which you are limited to integer samples of up to 16 bits/sample. If you look at browsers such as Firefox you'll find that they strip 16-bit PNG samples down to 8, so yes we recommend using 8-bit sRGB rather than 16-bit linear samples for export for web use. From a human-vision viewpoint, 8-bit sRGB is roughly equivalent to 11- or 12-bit linear, so 16-bit PNG is actually more precise (but not after it has been stripped down to 8 bits!)

[Dabrosny]

we recommend using 8-bit sRGB rather than 16-bit linear samples for export for web use

Sure, but if I want to use 16-bit (or if IM is defaulting to 16-bit and I haven't given it any thought), there is certainly no harm in using 16-bit sRGB vs 16-bit linear. If it happens to be read directly by a browser, if anything the 16-bit sRGB reduced to 8-bit will be better than a 16-bit linear reduced to 8-bit.

From a human-vision viewpoint, 8-bit sRGB is roughly equivalent to 11- or 12-bit linear, so 16-bit PNG is actually more precise (but not after it has been stripped down to 8 bits!)

16-bit linear is better than 8-bit sRGB, but 16-bit sRGB is even better than that.

What I don't understand is, what is the advantage or benefit in storing an image as a 16-bit linear png vs storing it as a 16-bit sRGB png? It can easily be transformed back to linear after reading it in from the sRGB png.

When would it actually be preferable to store it as linear, and why would this correspond to cases where the current colorspace happens to be linear as it often is for hdri images (which is not a problem because we are storing them as float and not as 16-bit integers), which are precisely the images that can benefit most from the higher dynamic range of 16-bit sRGB integer storage as compared to 16-bit linear integer storage.

[glennrp]

There's no harm in writing 16-bit sRGB PNG images.

[Dabrosny]

There's no harm in writing 16-bit sRGB PNG images.

Right, so why can't it be the default, even if we happen to currently be working in a linear colorspace (perhaps because we read in an hdri image)?

Just because we're working on it as a linear float image does not mean it would be desirable to store it as a linear 16-bit (nor 8-bit) integer.
The most important thing to preserve is the perceptual information, not the colorspace per se.

[fmw42]

But you can always use -colorspace sRGB to convert from linear to sRGB. Why force the to default to sRGB. It seems to me that the going from linear to linear would be the most reasonable thing to avoid confusion the users and to give more flexibility. This way the user has control of what he/she wants to do. It seems illogical to me that one would have to use -colorspace RGB to prevent an automatic conversion from linear to sRGB when the data is already linear. My opinion, only.

[Dabrosny]

Fred, going from linear float to linear integer (linear png) is may sound "logical" but linear floating point is a *good* way to store image data and linear integer is *not* such a good way in that it is inefficient and entails more loss of perceptually-relevant data than nonlinear integer (sRGB png).

In my opinion, most users should *not* have to concern themselves which colorspace is being used *inside* the png file, which is a technical question. If anything they should understand the consequences of using different working colorspaces when performing operations on the images, but this is independent from what format is good for storage, especially when the working format (linear floating point) is not one of the options in the target file format.

It's more important that the image quality is preserved, which is has a *real* effect on what image they end up with, and that the file is compatible with other software. If they care what colorspace is used inside the png file they can set it explicitly. If they don't, then let's not make them unknowingly (by default) lose image quality and produce a less-compatible png file.

As I said above, all hdri image formats are nonlinear in how they actually store the data, and in fact by using floating point internally within IM we are *storing* it in a very nonlinear format as well. Because that type of nonlinear storage (floating point) is not an option for storage in png, we should choose the next best thing, which is sRGB, certainly not the linear RGB png.

[fmw42]

Dabrosny, if one wants to keep data as accurate as possible, then one should keep it as HDR in say PFM format. Going to PNG is going to lose quality no matter which way you treat it. Having said that, if one has to go to PNG (say for display or web usage), then there is a philosophical issue of approach on this. What is more logical for the user so as to avoid confusion. Do you keep the data linear to avoid a hidden change and let the user decide what to do or do you do it automatically and then possibly confuse the user by the change.

If I were doing processing that needed to change back and forth between linear and non-linear I would always use -colorspace sRGB and -colorspace RGB as appropriate to ensure I knew exactly what was going to happen rather than rely upon the software to do it automatically. As you have found out, it did not do what you expected. But if you had always done the conversion using -colorspace, you would not be having this issue.

Perhaps it is my penchant for understanding and ensuring that I know what is happening that I chose to do it this way.

However, I do understand the pros and cons for either approach. I do see your point about PNG storage in a format that keeps as much resolution as possible.

I am certainly willing to accept a decision by the developers or by consensus either regarding which way to proceed. My opinion above is not hard and fast. I rarely use HDRI format images, except internally when doing HDRI processing and then use MPC or PFM.

So perhaps we need to hear more from other users, perhaps other photographers, who use HDRI image formats more than I.

[snibgo]

Am I missing something? Wasn't there an issue about IM not doing a round trip correctly? Not reading linear PNG files correctly? Has that been resolved, or is someone investigating?


Anyhow, on whether linear data should be automatically converted to sRGB when saving as PNG:

I use HDRI for photography, including some linear processing, but not much. I don't write linear data to an integer file format. I use HDRI tiff (or miff) for that.

On principle, I don't like IM doing things by itself. I want it to do whatever I tell it to do. If it can't do what I say for some reason, I want it to stop and tell me why.

For example, I might have data in CMYK format, and tell IM to save it as PNG. IM knows that PNG can't store CMYK data, so it second-guesses me and converts the data to sRGB without even warning me. Personally, I don't like that. I'd prefer IM to say "PNG can't store CMYK", and leave me to handle the error, so I can change the colorspace in the way I want.

But we are where we are. Dabrosny argues that, as PNG is integer-only, and storing linear data in integers is unwise, and other software may ignore the linear flag, IM should convert linear to sRGB as part of saving to PNG, unless we really tell IM that we definitely want to store it as linear.

I see the argument. I don't support it because it's a step too far. This would be IM saying, "I could do what you have asked for, save linear as PNG, but that's unwise so I'll do something else instead."

However, I'm not massively fussed. It wouldn't change my workflow at all. Provided the behaviour is documented and is controllable, I'll live with anything.