41–50 of 94 posts
I don't understand why they don't compare it with YCbCr, which is a very similar colorspace that is much more widely used than some of the obscure ones they compare it with - notably, in JPEG.
This is some great work. The notable point here is that the work is done by a Computer Graphics Programmer using Open Source Free software (colorio and colour-science both for Python ) and not a Researcher using Closed Source Commercial software like Matlab.
FWIW, researchers I know use C++, Python, Linux and many open-source tools.
Earlier quoted context omitted.
> depends on the viewer’s adaptation state IIRC, both D65 and D50 are sufficiently extreme as to prevent full chromatic adaptation. Viewers will be aware a scene is lit "cold" or "warm"ly. > ICC’s relative rendering intent is supposed to take care of Yes. Browser support used to be poor, but I've not been following it. Firefox seems to still require user config?[1] A perhaps outdated WP article[2] suggests chrome sup…
Chromatic adaptation is definitely one of the trickier questions in color management. Here's my take on it. For the most part, when looking at a monitor, chromatic adaptation is pretty good. In other words, RGB #FFFFFF looks white, not light blue, and #808080 looks gray, not bluish-gray. It does start falling apart when you mix different lighting, for example holding a white piece of paper to the screen under normal…
This is a tour de force of colour theory, and should be mandatory reading for anyone serious about computer colour! Björn Ottosson not only did some mighty fine work, producing a simple equation that produces smooth colour gradients, but he "showed his work" too. Instead of just journal references, he littered this page with incredibly useful hyperlinks to difficult to find things such as the raw data for the Munsell…
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/
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.
Earlier quoted context omitted.
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/
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 c…
I’ve been using a variant of JzAzBz for the last year or so. Perceptual color spaces make image generation much easier. Can you help me understand how JzAzBz falls down?
Earlier quoted context omitted.
Another rather substantial difference is in M2 matrix of Oklab. In my experiments I don't see S-participation in colors with high spatial frequency. Because in image compression a lot of information is in high spatial frequency, one gets favorable image compression when M2 matrix is without S contribution in Luma. We use just [b b 0, a -a 0, -0.5 * c, -0.5 * c, c] in the M2 phase in JPEG XL. The two 0s there don't br…
One more interesting and substantial difference between Oklab and XYB is that XYB includes biases before the nonlinearity, i.e., one can consider the M1 matrix as a homogeneous matrix. These biases make the receptive model (more) linear close to zero, and the non-linearity ramps up when one goes further into high intensity. The idea there is to model the spontaneous opsin isomerization in the receptors. I believe sRG…
I think this might be a case where the requirements for image editing and image compression are different.
For image editing, especially when working with HDR images, I think it is better to just have a simple power function, since this makes less assumptions on the exact viewing conditions. E.g a user might want to adjust exposure while editing an image, and if the prediction of hue changes when the exposure is altered, that would be confusing (which happen if more complex non-linearities are used). When compressing final images though, that wouldn’t be an issue in the same way.
Earlier quoted context omitted.
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 c…
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.
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.
bjornornorn, thank you! I’m looking forward to trying it out! I’ve been using a variant of JzAzBz for the last year or so. Perceptual color spaces make image generation much easier. Can you help me understand how JzAzBz falls down?
E.g, if you scale a color by some value before converting to JzAzBz, the predicted hue will be different than without scaling.
Oklab will predict the same hue regardless of scale (but could also mean it does worse for extreme colors). So it is a trade off, with oklab being designed to be less complex.
Great article! I wish I would have had this a couple of years ago when I was working on improving a very old lossy image compression algorithm. I don't want to into great detail here, but there's a highly compressed image format that's designed so that it's super easy for low power (think 1990's embedded processors) to read and render. Basically the decompression is a bunch of LUTs - not just palette lookups, but als…