[Cuis-dev] Oklab color space and Oklch

[Luciano Notarfrancesco]

Oh, I get it now! Those -0.0001 and 1.0001 were weird, I think I
accidentally carried it over from some code snippet I found on the
internet. I also went with the okNilL:c:h: selector as you said and
simplified the method that implements the binary search. I also implemented
oklchLightness, oklchChroma and oklchHue as you suggested. Perhaps later we
could remove HSL stuff and simplify it to just #lightness, #chroma and
#hue. #luminance could still be useful, but it means something different to
lightness.

Also, I've been playing a bit with shades, tints and tones. The
nomenclature in the current messages is a bit weird, the correct names are
'shade' for a mix of a color with black, 'tint' for a mix with white, and
'tone' for a mix with gray (which in our case should be gray with the same
lightness, not middle gray). I don't include those methods yet because I
still have to implement interpolation. Currently, Color>>mixed:with:
interpolates the RGB coordinates, but with OKLCH we can do it better (and
somewhat slower, but I think it's worth it).


On Wed, Dec 10, 2025 at 1:46 AM Juan Vuletich <juan at cuis.st> wrote:

>
> 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 Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251210/1fbf675d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7753-MoreOKLCH-LucianoEstebanNotarfrancesco-2025Dec10-14h32m-len.001.cs.st
Type: application/octet-stream
Size: 5596 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251210/1fbf675d/attachment.obj>