It would be targeting the same display, but I don’t think you can think in terms of equivalence of tone mapping, or any of the rest of the rendering. The choices the Resolve team made when designing their rendering will be different from the ones we made.
Hello,
was there a conversation on the OCIO slack and as part of the “color-interop-forum” regarding the ambiguity of “srgb_texture” ? Maybe “sRGB-Encoding” and “sRGB-Display” would be helpful in that scenario as well ? @carolalynn
Regards,
Chris
1 Like
It is really Scene vs Display in the Interop forum. Here we are hugging the display so the same mechanics do not work. If we are not happy with the standard name as delineation, then lets call a cat a cat and use PieceWise / Hybrid vs Gamma2pnt2, this is really the only option: Piecewise - Wikipedia
This unfortunately assumes that people have some access to the standard and know its sections which is probably a percent of a percent of the ACES users.
2 Likes
Giorgianni-Kodak’s “scene” and “display” never worked either, so perhaps just using a descriptor of the encoding state and decoding state makes good sense?
Since we’re focusing on being totally explicit in our definitions, is it ok that the primaries are labeled as Rec.709 in both Rec.709 transforms and sRGB transforms?
It is obvious to us here that Rec.709 and sRGB primaries are equivalent, but is that the case for a general user who is looking for the correct transform for their display type? Should we bother to label them as sRGB when used in the sRGB transforms and Rec.709 in the Rec.709 transforms? Or is it generally accepted that they are one and the same?
1 Like
I don’t mind either way to be fair, the transformations to/from CIE XYZ are “potentially” slightly different for both:
- IEC 61966-2-1:1999 defines 4 places rounded matrices AND primaries/whitepoint, people use both of them which results in noticeable precision inconsistencies
- ITU-R BT.709 only defines the primaries/whitepoint which imposes computing the NPM, usually done at machine precision resulting in almost no noticeable precision inconsistencies.
I’m not saying that we should use the matrices for sRGB, just pointing out that I have always seen them slightly different because of the above.
+1 for using Gamma 2.2 and piecewise. I think for the average foot-folk like me, this is the most clear delination.
Looks like the user name currently is
sRGB
sRGB Gamma 2.2
This is perfectly fine and clear as well. You could possibly consider making the user names
sRGB
Gamma 2.2
1 Like
For the OCIO ACES config, after much debate they went with calling it Rec.709 (sRGB).
I think the sRGB user names should also reflect the choice of tone curve names.
1 Like
+1 for having them for all, HDR included, or none of them. Also, technically, isn’t it ACES white and not D60? 
Yes, absolutely.
Trust me, I toyed with trying to make it technically correct but unfortunately “ACES” has been used for too many things already and writing “ACESwhite” when all the others are a “Dxx” label seems like a lot.
I think since we are providing the exact chromaticities in the files and we can label them as “AP0” or “AP0 / ACES white point” (in fact the Rec.709 D60 sim output still has the chromaticities labeled as “Rec.709 ACES white”)
As part of all the other documentation updates, we add a callout to highlight that “the D60 in the names is actually not D60 but something really really close and so we call it that for convenience” and link to the existing “Derivation of the ACES white point” documentation page.
I like the D60 sim, but I would do it as a recommendation for implementers to expose the creative white point as a user facing parameter. And then I wouldn’t include the D60 sims in the default set in aces-output.
I tend to agree that while D60 sim has it’s uses, it isn’t the only “sim” and shouldn’t really be needed in most cases. It should be provided for all the outputs or none, but not just some. I think it makes it much more approachable if there’s one primary output for each display, where we assume the display white point and observer adapted white are on and the same (no “sim” required). Usually, most people expect equal code values on their waveform to be “white” - which would be the case for all the non-sim variants.
The only problem I see with removing it is that we had already included it (minimally so) in v1, and therefore some people have become attached to it or now expect it to be there. So if it was suddenly not available to pick from as a default, they might freak out initially, even though we would provide clear guidance on how and when one might want to use it. But I guess that logic could be applied to some of the other transforms we’re removing too… So maybe it’s workable and makes it easier?
I know the “D60sim” is included in some of the configs, would any of the OCIO team have very strong feelings against removing it as preset? (It would still need to be supported, just like any other “custom” or “advanced” user-created ODT for specific use cases).
It’s an interesting point, and one we need to discuss tonight.
The issue I foresee is what @jzp brought up in last week’s meeting. If only native device white transforms are available “out of the box”, unless it is trivially easy to make your own “sim” variant in all implementations, many people are going to make Rec.709 dailies with D65 white by default. Then it will be perceived as “not the same” if the DI uses D60.
Yes, we can discuss.
Shouldn’t this be the default? For a Rec709 deliverable such as for viewing on TV, the observer should (usually) be assumed to be adapted to a D65 white since most likely all other content (i.e. commercials) is mastered to that assumed white point. Yes, you could decide to creatively deviate from D65, but the vast majority of people won’t need this.
Usually the D60 sim is required in cases when trying to convince a director/cinematographer/etc. that you can make them match and when you have both displays in the same viewing environment to convince them of that. For example, if you’re in a DI suite with a D60 projector and you roll in a Rec709 monitor, you’d need to show the D60 sim version on the Rec709 or else the whites will be noticeably different. This is in fact the reason why we ever added the D60 sim variant in the first place - because we had this exact scenario.
However, if you presented the DI in one room, then took the viewer to a different environment and let them adapt to watching material with a D65 white then they should not be able to tell the difference (unless you biased them by telling them that they’re not going to match). Maybe for a more dramatic white point shift, but D60<>D65 is quite subtle if not viewed side by side.
It should be easy to make your own sim or any other “advanced” need, but we can’t just ship every option as a default - it’s too overwhelming. The average user shouldn’t need D60 sim for any common use cases, and I’d argue that if they’re experienced enough to understand the difference, they would know that they need to manually adjust the creative white in relation to the encoding white.
Sure for TV deliverables, probably. And any creative tint can be in an LMT.
But what (if I understood him correctly) @jzp was saying last week was that a particular studio ended up being forced to master their theatrical deliverables with D65 white, because when they did a D60 DI, creatives felt it didn’t match what they had seen throughout editorial, which had a D65 white.
And I agree that D60 and D65 are only very subtly different if you don’t A/B them.
1 Like
This is false, right?
This does not work.
The issue is that the purity dimension still attenuates when the “creative adjustment” is performed under the picture formation.
I don’t know how many times I have to say this, but apparently it’s many, many times.
The purity dimension is attenuated by the pictorial formation. That is, the additional stimuli not present in the original stimuli is “added in”. And that integration happens relative to the global achromatic centroid.
It is literally impossible to perform a proper tinting under the picture formation, which is a point I’ve been trying to draw attention to for years. It’s like putting a biased filter in front of a black and white camera.
The sole way to achieve proper tinting is on the post pictorial formation, hence the original Giorgianni concept of failing to locate the colourimetric wattage of the pictorial depiction remains a show stopper problem under his framework.
A solid example is , where spectrally biased energy in front of the camera is attenuated along the colourimetric purity dimension in the interstitial formed pictorial depiction, and then the formed picture is tinted.
These frames from Bringing Out the Dead1 lean in hard to the pictorial formation of creative chemical film, and the resulting attenuation of purity is a critical part of the formed picture. It is an absolutely crucial aspect of the cognitive fissioning that occurs in our visual system.
—
1 There is a beautiful example of tinting in BotD that I can’t upload as the PDF is 13 megs. The link with the time is here.
1 Like
I’m advocating removing the D60 sims from the default set only if we’re advocating for the user facing creative white parameter. If it’s not a user facing parameter then the D60 sims should be kept.