Check if color is a human, visible color [MacAdams Limits]

[facelessuser]

I'm not quite sure how I'd like to approach this, or when, but it would be interesting to implement if possible. While neat, it is not absolutely required, but I'd like to look into. There are already premeasured limits out there, much like the Pointer gamut, but it would be cool to calculate it if we can do so in a way that doesn't take forever to calculate. this would allow more accurate results.

[eeeps]

https://www.researchgate.net/publication/44673524_Fast_and_accurate_model_for_optimal_color_computation

In case it's helpful, there's a MATLAB algorithm in this article that I've seen referenced a few places. "The computation takes around 10s for each locus using MATLAB 2010a with Windows XP x64/2.8 GHz Intel Core 2 Duo/2 GB RAM." So maybe a second or two on modern hardware. No idea if there's a smart way to less work by either:

• only computing the sliver of the locus that shares a hue angle with the color in question
• using some set of fixed illuminants, rather than arbitrary illuminants

[facelessuser]

I did look at that paper before. I saw this as well: https://www.researchgate.net/publication/39435417_A_new_algorithm_for_calculating_the_MacAdam_limits_for_any_luminance_factor_hue_angle_and_illuminant.

I just haven't taken the time to dig deeper than a quick glance at the papers.

[eeeps]

So I think you might be able use the same technique you used to implement Pointer's Gamut checking, but with MacAdam's data from this 1935 paper (Here are some relevant screenshots: 1, 2, 3). R here = "visual efficiency", this technique will only work if that = luminance (Y). I am not sure about that assumption.

[facelessuser]

Yes, a LUT would obviously work. Of course a tradeoff of how big a LUT to keep in memory vs accuracy would have to be considered. I'd hate to include a high precision LUT table as it would be large and eat up a bunch of memory. The Pointer gamut approach uses a very small table because that is the only data available and it is small enough to not be a big deal. I'd like to get around to dynamically calculating whether a point is in or outside of gamut, but obviously a LUT is a solution that would indeed work.

[facelessuser]

It's likely we'll go with a LUT approach, regardless of whether we have an implementation that can generate values on the fly. I imagine it would be a "rough" approximation, as I'm not sure we want a giant table. It'll basically give you an idea if you are somewhere close to or past the furthest bounds. I'm generating some simple LUTs to get a baseline now, utilizing the Colour Science library...It's taking forever to get the optimized chroma for the given Lab lightness and hue steps. We'll see how it goes.

I may explore the faster approach once I have a baseline to see if it is an approach worth adding, as a manual way to get more accurate values. If it takes 10 seconds, it's definitely not something we'd have as the default way. Evaluation of it may come later, though. I figure I'll at least get something in now. It should let us add a rough visualization of the visible spectrum in various spaces in our demo app as well. I went ahead and added Pointer's gamut visualization on the main branch.

[facelessuser]

EDIT: That was supposed to be xyY in the image 🤷🏻 .

Figured out why it was slow. Seems we have an okay LUT for approximation. We just need to decide how big we care to support. Now we can check if a color is roughly around the gamut and force it in. It should be noted, though, that this is not a perfect fit to the visible spectrum.

[facelessuser]

Ugh, this approach is a little finicky. It can clip colors even in sRGB. It's just not accurate enough. I'll have to give this more time to work out something that approximates the gamut without clipping in gamut colors. It's fine for plotting, but not so much for detecting in gamut colors.

[facelessuser]

So, using a high res LUT and interpolating it in xyY (which has nice rounded, smooth contour), I think clipping sRGB resolved.

I tried plotting in Rec. 2020, and I was confused as parts of Rec. 2020 are clearly sticking out of the Rösch-MacAdam solid. This doesn't make sense.

So I checked out Color Science's visualizer "Colour-Visualizer", and the same thing is visible, so I'm not crazy:

And if you use Colour Science's in gamut check, it also gives False for Rec. 2020 Linear green:

>>> from coloraide.everything import ColorAll as Color, NaN
>>> import colour
>>> shape = colour.volume.spectrum.SPECTRAL_SHAPE_OUTER_SURFACE_XYZ
>>> cmfs = colour.MSDS_CMFS["CIE 1931 2 Degree Standard Observer"].copy().align(shape)
>>> ill = colour.SDS_ILLUMINANTS["D65"].copy().align(shape)
>>> xyz = Color('rec2020-linear', [0, 1, 0]).convert('xyz-d65').coords()
>>> colour.volume.is_within_visible_spectrum(xyz, cmfs, ill, tolerance=1e-12)
array(False, dtype=bool)
>>> Color('rec2020-linear', [0, 1, 0]).in_visible_spectrum()
False
>>>

So it seems we are behaving in a similar way. If we were checking the max extent (max-width), then yes, all of Rec. 2020 would be contained. But currently, very intense colors can protrude. I need to dig into this more. The implementation seems fairly sound, but maybe my understanding of what it means to be in the visual spectrum is confusing me 🤔. I assumed if the chromaticity points were within the xy plane, you are in gamut, but obviously, the Rösch-MacAdam solid is going to taper has luminance increases, narrowing which chromaticity points are in the solid at different luminance.

[facelessuser]

I think what we are targetting is more of a optimal color solid.

The optimal color solid or Rösch–MacAdam color solid is a type of color solid that contains all the possible colors that surfaces can have. That is, the optimal color solid is the theoretical limit for the color of objects*. It is bounded by the set of all optimal colors.

[facelessuser]

Now that I understand we are approximating the optimal color solid, this makes more sense. Tests are proving that what I have is a viable solution. We can detect and fit colors to this gamut. Now we can play with finding out how big a LUT we actually need. I fear that if we aren't big enough, we can easily clip spaces, just due to the shape of the gamut we are targeting. I guess that is a starting point. If we can implement a practical way to do it on the fly (I'm not holding my breath on a fast enough way in pure Python), then we can do that, if not, a big LUT is likely the only way.