But Display P3 seems to be as confusing as sRGB. From measuring the XDR display in my MacBook Pro, in “reference” HDR mode the EOTF I measure in Nuke’s Display P3 HDR mode is the piecewise sRGB function. But in “Apple Display (P3 500 nits)” mode I measure pure 2.2 gamma.
I do not of course know what, if anything, Nuke may be altering depending on the current display profile. I’ve always assumed it did nothing and just tagged the buffer as extendedDisplayP3 but I could be wrong.
Yikes.
Rather than have yet another religious debate about piecewise vs pure gamma 2.2 and which is “right”, I suggest we just provide both for P3D65 (similar to what we are doing for the sRGB Output Transforms).
This problem is not an ACES problem, so we should just provide the ability to use either. We are already considering adding multiple additional variants, so what’s a few more?
I do however worry about the provided list of presets getting too long. Do we really want a novice user to have all of these outputs presented to them as options? Sure, we want advanced users to have the ability to get any combinations of primaries, EOTF, white point, etc. but I worry about too many options with very subtle distinctions that can overwhelm less knowledgeable users.
Perfectly acceptable if folks accept that OETFs and EOTFs are not strict wattage stimuli specification inversions, and indeed follows the sRGB reference specification EOTF.
The Apple native display tag is informational only.
It’s not about inconsistency. It’s about compatibility.
The compound function was a hack to do graphics on 8 bit systems, nothing more. It is not compatible with video.
It’s a shame that it confuses generations to come.
ACES shipping compound ODTs will amplify this confusion.
So it is an ACES problem, if ACES still claims to be the international
Reference Colour Management implementation.
So I have tried re-organizing yet again, this time based on a name string defined by LimitingPrimaries-LimitingWhite_PeakLuminance_as_EncodingPrimaries-EncodingWhite_EOTF
As discussed in the Wednesday call, the only differences between some of these is the “on-the-wire” EOTF encoding. Therefore, grouping them like this for now allows us to look at the flavors of render that are defined by the combination of Limiting Primary/Limiting White/Peak Luminance. I have arbitrarily assigned a “type” to each (I used letters to distinguish), and it looks like we currently have 13 “flavors” of renders (A-M) .
Also as discussed, there seems to be a desire for the TransformID Name string to be verbose and fully “programmatically” assembled from the output variables.
The User Name would remain the “common” name or shorthand name.
A bit unclear how to label the “SDR” transforms which can have a 48-nit or 100-nit peak luminance depending on usage context. This is sort of where the absolute luminance labeling nomenclature breaks down, and I’m not sure how to reconcile that without making it more complex than it needs to be.
Based on this latest experiment trying to determine “the list”, I again ask the following questions:
Are these TransformIDs any better for those who have expressed concerns about the previous ones? Is this different structure at all helpful? If not, why not? What would help satisfy you?
Is the list adequate? Too many or any you might remove? Is there any missing that you feel should be there? Why? NOTE: I have removed the P3-DCI and Rec.2020 SDR transforms based on the conversation on Wednesday, where we discussed their omission for various reasons.
Is column D intended to indicate groups which are the same rendering with a different encoding?
If so, it is not correct. For example, B is used for:
DCDM (P3-D65 300 nit Limited)
P3-D65
P3-D65 (Rec.709 Limited)
Those are thee different renderings, due to the limiting difference and peak difference.
Also P3-D65 (Rec.709 Limited) has a duplicated ID and Name String from the entry above. Should it not be Rec709-D65_as_P3D65? In fact the limiting and encoding columns are duplicated too.
I also notice 1000, 2000 and 4000 nit renderings exist as P3-D65 ST.2084, P3-D65 limited Rec.2020 ST.2084 and Rec.2020 ST.2084. But the 500 nit version does not exist in P3-D65 ST.2084, which would just be a different encoding of rendering D. As 500 nits may turn out to be the most commonly used, it should probably be included in all the variants.
Another thing I realised is that the D60 sim transforms will include white fitting, so unless that is done in an external step after the render, then they are not actually the same renderings as the equivalents which are encoded with the same white point.
The transforms this affects I believe are:
DisplayP3 (D60 simulation)
Rec.709 (D60 simulation)
sRGB Gamma 2.2 (D60 simulation)
sRGB (D60 simulation)
I believe all the sRGB and Rec.709 D60 sims will need the same scale factor applied to them, as they are just different EOTFs. The Display P3 one will need a different scale factor.
The portion of the Transform ID that is the TransformType.NameSpace.NameString has been the filename. Should the more programmatically generated transform IDs also be the filenames? Are there any problems with this pertaining to length of filename that I’m overlooking?
The list of filenames would look like this:
(as list is currently and excluding any resolution of the current discussions of whether to not provide the sRGB/IEC61966-2-1 or whether to include a D60 white point equivalent for every output by default)
I hesitate to add more to the mix, but one combination missing from that list is Rec.709 limited 100 nits encoded as P3-D65 with piecewise / 2.2 gamma EOTF, so somebody on a P3 display can see a Rec.709 image.
Of course, being simply an encoding difference it is easy to add that to an OCIO config yourself.
Names look good, fantastic to see them programmatically generated and enforcing consistency. The filename length should not be an issue unless except on Windows where long file path are problematic. There is a 260 characters path limit and we are eating ~60 of them in the worst case. I don’t think this is practical problem though.
All, for those who haven’t been reading the Output Transform meeting notes, I am trying to finalize the list of changes I will need to make to included files, transform IDs and names in order to stage the “RC2” of the 2.0 dev release.
Please respond before July 12 if you would like to comment in any way on the list of pre-set transforms to be included and associated TransformIDs and UserNames. I will once more try to prompt the conversation with the following questions.
Please consider:
which transforms are included in the list
should D60 sim variants be included by default? (They always have been, but not for all output variants. We should probably have it for everything or for nothing. If not provided, they can always be created when needed by changing the creative white)
Are any transform pre-sets missing that you expected to be there?
Are any transforms present that you see no use for or think that we should omit?
User names
What is the proper level of description? Are they too simple? Or should they be more explicitly defined too?
How should the distinctions in characteristics such as limiting primaries, peak luminance and creative white be expressed alongside encoding parameters, all while keeping the names brief enough to appear for selection in UI menus by the average non-expert user?
TransformIDs
Are the updated TransformIDs any better for those who have expressed concerns about the previous ones?
Is the revised name string structure at all helpful? If not, why not? What specific changes would help satisfy you?
And the tag _IEC61966-2-1 is ambiguous (as we have discussed at length).
Could we use another tag which makes it clear which function you mean by that?
For clarification is
Output.Academy.P3-D65_1000nit_in_P3-D65_ST2084.ctl
the same as using in DaVinci Resolve CST
Output Color Space = P3-D65
Output Gamma Rec.2100 St2084
with Tone Mapping Max 10,000 Min 1000
?
and if not, what would relate to that Resolve setting?
