Color management support

[UjinT34]

Description

An app has some content in format A and says to compositor that it is in format B. The compositor stores it in format C and tells video drivers that it is in D. Monitor display it as E which leaves the user with what the F is going on?
To reduce this frustration and get some better visuals a color management system is needed for proper content processing on the way to a display device.

1. Compositor needs to decide which format better suits current clients and outputs:

• Simple: single monitor - use the max supported format

• Advanced: take into account all the clients and use a lesser format if it is enough to reduce resource consumption

• Tricky: multi-monitor setup - needs some common format
  Caveat: monitors lie about their capabilities, clients lie about their content

  Some relevant info is in output->parsedEDID for monitor capabilities and surface->colorManagement->imageDescription() for a client (assume sRGB if missing)

2. Compositor should convert all clients' buffers to the selected format and prepare a buffer for displaying
   Needs some shaders. Direct buffer manipulation might be easier but highly ineffective. This step should be avoided if possible.

3. Compositor should convert prepared buffer and/or set some drm properties to match output capabilities

• https://drmdb.emersion.fr/properties/3435973836/DEGAMMA_LUT output->state->setDeGammaLut
• https://drmdb.emersion.fr/properties/3435973836/CTM output->state->setCTM
• https://drmdb.emersion.fr/properties/3435973836/GAMMA_LUT output->state->setGammaLut
• https://drmdb.emersion.fr/properties/3233857728/HDR_OUTPUT_METADATA output->state->setHDRMetadata
  Caveat: not all properties might be supported by the given video driver, some of this properties might accept different values on different drivers, properties listed in a "natural" color pipeline order but it is not guaranteed to be so

HDR10 for a fullscreen app is the easiest thing to do because it can got straight to step 3 with little to none modifications. Might still need some drm properties adjusting. Current implementation uses only HDR_OUTPUT_METADATA.
On paper color management should be relatively simple and straightforward. In reality some bits should be ignored in favor of some sane defaults. Some double back and forth conversions might be needed just to slap a transformation in between. What those bits and defaults are might depend on hw setup.

Lots of docs about color and HDR https://gitlab.freedesktop.org/pq/color-and-hdr

Somewhat a duplicate of #4377

#9506
#9600
TODO

• Convert primaries
• Handle luminances
• Mark relevant proto features as supported
• Add a way to change output image description
• Add a setting for fullscreen passthrough
• Fix desktop effects with HDR
• CM for decorations
  • Border issues Border rendering does not work for the first few seconds on launch #9888 Borders blinking in hdr #10422
• Wiki page
• CM for blur
  • tiled
  • floating
  • Background behind translucent window has artifacts in hdr #9852
• CM for cursor
  • software
  • hardware
  • hardware with cpu buffer copy
• Better monitor image description settings HDR/CM: Black levels aren't perfectly black, huge issue for OLED #9716 Monitor v2 HDR rules #10623
• Better fullscreen logic Auto hdr #9785
  • SDR passthrough Fix CM for DS and SDR passthrough #11503
  • HDR passthrough
• Direct scanout
  • SDR
    • primaries Fix CM for DS and SDR passthrough #11503
    • luminances
  • HDR
    • PQ10
    • scRGB (not possible?)
  • Handle SDR/HDR switch with DS or block DS when content and monitor settings do not match cm: handle CM for SDR content with cm=hdr, cm_sdr_eotf=2 #12127
• Better internal format (FP16?) FP16 support #10558 Experimental FP16 #11000
• Handle icc profiles
• Optimize CM shader Use precomputed primaries conversion #9814
  • don't use math for global constants
  • use pre-calculated matrices for primaries conversion and luminances
  • borders are delayed #9795 opengl: add missing skipcm if case #10888
• Utilize drm properties
  • (DE)GAMMA_LUT
  • CTM Fix CM for DS and SDR passthrough #11503
• Handle YCC
• Decode to linear renderer: implement wp-color-management-v1 transfer functions #11084
  • SRGB
  • GAMMA22
  • GAMMA28
  • ST2084_PQ
  • HLG
  • BT1886
  • ST240
  • LOG_100
  • LOG_316
  • XVYCC
  • ST428
• Encode from linear (check drm properties and monitor capabilities, everything supported by the hw might be covered already) renderer: implement wp-color-management-v1 transfer functions #11084
  • SRGB
  • GAMMA22
  • GAMMA28
  • ST2084_PQ
  • HLG
  • BT1886
  • ST240
  • LOG_100
  • LOG_316
  • XVYCC
  • ST428
• Proper proto error handling Handle inert CM outputs #11916
• Better inverse tonemapping Renderer: High quality inverse tonemapping for SDR on HDR. #11341 cm: higher-quality tonemapping #12204
  • Handle mastering primaries
• Correctly handle color values outside 0.0 - 1.0 range

[ninetailedtori]

Just trying to understand point 1.3 - Per-monitor HDR would require us to implement a common format between all monitors used? That might be conflicting with a potential client's setup with an HDR monitor and a monitor they'd like SDR content on. But if we were to do the ideal setup of being able to tie colour management per monitor, we'd need to be able to individualise the colour management protocols to each monitor instance, as well as content translations. My other worry would be in that case about apps that might at some point be spread between two monitors as well, and how we'd handle those. We could simply disable rendering for the window when it's between a monitor, in such a case. This issue wouldn't happen if we implemented a check and requirement for HDR that monitors need to have the same colour management specs though.

[UjinT34]

There is a content format, output format and a preferred format. In ideal situation they are all the same and no CM is needed. It is highly unlikely in a multi-monitor setup. So preferred format should be picked to avoid CM for at least one of the outputs without sacrificing color accuracy for the others. If the app chooses to provide it's content in a preferred format the part of this content which is displayed on an output matching the preferred format will be rendered without CM. And parts on the other outputs will need some CM matching their formats.
E.g. when one output is HDR and the other is SDR the preferred format should match the HDR one. HDR content will be displayed as intended on the HDR output and will require CM for displaying on the SDR one.
Not really worth to put much thought into it at the moment because existing proto clients (at least those I am aware of) ignore the preferred format.

[ninetailedtori]

Yea, that makes sense :D

[Nel-xhan]

I am really interessted in HDR support. I cant wrap my head around how to enable it. Do i have to enable certain flag(s) when building. Help is appriciated.

[nergdron]

with the new experimental HDR support in 0.47.0, there's weird issues where switching between virtual desktops where there's HDR content on one and SDR content on another causes the whole display to switch HDR to switch on and off, but the SDR images are super washed out when this happens. I assume this ticket is the pre-req to that working correctly (ie SDR displays in normal SDR ranges after switching out of an HDR app)?

more to the point, is there a way to reset hyprland's handling of SDR content after this happens, other than just restarting hyprland?

[UjinT34]

Switching back to SDR works for me. Maybe your monitor keeps hdr active for some reason. Or some other software modifies gamma and/or ctm (night mode or something similar). You can try to toggle experimental:wide_color_gamut and experimental:hdr. If this doesn't help open a new issue please.

[Samir2zk]

Yeah I can't turn off HDR once enabled. I have hdr = false xx_color_management_v4 = false wide_color_gamut = false under experimental and ENABLE_HDR_WSI=o but still doesn't disable it. Any idea on how to disable it in Hyprland? I got no hdr setting in my monitor, only says if it's on or off. ( I have to go back to KDE to enable or disable RIP )

[Soliprem]

so what's the situation now after the new protocol?

[UjinT34]

so what's the situation now after the new protocol?

still no CM, only protos. more correct implementation of the official one added .