[Cuis-dev] Oklab color space and Oklch

[Nicolas Cellier]

A connexe subject, here is one article explaining the gamma correction and
sRGB color space
https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/
Normally most image processing should be performed in linear RGB color
space, and I don't think that our BitBlt primitives really follow this
rule...
Nicolas

Le mar. 9 déc. 2025 à 19:46, Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> a écrit :

>
> 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
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251209/e4e65fa2/attachment.htm>