Screen captures are always rendered to sRGB; implement xx-image-capture-color-management-v1 so wide-gamut content survives screenshots

[marcusbuffett]

Summary

On a wide-gamut output with colour management enabled, the screen is rendered in the output's colour space, but every screenshot and screen-share frame is converted to sRGB first. Colours outside sRGB display correctly and then clip in the capture. This happens for every capture client, including ones that bind wp_color_manager_v1.

Where it happens

src/managers/screenshare/ScreenshareFrame.cpp (v0.56.2 and current main): copyDmabuf(), copyShm() and storeTempFB() each call setImageDescription(NColorManagement::DEFAULT_SRGB_IMAGE_DESCRIPTION) on the capture framebuffer before rendering. renderMonitor() computes IS_CM_AWARE and passes .cmBackToSRGB = !IS_CM_AWARE, but since the target framebuffer is sRGB either way, aware clients receive the same sRGB-converted pixels.

Reproduction

• Hyprland 0.56.2 (Arch/Omarchy), render:cm_enabled = true. Internal panel eDP-1 (LG), EDID primaries wider than Display P3, cm = "edid", XRGB8888.
• Chromium 152 launched with --enable-features=SurfaceColorManagement --force-color-profile=display-p3-d65 --force-raster-color-profile=display-p3-d65, showing this test page (gist). On screen, each "P3 max" swatch is visibly more saturated than the "clipped to sRGB" swatch next to it.
• grim -o eDP-1 of that screen. Sampled pixels:

swatch	"P3 max"	"clipped to sRGB"
brand green	(0, 182, 96)	(1, 181, 95)
brand orange	(255, 84, 0)	(255, 83, 0)

The capture is the sRGB clip. A grim build that additionally binds wp_color_manager_v1 (so isClientCMAware() returns true) captures byte-identical output.

Proposal

wayland-protocols has merged xx-image-capture-color-management-v1 (experimental; the ext- version is !448). It gives a capture client get_capture_source_colors → the compositor's preferred image description for a capture source, and set_frame_image_description to choose the frame's encoding.

Implementing it in Hyprland would mean: advertise the output's image description (CMonitor::m_imageDescription / workBufferImageDescription()) as the preferred description for an output capture source, and render capture frames into the description the client set instead of the hard-coded sRGB one. Clients that don't use the protocol keep getting sRGB, so current behaviour is unchanged for them. With that, screenshot tools can tag their files with the right colour space, which is what makes screenshots on macOS come out matching the screen.

I can test builds on this hardware.

[github-actions[bot]]

This discussion has been automatically closed.
Discussion format is NOT optional!

[github-actions[bot]]

⚠️ Strike 1/3 issued to @marcusbuffett by system.