[Cuis-dev] Oklab color space and Oklch

Juan Vuletich juan at cuis.st
Tue Dec 9 10:46:31 PST 2025


On 2025-12-09 3:07 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> On Wed, Dec 10, 2025 at 00:21 Juan Vuletich <juan at cuis.st> wrote:
>
>
>     Why didn't you use 0.0 and 1.0 as min and max values?
>
>
> I just followed the specification. The chroma parameter doesn’t really 
> have an upper limit, I’m not sure why it was made in this way. In 
> practice, it doesn’t seem to make a difference to go over 0.5, and CSS 
> uses 0.4 as 100%.

I wasn't clear. Apologies. I mean, in #okl:c:h: I read

     min := -0.00001.
     max := 1.00001.

I think I'd prefer 0.0 and 1.0, unless there's some reason for that I 
don't see.

>
>     Would you provide the conversion from sRGB (i.e. our Color
>     instances) to
>     OkLCH? That is really needed too. I'd also want an instance creation
>     method that answers nil if parameters lie outside our sRGB space of
>     Color instances (i.e. if the OkLCH values can not be accurately
>     represented by an instance of Color). Does #okOrNilL:c:h: sound
>     reasonable? Any better option? With these two, I could do
>     something like
>     #experimentsTowardsANewColorPalette but using this better color space.
>
>
> Yeah, my idea was to try to do some sort of parallel protocol for 
> different color spaces, something like aColor okLChDo: [:L :C :h| …], 
> HSLDo:, etc. Later we could rethink messages like #hue (that currently 
> returns the HSL hue, and its different to the OkLCH hue), and I’m not 
> sure if we should eliminate those methods or make a unifying choice of 
> a specific color space and coordinates.
At least #okLCHhue, #okLCHluminance and #okLCHchroma are needed as a 
first step, it would be great if you could cook those. We can later 
decide if we want to keep HSL or not. We may decide to remove it.
> The message okOrNilL:c:h: might be ok, aother option could be 
> okl:c:h:ifFail: with a block as argument, not sure.

Yep. That's good too.

> And perhaps later we could start cleaning up all those messages like 
> veryVeryMuchDarker, quiteDarker, etc, or come up with something better 
> (should again look at what designers do for these things, I think).
>
>
>     Finally, it would be wonderful to migrate all our theme related
>     stuff to
>     this. This is so much better! Also, all our 'groups of shades' and
>     'transformations' methods look so primitive... We really need to
>     update
>     all that stuff.
>
>
> Yes, absolutely, I think it would be great. I’ll try to help with 
> anything necessary, perhaps do it in small steps so that we don’t 
> break everyones themes. Hopefully more people will be interested in 
> helping with all this… it’s a fun project and there are many 
> small parts to it.
>
> Cheers,
> Luciano

Thanks,

-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251209/bfcc5dfe/attachment.htm>


More information about the Cuis-dev mailing list