Is mid gray nit setting in ST2084 based on 0.18 in scene linear, not 18% mid gray?

Discussions - Using ACES
,
1

I assume that 18% reflectance mid gray is 0.2 in scene linear and 90% is 1.0. Is this correct? If it is, could you please explain me this:

I added a solid white in Resolve and multiplied it by 0.2 to get 18% reflectance equivalent. After that I added Color Space Transform effect to convert from linear to ST.2084 (not ACES), and get a 10 bit value 365. This perfectly matches new Resolve ST2084 nits waveform analyzer scale. And if I multiply by 0.15 instead of 0.2, I get 10 bit value 340 and 15 nit on analyzer. Everything works as expected.

Then I turned off Color Space Transform effect and added ACES 1.1 Transform effect to convert from ACES AP0 Linear to ST2084 ODT with mid gray setting exposed to the user and set to 15 nit. But in this case I got 10 bit value 352 instead of 340.

I thought I did something wrong or maybe Resolve has something wrong with its ACES, so I checked it with Paul Dore OFX ACES 1.2 and get similar results.

After that I changed multiplication of solid white from 0.2 to 0.18. And this time I got perfect match with Resolve analyzer showing 15 nit and 10 bit value 340. Then I changed ODT mid gray from 15 to 20 nit and get 10 bit value 365 and again perfect match with Resolve nits scale in analyzer showing 20 nit.

Looks like in ACES mid gray is 0.18 in scene linear instead of 0.2. Could you please tell me, what is the reason for that, or am I wrong and missed something?
And thank you all for ACES! Itā€™s incredible!

2

No, this is not a correct assumption.

Generally speaking - 18% is 0.18 and 100% is 1.0.

In the ACES specification (SMPTE ST 2065-1), an 18% scene reflectance maps to a value of 0.18. However, technically speaking according to the ACES specification, a nominal 100% scene reflectance value actually does not map to an ACES value of 1.0, but instead to an ACES value of 0.97297. This is because ACES is defined via a Reference Image Capture Device that has a nominal camera flare value of 0.005 and ACES is normalized to 0.18. Hence, 1.0x(0.18/0.185) = 0.97297.

And yes, 0.18 should map to 15 nits by default through the HDR ACES Output Transforms.

4 Likes
3

Thank you for your answer! This is really helpful!
I checked LogC white paper. There 18% mid gray is full scale 10 bit value 400. Which actually maps to 0.18 in linear gamma. I was sure it will show 0.2, to be honest.

My assumption was based on lutcalc
Screenshot 2021-01-30 193920

Is this something about full vs legal thing? I always thought Linear encoding can only be in full scale.

4

I think that the confusion may come from the fact that Sony refer to something they ā€œlinear IREā€ in their white papers, where 20% linear IRE is equivalent to 18% reflectance.

This is further confused by some of the Sony S-Log papers giving conversion equations to reflectance, and some to linear IRE. So sometimes a compensation factor of 0.9 is needed, and sometimes it isnā€™t.

As far as I know, only Sony do this.

It looks like your plot comes from LUTCalc by Ben Turley. Since Ben (I believe) owns Sony cameras, and built the app originally for his own use, he incorporates the Sony linear IRE calculation in the app.

1 Like
5

Hi All,

Iā€™m the Ben that Nick mentioned. I donā€™t have much useful to add, but my understanding of the linear IRE thing is down to the conventional reference white in the real world being a 90% reflectance card . The knee in conventional cameras tended to make 90% reflectance = 90% recording, but without the knee activated 90% reflectance would notionally be 100% recording at nominal exposure, and with conventional gamma 100% linear ā†’ 100% gamma corrected.

Now we have cameras capable of huge dynamic ranges and curves deliberately intended to have lots of headroom so that camera midtone exposures can be consistent even when highlights are challenging. We also have ACES designed to bring disparate cameras into a consistent frame of reference, and to get to that frame of reference and keep the maths sensible a well (sensibly) defined scene linear is the way to go, and 90% reflectance is, like 18% grey, a reference point rather than a limit.

I have no idea why Sony (and if I remember correctly Canon with the first C-Log white paper) went with ā€˜linear IREā€™ in their log technical documentation, but I can say that in writing my app it was a headache double checking when the 0.9x factor is needed.

As a fun side experiment, if you have LUTCalc, you can try comparing DJI D-Log gamma to Sony S-Log3 with ā€˜slopeā€™ set to 0.9 in the ASC-CDL customisation. This is the same as multiplying by 0.9 in linear space (ie 18/20). I got the parameters for both of those curves from the respective manufacturers published documentation,

Ben

1 Like
6

Continuing the 90 vs 100 nit topicā€¦

Looks like these IDTs for canon from ampas github donā€™t have the 0.9 multiplication (I compared Canon Log 2) and thus donā€™t match neither the OETF in CTL from the Canon downloads page, nor Resolve implementation for Canon IDTs (there are some differences in 3x3 matrices between Resolve Canon IDTs and official Canon IDTs though). And in Resolveā€™s Color Space Transform OETFs for Canon donā€™t match anything at all. So it is another one (third) implementation.

So, whoā€™s versions are correct in the end? :slight_smile:
Probably by saying ā€˜correctā€™ I mean where 0.18 CV equals 18 nit from scene. But Iā€™m not sure this is the way I should think of it.

And there is one more thing, itā€™s not about exposure, but regarding Canon primaries. Their rec709 (even D55) is not even close to match Rec709 primaries, and the same with DCI-P3 (which they at least named DCI-P3+). Is their rec709 meant to be different from the actual rec709 or they made 9 typos :slight_smile:

Thanks!

7

Iā€™m confused. What are you referencing?
The IDTs on the aces-dev Github repo donā€™t have Rec.709 or DCI-P3 versionsā€¦ they are intended to map the camera primary encoding setting (either Rec.2020 or Cinema Gamut) to ACES 2065-1 encoding.

8

In the end of the page there is a link to ā€˜LegacyIDTs.mdā€™ There are links to IDTs published by Canon in CTL.
For example this one:
Canon_EOS_C100_IDT_A_D55_Ver.1.0.ctl (3.8 KB)

	aces[0] =  Clip(0.561538969   * lin[0]  +0.402060105 * lin[1]  +0.036400926 * lin[2]);
	aces[1] =  Clip(0.092739623   * lin[0]  +0.924121198 * lin[1]  -0.016860821 * lin[2]);
	aces[2] =  Clip(0.084812961   * lin[0]  +0.006373835 * lin[1]  +0.908813204 * lin[2]);

The same matrix can be found here: ACES_ODT_Candidates/ACES_ODT_Candidates_rev009.ocio at main Ā· ampas/ACES_ODT_Candidates Ā· GitHub
And it is called Rec. 709 Daylight here.

Lines 430-443:

 - !<ColorSpace>
    name: Input - Canon - Canon-Log - Rec. 709 Daylight
    family: Input/Canon
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Canon-Log - Rec. 709 Daylight
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    to_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: Canon-Log_to_linear.spi1d, interpolation: linear}
        - !<MatrixTransform> {matrix: [0.561539, 0.40206, 0.0364009, 0, 0.0927396, 0.924121, -0.0168608, 0, 0.084813, 0.00637383, 0.908813, 0, 0, 0, 0, 1]}

But it doesnā€™t match an actual rec709 to AP0 matrix (using cat02), which, if Iā€™m not mistaken, looks like this:

{{0.4395756842f, 0.3839125893f, 0.1765117265f},{ 0.0896003829f, 0.8147141542f, 0.0956854629f},{ 0.0174154827f, 0.1087343522f, 0.8738501650f}};
9

I see, thanks for clarifying. And yes I get similar numbers as you for a Rec.709 to AP0 matrix.

The C100 models were not submitted through the ACES Logo Program, and so I can not say exactly what Canon was doing in those legacy IDTs since I never qualified them, butā€¦ if you open up those CTLs, you can see that there are actually two matrices included. These IDTs have an additional 3x19 matrix prior to a linearization step and then a second conversion matrix to ā€œACESā€. The matrix you are citing as Rec709 to ACES is only the second of those matrices. As such, I think the labeling is a bit misleading and I donā€™t think it is intended to be equivalent to a ā€œRec 709 to AP0ā€ matrix. The matrix2 is most likely going from some internal camera encoding that is active when the camera is set to ā€œRec. 709ā€, which results from applying matrix1 to camera native data.

The real question is what does the camera setting ā€œRec. 709 Daylightā€ actually mean in terms of what the primary encoding is when set to that mode? I trust Canon to know the inner workings of their camera and how the native data should be interpreted better than myself. My suspicion is that the confusion is mostly attributable to a failure in clear and accurate labeling and being a bit lax with the term ā€œRec. 709ā€

1 Like