[Cuis-dev] Oklab color space and Oklch

[Juan Vuletich]

This is great, thanks!

I just had to expand `Color experimentsTowardsANewColorPalette` with new 
possibilities.

New stuff now at GitHub. Everybody, play a bit with this. It is sooo cool!

Cheers,

On 2025-12-10 6:50 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> 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 Vuletich
>     www.cuis.st <http://www.cuis.st>
>     github.com/jvuletich <http://github.com/jvuletich>
>     researchgate.net/profile/Juan-Vuletich <http://researchgate.net/profile/Juan-Vuletich>
>     independent.academia.edu/JuanVuletich <http://independent.academia.edu/JuanVuletich>
>     patents.justia.com/inventor/juan-manuel-vuletich <http://patents.justia.com/inventor/juan-manuel-vuletich>
>
>
-- 
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/20251210/2ee7c29d/attachment.htm>