Color management support

### 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://

Posted by UjinT34 on Jan 14, 2025, 8:07 PM

Tags

• support (SaaS)

Related issues

• As I replied in another comment[1], it's their software, their choice.
• [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
• > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
• Feature request: support multiple named accounts per app/connector
• Support standalone Windows installer (`codex-setup.exe`)
• [feature]: Move OIDC back to self-hosted OSS(Plane Free)