Answers to Chris’ questions below:
- Yes, it is possible to create a “simple” ACESclip using the current Strawman (re-introducing
- In the more “complex” ACESclip representation an (optional)
<history> element is introduced, where items no longer current are timestamped and moved into (and eventually forgotten). Only elements outside of
<history> are mandatory and relevant for immediate/automatic/default processing.
I can play a live demo on ACESclip at the next VWG meeting, showing how the XML looks like and changes after 6-7 steps of an end-to-end pipeline: on-set, pre-grading, editorial, grading, compositing, mastering, archival.
Furthermore, attached here is tentative draft on an ACESclip specification that I based on the Strawman, but including the clipID.
S-2019-009__ACESclip_W.Arrighetti_v1.1.1.pdf (635.0 kiB)
Please consider chapters 1, 4, 5 and app. A to be mostly copy-n-pasted from the original ACESclip document, whereas chapters 3 and 6 and apps. B and C to be completely new.
The document is a preparation for the more complete ACESclip (which will include the historic/forensics optional component), as well as additional features for some of the XML elements.
However, if you stick with just Required elements (and their attributes), the implementation is essentially based on Strawman, with the only new introduction being the
<clipID> element for binding with footage.
As regatrds samples in my posts above from last week, you will find the “simple” ACESclip example in Appendix B (strawman_Walter-sample_01.ACESclip.xml), whereas the more “complex” ACESclip example (with “historic” color-pedigree) in Appendix C strawman_Walter-sample_02.ACESclip.xml).
Here is a further update, with full historical/forensics elements included.
- Appendix A is currently unfinihsed; will contain the full ACESclip XSL.
- Appendix B contains the “simple” ACESclip usecase (one double LMT, one color pipeline, no historical data)
- Appendix C contains a complex ACESclip usecase (including full color-pedigree); it also shows how to link to an IMF package (both output-referred mastered, and an App.#5 ACES master).
S-2019-009__ACESclip_W.Arrighetti_v0.7.pdf (612 kiB)
Any program that is capable of processing history/forensic elements (either reading and writing), will do it. Otherwise, the product will simply ignore the whole
<history> top-level element (but leave its content unchanged).
Whenever ACESclip is processed, if something changes, a new
<colorPipeline> element is generated, whereas its “old” content is appended as a new
<revision> element in the historic section (i.e. the top-level
<history> element). Things that can be retrieved from there are:
- What was a specific clip stored in the past: which filename, file format, tapename (up to the original camera name and metadata when, if and when it was a camera-native file)
- what Input Transform (and its parameters) the camera-native file was processed with (otherwise this would be lost when camera-native is rendered into an ACES color-managed EXR/MXF file).
- what Ouptut Transforms (and their parameters) the footage had been viewed though, in several stages of production/post-production (this may be recorded even for files no longer in thse viewing pipelines, like the on-set’s)
- what LMTs (including CDLs) was the footage processed with, that may have been possibly baked in a future render of the file
- are we looking at a baselight-grade, a technical-grade, a creative-grade or a finished version of the film?
- who, from which system and application (and their versions), domain/hostname, touched that file