Today we are releasing ACES 1.2 Release Candidate 2 (ACES 1.2 RC2) the ACES community for final review. ACES 1.2 RC2 is based on the significant and substantive feedback collected from the Architecture TAC, various ACES Working Groups, and the ACES community after the release of ACES 1.2 Release Candidate 1 in December of 2019. As such, we are asking you to review RC2 for critical “showstopper” issues that would impact the final release of ACES 1.2. In particular, we would like you to review the attached Common LUT Format (CLF) and ACES Metadata File (AMF) specifications which represent key new features included in ACES 1.2. We are asking the community to provide relevant feedback by March 20, 2019. During this final review, substantial editorial changes or changes to the scope of RC2 will be logged and held for consideration in a future ACES release. Barring any showstoppers, the final release of ACES 1.2 will be issued shortly after that date.
ACES 1.2 represents a significant step in setting the stage for ACES 2.0. We would like to thank the members of the ACES community who have actively participated in the development of ACES 1.2 through ACESCentral.com and within the various Working Groups. We believe your participation in the process that we’ve created, have continued to refine, for the inclusive and open development, review, and delivery of ACES releases has led to a stronger ACES release that better addresses the needs of the motion picture, television and broader content creation communities.
I’ve been reviewing the latest drafts and also looking at the CTL under the v1.2_rc2 tag on GitHub and have a few comments:
In the CTL, I notice some of the ACEStransformIDs have change format. For example, in idt/vendorSupplied/sony/IDT.Sony.Venice.SGamut3.ctl it has: <ACEStransformID>urn:ampas:aces:transformId:v1.5:IDT.Sony.Venice.SGamut3.a1.v1</ACEStransformID>
In my opinion, the URN stuff is not necessary. Also, it is not applied consistently across all transforms. Is there an update to the ACES Versioning spec that discusses that? It should probably be posted here too.
One of the weakest parts of the current specs is the lack of detail about how to establish a link between an AMF file and the transforms it references. This is done via the ACEStransformID but now there seems to have been a major change to those IDs that seems to have had no discussion here on the forum. Are there any examples of how this is to be used? I’m worried that this will cause interop problems.
The IDT referenced in the previous point is expecting linearized data. This is a change from the other IDTs. It’s not clear why the Venice has this IDT but not one that is expecting S-Log3 encoded values (which would be much more common).
The naming of the CSC transforms should be reviewed. For example, in csc/sony/ACEScsc.Academy.SLog3_SG3_to_ACES.ctl it has: <ACESuserName>SLog3 SG3 to ACES2065-1</ACESuserName>
Why is the naming so different from the equivalent IDTs? For example, why “SG3” here but the IDT says “ACES 1.0 Input - Sony SLog3 SGamut3”?
I think the CLF spec should get an updated name rather than S-2014-006. It seems CLF, AMF, and the updated versioning spec should get document names that start with “S-2020-”.
I’ve noticed some minor issues with the matrices in the IDTs/CSCs and have started a private thread about that. I’ll report back if necessary, but wanted to at least mention the issue.
I suspect that may be down to me making up “placeholder names” when I wrote the CTL for the CSTs, and not flagging it up as something that needed to be updated.
Well, the URN stuff as you call it has been added to follow a broadly adopted convention for public identifiers. It’s a practice that allows identifiers to be prefixed with the urn prefix and a scheme that eases detection and parsing.
While AMF could have lived without this change, please consider the fact that transform IDs also might be stored elsewhere. Having a consistent mechanism to identifiy transform IDs and a scheme that tells you what to expect and how to parse them is IMHO helpful.
As a matter of fact I find the regex in the AMF XSD not so useful because any change in the syntax of the transform IDs would require a change in the XSD too.
I hope that helps, but feel free to discuss that at our upcoming call today.
Hi there, I was wondering if there’s any news on when ACES 1.2 will be available in DaVinci Resolve. Is there any update as to whether Blackmagic plan to implement it in Resolve 16?
