bjornornorn

Just a small correction: Logarithmic != gamma encoded. Most software use sRGB encoding which is close to a power function (often referred to as a gamma function). Logarithmic encoding is often used for encoding HDR images, but is not what most software use.

Thanks a lot for the kind words!

Yeah, should be similar a lot of the time. Deep blues are the colors that are the most different.

Thanks!

Regarding: “Cube is beautiful in the sense that it allows scaling the intensity without considerations, but it is quite awful in the near black psychovisual performance.”

Yeah, that is the tradeoff, same for dealing with hdr values. The idea with Oklab is to avoid having to know what luminance the eye is adapted to, by treating all colors as if they are within the normal color vision range basically. Makes it simpler to use and more predictable to use, but makes predictions in the extreme ends worse than it would be taking knowledge of the viewing conditions into account (given that you can do so accurately)

E.g. linear ramp for near black values would not be good if you are in a dark room, only viewing very dark values full screen on a monitor (so there isn’t anything bright around to adapt to)

Yes, exactly. The results will be more accurate as in closer to perception of light (for rendering for example you would want a linear color space)

Nice! Definitely the the type of use case I had in mind.

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.

The largest difference is that JzAzBz has been designed to model lightness perception of very bright colors and very dark colors. Depending on your use case this could either be useful or a problem, since it means that you have to be careful with the scaling of the input data to JzAzBz.

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.

Not that familiar with XYB and its properties. Is there anywhere I can read more? Found some specifications, but not anything on its properties.

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.

Yeah, that’s pretty much why I didn’t include it.

I haven’t really seen YCrCb used except anywhere for in compression, so didn’t think of including it (an neither do most papers related to perceptual color spaces).