ACES 1.2 Release Candidate #1

Alexander_Forsythe · December 21, 2019, 5:16am

ACES 1.2 Announcement

We are sharing today, an ACES version 1.2 release candidate 1 that includes the AMF spec and the CLF spec. These specs were developed by the respective Virtual Working Groups (VWGs) and commented on by the ACES Architecture Technical Advisory Council (TAC).

A year ago, we targeted this week for the production release of ACES 1.2, but the TAC has requested a little extra time to encourage additional comments from the ACES Implementation VWGs, implementors and the public before the production release. We believe doing so will ensure that the widest and most thoughtful community comments are received and will result in AMF and CLF specs that will be rapidly and widely adopted by the industry.

The evaluation period for this release candidate will close on January 17, 2020. We anticipate the production release several weeks after that depending on feedback received.

This is the first ACES release under the new, more community-driven governance structure. We are confident that its structured, multilevel and transparent development process is a significant improvement and therefore will result in a better end product for content creators.

Thanks to the many participants on our calls and on ACESCentral.com who have contributed their best thinking on these topics. We look forward to the production release on or about February 3, 2020.

Sincerely,

ACES Leadership

Thomas_Mansencal · December 21, 2019, 9:59am

Congratulations to the Academy and everybody involved. It is great to see how the community feedback contributed to steer and shape the project development process!

One could be nitpicking about details here and there but in the grand scheme of things it is a certainly a great step forward!

steve · January 7, 2020, 11:07am

The known error with the CTL interpreter, introduced with ACES v1.0.3, has still not been corrected.

If you look at an ODT file you will see that the ‘type’ of the parameter ‘legalRange’ was changed from ‘varying int’ with a default value of 0 (in ver 1.0.2) to type ‘uniform bool’ with a default value of ‘false’.

This changes the parameter from a variable to a constant, and for For some reason, the CTL interpreter is not correctly setting the default value to false. The interpreter randomly think it is set to true/false, so is incorrectly and randomly activating the ‘legal range code’.

The ODT has to be edited to remove this error.

Steve

nick · January 7, 2020, 1:47pm

It appears that in ACESlib.OutputTransforms.ctl, the order of operations still clips to LIMITING_PRI before chromatic adaptation. This means that, for example, for D65 Output Transforms without D60 sim, red is clamped at about 98% of Y_MAX. This is probably imperceptible for HDR Output Transforms, but if the Output Transform function is used for SDR, the red channel is clipped noticeably below 100%.

github.com

ampas/aces-dev/blob/63c45dec9bc7147cf95f7876f74c800d6563aafa/transforms/ctl/lib/ACESlib.OutputTransforms.ctl#L130


    }
} else if (SURROUND == 2) { // Normal surround
    // INACTIVE - this does NOTHING
}


// Gamut limit to limiting primaries
// NOTE: Would be nice to just say
//    if (LIMITING_PRI != DISPLAY_PRI)
// but you can't because Chromaticities do not work with bool comparison operator
// For now, limit no matter what.
XYZ = limit_to_primaries( XYZ, LIMITING_PRI); 


// Apply CAT from ACES white point to assumed observer adapted white point
// TODO: Needs to expand from just supporting D60 sim to allow for any
// observer adapted white point.
if (D60_SIM == false) {
    if ((DISPLAY_PRI.white[0] != AP0.white[0]) &
        (DISPLAY_PRI.white[1] != AP0.white[1])) {
        float CAT[3][3] = calculate_cat_matrix( AP0.white, DISPLAY_PRI.white);
        XYZ = mult_f3_f33( XYZ, D60_2_D65_CAT);
    }

I think that this has been discussed before, when it came up with regard to @Paul_Dore’s DCTL implementation, but I am flagging it up again, as I believe the issue is still present.
I will also raise an issue on GitHub.

KevinJW · January 7, 2020, 2:15pm

I believe I’ve only mentioned this in semi-private channels …

There is also a clamp in the ADX transforms (not new to 1.2):

lines around 71 in ACEScsc.ADX10_to_ACES.ctl and ACEScsc.ADX16_to_ACES.ctl

// Convert Channel Independent Density values to Relative Log Exposure values
float logE[3];
if ( cid[0] <= 0.6) logE[0] = interpolate1D( LUT_1D, cid[0]);
if ( cid[1] <= 0.6) logE[1] = interpolate1D( LUT_1D, cid[1]);
if ( cid[2] <= 0.6) logE[2] = interpolate1D( LUT_1D, cid[2]);

interpolate1D is defined to clamp outside the range and so there should probably be linear extrapolation added for the lower portion of values so that values below ‘95’ (-0.19) don’t get clamped during conversion. similar to how this values above 0.6 are handled.

There are potential issues with the following pow( 10 , logE[*] ) calls, but that is a more involved discussion relating to noise, that doesn’t have as obvious a potential fix.

I believe Filmlight currently do something similar to my suggestion in Baselight/Truelight.

Kevin

john.quartel · January 7, 2020, 4:39pm

One of the Bradford matrix coefficients in the P-2013-001 document is not correct (line 62 of procedure.tex). The first coefficient is listed as 0.8950 but I believe it ought to be 0.8951 (as listed int the ctls).

john.quartel · January 7, 2020, 4:52pm

I implemented the ADX transform in Baselight circa 2013. I analysed the 1D LUT and found that I could get a very good approximation with an inverse parabola (not only was this convenient for implementation as a shader, but I could also invert it symbolically). From memory, I broke out to linear at the bottom based on the last two points in the 1D LUT.

nick · January 7, 2020, 6:09pm

Hey @john.quartel! Good to see you here.

That sounds like a good idea to use a mathematical approximation to the LUT in the official CTL. Then the function becomes the actual transform, rather than an approximation of it, and will be the same in all implementations.

I’m fully in favour of replacing LUTs with mathematical operations where possible.

Even if it changes the result slightly, now seems like a good time to do it. The introduction of the SSTS changed the result of the HDR Output Transforms with 1.1, after all.

KevinJW · January 8, 2020, 8:37am

I didn’t want to say what Filmlight actually did, as i wasn’t sure if that might break some license… but I independently did the same linear extrapolation using the bottom two nodes.

I did not try fitting to a function, but i agree with the potential benefits, next time i need to revisit ADX I’ll see if i can find something that has similar benefit for our primary implementation using. OpenColorIO

Kevin

sdyer · January 23, 2020, 9:06pm

Thanks for the reminder. I have reverted the Rec. 709 and Rec. 2020 SDR ODTs to the syntax used in ACES pre-1.0.3. The changes are on the ‘dev’ branch ahead of the ‘rc1’ tag and will be included in the 1.2 release. Direct link below:

Does this look like it will address your concerns?

sdyer · January 29, 2020, 1:17am

Thanks, @KevinJW for the feedback. I also have not forgotten your feedback to my query regarding experiences with ADX (and whether or not the per-channel gains were used or not).

It is probably a good idea to replace the LUT segment with a functional approximation and unclamp the bottom end, but I think it will be deferred to a later release since this was never on the list for ACES 1.2 and I would want time to test any changes that we make to this transform.

There has been talk of maybe starting an “ACES with film” virtual working group in the near future, and this transform would be well within scope for such a group to examine and suggest updates.

I’ve added an issue on Github to keep this logged for the next version.

KevinJW · September 11, 2020, 10:33am

As I was browsing some of my workings for something else I came across this and thought I should include the Graph of the extension to save people the bother