colorspacious
colorspacious copied to clipboard
RuntimeWarnings
I'm converting lots of colors to find the edges of the RGB cube, and getting RuntimeWarning
sometimes, which probably shouldn't happen?
cspace_convert((0, 0, 0), "JCh", "sRGB1")
C:\Anaconda3\lib\site-packages\colorspacious\ciecam02.py:333: RuntimeWarning: invalid value encountered in true_divide
/ (np.sqrt(J / 100) * (1.64 - 0.29**self.n) ** 0.73)
Out[3]: array([ 0., 0., 0.])
cspace_convert((2.0202020202 , 62.5 , 259.2), "JCh", "sRGB1")
C:\Anaconda3\lib\site-packages\colorspacious\ciecam02.py:397: RuntimeWarning: invalid value encountered in power
/ (400 - np.abs(RGBprime_a - 0.1))) ** (1 / 0.42))
C:\Anaconda3\lib\site-packages\colorspacious\basics.py:28: RuntimeWarning: invalid value encountered in less_equal
linear_portion = (C_linear <= 0.0031308)
Out[2]: array([ nan, nan, nan])
cspace_convert((5.050505050505051, 125.0, 223.20000000000002), "JCh", "sRGB1")
C:\Anaconda3\lib\site-packages\colorspacious\ciecam02.py:397: RuntimeWarning: invalid value encountered in power
/ (400 - np.abs(RGBprime_a - 0.1))) ** (1 / 0.42))
C:\Anaconda3\lib\site-packages\colorspacious\basics.py:28: RuntimeWarning: invalid value encountered in less_equal
linear_portion = (C_linear <= 0.0031308)
Out[2]: array([ nan, nan, nan])
etc.
import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)
1.0.0 1.13.3 sys.version_info(major=3, minor=6, micro=3, releaselevel='final', serial=0)
colorspacious.__version__
Out[6]: '1.1.0'
This doesn't indicate anything wrong with the code. There are some weird-but-correct edge cases in the underlying conversion formulas that trigger warnings, and I've been too lazy to track down exactly where we should be suppressing the warnings...
In the first case, I think what's happening is that there's a computation that goes like 1 / (1 / 0)
and ends up giving 0, which is correct in the weird rules these formulas use but makes numpy cranky in the middle. Probably that should be hidden.
The other ones appear to be the normal warnings you'd expect numpy to emit whenever it produces a nan, and in this case the answers legitimately are nan, so I guess the warnings are correct?
BTW, if you're trying to find the edges of the sRGB cube in JCh space, then it's probably simpler to start with the edges in sRGB and then convert to JCh instead of going the other way around :-). That's how the animated volumes in the scipy 2015 talk were produced.
but makes numpy cranky in the middle. Probably that should be hidden.
Yes, that's what I meant.
BTW, if you're trying to find the edges of the sRGB cube in JCh space, then it's probably simpler to start with the edges in sRGB and then convert to JCh instead of going the other way around
For a given J and h, I'm trying to iterate C from 0 until I hit the RGB wall, for generating bivariate colormaps with maximum chroma that can fit on the screen (and for a given illuminant or whatever) https://github.com/BIDS/colormap/issues/6#issuecomment-220839685 Previously I had it working with either colorpy
or colormath
But yeah I guess the second and third are kind of my fault for testing points too far out, when the wall is only at C=25.5:
(Got it working by turning NaNs into zeros: https://github.com/BIDS/colormap/issues/6#issuecomment-352002922)
(Also shouldn't cspace_convert((100, 0, 0), 'JCh', "sRGB1")
== [1.0, 1.0, 1.0]
? I get [ 1.014, 0.995, 0.992]
)
shouldn't
cspace_convert((100, 0, 0), 'JCh', "sRGB1") == [1.0, 1.0, 1.0]
?
I don't think this was a goal of the CIECAM02 designers, no. In color theory the concept of "pure white" is extremely complicated: https://en.wikipedia.org/wiki/White_point
BTW, if you're trying to find the edges of the sRGB cube in JCh space, then it's probably simpler to start with the edges in sRGB and then convert to JCh instead of going the other way around :-). That's how the animated volumes in the scipy 2015 talk were produced.
there's a problem: if you convert all 2^24 RGB points to JCh, then groupby J, h -> Cmax in 101 x 360 bins (like histogram2d with max instead of sum) some bins near J 0 or J 100 are empty:
Why: if you inflate a tilted rgb cube, black - white vertical, into a cylinder, there are too few rgb points near black / near white to fill those layers. (should've been obvious ...)