As mentioned in the April 3 WG call, I added the ability to pass the a surround setting to the JMh-to-XYZ conversion that happens toward the end of the processing chain. (I believe this effect is equivalent in the Nuke to changing the selection for the Output viewing conditions.) It is important to note that changing the values at this step change the effect of the JMh-to-XYZ conversion step only and does not cascade back to the other times the surround values are used in by the same CAM formulas, so won’t affect the earlier rendering steps or parameter that have already been set to assume those values for the CAM conversions.
The effect seems to be what we’re after but the magnitude of the adjustment between the settings is quite large.
It was suggested that I compare against the adjustment currently being done in v1, which I knew to be quite subtle, but noticeable. The plots confirm that the magnitude of the effect is much greater in v2 with the current values that are set by the viewingConditionsToSurround( ) function.
With a bit of further testing, I think we could still use this mechanism to apply the adjustment, but just set more realistic values for the 3 toggles. The default in all of the transforms right now is “dim” because that is what everything was set to while we were doing the development.
No I don’t believe so. Although at this point, v1 is probably at least somewhat more realistic a guide than the existing parameters as pulled from the CAM (since we’re not using them as intended and we’ve been told that even when used as intended they don’t seem right).
I agree that a much smaller value change along the lines of +/- 0.01 is probably much closer to what values would be determined if we did some testing, but without setting up some experiments to verify, such numbers would just be a guesstimate.
Have you tested whether you need to include this in the hull for gamut mapping, as @priikone mentioned? If the conversion from JMh to output is changed, intuitively the hull we gamut map to also has to change. If the surround tweak was after all output but before encoding, eg a gamma tweak to Y when we were in XYZ before final RGB encoding, that wouldn’t affect gamut mapping.
The stock set has no explicitly bright surround targets. Only dim, and implicitly dark for the cinema ones.
Many people found the dark-to-dim compensation in ACES 1 confusing, expecting to see a match between cinema and Rec.709 with just a conversion of encoding primaries and EOTF.
Correct. An ACES value of 0.18 is mapped to 10 nits by the 100 nit Rec.709 rendering and 4.8 nits in the 48 nit P3 renderings.
This is because they use exactly the same tone curve. The rule is that for cinema rendering we use a peak luminance value in the tone curve calculation which is 100/48 * actual_peak_luminance. For SDR renderings we do not need to cancel that out in the encoding step, since those are 0-1 normalised. It does need to be accounted for in ST.2084 encodings, so that e.g. a 108 nit rendering has a tone curve calculated based on 108 * 100/48 = 225 but is still encoded with a peak of 108 nits. That is the purpose of the linear_scale_factor in the code, which is 1.0 in most cases, but 0.48 for PQ encoded cinema renderings.
We obviously can’t know what everybody wants. And that wouldn’t be the same for everybody anyway!
I was what was wanted by those who expressed a preference during the meetings. I believe one of those was @jzp, and it tallies with what he said here:
I think that with ACES 1 many people were confused that a simple colorimetric mapping from a cinema rendering to Rec.709/BT.1886 did not match the Rec.709 rendering.
If you look at the ARRI Reveal LUTs, they have done the same thing. I believe for the same reason.
I would argue that the dark-to-dim compensation in the ACES 1 transforms is enough to be noticeable if you A/B images and your expectation is that they should look the same, but small enough that its absence makes no real difference to how you perceive the image without an A/B comparison.
