Plug-In: PercepTool 2

[jcr6]

Do you have a better term to describe numeric clipping in the channels?

Tell us how to say it correctly. At this point you must understand what I mean to say.

[andrewrodney]

Originally Posted by jcr6

Do you have a better term to describe numeric clipping in the channels?

Tell us how to say it correctly. At this point you must understand what I mean to say.

Yes, its called clipping! Gamut has no place in the discussion.
There is tonal clipping (all three channels clip) and saturation clipping (you have less than all three but at least one channel clipping). Its easy to see this in Adobe Camera Raw’s Histogram. White/Black: all three channels clip. Color, one or two channels are clipping (with the current rendering settings which of course you can alter).

Red=Red channel
Green=Green channel
Blue=Blue channel
Yellow=Red+Green channels
Magenta=Red+Blue channels
Cyan=Green+Blue channels

[jcr6]

I'm sorry. I shouldn't have thrown the word "gamut" into the mix. (barely resisted a pun, here.)

I see you've got a LIVE session coming up. Hope it goes well.

[gmachen]

Originally Posted by jcr6

Do you have a better term to describe numeric clipping in the channels?

Perhaps "ambit" clipping.
Means the same thing as "gamut" in ordinary language usage, but whereas the latter is pretty much reserved for the bounds of a given color space in our context, it probably only could foster confusion. One might think of amit as the bounds within a given gamut?

[jcr6]

Follow up question, In your opinion is it a fair statement that colors with a constant ratio of red to green to blue, in any color working space, are really the same color just with different luminance?

[gmachen]

^ I think you'd be safer from the attack of the pedants here if you'd just say that they're the same hue. In my opinion, two samples with the same hue but different tonality are a different color, in layman-speak.

In Photoshop's color picker, one can enter different sets of RGB values of constant ratio, e.g., (256,128,64) and (128,64,32), and one can see that the hue value remains constant at 20, so strictly speaking they're the same "color," but to my subjective perception, they really are different colors.... I also have a vague recollection that somewhere in the annals of color science there may be an actual perceived hue shift with changing tonality, ceteris paribus, so unless I'm mistaken about that, there really would be an actual change in color.

[jcr6]

I could agree that the hue component is the same. But I think it is more than that.

Is the saturation different? In both HLS and HSI spaces the saturation is constant when you do that. in fRGB, the ratios remain constant so only luminance changes. In L*a*b the math is murky:

//LAB<-->RGB Conversion functions (from Foley and van Dam)
void _ConvertRGB24toLAB8(unsigned char *data8, long width); //conversion in place
void _ConvertRGB24toLAB8(unsigned char *data8, long width)
{
long x;
for (x = 0; x < width; x++)
{
long x3 = x * 3;
float R = data8[x3];
float G = data8[x3+1];
float B = data8[x3+2];
float L = (R + G + B + (float)1.0) / (float)3.0; //has to stay in range
float a = (float).33333*(R - G) + (float)127.5;
float b = (float).83333*((R + G) / (float)2.0 - B) + (float)127.5;
if (a < 0) a = 0; else if (a > 255) a = 255;
if (b < 0) b = 0; else if (b > 255) b = 255;
data8[x3] = (unsigned char)L;
data8[x3+1] = (unsigned char)a;
data8[x3+2] = (unsigned char)b;
}
}//_ConvertRGB24toLAB8

void _ConvertLAB8toRGB24(unsigned char *data8, long width); //conversion in place
void _ConvertLAB8toRGB24(unsigned char *data8, long width)
{
long x;
for (x = 0; x < width; x++)
{
long x3 = x * 3;
float L = (float)data8[x3];
float a = ((float)data8[x3+1] - (float)128.0)*(float)3;
float b = ((float)data8[x3+2] - (float)128.0)*(float)1.2;
float R, G, B;
R = (L + a/(float)2.0 + b/(float)3.0 + (float)0.5);// L*a*b model
G = (L - a/(float)2.0 + b/(float)3.0 + (float)0.5);
B = (L - (float)2.0 * b/(float)3.0 + (float)0.5);
if (R < 0) R = 0.0; else if (R > 255) R = 255;
if (G < 0) G = 0.0; else if (G > 255) G = 255;
if (B < 0) B = 0.0; else if (B > 255) B = 255;
data8[x3] = (unsigned char)R;
data8[x3+1] = (unsigned char)G;
data8[x3+2] = (unsigned char)B;
}
}//_ConvertLAB8toRGB24

But if it is true that BOTH Hue and Saturation remain constant if the RGB ratios are the same, then a proportional representation of the color vector (fRGB) combined with a separate luminance is a useful numeric space, and one that only runs into trouble (must not say "goes out of gamut" for fear of getting into trouble) when clipping occurs.

And that trouble cannot happen in 32-bit mode.

[dxc]

late to the party, however one thing:

@jcr6:

"...Specifically a 32-bit number is FLOATING POINT..."

not necessarily. a 32bit number could be a float or it could be an integral type, or less commonly it could be something else, e.g. fixed point.

a four byte floating point number (ieee-754, typical for
winblows or mac) can represent a much wider range of values approximately,
but cannot exactly represent all the values represented by a 32bit unsigned
integer (or signed for that matter) exactly. in other words a float loses precision
relative to a uint32_t for the range of values the integral type can
represent. if you don't believe it, try converting back and forth uint32_t
-> float -> uint32_t for a few values, it shouldn't take long to find one
that doesn't match, for example 1,111,111,111.

of course a float may exactly represent the range you care about, i.e.
anything that fits in 24 bits, over 16 million values.

more pedantry I'm sure, but surprising to some...

dxc