Where is sRGB 2.2 Gamma Display?

[Sdaniele]

After a very long and emotional debate over on ACES Central I thought we came to the conclusion to have both sRGB Encoding (compound function) and sRGB Display (pure 2.2 Gamma) in the ACES configs. I cannot see the sRGB 2.2 Gamma Display EOTF in the config.
Same for Apple P3 Display.

[nick-shaw]

The VWG decided to provide both piecewise and 2.2 gamma transforms, to acknowledge that both exist out there in the real world. By only providing piecewise in the Studio and CG configs, OCIO are certainly making a statement about which side of the debate they fall on.

[nick-shaw]

I don't know if we came to an agreement about naming the two. Your "encoding" and "display" terms, @Sdaniele, would also make a statement about which is the "correct" EOTF.

[Sdaniele]

I am happy to re-discuss the naming; I was just quoting the CEI/IEC 61966-2-1 :-). But I can understand that the other side would have a problem with it. I am sure, we can find a neutral naming convention.

[sobotka]

For those folks who stumble into this thread in the future, a bit of a narrative myth. Any resemblance to people or corporations, living or dead, is purely coincidental.

During the “sRGB wars”, some parties around Corporation A and Corporation B were wanting to at least get some consistency out in the wild regarding computer displays. One person, Person A, wrote up the original specification with consultation from Person B, an expert in transfer function characteristics. The original specification had a uniform input / output characteristic of a basic power function, and went through some revisions.

Film Corporation C, who at the time, was a highly active entity attempting to force their IP everywhere. They effectively refused to get behind the long and drawn out specification validation procedure. The 1.01 version of the specification, as a result of Film Corporation C’s posturing, integrated the two part encoding as what is effectively an OETF. The two part encoding was part of Film Corporation C’s own attempt at a standard in SOMETHING_RGB.

The sRGB specification has a very clear section on the input / output characteristics of the display. They are as follows, and were broadly congruent with the hardware of the time.

Despite conceding ground to Film Corporation C, Film Corporation C went to great lengths trying to torpedo the specification. During the extensive battle, a third person, Person C, emerges on the scene. Said person becomes heavily involved in the committee process, and power dynamics were formed. Person C continued to meddle at every turn, in an attempt to fracture and disrupt the standard. These undermining attempts officially continued up to 2006, in Helsinki, and continues even to this day.

By asserting a revisionist history, Party A is clearly falling on the side of Film Corporation C and their ulterior motive manipulator, who had no part in the authorship of the original specification.

As much as this has been a narrative romp, it would be an amazing piece of fiction if it were coupled with several hundred megabytes of documentation from the time. Fiction writers of the future might be wise to do some historical work if they were to write a piece of fiction as above, and follow the lineages of the people involved with Party A from different eras.

Such a revisionist history has now relegated the vast majority of sRGB compliant displays out in the wild to now being out-of-specification with respect to the reference standard in place in IEC 61966-2-1 due to an erroneous, ahistorical, and flatly peculiar reading of section 4.1, which is completely outlined in formula (1):

[doug-walker]

@Sdaniele , @nick-shaw the topic of which CTLs to include in the Studio and CG configs was discussed at the February 17 OCIO TSC meeting.

@nick-shaw , I disagree that anyone was intending to "make a statement" in this regard. It is more a question of prioritizing what the group focuses on. The OCIO team has been extremely busy with the implementation and testing of the ACES 2 algorithms since there are a lot of people waiting on us for that. That has limited how much time was available to focus on changes to the configs themselves. There are definitely a number of known items we want to address for the next configs release later in the year. We will certainly revisit this topic.

@sobotka , I will tell you that, as someone who was personally involved in the sRGB development process, that your characterization is just flat out wrong. Please stop spreading these malicious falsehoods.

[sobotka]

Out of curiosity, who was the primary author of the original sRGB specification, Mr. @doug-walker?

Further, what does the reference present in plain language, what the input / output characteristic should be for sRGB?

[KelSolaar]

Disregarding the sRGB debate itself and just to give some context, the fact that we got the ACES 2.0 configs out should be enjoyed positively.

I haven't been able to attend all the late OpenColorIO meetings, but I don't recall there has been any specific decision, will or intent to not include the G2.2 displays. I know I/we said on ACEScentral that they should be there but AFAIK, we never discussed about them in the recent meetings.

As you know, those meetings are open, anyone can attend them and chime in. Also, configs artifacts have been made available since August 2024 for people to try and give feedback.

At any rate, I'm the last person that touched the spreadsheets driving the generation, so you can blame me, AND also take the generator, and build a config with the missing displays right now :)

[zachlewis]

I honestly don't think we'd intended for that to imply an endorsement of the piecewise over the power function, per se, but I understand how it appears that way -- I think when it came up, my feeling was, the benefits of providing as few displays as we could get away with in the builtin configs outweighed the costs of upsetting half the folks with opinions on the matter; and anyone who felt strongly would have the means to correct the situation for themselves. But in retrospect, as far as stuff that ships with OCIO, maybe it's better to be as explicitly agnostic as AMAPS itself is on the matter, and defer the decision to the user of what to use for SDR viewing, if not Rec.1886. If we don't want to expose both sRGB flavors, perhaps we can find more of a middle ground -- maybe include the Gamma 2.2 display color spaces, and maybe even implement the views, but leave a couple of them inactive, if we didn't want to expose them both by default.

Anyway, it sounds like the people are asking for Gamma 2.2 views to be included, and I believe we'd always intended to reexamine the Gamma 2.2 views, if that's what the people asked for. And it sounds like the people are asking!

It's regrettable that the ACES configs' use of "sRGB - Display" directly conflicts with FilmLight's efforts and pleas to colloquially define "sRGB Display" as Gamma 2.2 Rec.709. It would be nice if we could do something about that.

Personally, in my configs, I find it useful to never use "sRGB" unless I'm referring to the piecewise transfer function; and whenever I'm referring to the piecewise, to always use sRGB (~2.22) -- even stripped of special characters and casing, srgb222, to me, unambiguously denotes the piecewise transfer function, as opposed to a pure power function or a set of primaries.

If this isn't too late or too different, maybe we can get rid of the " - Display" suffix for at least the Display names? Even with the Display Color Spaces, I feel like if we lost the " - Display" suffix, the color spaces would still be sufficiently distinguishable from their texture-encoding counterparts. If it gets confusing, we can make the display colorspaces inactive, and encourage the use of the colorimetric "Un-tone-mapped" views.

I believe Apple specifically asked for the "Display P3" color space that employed the piecewise inverse OETF, but I might be mistaken about that. Is it important that we define a Gamma 2.2 P3-D65 display as well?

I guess another question perhaps worth considering is, whether we should define virtual display views for applications and platforms that are able to provide a "virtual display" that de facto matches whatever transfer characteristics the system thinks the display uses...

[Sdaniele]

Adding the straight 2.2 Gamma versions with both 709 and P3 primaries is hopefully not much work and I hope the OCIO team will decide to add it. It allows users to produce what they might need, no matter what we call them.
Regarding the naming, I am not dogmatic at all... ☮

[KelSolaar]

Adding the straight 2.2 Gamma versions with both 709 and P3 primaries is hopefully not much work and I hope the OCIO team will decide to add it.

Not hard at all, they are already in the Reference config, so it is a few checkboxes in the Google Spreadsheet.

[Sdaniele]

@KelSolaar
You know which buttons to push...
What can we do to make this work?

[Sdaniele]

Ups, I think I closed the issue. But cannot reopen it :-(

[carolalynn]

Hi all, apologies for the delay in my response, been a busy week. I can address the "how do we get this done" part:

As others in this thread have noted, this was not a decision we came to lightly, nor without adequate time for the public to review, test, and give feedback. These configs are now released. However, we made the concious decision not to build them in to the 2.4.2 library and instead wait until 2.5, because these are big changes and we anticipated some issues.

So the path to get new color spaces added is first to do as you have done, and open an issue. Second, we farm for community feedback and see if other folks would value the addition. Third, we discuss it at an OCIO TSC meeting (these meetings happen every other Monday at 11am PT, calendar.opencolorio.org, and they are open to all). I would ask that you find time to attend one of our meetings. We have one next week, March 31. Not to be "woe is me" here - but OCIO has always been nothing but an amazing partner to ACES - we do our best to attend meetings, be a part of discussions, etc, and we would appreciate the same courtesy. Kevin shouldn't have to represent the entirety of ACES in our OCIO TSC meetings.

One of the main reasons we will need the discussion in the TSC instead of "just pushing the buttons" is because of our favorite thing to do - naming things. We labor over this, because as we're all aware, and this thread already demonstrates, it's hard. Not only is it hard to agree, but it's also hard to change once it's been released. It may seem overly bureaucratic, but OCIO is implemented in over 30 applications, and we have a responsibility to them, as well as to our users, to be measured and consistent.

All that to say - we very much appreciate the feedback, and we would be open to feedback on how to make that process easier for you to follow and participate in during our release candidate window.

I anticipate the timeline to do another config release to be a month or two, just to set expectations.