range of JzazBz coordinates

[eonadler]

We have encountered the following issue, which has been reproduced using a few independent RGB --> JzAzBz implementations (including colorio and https://github.com/quag/JzAzBz/blob/master/python3/srgb255ToJzAzBz.py) ---

The JzAzBz paper (https://doi.org/10.1364/OE.25.015131) seems to suggest that the coordinates should span roughly Jz in (0,1), Az in (-0.5, 0.5), Bz in (-0.5,0.5). However, when we explicitly map all RGB tuples in (0,255) x (0,255) x (0,255) to JzAzBz as follows, we find that (Jz, Az, Bz) span (0,0.167), (-0.09,1.09), (-0.156,0.115).

So we're wondering if the original paper renormalized their coordinates, or if there's a mistake on our end.

Extremely simplified code that demonstrates the basic issue:

import numpy as np
import colorio

colorspace = colorio.SrgbLinear()
colorspace2 = colorio.JzAzBz()

jzazbz_test = np.zeros((256,256,256,3))
for i in range(0,255):
    for j in range(0,255):
        for k in range(0,255):
            jzazbz_test[i][j][k] = colorspace2.from_xyz100(colorspace.to_xyz100(colorspace.from_srgb1((i/255.,j/255.,k/255.))))

print('min Jz={}'.format(np.min(jzazbz_test[:,:,:,0])))
print('max Jz={}'.format(np.max(jzazbz_test[:,:,:,0])))

print('min Az={}'.format(np.min(jzazbz_test[:,:,:,1])))
print('max Az={}'.format(np.max(jzazbz_test[:,:,:,1])))

print('min Bz={}'.format(np.min(jzazbz_test[:,:,:,2])))
print('max Bz={}'.format(np.max(jzazbz_test[:,:,:,2])))

[nschloe]

Without getting to the bottom of the matter, let me first suggest to vectorize the code. Python loops are awefully slow, so you never want to use them. This

import numpy as np
import colorio

colorspace = colorio.SrgbLinear()
colorspace2 = colorio.JzAzBz()

X = np.linspace(0.0, 1.0, 256)
x, y, z = np.meshgrid(X, X, X)
pts = np.array([x, y, z])

jzazbz_test = colorspace2.from_xyz100(colorspace.to_xyz100(colorspace.from_srgb1(pts)))

print("min Jz={}".format(np.min(jzazbz_test[0])))
print("max Jz={}".format(np.max(jzazbz_test[0])))

print("min Az={}".format(np.min(jzazbz_test[1])))
print("max Az={}".format(np.max(jzazbz_test[1])))

print("min Bz={}".format(np.min(jzazbz_test[2])))
print("max Bz={}".format(np.max(jzazbz_test[2])))

is about 70 times faster.

Next, a picture of the SRGB gamut, created with

import colorio

colorio.show_srgb_gamut(colorio.JzAzBz(), "out.vtu", n=100) 

Okay, this conincides with what you've measured.

In the article, they're referring to the Rec.2020 cube which is larger than sRGB, so there's one difference. The difference in the scales however seems too big to explain that. Perhaps I could add a function that returns the Rec.2020 gamut in any color space to confirm.

It'd be awesome if you could check the values of colorio against their MATLAB ☹️ reference implementation at https://figshare.com/articles/JzAzBz_m/5016299.

[nschloe]

Okay now, here's the Rec.2020 (HDR) gamut. Doesn't look right either, so need to confirm with the MATLAB code.

[jrus]

The “XYZ” coordinates they are using are counted in nits, and range from 0 to 10000. It’s not clear if the best way to use the color space is to scale white to 10000, or instead to leave the maximum at whatever the actual luminance of the display is.

[jrus]

If you want to compare against another implementation I believe https://observablehq.com/@jrus/jzazbz is correct w/r/t the paper.

[nschloe]

I've just checked with the Ebner-Fairchild and Hung-Berns plots of JzAzBz, and they look alright in the current implementation. The Rec2020 plot looks wrong.

When changing to nits, Ebner-Fairchild and Hung-Berns are out of whack while the SRGB (Rec. 709) blob looks like what they have as Rec 2020.

Something is wrong.

I've tried contacting the authors over a year ago, but only got back to M. Safdar who referred me to M.R. Luo who never replied.

[jrus]

I don’t know what specifically you are plotting or what “look alright” or “out of whack” mean.

I would recommend you try scaling white to 10,000 before converting to Jzazbz in every one of your desired plots and see what happens.

[nschloe]

Okay, I've added some images to make the situation clearer:

On master: Ebner-Fairchild, Hung-Berns, and Munsell data seem okay.

With the suggested change, everything seems wrong, but the gamut resembles more closely what's given in the article.

Ebner-Fairchild

article	master	with change

Hung-Berns

article	master	with change

Munsell, level 5

article	master	with change

Rec. 2020 (HDR) gamut

article	master	with change

[eonadler]

Thank you both for your insightful comments.

My group is interested in JzAzBz because it is perceptually uniform under a Euclidean metric. So I'm not concerned about the specific coordinate ranges, even if they are different with respect to the paper, if they just reflect linear transformations of the coordinate system.

So, given that the change suggested by @jrus is a rescaling, do you think the coordinate range issue is just a matter of convenience? To me, the Rec. 2020 gamut in @nschloe 's final plot just looks rotated with respect to master, which isn't an issue for my use case.

[jamadagni]

I simply multiplied the JzAzBz output by 598.1807563064359 which is 100 divided by the Jz component corresponding to RGB triplet (255,255,255). I find the resulting numbers nice to compare with the output of the LAB/CAM02/CAM16:

        RGB |                           LAB |                      CAM02UCS |                      CAM16UCS |                 JZAZBZ-SCALED
  0   0   0 |    0.0000    0.0000    0.0000 |    0.0000    0.0000    0.0000 |    0.0000    0.0000    0.0000 |    0.0000    0.0000    0.0000
  0   0 255 |   32.3026   79.2022 -107.8533 |   31.2239   -8.3659  -39.1590 |   36.2552    8.5896  -37.8669 |   41.4225  -18.4584  -93.4991
  0 255   0 |   87.7370  -86.1777   83.1908 |   87.0057  -32.2317   30.4331 |   86.5506  -35.4870   27.5038 |   78.8833  -55.5455   60.1641
  0 255 255 |   91.1165  -48.0717  -14.1263 |   90.2576  -28.4179   -9.2366 |   90.6384  -28.5505   -8.5056 |   86.2685  -36.2323  -15.9889
255   0   0 |   53.2329   80.0906   67.2008 |   60.0487   38.6798   24.3153 |   59.1734   40.8207   21.1519 |   59.1962   59.6086   54.5743
255   0 255 |   60.3199   98.2421  -60.8341 |   66.6790   36.4558  -21.1075 |   67.3853   40.2178  -19.1223 |   70.3016   56.2463  -45.9072
255 255   0 |   97.1382  -21.5641   94.4861 |   97.4097  -10.3133   35.6083 |   96.8014  -12.7831   33.0375 |   94.1758  -14.4070   68.9318
255 255 255 |  100.0000    0.0000    0.0000 |  100.0000   -1.9170   -1.1378 |  100.0000   -1.8976   -1.0728 |  100.0000   -0.0802   -0.0493

[daT4v1s]

there seems to be an error in the reverse part of the model

y = (y_ + (self.g - 1) * x) / self.g

y = ((z_ * self.b - z_ + x_) * self.g + (y_ - z_) * self.b + z_ - x_) / (self.b * self.g)

i couldn't get the reverse transform to line up otherwise (arduous)

[nschloe]

@daT4v1s Could you open a new issue for that?

[nschloe]

@daT4v1s Forget about it, that's a non-issue. Your alternative expression is exactly the same as the original one. Open an issue if there still is something wrong.

[eonadler]

I'm closing this, since based on the helpful diagnostic plots from @nschloe, I believe that the normalization/range issue is purely cosmetic, and does not affect the relations between JzAzBz coordinates.

[nschloe]

@eonadler It'd be great to find out what's wrong; there seems something fishy about the Rec.2020 plots in the article.