In Compose UI or better put, in skiko, is there na...

# compose

[Ali Khaleqi Yekta]

In Compose UI or better put, in skiko, is there native support for displaying colors beyond rgb? I'm asking because even though Compose Color class supports storing a color in Oklab space, its companion Color properties use RGB.
Can we actually "display" oklab colors like in web?

[romainguy]

What APIs are you talking about? Color can store colors in various color spaces including non-RGB

[romainguy]

The problem though is that Canvas always converts to sRGB at the moment (which is fine for oklab since the display isn’t oklab)

[romainguy]

It is however an issue for wide gamut colors. You can use the native Canvas on android to render wide gamut or HDR though

[romainguy]

Note that oklab is used to animate colors already

[Ali Khaleqi Yekta]

@romainguy
> Color can store colors in various color spaces including non-RGB
Exactly! And the fact that it can be stored in oklab, yet every single companion property in androidx.compose.ui.graphics.Color (src) just uses sRGB, made me doubt that maybe trying to put any wide gamut colors into display may actually render/display that color in the sRGB space regardless.

[Ali Khaleqi Yekta]

The problem though is that Canvas always converts to sRGB at the moment

Exactly my question!

[Ali Khaleqi Yekta]

(which is fine for oklab since the display isn’t oklab)

I don't understand. What do you mean by display isn't oklab?

[Ali Khaleqi Yekta]

This whole question initially started as I saw the complete migration of modern web development towards oklch(...) as the default way of defining colors, specially after Tailwind moved completely from rgb in v3 to oklab in v4, as, well, for many reasons, but one being that it essentially contains more vibrant colors that RGB lacks.

oklab is used to animate colors already

...another perk of the oklab colorspace as the default is exactly this. No need for going back and forth between srgb and oklab. Color mixing can be most natural and color display can be more vibrant.

[romainguy]

The fact that the predefined constants are in sRGB doesn't mean wide gamut colors can't be used. And RGB doesn't "lack" vibrant colors. RGB is a color models, and sRGB is a gamut within that color model. There are many RGB gamuts, some are even larger than the visible spectrum (ACEScg for instance)

[romainguy]

oklch is nice because it provides HSV/HSL like ergonomics without being tied to the smaller sRGB gamut.

[romainguy]

Again, nothing to do with what Compose can or cannot render

[romainguy]

I would add that even when Tailwind chooses oklch as its default, color blending still happens in the RGB color model as this is still what rendering pipeline use to store pixels (and what displays accept as input)

[romainguy]

Like I said, the native Canvas can render in wide gamut and HDR just fine, it's just that Compose doesn't at the moment. Fixing it is a bit tricky because of a mismatch between Compose's color spaces and Android's color spaces

[romainguy]

Standardizing on a single color space is not ideal btw. The approach taken by Android/Compose is typical color management: a color can be defined in any number of color spaces and is converted to the color space of the render target

[Ali Khaleqi Yekta]

@romainguy Thanks for the detailed and quick answer! I was conflating the RGB color model with sRGB/Hex limits. That makes more sense. So, the core issue isn't the color space I'm using to define the color (Oklab vs P3), but rather that Compose's drawing pipeline currently bottlenecks everything down to sRGB before it hits the screen?

Is there an existing issue tracker or roadmap for wide-gamut support in Compose Canvas? Since standardizing on oklab is becoming common for design systems (for the mixing/ergonomics benefits you mentioned), it would be great to actually see those colors rendered faithfully without any clamping.

[romainguy]

I filed an issue about it internally before I left. No clue what the timeline is on fixing it unfortunately. Note that rendering to sRGB is also not related to mixing colors in Oklab. These are independent things

[romainguy]

(also Oklab is not perfect either and has its own issues)

[Ali Khaleqi Yekta]

Standardizing on a single color space is not ideal btw.

And may I ask for this particular point you mentioned, is it ideal for application-level design system palettes to default to oklab? I don't know much in this area, I assumed following web best practices can't be that bad.

[romainguy]

I don't think Oklab is a good input. Oklch sure. But Lab models are opponent models and not particularly intuitive

[Ali Khaleqi Yekta]

(also Oklab is not perfect either and has its own issues)

Oh, that's not good. So I guess there's no "pick and forget" approach to this.

[romainguy]

Colors and color management is a deep rat hole infested with evil spawns who will ruin your life 😂

[Ali Khaleqi Yekta]

That's... sad😂💔

[romainguy]

Even if Compose was not limited to sRGB it doesn't mean colors will be entirely faithful. You're still bound by what the render target and the display can do, which may or may not match what your designers did

[romainguy]

(and perception is another layer on top that ruins everything as the colors of your walls, the size of your screen, the lights around you etc. can change how you perceive the final colors)

[Ali Khaleqi Yekta]

You're still bound by what the render target

Oh yes that's for sure, but I just wanted every choice to be good on my side. Of course we can't even guarantee the target screen would have colors at all, or if the user is not color blind, etc.

[Ali Khaleqi Yekta]

I really don't know anything at all. Do you maybe have any advice for application-level code to deal with colors? or anything in your experience that has the least downsides to it?

[romainguy]

The two most important things are:

[romainguy]

• Get designers and developers to make sure they use displays with a similar gamut (and properly color managed)

[romainguy]

• Make sure all colors chosen by designers are in a well defined color space (engineers can always convert them to whatever they need)

[romainguy]

You might also find this useful:

[romainguy]

https://docs.google.com/document/d/12W-n3nTl6C8-SyeP_trvKBXQirMLmvsGGl3yUlQsHaQ/edit?usp=drivesdk

[romainguy]

Ah here's the bug i filed that explains everything:

[romainguy]

https://issuetracker.google.com/issues/388511109

[Ali Khaleqi Yekta]

Thanks for the help! I learned a lot (of disappointing facts😂). Appreciate it!

[romainguy]

The bug explains what happened. It's a silly mistake that happened years ago. When we first tried to enable non sRGB it broke a bunch of apps. The only correct fix I can think of would require to synchronize the release of Compose and Material and get apps to update both at the same time 😕

[Ali Khaleqi Yekta]

Oh god. Why does it have to be so inconvenient

[romainguy]

I hope that smarter folks than me on the compose team will find a solution that avoids this

[romainguy]

But yeah, nasty side effect of optimizations (constants inlined by the compiler, and constant values conflicting between platform and Compose, which is silly considering that the same team owned both sides 😂 Shit happens 🤷‍♂️)

[Ali Khaleqi Yekta]

The more I read the issue the more confused I get.

This would therefore require introducing new APIs like Long.toPlatformColorLong() and Long.toComposeColorLong()

And this is a new issue. In 2025. Over one of the most primitive things about UIs.

[romainguy]

I wouldn't call it the most primitive but yeah it'd be nice if it was fixed quickly. That said it also shows that most devs don't seem to care much about wide gamut or HDR 😕