Surround Induction Factors... N_c curiously different?

[briend]

I have no idea if this is a typo or just different for some valid reason, but the DIM and DARK conditions have N_c factors of 1.95 and 1.8 instead of 0.95 and 0.8, respectively.

https://github.com/njsmith/colorspacious/blob/master/colorspacious/ciecam02.py#L19-L27

I checked wikipedia and Colour-Science and they seem to use 0.95 and 0.8:

https://github.com/colour-science/colour/blob/master/colour/appearance/ciecam02.py#L108-L111

[KelSolaar]

@briend : We use the parameterisation from [1]:

It differs very slightly from [2] where Nf for Dim equals 0.9 instead of 0.95:

References

1. Moroney, N., Fairchild, M. D., Hunt, R. W. G., Li, C., Luo, M. R., & Newman, T. (2002). The CIECAM02 Color Appearance Model. Color and Imaging Conference, (1), 23–27. Retrieved from http://www.ingentaconnect.com/content/ist/cic/2002/00002002/00000001/art00006
2. Fairchild, M. D. (2004). Color Appearance Models (2nd ed.). Wiley. ISBN:978-0470012161

[KelSolaar]

The positive thing is that this should not affect the Viridis &c o colormaps as the surround used is average.

[njsmith]

I probably just screwed up when typing in tables of numbers. I love how I even added a comment at some point with the right numbers, without noticing the discrepancy...

@KelSolaar That discrepancy pretty weird. Do you think Fairchild (2004) rounded to 1 decimal, or... what? I guess the proper thing to do would be to check what the actual CIE spec says, but I'm not really interested in paying €66 for it...

[KelSolaar]

[3] uses the rounded version:

I'll spin a mail to Mark!

References

3. Luo, M. R., & Li, C. (2013). CIECAM02 and Its Recent Developments. In C. Fernandez-Maloigne (Ed.), Advanced Color Image Processing and Analysis (pp. 19–58). New York, NY: Springer New York. doi:10.1007/978-1-4419-6190-7

[briend]

@njsmith yeah I saw the commented table w/ the correct numbers and wracked my brain trying to imagine a valid reason for the discrepancy. I almost didn't report it, and then I remembered that we are still human and a typo like that is exactly the kind of thing I would do :-)

[njsmith]

Yeah, it turns out color technology is a nightmare when it comes to correctness, because it's all about big tables of numbers and complicated formulas that you have to copy out of papers, and there aren't any solid "gold standard" values to check your computations against. And if you do get something wrong then maybe it looks a little weird, but who will notice, really? You can test against other implementations, but sometimes they don't exist, or they can be wrong too... I did a lot of work tracking down reference values for the colorspacious test suite, but even that mostly checks that computations are correct for given inputs; it doesn't tell you that the inputs are correct, and these constants are inputs :-/.

[njsmith]

Okay, I just released v1.1.1 with the fix. Thanks again for catching this!

[briend]

Oh I totally understand. That is, I barely understand anything ;-). I'm trying to add ciecam color adjusters to MyPaint and it's been pretty "fun" dealing with negative and >1.0 RGB values. To pile on to that I'm allowing adjustable illuminants, axes, and a "color purity" hard limit (so you can limit you color choices to greys, muted pastels, etc). It's kind of neat that the concept of colorfulness (or s or C) is related to the illuminant. So, if you limit you colorfulness to, say, max of "30", you'll be limited to a different set of colors under D65 versus illuminant A. Sort of a way to give your painting a limited palette or color mood by constraining your color selections. Without that hard limit, though, the illuminant makes no impact since, for example, you can still articulate a strong saturate "blue" color under illuminant A; it will just have an outrageous colorfulness value.

So anyway that led me to trying different surrounds since it sounds like I should be using DARK when I'm working on a computer in the dark, I suppose. Not surprisingly, I don't notice any difference whatsoever w/ different surrounds. But, at least we can rest knowing those values are "correct". . . maybe :-)

[njsmith]

So CIECAM02 is a model that given some description of the light hitting your eye, and the viewing conditions, attempts to guess what kind of subjective sensation you'll experience. The reason the illuminant conditions affects the estimated colorfulness is that your brain tries to "adjust" for the color of the illuminant when it's figuring out the color of objects. So if the illuminant is a bit blue, and then some light hits your eye that's a bit blue, your brain goes "ah-hah, this must be light reflecting off a white object, so I will perceive it as white, not blue".

Anyway. For a painting program, you're probably ultimately storing sRGB, and we assume that ultimately people are going to be taking those sRGB images and putting them on their website or something for their friends to look at? In this case I think I'd suggest sticking to colorspacious's defaults for sRGB↔CIECAM02 conversion – we don't actually know what the viewing conditions will be for their friends looking at the website, but it probably doesn't have much to do with the viewing conditions the artist happens to be working with. And if your goal is to, say, have the friends perceive the image as having a specific limited palette, then it's their viewing conditions that matter.

[KelSolaar]

Mark replied and the official CIE number is 0.9:

The official document says 0.9 for dim. (1.0 for average and 0.8 for dark). However it does allow for intermediate values if so desired, so a 0.95 value is by no means “off limits”.

I guess this needs another update :)

[briend]

@KelSolaar Haha. . . I probably shouldn't have been so PR-happy. :) @njsmith should I do a PR or do you want to just fix it (probably already did by the time I type this heh)

[njsmith]

@KelSolaar Just looking over your screenshots again before rolling a new release, and I noticed there's another discrepancy! Your [3] has the Dark c as 0.535, while [1] and [2] have it as 0.525. What do you think? Should we hassle Mark again?

[njsmith]

(This is also making me nervous about all the other tables of constants...)

[KelSolaar]

I think the correct one is 0.525: https://github.com/igd-geo/pcolor/blob/master/de.fhg.igd.pcolor/src/de/fhg/igd/pcolor/colorspace/Surrounding.java#L68

This implementation directly references CIE 159:2004.

Is that number worth $69.96?, I don't really want to bother Mark with that again.

[KelSolaar]

So confirming it is 0.525, my collection of CIE standards just +1 :(

[njsmith]

Released v1.1.2 with the fix.