EDL to CDL conversion tool

Tags: #<Tag:0x00007f964c8ce4b8>

(Walter Arrighetti) #1

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.

You can find the edl2cdl here in my GitHub page

(Alex Beyer) #2

Hi Walter,

there is a very elaborate Python and PyPy script out to convert between different CDL / CC formats:

I needed to convert a RESOLVE .cdl (which is a CMX EDL with CDL comments) and it didn’t work with your script.


(Walter Arrighetti) #3

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.

(Alex Beyer) #4

Hi Walter,

thanks for your reply.

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

(Nick Shaw) #5

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.

(Walter Arrighetti) #6

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).