I am very confused. "Opto-electrical transfer function" is a way of translating between optical (scene/light) information and an electrical representation, which is what a camera does.

There is a long and deep rabbit hole here, but let me be very clear; no camera has ever presented the colourimetry fit to its sensor catches.

There is no “scene” in the Mona Lisa; the picture, as a picture, exists as a closed domain arrangement of colourimetry.

Happy to try and delve into the rabbit hole, but the point above stands, as well as notions of “scene” being distractionary here. The question is about quantised signals, typically expressed in an integer encoding, failing to quantise well in the lower end. There is zero need to bring “scene” into the equation, and it is a red herring.

"This sRGB standard essentially defines the second part of this transformation between the reference RGB display space and the display CIEXYZ tristimulus values in a dim viewing environment.", seems pretty clear to me that the sRGB transfer function is intended to apply to the mapping between the digital representation and what the output display does.

Note the RGB part, which is tied to representations as code values.

From the perspective of common computer graphics, the intent is that if you perform linear-light image processing operations (such as antialiasing filtering)

Case in point, uniform tristimulus is the wrong domain for constructive approaches, as well documented in glyph rendering over the years.

RGB is not light. It’s tristimulus. It is 100% photometry all the way down.

If you don't get a good match to the linearity of the display output with this transform, you get nonlinearities as shown in 13.1 of the KDFS.

I have no idea what the KDFS is, but if the above statement about AA is any indication, I suspect there is room for caution here. Constructive approaches are attempting to build a signal that never existed, as though a photometric observer were to sense the geometry. Hence sampling from uniform tristimulus is the wrong domain.

The whole reason I bring up the discrepancy between the sRGB OETF and the prescribed EOTF is to appreciate that there is a historical gulf here that must be bridged. ICC protocols cannot account for this given that it effectively negates the display transfer characteristic to get to a uniform tristimulus no operation from code value to exit stimulus in terms of radiation.

There are merits to this, but we must also accept that the historical approach had implicit management at work, which also accounted (or at least attempted to) for viewing conditions. Applying a discrepancy between an OETF and an EOTF does more than simply what folks think of “contrast”. It changes the colourimetry fundamentally. It changes chromaticity purity, as well as chromaticity angles, and luminance output. This is the “happy accident” part of the implicit approach; low overhead, and acceptable results.

Again, for 99% of cases, all of this is bunko nonsense. It is worth, however, noting how the historical facets worked at the mechanical level in order to fully appreciate that we cannot simply gloss over the importance of the discrepancy, even in full ICC chains; there is still a lack of accounting for surround and veiling glare, as well as hardware colourimetry in terms of absolute luminance minimum and maximum. All of these facets play a role in the formulation of colour within our visual systems, and as such, the oldschool implicit mechanic is worth studying more than in passing!

The sRGB formulae in the KDFS have been universally used to translate linear light values for texturing and filtering since sRGB came into existence; I find it a bit hard to believe that they're not expected to represent this mapping or that nobody would have raised the misuse by now.

There is a subtle different set of contexts here.

In cases where texturing is important, the photometric colourimetry being arranged as uniform tristimulus can be beneficial. In this case, an “idealized” inverse of the encoding applies. With that said, a majority of folks are using random textures and frankly, none of it matters. And we won’t get into the nuances of pseudo-albedos anchored in photometry…

The subtle nuance is that a texture is not a picture in the surface-presented-as-a-picture for audience reading is. It is an incredibly important distinction.

I'll continue to rummage through my contacts and see whether I can find a way to contact the sRGB draft authors.

Mr. Motta might be at a large search company. Mr. Stokes can also be tracked down. Dr. Poynton is well worth reaching out to.

The point I would make here is not to distract or belabour things over what amounts to effectively nonsense, including the whole heap!

The point here is to glean what we can from the historical approach of implicit management, and its critical role in picture appearance equivalency. We can plausibly do better, but a comprehensive grasp of the issues at hand, including fully understanding how discrepancies between an OETF and EOTF shape our picture reading, is critical.

It probably cascades into a much deeper hole with respect to what a picture is, and why cameras never can, or should, represent the colourimetry that is fit to their quantal catches. This is a point worth noting as there is often an assumption that a picture is nothing more than as-measured values. We don’t have even the faintest idea of how pictures work, but we can indeed focus on the appearance facets and learn from the historical implicit processing.

The sRGB EOTF is a pure 2.2 power function #19

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions