Hacker News Reader

Hacker News

Comment by bjornornorn | Hacker News Reader

Parent Full thread

bjornornorn

Author here.

Wow, thanks a lot!

If anyone has any questions feel free to post here and I can try to answer.

I have another post that goes into more detail onhow software often gets color wrong:

https://bottosson.github.io/posts/colorwrong/

View on HN

It's a great article, and an interesting new colour space. It would be really interesting to see a variety of image transformations done in each of these colour spaces, on a variety of images (photos in particular). E.g. resizing and blurring as jiggawatts suggests, and also things like brightness, contrast, saturation, white-balance, etc.

How big are your datasets? Would the parameters get better if they were bigger, or have they converged to some optimum?

A couple of typos I spotted: "asses", "he final".

Yeah, would be nice. I've been thinking a bit about following up with that.

The generated dataset consists of a few thousand colors. The hue dataset is using 15 different hues only. Some more data there could definitely be useful.

I think the biggest problem is that there isn't that much experimental data overall, especially for wide gamut colors. The hue data is from experiments with sRGB displays if I remember correctly, and CIECAM I think has mostly been derived based on surface paints, which makes it fairly limited.

Comprehensive experiments done using modern calibrated wide gamut displays would be fantastic.

Thanks, will have a look at the typos!

Let me recommend reducing the number of decimal digits in your published forward matrix to 4 or 5. There's no way the extra 5 digits are making a practical difference here, and they make it a lot harder to write down in a visually compact way.

Do it soon before you have too many people creating independent implementations.

Your OKlab vs HSV plot is useful, but left me curious what that would look like in CIE Lch just varying hue. It seems the most direct comparison to me, just workign in LCH vs your proposal and the post isn't super clear about the benefit.

Actually, I'd love to see this sort of hue-only varying comparison to several other popular color spaces, including CIELAB and HLS, too.

There are a two different CIE LCh color spaces: they are cylindrical samplings of CIELAB and CIELUV, similar to how Oklab can also be sampled with cylindrical coordinates

The comparisons with CIELAB and CIELUV are using LCh coordinates. That’s how hue and chroma predictions are made using those spaces.

Hello

Really nice work!!! How does it compare with HSLuv (https://www.hsluv.org/)? It seems that both scheme try to manage the perceptual color problem...

That is based on CIELUV, which is one of the spaces tested against in the article. CIELUV is useful because its chromaticity space is a projective transform of XYZ. That also means it doesn't predict perception of hue as well as more complex models.

Yeah, I feel like I learned more in color science in one post, than I've accumulated in a life time ;)

I'm sure you're aware that a quick and dirty method of fast image segmentation is just to compare image frames in varying color spaces. Would sRGB be the best "complement" to oklab in such a pipeline?

Also wondering aloud here if maybe you haven't stumbled upon an ideal color space for optical flow fields between pixels in moving images, in video prediction research for example? Great work!

I have suggestions for a color picker. It's definitely non-traditional.

Instead of a continuous gradient for the color, show patches of color in a randomized order. Display the colors over top of grayscale gradients of different sizes. This helps to deal with the trouble of human perception being affected by background and by solid angle. You might also want to consider showing the new color right over or around an image of the user's choice.

For example, on a small screen, you might have a 256x256 patch on a 512x512 grayscale gradient for the currently selected color, and numerous 16x16 patches on 32x32 gradients for the choices that the user can make.

With each click on a choice, the whole array of choices is redone.

Available choices are provided as variations of the current choice and any colors that might have been bookmarked. Take the current choice, and vary the hue. Take the current choice, and vary the saturation. (including the negative extreme, positive extreme, and grey) Take some properties (hue, saturation, etc.) from the current choice, and others from a recent bookmark. Probably also throw in a 3x3x3 sRGB to make dramatic changes simple. Be sure to include everything that is within 2 or 3 units of the current choice in sRGB. In a plane that slices through the current selection and the grey line, provide choices that run along lines from the current choice in 4 different directions: black through the current selection until out of gamut, white through the current selection until out of gamut, along the saturation axis both directions, and along the L axis parallel to the grey line.

So with each click, you head in the direction you prefer.

I've been trying to get into this area of study.. what did you read to know all this stuff?

The best online resource is https://www.handprint.com/HP/WCL/wcolor.html

Or you can buy an introductory color science book or two. Let me recommend Mark Fairchild's Color Appearance Models, https://www.amazon.com/dp/1119967031/ but here are a few others https://www.amazon.com/dp/1119367220 https://www.amazon.com/dp/0470024259 https://www.amazon.com/dp/1118173848/ https://www.amazon.com/dp/0470049049

Yeah, both of those are good recommendations!

I also think it is useful to focus on understanding the various experiments that have led to the different color models. The most important one is the experiments that led to CIE XYZ. Lecture notes from universities seem like one of the best sources of info about the basics. Such as this: https://www.cl.cam.ac.uk/teaching/1516/AdvGraph/02_Light_and...

Other experiments that are interesting, but a bit hard to find information about are: The Munsell renotation effort in the 1940s, the experiments that led to OSA-UCS, the MacAdam ellipses.

I also like this paper since gives a fairly good overview and lots of new keywords to search for: https://www.osapublishing.org/viewmedia.cfm?uri=oe-25-13-151... (and is freely available)

For those interested in the Munsell system:

Landa & Fairchild 2005, "Charting Color from the Eye of the Beholder", http://markfairchild.org/PDFs/PAP21.pdf

* * *

Nickerson 1940 "History of the Munsell Color System and Its Scientific Application" https://doi.org/10.1364/JOSA.30.000575

1943 OSA Munsell renotations report: https://doi.org/10.1364/JOSA.33.000385

Nickerson 1976 "History of the Munsell Color System, Company, and Foundation" (3 parts) https://doi.org/10.1111/j.1520-6378.1976.tb00003.x https://doi.org/10.1111/j.1520-6378.1976.tb00017.x ahttps://doi.org/10.1111/j.1520-6378.1976.tb00028.x

Nickerson 1983 obituary for Alex Munsell, https://munsell.com/color-blog/alexander-ector-orr-munsell/

Kuehni, "The early development of the Munsell system" https://doi.org/10.1002/col.10002

Fun bonus: https://observablehq.com/@jrus/munsell-spin

How well do halftoning algorithms work in Oklab and other perceptual color spaces? E.g., would results of Floyd Steinberg look better when error diffusion is done in Oklab vs. the other or the raw color spaces?

Another question: When going back from Oklab to the device color space, some numbers may at times fall out of range (e.g., negative). Is there a recommended way to bring those back into range to perceptually close colors?

Thanks.

Dithering is usually best done in a linear space; the mixing of light is modeled as a physical rather than a perceptual process. This is especially true when the pixels are small and one can imagine a low-pass filter removing the high spatial frequencies. When dithering to huge, chunky pixels that can be individually perceived, different considerations might apply.

Indeed, I have observed for it to work better in the raw space. Even going to linear gamma space seems to hurt.

However, it's not clear to me why should this be so. For a given wavelength, I would understand that mixing in physical space would be better, i.e., this may apply to lightness. Why should it not work better when applied more generically in a perceptual space (Note: I have worked with displays with more than three primaries), even when pixels are not individually perceptible.

If you're trying to show raw space RG (50, 50), then when you show (100, 0) and (0, 100) in adjacent pixels, there are exactly 50 * 2 units of light distributed over each pair of pixels, so your eyes will see (50, 50) if the pixels are small/far enough.

Another way to put this is that dithering works because of physical blending of photons due to an insufficiently sharp eye lens before perceptual mechanisms in the brain.

You are taking the example when dithering is done independently for each color channel. Dithering can also be done across color channels, which can be useful for displays with more than three primary colors. Even in those cases, I found dithering to work better in the physical space, and not in perceptual space. I am trying to understand why.

Further, the question still remains why is it that mixing of photons spatially as you explained works better imperceptible pixels, and yet we need these non-linear color spaces when having larger areas.

Goes without saying that the intensity hit for 50 need not be the midpoint of that hit for 0 and 100 given the gamma curve, and actual mapping of the value to intensity for the pixel.

Dithering is best done linearly with respect to light intensity.

But if you zoom in enough, any smooth curve looks linear.

Great work! Just noted that the color space was already added to the culori.js library, including a cylindrical oklch variant.

Reply on news.ycombinator.com