gdk-pixbuf: Decode HLG images - #1729
Conversation
|
Given that gdk-pixbuf does not support HDR at this time, with no way to pass through HDR metadata or handle anything but 8-bit depth, this is a good thing. HDR<->SDR conversions would probably be useful and better placed in the core, but until that time, this seems fine. |
| /* BT.2020 -> BT.709 matrix (linear light) */ | ||
| const float m[9] = { | ||
| 1.660227f, -0.587548f, -0.072838f, | ||
| -0.124553f, 1.132926f, -0.008350f, | ||
| -0.018155f, -0.100603f, 1.118998f, | ||
| }; |
There was a problem hiding this comment.
One can't assume the color primaries will always be Rec2020 here. DCI P3 + HLG is not uncommon (iPhones?). I wouldn't be surprised there are other combos like 709 + HLG out there as well... That's why this was left to ICC profiles and proper external color management...
There was a problem hiding this comment.
Being the pixbuf loader I imagine only image decoding is relevant here. Smartphones do not emit HLG-encoded images, but use an SDR base image with a separate optional gain map for converting to HDR rendition.
Not sure if iPhone uses DCI-P3 for the base image, but they wouldn't hit this conversion. bt709 + hlg also sounds mostly like a video workflow.
There was a problem hiding this comment.
When it comes to HEIF and AVIF, it's good to keep video workflows in mind, because they're totally legal and starting to be used for exporting HDR snapshots from NLE video software as well, and I know VLC wanted to use AVIF for exporting HDR directly. (Not sure where that proposal went.) That way it's a simple matter of copy the frame buffer, copy the HDR metadata, done.
That's why I think the rescaling should be more in the core than the individual plugin, for when needed.
There was a problem hiding this comment.
I know VLC wanted to use AVIF for exporting HDR directly
FWIW, darktable can already export HDR AVIFs, and all 4 profiles are available: HLG in Rec2020 or DCI-P3, and PQ in Rec2020 or DCI-P3.
That's why I think the rescaling should be more in the core
Why should core (or any plugin) reinvent color management? For example libjxl is trying to do this for a while and there are still bugs popping up associated with it...
IMHO energy is better spent improving other parts of the stack to support CICP (nclx) signalling and color management in general (but obviously this doesn't provide a shorter/quicker path).
There was a problem hiding this comment.
@kmilos I agree that it would be even better pushed to an external library, as long as it's fast, maintained, and secure. Do you have experience with any color conversion libraries? I know zimg was used for VapourSynth and newer AviSynth plugins, but I don't know if that's old news or not, especially since it's not HDR-aware.
There was a problem hiding this comment.
Do you have experience with any color conversion libraries?
Only lcms2, and I feel the whole ICC-based ecosystem is not quite there yet when it comes to HDR unfortunately...
There was a problem hiding this comment.
Well, ICCv4 only works for SDR by definition, and iccMAX doesn't really seem to be happening...
87aba69 to
9b4d739
Compare
If a HEIF image using Hybrid-Log Gamma or PQ, passing the pixels along as-is will lead to a very dull rendition, similar to ungraded video footage. Convert HLG+BT.2020, HLG+P3 and PQ+BT.2020 to plain sRGB, targetting 1000-nit display light for HLG, providing a rendition in line with user expectation.
|
Thanks, looks more complete now! |
|
I think I'm happy with the current form of it, especially given that the whole ecosystem is likely switching to the glycin loader. I have a jank test tool that allows injecting this loader easily to show test pictures, throw it in the repo and use according to the comments at the top. Comparison of one of the Netflix PQ AVIF's And one of my test HLG HEIF's: |
3 participants
If a HEIF image using Hybrid-Log Gamma, passing the pixels along as-is will lead to a very dull rendition, similar to ungraded video footage.
Apply a conversion to to 1000-nit display light, providing a rendition in line with user expectation.
End-to-end testing with the real clients proved to be a bit cumbersome, so used a small hack client that injects the new pixbuf loader for validation. The output now looks like the tev image viewer.
Fixes: #1728