Calculating "inGamut(space)"

[SoftMoonWebWare]

Aloha!
I've been trying to wrap my head around this repo for a minute now. So very powerful, so very complicated.

I really want to understand HOW this repo calculates "inGamut". I think I understand that it checks the "Color Object's" "range" or "refRange" property, or converts it to the color-space who's gamut we are trying to find, then checks these values. Is this correct?

For instance, I want to know if "OKLCh( _L, _C, _h)" is in the P3 gamut or the Rec.2020 gamut or ... maybe ? ... the UHD gamut? I need to convert to those color-spaces (though the XYZ space), then check if their values are in range?

[facelessuser]

Easy peasy. Just call inGamut and send the space in that you want to test.

> let c = new Color('rec2020', [0, 0, 1]).to('oklch')
undefined
> c.coords
[ 0.42344825660521684, 0.3828105916181844, 245.0667522688908 ]
> c.inGamut('rec2020')
true
> c.inGamut('srgb')
false

Internally, yes, it converts the color space to the specified gamut. It does check the range. It doesn't care about refRange as those are defined only as references for percentages, only if a color has a defined range is it bound to a gamut.

Hope that makes sense. Most of the time, you don't need to know any of that, but it is nice to be able to understand what is going on to have a deeper understanding of what is really happening.

[SoftMoonWebWare]

Thank You!
My project is 6300+ lines of code and 12-13 years old.
It relies on an old (but always evolving) library for color conversions.
Changing the interface from the old library to this new one would be far more work, and I prefer to use all my own libraries anyway, or at least stick to those that I basically comprehend. I use an old "to-colorblind" library file, and while I don't comprehend the algorithm fully, I get it enough to modify it to work with my purposes.

So I'm trying to understand how all this works, so I can incorporate it into my RGB_Calc library file. It was designed to work exactly like I need it to under various conditions, while delivering the fastest performance available under various conditions, for creating graphics when you are calculating the color of thousands if not hundreds of thousands of pixels. In JavaScript, Arrays are FAST. Objects are NOT. Functions are FAST. Creating an object just to use it's prototyped methods is NOT.

I don't know the full extent of the use of this library, but I see a lot of Object-oriented stuff going on when it comes to "color-objects" vs. "color-arrays". My library uses the best of both worlds, under the conditions you need, at your command.

I need to check if my output is in-gamut as I convert the color, and return null if not. The gamut will be a configuration option of a given RGB_Calc instance (RGB_Calc is a conversion-calculator class constructor, as well as a stand-alone conversion-calculator). If not, I gotta LOT of overhead in a LOT of places in that 6300+ lines of code that needs to be completely rewritten.

I am happy that it looks like it will adapt to all-new gamuts (beyond sRGB) with ease; just the overhead of all the conversions will be the slow-point.

Now I am awaiting:
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API
to take effect.

And still trying to wrap my head around HOW bit-depth is figured. Standard per color-space, i.e. REC2020 is ALWAYS 10-bit/channel or 16 bit or whatever? Or will that be platform specific? Monitor specific? Will the Media_Capabilities_API provide the answers? First I gotta get a computer with a newer graphics board, then the new monitor, or all I will be doing is guessing anyway...

Mahalo! and Aloha!