Here I try to reply to your questions one by one with my personal views.
In the next reply I will draft my personal view on immediate actions.
.
“ACESclips” should be a sidecar to any clips – either stored in an ACES format (ST2065-4/-5) or not. It’s in the latter case (ACESclip manifesting a non-ACES footage), however, that their power becomes even more useful.
Just think to camera-native raw files (ARRIRAW, R3D, etc.). They are usually brought deep into a postproduction pipeline “as is”, because of time / computation / storage effort to transcode into EXR and preservation of original picture and metadata.
An outstanding exception to that being de-Bayering camera RAWs at the source to ensure pixel-precise plates are delivered to all departments (e.g. VFX).
When such camera-native files are extensivley used deep into a workflow, they may undergo many ACES technical and creative processes, until a master is finally produced in another file format. Along the pipeline color and imaging metadata were stacked, that different production software (conforming, compositing, color, video localization) may refer to.
Such information are, roughly:
- which ACES version is being used overall
- which exact IT (and its parameters) was used to enter the clip into ACES
- which CDL was used to monitor on-set (might be never used again, yet still relevant)
- which LMT(s) were applied at different steps (possibly stacked one on top of the other)
- multiple OTs (and their parameters) might have possibly be pre-determined for specific, generic or particular devices/enviornments, to view the clip with
The mos timportant aspect, to me, is how to logically link the ACESclip to its footage. Despite <ClipID> and other tags already drafted in the strawman, a very important piece is still missing: without a recommended practice (in fact honored by all Product Partners) to link an ACESclip to the UID specific for every major image file format, there is no chance to mantain such a logical link.
It is Ye Same Ol’problem of “which camera metadata do I put in an EDL tapename?”, as well as “which ALE column do I conform an edit against?”.
Once it is clear which metadata in a file header the ACESclip links with, no naming-convention of filesystem proximity loose bonds are needed.
I suggest, however, to keep in the ACESclip specification that, for as far as possible, ACESclip should aldo be bound to its videoclip or file-per-frame sequence using also naming convention enforcement. For example (exploring either XML and JSON options):
- To a RED clip
A174_C001_1901FF_001.R3Dthe ACESclip should beA174_C001_1901FF.ACESclip.xml(hint: RED tapenameA174_C001_1901FF, instead, is not sufficiently unique to serve as ClipID) - To an CinemaDNG file sequence
reel_[0000000-9999999].dngthe ACESclip should bereel.ACESclip.json
Places to specify ACES version as well as IT, LMT and OT are already in place in the strawman. They should only be “extended” to allow:
- parameters in case a parametric Input Transform is used
- parameters in case parametric Output Transforms are used (read below)
- multiple Output Transforms in case a previous team steps backwards in the pipeline (e.g. camera, pre-grading, or an OTT distributor who later stream the content) pre-arranged a series of predetermined viewing devices to view the clip with, for example:
- 1 standardized on-set monitor
- 1 standardrzed HDR monitor for editorial
- 1 DCI projector
- 1 primary grading HDR monitor
- 1 standardized monitor for compositing
- 1 common Rec709 output for production-people previz on iPads/etc
- 2 standardized profile HD TV models for HD deliveries
- 1 standardized profile for DolbyVision HDR deliveries
- 1 standardized profile for HLG HDR deliveries
- different LMTs in case different creative looks are to be compared. In this case the ACESclip may reference different external CLFs or they may be included in the XML/JSON in a separare area of the ACESclip, each with its UUID. In the color-pedigree section of the ACESclip, they are simply recalled based on that UUID (either stacked one on top of the other, or as alternatives that may be selected from a UI). This is the same mechanism used in reference files in a DCP: there is a XML namespace of all the assets, where UUID is liked to every file (the PKL) and another XML namespace where timeline is described by its assets (the CPL).
- While ACES components contained in Academy-distributed, official ACES releases may be referenced by just their name (or, better, via the hash of their original files – see my earlier proposal on TransferHash field in CTLs), possibility to link customized, non-official components should be given. They may be either referenced as external files (so again a UUID/hash mechanism realizes the logical bond), or just embedded inside the ACESClip (which is useful particularly for XML ACESclips and external files, as namespaces can be reliably used)
- Examples of such externally- or internally-referenced ACES components may be:
- customized ITs (e.g. non-Product Partner cameras, or inverses of unofficial OTs).
- customized RRTs (of course this should be avoided for as much as possible),
- customized ODTs (e.g. exotic or particular monitors where the ODT may also account for their profiling)
- other forms of creative or technical transforms to be considered as (parts of) LMTs
- 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). Again, particularly for XML ACESclips where attributes can be added to XML elements, I usggest 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 (accoring to the system’s local time of course)
- hostname, username, OS (+version) and software application (+ version) doing the change
- optional comments/notes that can be hand-filled