Back

@wolfpld looks like PQ-encoded RGB being displayed (wrongly) on an sRGB display. Is it possible libheif is just giving you a 8-bit version of the PQ signal in the file?

@rfnix In my code it's just a standard decode call, as in their example in the readme:

heif_decode_image(handle, &img, heif_colorspace_RGB, heif_chroma_interleaved_RGB, nullptr);

The images I show are either viewed in gwenview, or converted to jpeg with ImageMagick. Regardless of the method, the output is the same.

@wolfpld if you're not saving the ICC profile or CICP/nclx it's definitely going to get displayed wrong. You're still getting an HDR signal here AFAICT.

(Iirc libheif has RRGGBB or something for 16-bit signals?)

@rfnix I just downloaded a picture from the internet and none of the tools I have can display it properly. This is not a "me" problem.

@wolfpld ah sorry that came off as "this is your fault", that was not my intention, I was interrupted and finished the message too quickly...

What I wanted to add is : the state of HDR support in OSS libraries is very very young, most of them concern themselves with getting the raw RGB pixels and leave you hanging there trying to figure out how to interpret them. And unlike SDR where one will get something close when forgetting the colorimetry metadata of a Display P3 image and may not notice it, for HDR it's absolutely necessary.

@wolfpld technically at this point in time you need libheif+LittleCMS if you want to interpet colors correctly in HDR, or reimplement part of the standards e.g. what mpv does in its rendering shaders.

@wolfpld another solution might be OpenColorIO but I'm way less familiar with it...

@rfnix The color theory is definitely a headache generator for me. For now, the plan is to get the HDR data and put it into a tone mapper, which I think expects BT.2020, and this will be vastly superior to what anyone else does, even if incorrect.

libheif exposes color space information, and what you say sounds like the way to do things, but it may be a bit much, at least for now.

@wolfpld it your tonemapper supports BT2020 you should be good, but it probably also has to know about the transfer function (otherwise it will very likely result in under-contrasted images if your input is PQ).

I'm curious about which libs you're thinking of for tonemapping (or are you thinking of implementing one?) - I admittedly don't know that area as well as I'd like. I know the Blender community have stuff like Filmic/AgX but I don't know how accessible they are from outside of Blender.

@wolfpld got it, thanks! Simple and "good enough" until we need more right? ;)