jz**** color spaces have NaN where all other spaces have numbers

[sidewayss]

https://codepen.io/sidewayss/pen/JoPGdQy

Open the CodePen console and you'll see a list of space ids followed by coordinates. The only NaN coordinates are in the jzczhz and jzazbz spaces.

This is a bad set of coordinates to begin with, but the fact that it's just these two spaces makes me think that it's a bug.

This issue is based on this Q&A: #612

[svgeesus]

Sorry not to have noticed this issue until now.

I agree that this is a bug.

Looking again at the code for Jzazbz, I confirmed that the matrix values and the equations are the same as in the Sadfar et al paper. They also seem to be the same as in the Jacob Rus observable.

I agree with @facelessuser that Absolute XYZ should not be clamped to positive values, and that the code for Jzazbz should use the sign-preserving spow() function. I made those changes in a color.js branch.

Looking now at the conversion from sRGB white, in the (modified) colorjs I get color(jzazbz 0.22207 -0.00016 -0.00012) and color(jzczhz 0.22207 0.0002 216.08). The chroma for pure white strikes me as way too high.

The same conversion in Coloraide:

chris@SuperNomad:~$ python
Python 3.12.3 (main, Jan 17 2025, 18:03:48) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from coloraide import Color
>>> w = Color('white').convert('jzazbz')
>>> print(w)
color(jzazbz 0.22207 -0.00016 -0.00012 / 1)
>>> w2 = w.convert('jzczhz')
>>> print(w2)
color(jzczhz 0.22207 0.0002 216.08 / 1)

The observable notebook (after changing the color to be converted to whte, and the media white luminance to 203) gives

user_jab = 
    
  Array(3) [
  0: 0.22206398164774332
  1: -0.00016398964837013863
  2: -0.00010233622023381184
]

So these are all giving the same values (to 5 significant figures) and yet the chroma for white looks suspiciously high.

If a simple monochromatic color is giving bad values, I certainly don't trust conversions of wildly high chroma values.

[svgeesus]

It looks like the brighter the neutral color, the greater the chroma shift, and all at a consistent hue:

• color(--rec2020-linear 0.002 0.002 0.002) is color(jzczhz 0.01008 0.00002 216.08)
• color(--rec2020-linear 0.2 0.2 0.2) is color(jzczhz 0.11443 0.00014 216.08)
• color(--rec2020-linear 2 2 2) is color(jzczhz 0.29066 0.00022 216.08)
• color(--rec2020-linear 12 12 12) is color(jzczhz 0.5719 0.00027 216.08)

[facelessuser]

Maybe this will clear something up. Jzazbz is kind of based off CAM work. So models like CAM16, CAM02, and all of those that have some assumption of background luminance, adapting luminance and such. All of these spaces, when the eye is not fully adapted, have chroma that behaves in a similar way, where colors that one would normally consider achromatic have higher and higher chroma as the lightness increases. When the eye is adapted, the achromatic line will behave differently. CAM16 will give you all zeros for chroma then.

ZCAM, which was either based off similar work as Jzazbz (or the other way around, I don't recall), has chroma behave in a similar way. As a matter of fact, it looks similar for JzCzhz, ZCAM, and CAM16.

[svgeesus]

@faceless2 thanks! So, this makes returning achromatic hues as none tricky.

[facelessuser]

I messed up with the first plots. I've updated with correct chroma, but the shape is the same.

[svgeesus]

Open the CodePen console and you'll see a list of space ids followed by coordinates. The only NaN coordinates are in the jzczhz and jzazbz spaces.

With the modifications suggested by @faceless2 ](#635 now get color(--lchuv 86.8 42.9 230) = color(jzazbz 0.1908 -0[.0231 -0.0378) = color(jzczhz 0.1908 0.0443 238.6) ie it no longer blows up with NaN everywhere.

[facelessuser]

So, this makes returning achromatic hues as none tricky.

@svgeesus Yes, if you mean achromatic to mean achromatic according to sRGB, Lab, etc., then yes. If achromatic is relative to the space (meaning when chroma is zero in the given space, then no, you just use the same logic, but it won't be won't be pure white, etc. I think that is not what is intended in CSS though...

I always assumed that adapting lightness and background luminance would affect the appearance of what is achromatic in the model, but I'm not sure about the intention and why this occurs in these models or if colors below this line are supposed to be ignored.

I've personally, after at one time generating true achromatic splines (which get close to the achromatic curve, sort of), decided I would just treat achromatic relative to the space. CAM16, JzCzhz, etc. are achromatic when close to zero, their achromatic just looks a little different due to the environment.

This does bring up a good question though, if we want zero chroma to mean pure white at the given lightness, is JzCzhz a good space for CSS in that regard, or is doing gymnastics to calculate that "true" achromatic line (according to the other spaces) worth the effort.

Also, I think you meant @facelessuser, faceless2 is going to be confused why they keep getting pinged 🙃 .