Myndex
commented
2 years ago Hi Dustin @dustinwilson Thank you for commenting. In three years I think you are the first person to ask me about this, and I have written about it in some of the docs (somewhere...), but let me explain in depth.
Background
1) APCA is not processing images. the goal is to emulate monitors in real world environments, and weighted toward "likely worst case", such as monitors with the black clipped, or a lot of ambient light, and other factors.
2) The IEC spec specifies the reference monitor has a simple gamma curve of 2.2, though it also specifies a monitor with a puny 80 cd/m² (common for the CRT types back in the 90s).
- Today monitors are routinely set much brighter (some phone can be 1200 cd/m² ) other user adjustments tend to raise the gamma (higher monitor gamma means lower mid brightness creating higher contrast), as seen in a number of surveys of actual monitors in the wild, and our own studies here in the lab. Monitor manufacturers and physical monitor standards also reference the simple gamma.
3) When the IEC spec was written (1996 to 1999) CRTs are what people used, and they followed a simple gamma. Today LCD are (by and large) also using a simple gamma in a LUT typically, though some like the high end Eizo can use the piecewise sRGB curve.
- We could discuss the 👍 & 👎 of piecewise vs simple gamma for hours. It is a common topic in color group discussions. How deep do you wanna go?
- The piecewise transform is computationally expensive, so it is commonly NOT used, unless (like Apple, and some vidcards) it's in hardware or par of a LUT. For APCA I'm not really concerned about speed as the task is simple enough, but I have other reasons I'll discuss further down.
- Adobe ships(ed?) a version of sRGB ICC profile called "simple sRGB" that is the simple gamma curve (2.2)
- The purpose of the piecewise was for computational connivence in circa 1990s era computers. Remember that math coprocessors were just becoming a standard item back then, (and still most processing was 8bit INT due to system resources, etc.) when using a simple gamma curve you end up with an infinite slope at 0, which can be a problem in some image processing applications (at least back in the day) so the piecewise was used to prevent that, the linearization prevents the infinite slope, and the offset was added to then make the resultant function as close to a target 2.2 gamma as possible.
- And again, the standard specifies monitors with the simple 2.2 gamma, in multiple places in that document even.
4) For visual effects work, if our workflows include sRGB we DO use the piecewise though out the facility, in and out, so that we there is no ambiguity not cumulative errors.
- however, we also almost never go "back" to sRGB. We unwind into a linear floating point space and stay there until we output for deliverables, decreasingly 10 bit DPX log, today much more likely to a 16bit Tiff log encoded, or to 16 bit half float EXR which is linear.
- The only time I output using sRGB is for images destined for web or web-type content. And I usually use Elle Stones's well behaved profiles.
5) These are not the photons you are looking for. Or are they? Remember that the piecewise is an attempt to estimate the simple gamma curve as closely as possible. Poynton's gamma faq and his other writings talk a lot about the usefulness of gamma, and having gamma NOT match the image origination gamma, but to allow for a system gamma gain to create the same perceptual intent as viewing the original scene.
- Don't assume that using the piecewise gives an accurate real world prediction of the monitor's actual luminance.
- And especially not the coefficients from the standard matrix, which are derived using the CIE 2° observer which we know has flaws particularly in blue, but all of this works pretty well do, in part, to our very accommodating human vision system that filters everything we see and interprets it based more on contexts than absolutes.
- Add to that the relatively massive variance in manufacturing, and the fact that each OS uses a different color management system.... who needs hair anyway?
TL;DR Part I
The point with most of the above conversation is that whether to use the piecewise or the simple gamma, or just some LUT, is up to your needs and the specific workflow. In the case of APCA, it's the "and of the road" it's for predicting perceptual lightness contrast, Lc.
In the early versions of SAPC and APCA, I was using 2.213 as the exponent, as that had unity at code value #777. Last year I shifted to 2.4 along with shifting the several other major constants in APCA to fit the empirical data of the continuing studies of users viewing self illuminated displays.
^2.4 matches actual output of monitors (some even higher, 2.5, in extreme cases 3.0) and 2.4 has some other benefits in terms of the relationship between green and the red and blue primaries, in a way that is helpful to color insensitive vision on sRGB monitors (though a different approach is required for Rec2020 to be sure).
Why Y?
Y is luminance from CIEXYZ. It is linear as light is in the real world. If you are doing ray-tracing, or compositing, you'll probably want to be in linear — but not for modeling human perception, which is not at all linear. (This is the key reason that WCAG_2 contrast does not work as intended — it does not follow perception).
So APCA takes the linear Y and curves it to model perception. You may be familiar with L from CIELAB, APCA does something similar, but where L is tuned to surface colors (Munsell) the APCA is tuned specifically for self illuminated monitors, and then specifically for readability.
When it comes to how we perceive contrast, after the retinal cells, the cones receive photons their electrical output goes to the ganglion cells which essentially data compresses what we see (opponent process) so that it fits thru our optic nerve and then heads off through the thalamus and then to V1 of the visual cortex.
V1 filters based on the luminance information in the visual stimuli. After filtering in V1 that visual stimuli is sent off to other areas of the brain for processing. V4 for instance is known to be very active in color processing. And depending, the filtered visual data is sent to the visual word form area (VFWA) which leads to lexical processing on the left side of brain. The VFWA is where whole words and letter pairs are filtered/recognized.
And the key to this? Good luminance contrast. Not chroma or hut, but specifically luminance. Luminance is three times higher resolution than chroma, and luminace is where the details are, and that's critical for reading small/thin fonts.
Rather than recite the rest of this part of theory, here's a link to a white paper in progress: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup/Whitepaper
Other Questions:
You mentioned:
you don't max to 0 if negative and min to 1 if above 1 though)
I do though, it may not be obvious, nor technically needed in this implementation, but min-max is a by product of the bitshifting:
function sRGBtoY (sRGBcolor) {
// send 8 bit-per-channel integer sRGB (0xFFFFFF)
let r = (sRGBcolor & 0xFF0000) >> 16,
g = (sRGBcolor & 0x00FF00) >> 8,
b = (sRGBcolor & 0x0000FF);This version (deprecated by the way) takes a 24 bit number and uses masking and bit shifts to separate the color components.
sRGBcolor & 0xFF0000 is a bitwise AND that in this case clamps the red channel to 0xff - it will be 00 to ff as a result. The >> is a bit shift that takes 0xff0000 and makes it 0xff. This is typically the fastest way to parse a numeric color value.
Note however that sRGBtoY in all latest and future versions takes a simple rgba array [123,123,132,1.0], and sRGBtoY() returns Ys which is the SAPC "version" of Y with the aforementioned adjustments for the contrast prediction.
For instance, if I feed your function 0x662d91 I get 0.05333370870294055 back for Y when if it u
Yes, and not specifically relevant to our use case as I mentioned or inferred above. You'll notice for instance that the first stage in APCA is a soft black clamp, which does something similar to the sRGB piecewise linearization, but is specifically tuned for the contrast prediction. The specific relative luminance is not something that will be used outside of the function — and both text and background are processed identically, and this processing is part of the entire chain that gets us to the perceptual contrast prediction.
TL;DR Part II
In short, we are doing that conversion intentionally, based on extensive work here in the lab, and other studies. It is part of the total processing chain for perceptual contrast, and is not intended for any other use.
I hope that answers your question? I may be a bit sleep deprived, so feel free to ask further if I wasn't clear on anything.
Thank you!
Andy
dustinwilson
I am trying to implement the APCA contrast algorithm into my PHP color library, and am trying to figure out what you're trying to do in your
sRGBtoYfunction.What it looks like you're doing is that you're converting from sRGB to CIEXYZ D65 (because you're not doing chromatic adaptation, and the sRGB input color is D65) but only using the Y lightness channel. However, when you do inverse companding you're not using the sRGB inverse companding algorithm but something like what other RGB profiles use (you don't max to 0 if negative and min to 1 if above 1 though) except with sRGB's 2.4 gamma (for the purposes of companding) instead of 2.2. For instance, if I feed your function
0x662d91I get0.05333370870294055back for Y when if it used sRGB's inverse companding it'd be0.06746021917230773.Above is what you have now, but if you were to use sRGB's inverse companding it'd be like this:
Is there any particular reason for this?