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:

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]

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.

Edit: The exposure offset on image export functionality is already present in darktable. In the export module, set the style to a -5.5ev preset, mode is append history.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[AndrewKeYanzhe]

@kmilos even after gtk supports HDR in the future, I assume substantial effort will be needed to migrate darktable from gtk3 to gtk4? Would you say it will take at least 1+ years for the migration (and I understand there may not be enough developers interested in this)?

In the mean time, I have written a simple swift app that uses a Metal layer on macOS with metalLayer.wantsExtendedDynamicRangeContent = YES; to bypass Apple's tonemapping. This will clip the EOTF at the panel peak instead of using EOTF rolloff.

I'm wondering how realistic it is to link darktable to a swift app, and the swift app acts as a 2nd window that can show HDR. darktable can pass the rendered image as a 32 bit linear float image in the bt 2020 colour gamut to the swift app.

[AndrewKeYanzhe]

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

In response to "there is some scaling to be done somewhere", I think scaling on export is a possible solution as mentioned in https://github.com/darktable-org/darktable/issues/17710#issuecomment-2441173772.

My current HDR workflow is:

1. Import image
2. Turn filmic RGB off
3. Set output colour space to PQ BT2020
4. For now, my viewer is set as display profile: sRGB. This allows me to gauge exposure of midtones, although understandably the highlights appear clipped and do not represent the output HDR image
5. Export with a -5.5ev preset, resulting in a PQ HDR AVIF that matches the exposure of the sRGB viewer.

Therefore, I believe a swift app linked darktable that shows an HDR viewer using Apple's EDR APIs will result in a complete solution.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[AndrewKeYanzhe]

Comment to remove stale label

[MaykThewessen]

Feature request

Add support for exporting .avif (and optionally .heif) with HDR metadata (Rec.2020 gamut, PQ or HLG transfer functions).

⸻

Motivation / Use case • Many HDR workflows today rely on AVIF/HEIF for distribution and sharing. • On iOS/iPhone, .avif and .heif are the most widely supported formats for HDR stills, including Instagram. • Lightroom currently supports HDR export to AVIF/HEIF, which allows uploading HDR images directly to Instagram in up to ~2000 nits. • I shoot Canon .CR2 RAWs, process them in darktable, and want to publish them in HDR without going through TIFF/EXR → external encoder → re-tagging. • On desktop I view HDR10 output on a Lenovo P32pz-30 HDR monitor; AVIF with Rec.2020 + PQ/HLG metadata displays correctly.

At the moment, darktable can export to float TIFF/EXR for grading pipelines, but there’s no straightforward way to generate consumer-friendly HDR files for actual display/publishing.

⸻

What’s needed • Export to .avif (libavif) with: • Wide gamut ICC profile: Rec.2020 primaries. • Transfer function: PQ (ST.2084) or HLG (ARIB STD-B67). • Embed HDR10 metadata blocks: • Mastering display primaries: • Red: (0.708, 0.292) • Green: (0.170, 0.797) • Blue: (0.131, 0.046) • White: (0.3127, 0.3290) (D65) • MaxCLL (Content Light Level): e.g. 2000 nits • MaxFALL (Frame Average Light Level): e.g. 400 nits • Correct matrixCoefficients, colour_primaries, transfer_characteristics fields in the bitstream: • matrixCoefficients = 9 (BT.2020 non-constant) • colour_primaries = 9 (BT.2020) • transfer_characteristics = 16 (PQ) or 18 (HLG) • Optionally, parallel support for .heif (using libheif), which is also widely supported on Apple devices.

⸻

Benefit

This would make darktable competitive with Lightroom for HDR workflows and provide an end-to-end open-source HDR still photo pipeline, from RAW to Instagram/consumer HDR displays.

⸻

References • Pixls forum thread: Processing RAWs for HDR displays in darktable • libavif GitHub – shows HDR metadata support already exists in the encoder. • Apple iOS 16+ and Instagram both recognize HDR AVIF/HEIF with Rec.2020 + PQ/HLG tags.

⸻

Would it be possible to add this to the export module, similar to current TIFF/EXR options but with consumer-oriented HDR metadata baked in?

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[AndrewKeYanzhe]

@MaykThewessen I believe darktable already supports HDR AVIF export with PQ transfer function