No display technology, not even a professional display, has anywhere near the precision for this to matter.
sRGB profile comparison
21–29 of 29 posts
Re: sRGB profile comparison
#22For more hilarity, many people also believe the EOTF (decoding gamma) is supposed to intentionally differ from the OETF (encoding gamma). You can read an entire debate at https://gitlab.freedesktop.org/pq/color-and-hdr/-/work_items...
It is. The EOTF wasn’t an engineered function in 1996, it was the natural response of CRTs. The EOTFs of later technologies like LCDs were developed to approximate this response, not to be an inverse of the encoding gamma.
Sure but modern ICC color-managed workflows (e.g. digital photography, printing) basically don't distinguish between EOTF and OETF. Assuming your source is tagged correctly and all displays have a profile matching their true response, you necessarily need to linearize with the inverse of the encoding gamma. All edits are done directly in the source color space, if the viewer's profile differs from the source it's up the viewer to translate accordingly. You don't edit images "on the assumption" that they'll be decoded with a 2.2 gamma.
For some reason video workflows never adapted to the ICC system (probably because in CRT days you couldn't really adapt your decode gamma on the fly) which is basically where the whole debate in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... comes from.
I'm not saying that the people using 2.2 EOTF are wrong, but all this just adds to the absurdity: in the modern day where LUTs are cheap and plentiful, instead of tagging content as an ambiguous sRGB it could simply be tagged as gamma 2.2 if it's actually intended to be decoded at that gamma.
Re: sRGB profile comparison
#23Earlier quoted context omitted.
If you're using sRGB with 16bit color you already have problems. It is an 8bit per color hack that worked perfectly well with CRTs and early LCDs. There were multiple different hacky versions with different vendors that were visually indistinguishable on displays of the day. Even most modern displays are not really capable of more than 10bit color (RGB miniLED and QD-OLED barely are). Even REC2020 doesn't need 16bit.…
Your eye also doesn’t have a consistent gamma, nor does the camera, now does any viewing technology. If you’re complaining about the slight linear section of many gamma curves, they are very important for avoiding various artifacts.
Well, there's all sort of different problems, but most modern display technologies both in software visual profile and hardware implementation use LUTs. When sRGB was born the monitors were unable to even meet it as a spec so some crazy simplifications were fine. Now we're using those bits to drive HDR monitors over much larger color volumes and dynamic range, but it's hard to move on from the "good enough" legacy of sRGB.
Certainly, eyes don't have a consistent gamma, they don't even match between people, much less outside the foveal field.
Re: sRGB profile comparison
#24Earlier quoted context omitted.
It is. The EOTF wasn’t an engineered function in 1996, it was the natural response of CRTs. The EOTFs of later technologies like LCDs were developed to approximate this response, not to be an inverse of the encoding gamma.
Sure but modern ICC color-managed workflows (e.g. digital photography, printing) basically don't distinguish between EOTF and OETF. Assuming your source is tagged correctly and all displays have a profile matching their true response, you necessarily need to linearize with the inverse of the encoding gamma. All edits are done directly in the source color space, if the viewer's profile differs from the source it's up…
It depends what you want to apply your linear functions on. If you want to work directly in the source scene light (e.g. photography), then it would make sense to use the inverse OETF. If you are blending graded scenes of emissive light, i.e. a movie, then using the EOTF makes sense. The reason for this is that movies are graded with that EOTF in mind, so by linearizing with that EOTF, you get a resulting linear value as it is intended to be seen by a viewer.
Regardless of what you use for a linearizing function, the more important thing is that you use the correct encoding function afterward, so that you don’t introduce any additional gamma correction. For example, it was common to use a simple squaring function for speed. This gives fairly good results as long as you apply the square root function afterward to restore the original gamma correction. It doesn’t matter if the source is 2.2 or 2.4 gamma encoded or something else, that correction will be preserved. The blending post-linearization will be less accurate, but much better than not linearizing at all.
Re: sRGB profile comparison
#25Earlier quoted context omitted.
Sure but modern ICC color-managed workflows (e.g. digital photography, printing) basically don't distinguish between EOTF and OETF. Assuming your source is tagged correctly and all displays have a profile matching their true response, you necessarily need to linearize with the inverse of the encoding gamma. All edits are done directly in the source color space, if the viewer's profile differs from the source it's up…
It depends what you want to apply your linear functions on. If you want to work directly in the source scene light (e.g. photography), then it would make sense to use the inverse OETF. If you are blending graded scenes of emissive light, i.e. a movie, then using the EOTF makes sense. The reason for this is that movies are graded with that EOTF in mind, so by linearizing with that EOTF, you get a resulting linear valu…
>The reason for this is that movies are graded with that EOTF in mind, so by linearizing with that EOTF
I guess this is the part I find anachronistic. Why do we work in the source scene light for photography, but do the opposite for videos? It makes sense if you assume the viewing device is "dumb" (like a television or CRT, especially in the analog days) but by now I assume the workflows are all fully digital, and even the most basic output device can apply LUTs. When digital video container formats were introduced, why didn't they align with what ICC did? It would have saved a lot of headache for everyone, compared to limited NCLC tags and the mess around EOTFs.
Re: sRGB profile comparison
#26Earlier quoted context omitted.
graphic designers don't really see any of this, either. It's going to be photo junkies or people working on image processing systems (either building them or using them) that have to deal with this. But for the most part this shouldn't really matter much. A huge amount of things these days are properly color managed, so as long as the thing that wrote the profile actually, you know, wrote what it actually wanted then…
> We're largely past the days of just hoping that the image and the display happen to agree on roughly the same colors. Ah haa ha ha haaaa! We're nowhere near past that point, we haven't even begun to approach that point. That point is something I would like to reach before I die, but since that's maybe just a couple of decades away, it's not looking likely. In general, Windows and Linux does not color manage, or so…
HDR has problems that aren't the fault of missing color management. Notably, the fact that HDR of the HLG & PQ variety (so HDR10) do not have specified behavior. The specs are wrong in that they basically just don't exist for half the problem. Which also means most content is badly authored, too, almost certainly including your fancy pants Nikon. This is why gainmap images almost immediately dominated the mobile phone capture space, they are actually properly defined. So both viewers and creators know what they're actually intended to do.
The rest of your rant seems mostly anchored around the fact that most things still produce sRGB, which is true, but they still typically map inputs into sRGB appropriately (that is, they get clipped). Which still is being properly color managed.
Re: sRGB profile comparison
#27Earlier quoted context omitted.
> We're largely past the days of just hoping that the image and the display happen to agree on roughly the same colors. Ah haa ha ha haaaa! We're nowhere near past that point, we haven't even begun to approach that point. That point is something I would like to reach before I die, but since that's maybe just a couple of decades away, it's not looking likely. In general, Windows and Linux does not color manage, or so…
HDR has problems that aren't the fault of missing color management. Notably, the fact that HDR of the HLG & PQ variety (so HDR10) do not have specified behavior . The specs are wrong in that they basically just don't exist for half the problem. Which also means most content is badly authored, too, almost certainly including your fancy pants Nikon. This is why gainmap images almost immediately dominated the mobile pho…
All of my rant applies identically to 10 bpc images and wide gamut (non-sRGB) for exactly the same underlying reasons. They all have the same fix: frame buffers must be 16 bpc and input images must be color managed.
HDR has one extra minor issue on top, which is that there needs to be an output mapping to the display max brightness capabilities but this isn’t that different to what’s needed to correctly tone map wide gamut to arbitrary displays.
Also: if the spec is so “wrong” why does YouTube HDR just work? Also… Apple TV, NetFlix, etc… on practically all devices?
They got it right!
There is no fundamental color management difference between moving and still images.
If anything, moving images are harder!
Re: sRGB profile comparison
#28Earlier quoted context omitted.
Your eye also doesn’t have a consistent gamma, nor does the camera, now does any viewing technology. If you’re complaining about the slight linear section of many gamma curves, they are very important for avoiding various artifacts.
Well, there's all sort of different problems, but most modern display technologies both in software visual profile and hardware implementation use LUTs. When sRGB was born the monitors were unable to even meet it as a spec so some crazy simplifications were fine. Now we're using those bits to drive HDR monitors over much larger color volumes and dynamic range, but it's hard to move on from the "good enough" legacy of…
LUTs don’t magically add color volume, change the possible colors or dynamic range, or add much at all to the physics of a display. They’re usually used to reduce bit depth. They do not add more low or high colors than the screen physics started with.
Re: sRGB profile comparison
#29Earlier quoted context omitted.
It depends what you want to apply your linear functions on. If you want to work directly in the source scene light (e.g. photography), then it would make sense to use the inverse OETF. If you are blending graded scenes of emissive light, i.e. a movie, then using the EOTF makes sense. The reason for this is that movies are graded with that EOTF in mind, so by linearizing with that EOTF, you get a resulting linear valu…
>The reason for this is that movies are graded with that EOTF in mind, so by linearizing with that EOTF I guess this is the part I find anachronistic. Why do we work in the source scene light for photography, but do the opposite for videos? It makes sense if you assume the viewing device is "dumb" (like a television or CRT, especially in the analog days) but by now I assume the workflows are all fully digital, and ev…
It’s because the viewing format has a fairly consistent gamma curve relative to viewing environment ambient light level. In a theater its about 2.6 and this works with no ambient light, and in a living room its about 2.4 with dim lighting, and on a computer screen its about 2.2 with typical office lighting. With controlled lighting, the perception of the output image under these three different gammas will be identical. This gives graders a great deal of precision. They can calibrate their screen and studio to appear exactly as it should to these idealized environments. That a number of people watch content in non-ideal environments is irrelevant (even though its often brought up as a strawman argument against consistent working environment viewing conditions).
With photography, you don’t have that control at all because traditionally photography was about prints. Every printer (regardless of kind) had to be profiled and you needed an explicit ICC conversion process for it to work. If you are solely publishing photographs digitally and have no intention of printing, you actually could adopt a film workflow and it would be just fine.
In short, film production doesn’t actually need the added complexity of ICC profiling. They could adopt it, but it’s not strictly necessary. Trouble comes when people don’t understand the fundamental reason why gamma correction and different primary spaces exist in the first place.