Hello.
After many years I’m back at writing pure code to help my teams with automations for a theatrical project we’re doing VFX and finishing for ― all in an end-to-end ACES 1.0 pipeline of course !
In particular, this Python script is called edl2cdl and its task is to translate the CDL values embedded in an EDL file from editorial into ASC CDL’s XML-based formats (.ccc, .cdl and .cc file extensions). edl2cdl has mainly one small, practical but paramount use by CG/compositing products (like The Foundry Nuke), which are poorly to completely-non timeline based, while artists using them still benefit to view their job through the cinematographer’s own intent (which should have been quite effectively represented via CDLs).
Adding some automation to have the right VFX plates receive the corresponding CDL from the set can be tricky, so this script (plus some Nuke gizmo I’ll post later) allow for a really functional and working workflow.
Where’s the ACES part? Well, despite CDL can be well used outside of (and in fact were designed by the ASC long before) ACES, they are indeed a valuable bridge component to it.
Particularly if your on-set or near-set color-grades are done using CDLs viewed through an ACESproxy pipeline or on top of a color-corrector internally working in ACEScc, then the transmission in the next DI, VFX and finishing stages is very straightforward as long as CDLs are always applied on top of ACEScc codevalues.
Hi Alex. edl2cdl works only if the clipname/filename is written in some specific fields within the EDL, as written in the description in github.com/walter-arrighetti/edl2cdl This just covers a handful of possibilities among the manifold ways EDLs can account for clip-related metadata (like reel/clip/tape/file names).
For EDLs done that way, there’s not really much more needed than this conversion script. More complex tools, like the one you mention, may be able to process a broader range of ways to incorporate metadata (though I’ve never tried it myself).
Based on my experience, edl2cdl is capable to do the job for all the CDL-based cinema projects, shot in ALEXA/RED/Sony cinema cameras I recently stumbled upon – at least according to the on-set convetions used by most DITs in my country).
If you want to share your EDL it’s possible that format can be considered in the future for the script.
The clipname / filename is not the problem. Your script doesn’t seem to recognise the CDL values within the EDL. I suppose the regular expression doesnt allow for the SOP/SAT format Resolve is exporting. Below you find a CMX3600 CDL example exported from Resolve (unnecessary empty lines removed)
TITLE: BRIT_EP101_NC5_270217_SC20_HND_FST.edl
001 B052C009_160726_R01P V C 10:58:03:18 10:58:05:22 10:21:36:05 10:21:38:09
*ASC_SOP (1.078738 1.078738 1.078738)(-0.177261 -0.174328 -0.134739)(1.000000 1.000000 1.000000)
*ASC_SAT 1.000000
FilmLight’s Prelight (and Truelight Onset) generate EDLs in that same format, and the script gives a “No Color Decision(s) found” error with these too.
Hi Alex.
Thanks for posting your EDL with embedded CDL; I modified the script on GitHub that should now be able to parse the numerical values with 6 decimal digits as well (as in your example).
I need to point out again, though, that the script assumes the CDL’s CCCid filed to be taken from ClipName comment-line (as written in the script’s ReadMe on GitHub), not from the inline TapeName field, as seems instead to be the case in your example. Your EDL should also contain a "* FROM CLIP NAME: ClipName" line (ASC_SOP and ASC_CDL are comments as well).
Hi Jose.
From what I see it’s not an incompatibility with DaVinci Resolve’s EDLs, but the fact that the comments in the EDL were not prepared as specified for edl2cdl. EDLs can be generated/exported/converted with many different conventions, according to your interoperability needs and workflow.
As clearly reported in edl2cdl's readme page from GtiHub, the tool works only with those events in an EDL that correctly associate a CCCid field (i.e. the identification tag of a colloquially-referred-to-as “single CDL”) to the corresponding set of color-grading numeric parameters.
The above association is usualy workarounded with the CCCid reported in the corresponding event’s comment-line * FROM CLIP NAME:, which I don’t see in your example.
This is a best practice of many on-set products; or at least it was when the tool was developed a few years ago.
So, in your comment, the tool cannot guess the name of the target CDL(s); in an EDL with multiple cuts (events), each with potentially different color corrections, there would be plenty of CDL files to export – yet which grade goes in which filename?
Also remember that using the right command-line arguments, edl2cdl can also instructed to export all the color-correction data (“single CDLs”) in a single .CDL file.
Thanks for the reply. Doing some tests I found many more aspects of the EDL that weren’t being recognized, like the lack of space after starting the comment line, and the existence and format of the two editing lines (even in presence of the * FROM CLIP NAME). As far as I know Resolve doesn’t give out options for EDL formatting, I think it uses CMX Style EDLs, only the “ALE with CDL” exports Clip Name and CDL but in ALE format. So probably it is out-of-spec EDL export?
Anyway I don’t do much editing work so I created a ccc style CDL template and just replace the 10 values, with the ccc I can use different CCCid’s to layer CDLs in Nuke, and hopefully Maya.
CMX 3600 is actually the real standard for EDLs (althoigh it has “legacy” limitations such as in tapename length). edl2cdl actually supports CMX3600.
The reason why it does not support multi-line events (cuts), is because it was conceived precisely for what seems apparently your very usecase:
source clips being on-set / near-set footage, where pre-grading is applied (as CDL) to individual camera-raw clips juxtaposed one next to the other (so no real need to support multi-track timelines),
target CDLs to be later used, automatically, in a VFX pipeline for viewing the plates with the same look designed on-/near-set with the cinematographer.
The tool was in fact developed for extracting CDLs (as either .ccc collections and .cc individual grades) for the the VFX plates of Il Ragazzo Invisibile: Seconda Generazione (G.Salvatores, 2018).
On the other side I also developed a NUKE gizmo to open the ARRIRAW shots and automatically apply the corresponding CDL by matching he CCCid field with the tapename in the .ari file header. I had planed to share this latter tool on GitHub (and reference it on ACES Central as well), but it needs a few restructuring in order to make it self-consistent from other, unrelated production pipeline.
ALEs are a good way to get ASC CDL lists out of Resolve. Parsing the values out of those and writing stand alone CDL files is relatively simple. I have a Python script wrapped in a OS X Automator app which you can drop an ALE on and it will generate CDLs. It is not sufficiently thoroughly tested yet to make publicly available, though!