Request: HDR viewers on macOS

[AndrewKeYanzhe]

Is your feature request related to a problem? Please describe.
When editing HDR images (e.g. with PQ 2020 output space) the image viewer appears very dark on macOS. The viewer is limited to SDR.

Changing the display profile to PQ 2020 results in a grey viewer, so it appears that the colorspace is not communicated to macOS color management.

The output images in PQ 2020 look fine when viewed in external apps like Google Chrome.

Describe the solution you'd like

Use the macOS HDR APIs (e.g. https://developer.apple.com/documentation/metal/hdr_content) to display the viewers in HDR. This is enabled when output color space is set to PQ BT2020, and this (relatively common) color space will be communicated to macOS.

macOS PQ ST2084 has 2 HDR tone curves: 1. highlight rolloff and 2. clip

1. Video consumption apps typically use highlight rolloff to display more highlight detail
2. Professional apps like Lightroom and DaVinci resolve use the clip mode, so that "what you see is what you get" when editing. Lightroom also shows the current display clip point (determine by the HDR headroom), which is useful because in brighter environments, there is less HDR headroom
   e.g. for the M1 Macbook Pro 16

• 1600 nits is 4 stops of headroom with SDR at 100 nits
• 1600 nits is 2 stops of headroom with SDR at 400 nits

Ideally, darktable would also use the ST2084 clip tone curve, and indicate to users where the clip point or HDR headroom is.

Alternatives

Additional context

Device: M1 Macbook Pro 16 with 1600 nits XDR display
darktable build: 4.9.0+916~gbc7af25093 (20241023)

Note: Macbooks 2018 and later, and iMac 2020 and later should support HDR 200 nits (when SDR is at 100 nits) https://support.apple.com/en-gb/102205 . I've tested an M1 Macbook Air which exhibits this behaviour. So, developers with these devices should be able to test this functionality.

[kmilos]

This is just one piece of the general (not totally solved?) HDR workflow puzzle...

See also:

#3880
#12173
#15967

etc.

P.S. It is very unlikely anything special for macOS using their API will be done, as the goal is for solutions to work cross-platform. So you might as well first ask/wait for GTK to support it... 😉

[AndrewKeYanzhe]

I've created an issue at the GTK bug tracker https://gitlab.gnome.org/GNOME/gtk/-/issues/7110

Their color management milestone tracker already says they intend to add macOS support
https://gitlab.gnome.org/GNOME/gtk/-/issues/6864

For performance reasons, is bt2020-linear suitable for darktable to pass to GTK and macOS? Apple has deprecated bt2020-pq while keeping bt2020-linear https://developer.apple.com/documentation/coregraphics/cgcolorspace

[kmilos]

For performance reasons, is bt2020-linear suitable for darktable to pass

Note that this is the default darktable working color space, so it could be, indeed.

The main "problem" w/ darktable is that it is built around ICC profiles and LCMS engine, and in ICC profiles 1.0 = max signal (so for e.g. PQ curve in an ICC profile 1.0 = 10000 nits), while for HDR workflow one would want 1.0 to be "diffuse white", so there is some scaling to be done somewhere...

[AndrewKeYanzhe]

@kmilos is it possible to have the following feature:

• In the output color profile module, have an option for users to set exposure offset on export. There will be a separate offset setting for each color profile, e.g. +0 for sRGB, -5.5ev for PQ bt2020.

My current workflow is to create PQ bt2020 avif images for viewing in Chrome, and I typically need to set an exposure offset of -5.5 so that the avif output is of similar luminance to the SDR viewer. So I will 1. edit images to the correct exposure, then 2. apply the offset to each image as a second step. At this point, the SDR viewer looks very dark so one will need to undo step 2. to make further edits.

The aforementioned feature suggestion would eliminate the second step and streamline the workflow.