search

darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.72k stars 1.14k forks source link

Request: HDR viewers on macOS #17710

Open AndrewKeYanzhe opened 3 days ago

AndrewKeYanzhe commented 3 days ago

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 commented 3 days ago

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

See also:

https://github.com/darktable-org/darktable/issues/3880 https://github.com/darktable-org/darktable/issues/12173 https://github.com/darktable-org/darktable/issues/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 commented 3 days ago

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 commented 3 days ago

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...