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

[sidewayss]

I'm asking here before presuming: Is this a bug? See this codepen: https://codepen.io/sidewayss/pen/JoPGdQy

Open the 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.

I'm testing invalid color strings of different types to see how they get processed. Removing the decimal place in this original color string's 2nd parameter, but not the 1st, causes an error to get thrown in my code. I just happen to be defaulting to jzczhz as one of my two color spaces.

[facelessuser]

Well, something is up. In my library, it handles these cases fine. I'll compare with a working example that runs fine in both, and then the problematic cases for comparison.

In the first example, the results are pretty much the same (ignoring floating point error differences likely due to floating point rounding differences when I generated my inverse matrix vs when Color.js generated theirs. Also, these can slightly differ at times depending on the platform they are done on. The point though, is that they are pretty much the same.

The next two examples mine converts and roundtrips fine while Color.js breaks down.

>>> Color("color(--lchuv 86.8 42.9 230)").convert('jzazbz').coords()
[0.19080045711600463, -0.02312030486839481, -0.03784299301779337]
>>> Color("color(--lchuv 86.8 429 230)").convert('jzazbz').coords()
[-0.8341670378101103, 213.87469579919897, 11.783872317426832]
>>> Color("color(--lchuv 86.8 429 230)").convert('jzazbz').convert('lchuv').coords()
[86.80000000000435, 429.0000000000131, 229.99999999999966]

And then color.js

> new Color("color(--lchuv 86.8 42.9 230)").to('jzazbz').coords
[ 0.19080045711600463, -0.02312030486839503, -0.037842993017793425 ]
> new Color("color(--lchuv 86.8 429 230)").to('jzazbz').coords
[ NaN, NaN, NaN ]
> new Color("color(--lchuv 86.8 429 230)").to('jzazbz').to('lchuv').coords
[ 0, 0, null ]

There's a couple differences for sure. I put in a few more protections for certain, non-ideal cases, so I have some signed power calls to account for powers on negative values. This provides sane results when some negative LMS values are generated due to the massive chroma being applied.

[sidewayss]

So I should submit this as a bug? Or maybe better that you do it with all the detail.

Great that you could locate it so quickly. It caused me to put a third level of validation in the input event of my text box, just in case. It's a version of the loop in the codepen that goes after the check for "NaN" in color.display(), which is after the try...catch block.

[facelessuser]

There's a couple of things.

1. Some signed power functions (util.spow) can help prevent the NaNs.
2. You won't get proper round trip due to the Absolute XYZ transform clamping negative values though: https://github.com/color-js/color.js/blob/main/src/spaces/xyz-abs-d65.js#L34. This isn't necessarily wrong. I don't clamp mine, but technically negative XYZ values are imaginary, and the PQ encoder expects positive values, though using spow can give it more sane behavior if it is going to get negative values anyway.

One thing is for certain, even if Absolute XYZ clamps negative values, you still get them during the LMS conversion if chroma is big enough compared to the lightness, so if the PQ encoder isn't updated to at least try and handle them sanely, you will get NaNs. NaNs could be expected with a perspective of "you've surpassed what Jzazbz is designed for", but if you protect against the NaNs, you will at least get sane values you can work with, even if they may not technically be right. Unclamping Absolute XYZ would then allow these sane values to round trip.

Anyway, I guess we need to figure out what Color.js wants to do. I can "fix" it if Color.js deems the current behavior as unacceptable. Then they need to decide how much of what I suggest they wish to do.

[facelessuser]

In short, you can file it as a bug, but we need to see if it will be viewed as such and if so, what measures are found to be acceptable.

[sidewayss]

I submitted issue #613 - same title as here. I kept it simple, essentially a copy/paste/edit of this original question. You can add what you see fit. Thanks!

[sidewayss]

we need to see if it will be viewed as such and if so, what measures are found to be acceptable.

I have my extra validation step regardless. So I'm set. Hard to imagine more validation than checking the coordinates in every available space. With Color.js still in a 0.N version a little extra validation might be expected.