[Cuis-dev] Oklab color space and Oklch

[Juan Vuletich]

Yep. See, for example #applySimpleGamma:to: in Cuis. Or 
ImageProcessing.pck.st

BitBlt works essentially only on gamma space. But you need more than 8 
bits per band to do image processing with reasonable quality. Usually 
Floating Point is best.

On 2025-12-09 5:21 PM, Nicolas Cellier via Cuis-dev wrote:
> 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 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>
>
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
-- 
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/2bc97d5b/attachment-0001.htm>