Hi all,
There were a couple questions in the paper about ACESclip and I wanted to provide my individual perspective on it. I agree with the sentiments that ACESclip should be simple, the only thing is, while assembling the different requirements, it got a little larger than originally envisioned. Metadata is certainly a key part of making the ACES files archival-friendly and certainly getting adoption of ACESclip is sincerely desired.
So a couple of direct questions are posed, and as best as I can, I will attempt an answer.
“Is it necessary to embed LUTS and ASC CDLs directly into the ACES clip file?”
The ACES_Tranform_Library XML element is directly to achieve “enable portability of ACES transforms in production”. I’m sure the community is well aware of the telephone-tag needed to get LUTs
in place for a production. These transforms are then promptly lost in the archive sense, and it would only be by coincidence if they got saved somewhere. While it is recognized that any sidecar can be lost, keeping it with an ACES sequence as required metadata give it a better chance of being preserved, and of being passed around when needed within a production.
The question also asks about ASC-CDL. This is a trickier one. ASC CDL already has several mechanisms for carriage including the EDL. There is also an XML form of ASC CDL. Because there was a recognition that sometimes a base grade is applied along with an IDT, and that sometimes there is an overall correction made
for a sequence, using the ASC CDL XML structure as a ‘leaf’ in the ACES clip XML would probably be a good thing. Presumably, there should not be a lot of extra code needed for this if a system can already read the ASC CDL XML format. So, ACESclip was never intended to replace use of ASC CDL in other formats, but is available as part of the ‘language of color’ that people are using to send ‘intent’ around with sequences.
It it not required that ASC CDL only be used within ACESclip.
“would it not be safer to embed the ACESclip data directly into the ACES container”
This was discussed at length. There is a problem in that ‘bad’ metadata is worse than no metadata sometimes. Consider in a production scale sequence (140,000 frames ) that the amount of time to reopen files and add a chunk of metadata at the end of all of them may be a costly processing operation. This may be of minor significance in a single VFX clip, but it is a major consideration when getting into sequences or productions as a whole. ACESclip is thought of as – all the metadata that never changes-- so a single change can represent metadata appropriate to an entire sequence. Note that application of ACESclip is also intended for dailies in which clips can be 20mins to an hour long, and that a single reference to the right metadata is better than having it in a large number of files that have ‘empty’ or ‘wrong’ entries.
“has XMP been considered”
XMP was not yet formalized when many design choices were made (although EXIF was). I believe the discussion came up but at the time, general XML was seen as a more broadly applicable standard.
There was also a recognition that OpenEXR has it’s own metadata and that the ACES container was standardized for the symbolic-based metadata structures within OpenEXR. There is no reason that an additional XMP ‘chunk’ (or even EXIF chunk) cannot be defined for use within ACESclip or OpenEXR. It is all a question of what would get the best support. Even now within the XML structure of ACESclip, an XMF field could be placed into the ACES_info subsection. I think a detailed proposal on how to do this from proponents would be most welcome.
“ACESclip is not widely advertised”
A chicken and egg problem. Some of the explicit marketing has down-played ACESclip because vendors indicated they might get to this last. ACESclip is part of the Logo program and I hope it gets the attention it deserves. Anything that users can do to help with adoption would be a great thing.
It may not be clear from the document that there is no requirement for any of the elements except for ACESconfig. Look for min_Occurs=1 to see what would be expected in a file.
A simple ACESclip could just be
ACESconfig
timestamp
version
aces:PreviewTransform
aces:RRTref
aces:ODTref
It is a reasonable question to ask about whether other elements within ACESclip should be removed so that implementations could be simplified and adoption enhanced. A reader is currently expected to read and pass through all of the metadata elements though many of them may not be present in any particular file. I think that is something that the Community should look at. It is a similar problem to ‘dark metadata’ : what should a program do if it doesn’t recognize chunks of metadata. Throwing out all unrecognized metadata is not the right answer 
I look forward to further discussion.
Jim