Calculating "inGamut(space)" #488
-
|
Aloha! 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? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment · 1 reply
-
|
Easy peasy. Just call > 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')
falseInternally, yes, it converts the color space to the specified gamut. It does check the 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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank You! 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: 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! |
Beta Was this translation helpful? Give feedback.
Easy peasy. Just call
inGamutand send the space in that you want to test.Internally, yes, it converts the color space to the specified gamut. It does check the
range. It doesn't care aboutrefRangeas those are defined only as references for percentages, only if a color has a definedrangeis 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 happe…