@jack.holm is the only person that contributed to the authoring of the standard in this discussion and he kindly provided clarifications about it. People, as he said, are free to do what they want with it.
Is this correct?
I looked. I only saw four names explicitly listed in the authors section, and five listed in the acknowledgments directly.
Has anyone actually reached out to any of the authors listed, or to those in the acknowledgements?
Your quote is incomplete, I said “in this discussion”.
I simply asked if he was one of the four original authors?
If he is one of the authors, perhaps we can work to get that reflected in the origin document included at A Standard Default Color Space for the Internet - sRGB so that it is historically accurate?
1 Like
You asked whether Jack was one of the authors, the IEC standard does not list any. The standard specifies that “International Standard IEC 61966 has been prepared by project team 61966: Colour measurement and management in multimedia systems and equipment, of IEC technical committee TC100: Audio, Video and Multimedia Systems and Equipment.” Jack was the technical secretary of TC100 (and also vice chair of ICC by the way), so yes he did contributed to the authoring of the standard.
That being said, good point about contacting some of the 4 authors in your link.
Cheers,
Thomas
It can’t be called necroposting, when it’s an immortal topic, right? 
Current ACES candidates still have sRGB only option for “office” displays. I think (and hope), the final product should provide an ODT for pure 2.2 power function as well.
For now with ACES 1.x many artists (probably the most?) don’t even have the option to monitor their work correctly. Only the ones, who have either their monitors switched to sRGB mode that also have piecewise sRGB EOTF (or have this by a random decision of a display vendor), or calibrate their displays via ICC profiles, that force their usually pure power function displays to perform like piecewise sRGB EOTF monitors.
And all the rest, who either choose to calibrate their monitors to Gamma 2.2 for bright surround (by uploading calibration LUT to a monitor for example), as it was originally intended for sRGB encoded content, or just can’t afford calibration at all and thus most likely also have pure power function displays, have to see their shadows darker without Gamma 2.2 option available.
Hi @meleshkevich,
If ACES was to keep only the piece-wise EOTF this should not prevent OCIO or implementations to define both or only the pure power variant. OCIO 2 makes that quite a lot easier actually!
1 Like
Hi! Recently I was trying to add pure gamma 2.4 there for Unreal Engine. I spent several hours with no luck. Was only able to do it modifying legacy “nuke default” config.
I’m absolutely sure most artists don’t even know that config file can be opened in notepad. Editing it? No chance most of them are going to try it.
So for now it’s like this:
“ACES exists to make everyone’s live easier. Just learn everything about coding OCIO. But first get lucky to even know from somewhere, that sRGB and Gamma 2.2 are different things.”
The majority of artists are artists, not coders.
Irrespective of whether ACES was to choose to have Gamma 2.2, an implementation still need to support it. I would read and contribute to that issue here: Add pure gamma 2.2 display to ACES configs · Issue #56 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub
1 Like
Hi @meleshkevich ,
truly an immortal topic indeed. From what I understand of the sRGB standard, monitors should always be calibrated at pure 2.2 gamma. However, the content on the wire should be encoded with the piecewise function on the computer side. In my understanding, this mismatch between the encoding side and the decoding side is designed to compensate for flare.
2 Likes
Hi!
Exactly. But sRGB ODT assumes that a display has piecewise sRGB EOTF. sRGB ODT compensates for brighter shadows of sRGB display. But this is an additional darkening of the shadows which happens on top of the tone curve of the DRT. In case of display with piecewise sRGB EOTF this additional darkening is canceled by a display curve. But for pure gamma 2.2 displays this results in double darkening, which makes shadows darker by both tone curve (intentional) and ODT/Display curves mismatch (unintentional and should be avoided).
Another thing is that the current v1.x DRT has a strange curve in the shadows. So from that point of view sRGB ODT looks like it’s actually developed for a pure gamma display and Rec709 ODT is just strange.
But this is a coincidence of having unusual tone curve of the DRT and linear segment near black on top of that for the sRGB ODT. But it’s not replicated and doesn’t match ODTs for the rest displays like gamma 2.4 for example.
I don’t want to get off topic, but this isn’t true. @Troy_James_Sobotka has pointed out what the spec says and I can’t really argue against that.
What I can provide is some context. I’ve had long conversations with multiple people involved in the creation of sRGB and NIF. All of them have told me that the original intention was for the monitor to have the piecewise EOTF and for the images to be encoded with the inverse of that piecewise EOTF. This allows for the display light to be directly encoded in the image file.
Don’t shoot the messenger here. I didn’t write the standard. But to a person, the people involved in the original engineering say the spec doesn’t embody what they intended. The spec has lead to all sorts of confusion and post-facto reasoning, but the intention of those involved, and I’ve talked to almost all of them in person, was that there was never supposed to be a pure 2.2 gamma EOTF.
3 Likes
Maybe someone has spoken to an original author and has verified that the EOTF is as per reference display in the specification. The additional facts that it follows the design intention of the BT.709 implicit chain is likely supportive evidence.
Either that or Mr. Motta, an expert in EOTFs, including having worked with Berns on the 122 specification, made an oversight?
I’ll leave it here, again, that there are four authors listed on the original paper. They can be contacted. There are five names listed in the acknowledgements.
And the specification is deadly clear on this, restated in several places, complete with explicit outlining.
The debate can rage, but the design is pretty darn clear. It’s also the default presentation for all out of box Windows and Apple machines, with the exception being the XDR that Apple let someone pooch.
1 Like
I’ve spoken with Michael, Ricardo, Charles and Ed. Charles was the only one who wasn’t
unequivocal. Others at Kodak who also worked on it but are unattributed had the same story.
1 Like
In the interest of historical relevance, the posting of the original proposal for sRGB was at CIC 1996 in Scottsdale.
Perhaps something might break on this soon…
Whatever very old (and apparently not written very clear) standards say, shouldn’t ACES stick to the current reality? Which is that the majority of displays have pure gamma EOTF. And most of sRGB content was produced on and for pure gamma displays.
ACES claims to support all future displays that are not yet developed, but it doesn’t even support the most popular display type in the world that exists for several decades.
ACES 2 can be in development for another year. Why not to release ACES 1.4 with added pure gamma 2.2 ODT and renamed confusing Rec709 ODT?
(In my previous post half of the time I called ODT as IDT. It’s a typo of course)
I agree with what @jack.holm posted earlier in this thread:
- A lot of color encodings are called sRGB that are not really sRGB. My suggestion would be if it is not exactly sRGB don’t call it sRGB, just say what it is, e.g. 200 nit peak white gamma 2.2 EOTF 709 primaries (or whatever).
1 Like
I agree, and hopefully it will be added to the ACES OCIO config. In the meantime, if you want to add it in, here you go:
- !<ColorSpace>
name: Gamma 2.2 - Display
family: Display EOTF
bitdepth: 32f
description: |
Gamma 2.2 monitor with Rec.709/sRGB primaries
isdata: false
encoding: sdr-video
from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_G2.2-REC.709}
1 Like
@Alexander_Forsythe That’s interesting new info. It does however make sense when presented that way. It’s a shame though that many monitors today don’t offer a true sRGB curve anymore. My ASUS ProArt lets me choose between 2.2, 2.4, 2.6 and PQ (with different ways to handle values >1000 nits). What’s also unequivocal is that the encoding function has to be the sRGB piecewise-function no matter what the display does. I don’t know if that is what you are saying @Troy_James_Sobotka . However, I think we can all get behind adding the sRGB piecewise-function in ACES 2. For the game we are shipping based on a modified version of an older prototype of the CAM DRT, I have replaced the gamma 2.2 EOTF with the sRGB piecewise-function.
The sRGB piecewise function is already what is used in ACES 1.x. Isn’t what people want the option to use pure 2.2 gamma (I realise you already can in OCIO apps)?
2 Likes