Wide-gamut (Display P3) images render sRGB-clipped on wide-gamut displays (blocked on Qt Quick HDR renderer)

[spantaleev]

Summary

Images with a wide-gamut embedded profile (Display P3 iPhone photos, Adobe RGB screenshots) render less vivid in Komai than in color-managed apps (Element, Eye of GNOME) on a wide-gamut display. #228 fixed the worst case by baking embedded profiles to sRGB at decode time, so colors are now correct within sRGB. But that bake clips wide-gamut content down to sRGB, so on a wide-gamut monitor the result is accurate-but-limited: roughly "halfway" to what a color-managed viewer shows at full P3. This issue tracks closing that gap.

Current state (shipped)

• Fix media-viewer image quality: sharp zoom, colour management, opaque backdrop #228 (merged, 2902a0f61) added convertToColorSpace(sRGB) in utils::readImage / utils::readImageFromFile (commit b8b4c438d), so P3 pixels are no longer shown as-if-sRGB. This is the correct, sanctioned approach on current Qt and fixes the common desaturation case.
• Fix media-viewer image quality: sharp zoom, colour management, opaque backdrop #228 explicitly documented "wide-gamut / P3 not addressed" as a known limitation. This issue is that limitation.

Root cause: Qt Quick, not Wayland/KWin

Investigated 2026-07-01 on Qt 6.11.1 + KDE Plasma 6 Wayland. Native wide-gamut rendering is not achievable with public Qt APIs today:

1. No public swapchain color-space API for Qt Quick. The wide-gamut/HDR formats exist on the low-level QRhiSwapChain::Format (HDRExtendedDisplayP3Linear, HDRExtendedSrgbLinear) but are not exposed on QQuickWindow / QQuickGraphicsConfiguration; QQuickWindow::swapChain() is read-only.
2. Qt Quick uploads QImage textures verbatim and never applies QImage::colorSpace(), so even P3 pixel data is shown as sRGB. No property/flag changes this.
3. The Wayland piece exists but is not enough alone. Qt 6.11 speaks wp_color_manager_v1 client-side and KWin supports it (Plasma 6.2+), but QSurfaceFormat::setColorSpace() tags the whole window, which would reinterpret the entire sRGB UI as P3 and oversaturate it. Per-surface tagging can't isolate the image region, and there are no wide-gamut pixels to present anyway (see 1 and 2).

Upstream trackers

• QTBUG-126035 - HDR support in Qt Quick (In Progress, no fix version): https://bugreports.qt.io/browse/QTBUG-126035
• QTBUG-134590 - HDR-capable renderer for Qt Quick (Open): https://bugreports.qt.io/browse/QTBUG-134590
• QTBUG-92853 - older umbrella (Open): https://bugreports.qt.io/browse/QTBUG-92853

Enabling infrastructure already in place: wayland-protocols color-management-v1 (staging): https://wayland.app/protocols/color-management-v1 - KWin support since Plasma 6.2: https://kde.org/announcements/plasma/6/6.2.0/ - Qt 6.11 gained the Wayland client color-management-v1 binding.

What would unblock this

When Qt ships a public Qt Quick HDR/wide-gamut renderer (QTBUG-126035): request a wide-gamut/extended swapchain for the media-viewer window, feed non-sRGB-baked textures for wide-gamut sources, and tag the surface via QSurfaceFormat::setColorSpace() (already wired in Qt 6.11). Until then, the sRGB bake stays as the pragmatic choice.

Scope

Wide-gamut / color-management only. The separate at-rest downscale-sharpness limitation also noted in #228 (Qt bilinear vs Chromium Lanczos) is out of scope here.

Environment

Qt 6.11.1, KDE Plasma 6 Wayland, wide-gamut display. Reproduces with any Display P3 image (e.g. an iPhone JPEG) compared side by side against Element or Eye of GNOME.

Related to #228