macOS: add HDR/EDR preview pipeline tap for external viewer (fixes #17710)

[MaykThewessen]

Problem

Closes #17710. When editing HDR images in darktable on macOS, the viewer appears very dark because GTK3 has no way to communicate HDR colorspace information to macOS color management. All pixel values are clipped to 8-bit SDR at the gamma module, discarding any HDR signal above 1.0.

Solution

A lightweight, opt-in pipeline tap that forwards float pixel data to an external HDR viewer over a Unix domain socket. The Swift Metal viewer app lives in a separate repository to keep the darktable tree lean.

What this PR adds to darktable (~250 lines total)

1. src/common/hdr_viewer.c/.h — POSIX C client (no dependencies)

int fd = dt_hdr_viewer_connect();   // non-blocking, 200ms timeout, -1 if viewer absent
dt_hdr_viewer_send_frame(fd, w, h, rgb_float32);
dt_hdr_viewer_disconnect(fd);

Returns -1 immediately when the viewer is not running — darktable never stalls.

2. src/develop/pixelpipe_hb.c — pipeline tap (~30 lines)

Taps the float RGBA buffer that is the input to the gamma module — the last step before uint8 downconversion. At this point all HDR values above 1.0 are still intact. Guarded by a conf key (default OFF):

darktable --conf plugins/darkroom/hdr_viewer_enabled=true

External viewer (separate repo)

The standalone macOS Metal viewer app is at: https://github.com/MaykThewessen/darktable-hdr-viewer

It uses CAMetalLayer with wantsExtendedDynamicRangeContent and rgba16Float to display linear BT.2020 data with Extended Dynamic Range on XDR displays (up to ~1600 nits on M1 MacBook Pro).

Notes

• Zero overhead when viewer is off: connect() returns -1 immediately, guarded by conf key (default OFF)
• No new dependencies: the C client is pure POSIX (compiles on Linux too, just returns -1)
• No Swift/Metal in the darktable tree: viewer app is a separate project
• The tap reuses the same float buffer the colorpicker already reads — no extra pipeline pass
• A proper solution requires GTK4 color management support; this is an explicit workaround for the interim

Testing

Tested on M1 MacBook Pro (14", XDR display) with darktable master built via Homebrew toolchain. HDR AVIF images with PQ BT.2020 output profile show correct highlight rendering above SDR white in the preview window.

[zisoft]

cd tools/hdr-viewer
swift build -c release
.build/release/HDRViewer

Does that mean the user is required to build and run this on their target machine?
What about bundling into the macOS packages?
CI / nightly / release build?

[kmilos]

What about bundling

What about

1. Make macOS viewer an independent project outside of dt (could live in darktable-org though)
2. Make client and tap build optional (start OFF by default, turn ON in macOS nightlies)

IMHO, the recent general feature creep trend in the project is becoming somewhat worrying...

[MaykThewessen]

Good points from both of you — agree on keeping this lean.

Plan: split into two pieces.

1. This PR (darktable side) will be reduced to just the C client + pipeline tap:

   • src/common/hdr_viewer.c/.h — ~180 lines, pure POSIX, no new dependencies
   • src/develop/pixelpipe_hb.c — ~30-line tap before the gamma module, guarded by plugins/darkroom/hdr_viewer_enabled (default OFF)
   • src/CMakeLists.txt — one line addition

   When the viewer isn't running, connect() returns -1 immediately — zero overhead. The conf key is opt-in, so this is completely inert by default.

2. Separate repo for the Swift Metal viewer: MaykThewessen/darktable-hdr-viewer

   Self-contained macOS app. Could move to darktable-org later if the project wants to adopt it. Users install it independently (Homebrew cask or download a signed .app from releases).

This addresses @kmilos's feature creep concern — the Swift/Metal code lives outside the dt tree entirely. The C client in darktable is minimal and platform-agnostic (compiles on Linux too, just returns -1 when no viewer is listening).

Will update this PR shortly with tools/hdr-viewer/ removed.