Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color management support #9064

Open
UjinT34 opened this issue Jan 14, 2025 · 4 comments
Open

Color management support #9064

UjinT34 opened this issue Jan 14, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@UjinT34
Copy link
Contributor

UjinT34 commented Jan 14, 2025

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)

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

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

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

@UjinT34 UjinT34 added the enhancement New feature or request label Jan 14, 2025
@ninetailedtori
Copy link
Contributor

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
Copy link
Contributor Author

UjinT34 commented Jan 15, 2025

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
Copy link
Contributor

ninetailedtori commented Jan 15, 2025

Yea, that makes sense :D

@Nel-xhan
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants