CDL support

[photonclock]

Lattice SWODs when importing the following XML CDL (in a file named onset.cdl)

<?xml version="1.0" encoding="UTF-8"?>
<ColorDecisionList xmlns="urn:ASC:CDL:v1.01">
    <ColorDecision>
        <ColorCorrection>
            <SOPNode>
                <Description>Neutral (modified)</Description>
                <Slope>1.00000 1.00000 1.00000</Slope>
                <Offset>0.00000 0.00000 0.00000</Offset>
                <Power>1.00000 1.00000 1.00000</Power>
            </SOPNode>
            <SatNode>
                <Saturation>1.00000</Saturation>
            </SatNode>
        </ColorCorrection>
    </ColorDecision>
</ColorDecisionList>

[gregcotten]

I had to look up what SWOD meant! Yes I can definitely reproduce this - when I updated cdl_convert to the newest version I had no idea that if it errored out it would ask for user input aka "Press enter to quit"! Fixed and will be in the next release.

[photonclock]

I've yet to find any CDL that Lattice will successfully parse. Please document an XML example. Thank you.

[gregcotten]

That is definitely a problem! We use cdl_convert, an open-source python library for converting between various CDL formats. It looks like there is a small bug (that I have just now fixed) that prevents Lattice from correctly parsing .cdl files. Most users are bringing in CDLs through .cc, .ccc, or .ale files so thanks for catching this bug with .cdl!

[gregcotten]

Additionally, I believe the CDL should look like this - the Color Correction nodes require IDs.

<?xml version="1.0" encoding="UTF-8"?>
<ColorDecisionList xmlns="urn:ASC:CDL:v1.01">
    <ColorDecision>
        <ColorCorrection id="neutral">
            <SOPNode>
                <Description>Neutral (modified)</Description>
                <Slope>1.00000 1.00000 1.00000</Slope>
                <Offset>0.00000 0.00000 0.00000</Offset>
                <Power>1.00000 1.00000 1.00000</Power>
            </SOPNode>
            <SatNode>
                <Saturation>1.00000</Saturation>
            </SatNode>
        </ColorCorrection>
    </ColorDecision>
</ColorDecisionList>

[gregcotten]

If you are ever needing just "one-off" CDLs I would highly recommend using .cc files.

All you would need to do is:

<ColorCorrection id="cc03340">
    <SOPNode>
        <Description>change +1 red, contrast boost</Description>
        <Slope>1.2 1.3 1.4</Slope>
        <Offset>0.3 0.0 0.0</Offset>
        <Power>1.0 1.0 1.0</Power>
    </SOPNode>
    <SatNode>
        <Saturation>1.2</Saturation>
    </SatNode>
</ColorCorrection>

[gregcotten]

Fixed and released in 1.4.7!

[photonclock]

If the ColorCorrection node does not have an id, Lattice should be able to ignore that and proceed with parsing the more relevant data - slope, offset, power, saturation values. Thanks.

[gregcotten]

@photonclock

Not sure if I feel comfortable supporting something off-spec from the ASC-CDL. I've contacted Arri about their issue - I have not seen a ColorCorrection node without an id before and the ASC-CDL spec strictly requires one.

[photonclock]

Not sure why you care about parsing a trivial bit of XML metadata that isn't particularly relevant to the operations performed by Lattice. The relevant data is SOP/SAT.

[gregcotten]

@photonclock Fixed it. It'll be in the next release.

[gregcotten]

@photonclock

Just so you know, there are programmatic reasons for taking the reasons behind the spec into consideration.

For example, in a CDL file with many corrections that a software must distinguish between, what do you do if the CDL nodes do not have ids? Do you start at "001" and increment up as you find more nodes without an id tag ("002", "003", etc.)? What happens if you decide that incrementing is the appropriate solution but then you end up having an ID collision when you stumble upon one of the nodes in the CDL file that has an ID specified as "001"? How do you handle those kinds of collisions? This is why I'm hesitant to break the spec.

[photonclock]

I'm not suggesting Lattice should ignore the spec where Lattice is writing CDL files -- I'm only suggesting that Lattice not be strict when parsing CDLs for input to Lattice. As far as your concern about providing a unique id (presumably for writing a CDL back out when none was provided on input -- ? -- I'm not entirely sure how Lattice uses 'id' or in what circumstance Lattice would need to track multiple CDLs by a unique id value) -- in any case, if it matters, throw a string with an md5 into the id parameter, i.e., "Lattice-vX.XX-12345678901234567890123456" to make it unique. But the id value just isn't important in any workflow I've encountered. Not to say there isn't a workflow where it is important, but I just haven't seen it. In most pipelines I've encountered, CDL via XML is usually only passed between onset color apps and dailies apps, and possibly from dailies to VFX. Otherwise, SOP/SAT is usually passed through the pipeline via Avid ALE, or EDL/CDL (a hideous format if there ever was one), or a codebook that contains the SOP/SAT values and other metadata for tracking the shot the SOP/SAT values were applied to. I know Nuke and Resolve do not care about the id value when parsing CDL.

[gregcotten]

Though this is completely inconsequential as the issue has been resolved, the CDL importer in Lattice will give the user a list of grades labeled by their ID - that is why it is important that they have one (programmatically generated or not).