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.
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!
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’.
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%.
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.
// 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.
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).
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.
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.
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
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?
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.
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
