i feel like i understand rgb spaces pretty well these days, but it is an ongoing thing and i did not to start with the knowledge i have now.
like, it's a cartesian space, fully mapped, every point a valid color, and then you can treat colors as vertices within that space, and do vector math on them.
I agree except for 'do vector math on them'. You can do that, but the result is usually wrong.
sRGB values are encoded with (two segments, with gamma=1.0 and gamma=2.4): this is why the perceptual midpoint between 0 and 255 is not 127 but 186. Similarly, if you add 64 to 0, the amount of perceptual difference between two colors is not
the same as the amount of perceptual difference between 255 and (255 - 64).
Most people do seem to treat it as a 3d vector (which is accurate). but you can't simply do vector math and expect a correct result; you have to
remove the gamma companding first (ie. turn sRGB into linear RGB), then do your math, then
add the gamma companding back in (ie. turn linear RGB into sRGB).
The result is not perceptually uniform, but it is closer to perceptual uniformity than simply performing math on sRGB values -- because simply adding, averaging etc sRGB values is almost without exception mathematically invalid.
Combining values that have companding built in is not a correct operation, you must always remove the companding first.
(Plenty of things cheat on this and just combine companded values anyway. for some things, you can get away with it, for others, it makes color mixing muddy, and for yet others, it results in incorrect metrics (eg. measuring distance between colors))
the idea that youd have to understand vectors to understand pixels and discrete spaces - again, hard to understand. but you need vector math to understand what you're really doing with even the standard straight lerp operation, which is essential to waht we do here, even if we do it in an art way and not a code one.
Yes, I'm thinking of stuff like antialiasing explanations. The 'ideal' intermediate color ramp can be calculated mathematically as a linear interpolation from color A to color B over S steps, but only if you are working with a colorspace that has a reasonable level of perceptual uniformity.
i mean, i maintain that im an expert on color but i havent yet comprehended the lab space or what its for really, and not for lack of ai posts about it. i understand that maybe it gets you access to more colors, samples between the samples in the cubic 255-space - and maybe the screen knows how to display them because it displays light in a not-quite-discrete manner. but you have to know it to be able to know it, and the lab space lives at the end of my knowledge. i do not know it, i do not know why to know it. maybe it has something to do with the idea that red, green, and blue actuall arent at 90-degree axis off of one another, and we only represent them this way? tbh idk
Any extra colors that Lab can specify are not part of sRGB, so not displayable on most monitors and therefore not relevant to most digital / pixel artists.
The value in Lab IMO is entirely about
perceptual uniformity, IMO.
Like I stated, being able to add N and change the brightness by a constant, consistent amount; being able to average two colors and get an inbetween color that really looks like an inbetween color, not a distortion. These are things that you cannot achieve reliably in sRGB or even linear RGB; the colorspace is not designed in a way that makes it possible.
Lab is not perfect at this either; it's a
pretty hard problem. It's just significantly better than the alternatives.
idk, im writing the 4000w essay you described even though i imagined i dont have to write it. rgb spaces seem intuitive to me originally, the way that even vector math is now, but ill still write a lengthy and symbol-heavy diatribes where im mostly arguing with myself, or that part of myself that represents the other guy, and not with the other guy. so like all i know is that i do not know this thing, i dont even know what it is to know it or why i will want to other than that ai talks about it quite a lot.
Dude, this is all the theoretical stuff. But if you get a colorpicker like GPick, and use the Lab colorselector (and the blend generator in Lab mode), you can see for yourself how it behaves and if you like how it feels, if you find it useful or not. I believe that it is, but you need not take my word for it, try it and see what you think. GPick is free / opensource.
i dont even really understand how to convert from rgb to hs-whatever even though i think its mostly just a simple function of the rgb values, and just subtraction at that (to get offsets maybe? to make the space circular? i do even not know why i know it)
I'm not sure what to make of this. It makes me think that perhaps, although you get that RGB, HSB, etc are vectors, you don't understand how they relate to displayed colors? That question is at the heart of my objection to performing math on RGB values : their nonlinear relationship to displayed colors.
Anyway, HSL, HSB, HSV etc are different polar transforms of the sRGB space. You can do them based off linear RGB and this looks/works a little better than sRGB, but as a rule nobody does. The Wikipedia page describes the sRGB->HS[B/L/I/V] transform fairly clearly, starting at
Hue and Chroma section.
