We had a good first call this morning (reminder that meeting times, agendas, and notes will be posted on the ACESclip Workspace), and one of the questions that came up was related to modifying ACESclip metadata, and how a user would expect that to be handled.
The example brought up was that on-set DIT might create ACESclip files to pass along to the dailies facility, and a dailies colorist may re-balance (or get DP notes to modify) CDLs or LMTs that are contained or referenced.
Proposal #1: modify ACESclip and time stamp modification date using
<modificationDateTime>, so an ACESclip will always assumed to be ‘current’ when receiving one. Would we want other identifiers like hostname or software name that modified it?
Proposal #2: append new values or even entire new
<ACESclip> instances within a master ACESclip file, becoming larger as more modifications are made, and ‘current’ values would be flagged somehow. Is the history of changes important? What is the use case?
Of course we are open to other proposals but these are the first that come to mind.
Please chime in if you have any thoughts on this topic.
I think that, if the format is carefully designed (and, again, I’d love to be inspired by IMF CPL logics), it should be possible to have both:
- a simpler syntax where just one change is indicated (and overwritten every time),
- whereas a history or revisions may also be stored (as part of a pedigree)ò
This way a “consumer” application which doesn’t support such versioning just skips the parsing of pedigree part when an ACESclip is read. It just honors the ACESclip at its current state, without its full history of revisions or cases.
How to do this? From my previous suggestion in “What is ACESclip?” thread (I know it was a damn long post, not many read it probably):
ACESclip may be generated as early as near-set or upon ingestion by the post facility) and may be modified in later stages (image pre-processing, pre-grading, color-grading, compositing, finishing, mastering).
I suggest every update is associated to a UUID that is reported as an attrivute to any element added or modified during that update. In a final part of the ACESclip a list indexed by those UUIDs reports logged data for each update, such as, at least:
- date/time of the change
- hostname, username, OS (+version) and software application (+ version) doing the change
- optional comments/notes that can be hand-filled
On the next topic I’ll post a sample strawman of the above concept on the original example ACESclip XML from Appendix A of
Please have a look at the uploaded example ACESclip XML from Appendix A of
TB-2014-009 in the form that I substantially modified…
By the way,
changing-metadata-sample.ACESclip.html (6.2 KB)
I had to change extension from
.ACESclip.html in order for it to be uploadable.
<Config> section may reference color-transforms in the
<TransformLibrary>. Cross-reference is against a
There is a
<History> section where the pedigree is stored as a list of
<Revision> elements, each with a mandatory
When either configurations (in
<Config> section) and color-transforms (in
<TransformLibrary> section) need to be versioned, a
ver attribute in their children is used to cross-reference with the
id attribute of a specific
<Revision> element in the
Coming to the ACESclip sample…
Here we have a clip with a sidecar ACESclip file that stores, since its inception, a color pedigree describing the whole “color history” of the clip itself.
- The clip is ingested from camera magazine, in a DI station (Input Transform is chosen once for all)
- On-set grading happens, in the form of a simple CDL
- DI colorist reviews the clip and applies basic look in the DI theater (3 days after), as a 3D LUT and, at the same time, the P3@D60 Output Transform for the theater is also chosen
- Another colorist prepares the Output Transform for the future HDR mastering on HLG monitor
- First day of finishing (simplifying, as another 3D LUT) is completed
To reconstruct the history, look at matching
ver attributes of elements in the top part of the XML with
id attributes of
<Revision> elements in the bottom section of the XML.
Besides, there are two “technical” Output Transform choices: one for DI theater and one for HDR mastering: they are indexed according to the
status of the
<OutputTransformList> elements, which is respectively valued
And, remember that simpler applications may just completely ignore the