CDL WTF

[Tom Gleeson]

Can anyone explain or point to me some resources on effectively using the three wheels under CDL in RedcineX ? The traditional three wheels in colour grading are obvious but CDL is somehow using them differently. It would be great if there are videos online showing people using them but I can find very little.

The manual unhelpfully says POWER This group allows you to adjust the Power image characteristics. OFFSET This group allows you to adjust the Offset image characteristics. SLOPE This group allows you to adjust the Slope image characteristics. How does anyone imagine this is helpful?

 

[Michael Tiemann]

CDLs are my new favorite topic ;-)

First, let me say that I'm not nearly the level of some of the good folks on these boards who are real experts on the topic. But having spent some time using it to solve a problem, I have some insights.

First of all, CDL is basically a very simple mathematical pre-processor, sitting between the first encoding of a RAW image to Log3G10 and the application of a creative LUT file. Log3G10 has nice properties, such as the fact that middle gray (0.18 in linear light) is encoded as 1/3. Many creative LUTs, such as Phil Holland's philmColor base and ghost LUTs, are carefully designed to be 18% gray-preserving, meaning that if your scene does have a swath that measures 0.18 in linear light, it will measure 1/3 in Log3G10 both before and after the application of the LUT. But not all LUTs maintain constant exposure: the philmColor print and tone LUTs are all about making things lighter or darker (or more contrasty or less contrasty) on a global basis. LUTs are wonderful and can create all sorts of looks, but they are not a panacea. In particular, they cannot see very well into the first several stops of a Log3G10 imaging pipeline because...math.

I wrote up a blog posting about my efforts to create a LUT to provide GIO Scope functionality in a post environment: https://manifoldrecording.com/2017/12/20/gio_lut/

TL;DR: even with Log3G10 encoding, the first 10% of a 33x33x33 LUT are busy encoding the lowest levels of exposure (stop 1) while the next 10% encode stops 6 and 7. While Log3G10 can encode values that are easily distinguished as stops 2, 3, 4, and 5, when presenting them to a LUT, they all collapse into either a bin that's claiming to also represent stop 1 or a bin that's claiming to represent stop 6. No good!

But with a CDL, one can transform the straight Log3G10 encoding into something that spreads more evenly across the LUT buckets. In the GIO Scope case, I found that a slope of 1.1, an offset of -0.10184, and a power of 0.5 not only allows for very good distribution across a 33x33x33 cube, but it even works with a 17x17x17 cube (somewhat...stops 3 and 4 are coalesced into stops 2 and 5 respectively):

gioColors17 = [
[0.29,0,0.36],# UV-1 @ 0
[0.42,0,0.51], # Magenta-2 @ 1
[0, 0.42, 0.51], # MedBlue-5 @ 2
[0, 0.48, 0.55], # Sky-6 @ 3
[0, 0.61, 0.61], # Cyan-7 @ 4
[0.3, 0.51, 0.47], # CyanG-8 @ 5
[0, 0.51, 0.44], # Aqua-9 @ 6
[0, 0.51, 0], # Green-10 @ 7
[0.35, 0.48, 0], # GreenY-11 @ 8
[0.41, 0.45, 0], # YellowG-12 @ 9
[0.45, 0.51, 0], # YYG-13 @ 10
[0.55, 0.53, 0], # Yellow-14 @ 11
[0.51, 0.37, 0], # Orange-15 @ 12
[0.51, 0, 0], # Red-16 @ 13
[0.23, 0, 0], # Red-16.2 @ 14
[0.1, 0, 0], # Red-16.3 @ 15
[0.03, 0, 0], # Red-16.5 @ 16
]

And without the CDL we don't have proper bins for stops 2, 3, 5, 6, 7 or 10:

# [slope, offset, power] = 1.0 0 1.0
gioColors17 = [
[0.29,0,0.36],# UV-1 @ 0
[0.29,0,0.36],# UV-1 @ 1
[0, 0.32, 0.46], # DkBlue-4 @ 2
[0.3, 0.51, 0.47], # CyanG-8 @ 3
[0, 0.51, 0.44], # Aqua-9 @ 4
[0.35, 0.48, 0], # GreenY-11 @ 5
[0.41, 0.45, 0], # YellowG-12 @ 6
[0.45, 0.51, 0], # YYG-13 @ 7
[0.55, 0.53, 0], # Yellow-14 @ 8
[0.51, 0.37, 0], # Orange-15 @ 9
[0.51, 0.37, 0], # Orange-15 @ 10
[0.51, 0, 0], # Red-16 @ 11
[0.34, 0, 0], # Red-16.1 @ 12
[0.23, 0, 0], # Red-16.2 @ 13
[0.1, 0, 0], # Red-16.3 @ 14
[0.05, 0, 0], # Red-16.4 @ 15
[0.03, 0, 0], # Red-16.5 @ 16
]

Now, the GIO LUT is obviously something quite different than a typical LUT. But back to the point of why use a CDL...it provides a way to use simple math to convert a Log3G10 encoding into a mathematical range that's suitable for the creative LUT you want to apply. CDLs are not a substitute for Lift-Gamma-Gain. The latter is something one applies in the color grading process. CDLs are mathematical prep for the first LUT.

 

[jussi rovanpera]

Offset = Offset
Power = Gamma
Slope = Gain

The reason to have those 3 controls instead of lift-gamma-gain is that the offset is the exposure/white balance control for log footage, and you can still use the 3 controls for video grading as well.

 

[Michael Tiemann]

Offset = Offset
Power = Gamma
Slope = Gain

The reason to have those 3 controls instead of lift-gamma-gain is that the offset is the exposure/white balance control for log footage, and you can still use the 3 controls for video grading as well.

I have read that the Lift Gamma Gain formula is:

outputColor = (gainColor*(inputColor+liftColor*(1-inputColor)))^(1/gammaColor)

Whereas in CDL land

outputColor = (slopeColor*inputColor+offsetColor)^powerColor

If we pardon the fact that gammaColor and powerColor have a reciprocal relationship and root them both out, we have

gainColor*(inputColor+liftColor*(1-inputColor)) =?= slopeColor*inputColor+offsetColor

Now things get ugly. If we divide out by gain (aka slope), we get

inputColor+liftColor*(1-inputColor) =?= inputColor+offsetColor/slopeColor

If we subtract inputColor from both sides, we get the strange behavior that one side still has a color dependence and the other does not. If we try to collapse the left hand side we get:

inputColor*(1-liftColor)+liftColor =?= inputColor+offsetColor/slopeColor

When liftColor is zero, offsetColor can also be zero and everything is simple. But as liftColor rises from zero, it increasingly throws all bets off. When liftColor is 0.5, there's a 2x imbalance between 0.5*inputColor and 1.0*inputColor that these parameters have to balance, and no matter what assignments one makes, if the next pixel is a different input color, those won't be the correct assignments for that color.

THIS IS WHY IT IS SO IMPORTANT FOR DAVINVI RESOLVE TO SUPPORT CDLs AS PART OF IPP2!

 

[M Most]

There is no reason for complex mathematical explanations of a CDL. It's pretty darned simple. Offset is essentially an exposure control. Slope is essentially a gain control, but one can think of it as a contrast control (with a pivot of 0). Power is basically a gamma control, but one can think of it as a low end contrast control because that is where its effect is most dominant. If one must know the math, offset is an add function, slope is a multiply function, and power is, well, a power function. But thinking about all that defeats the purpose.

And for those who are wondering "why not use lift gain and gamma," there are two reasons. One, those functions are more appropriate and basically scaled for a video gamma signal. The exposure/contrast model (represented reasonably well by the CDL) is more appropriate for log coded material, which is more common in professional cameras today. And two, and perhaps most significantly, the authors of the CDL were trying to come up with something that was not being done by any software companies at the time, but could be directly supported by all of them and yield the same results across all platforms. Nearly all software uses slightly different math for lift, gamma and gain, and you get slightly different results with the same values. CDL results are identical regardless of the platform. The results are the same in Baselight, Resolve, Nucoda, Lustre, Avid, Nuke, and anything else that supports them.

Hope that makes it a bit clearer.

 

[M Most]

CDLs are not a substitute for Lift-Gamma-Gain. The latter is something one applies in the color grading process. CDLs are mathematical prep for the first LUT.

I don't know where you got this from or if you just came up with it yourself. But there is no validity to this statement. LGG and SOP (aka CDL) are just different mathematical approaches to a color transform. They don't have a specific purpose beyond that. While it is true that a CDL is often applied prior to the LUT (in fact, it SHOULD be), that is just the way a basic color pipeline is constructed so that it can be passed unambiguously between platforms. By using that simplified pipeline, a DIT can create a grade on set using a combination of a CDL and a show LUT, and that can be passed to a dailies colorist, who can pass it to visual effects, who can pass it to the DI colorist (if desired), without any concern for what software any of them are using. That's a common use, but it's not a description of what a CDL is or represents.

 

[Michael Tiemann]

CDLs are not a substitute for Lift-Gamma-Gain. The latter is something one applies in the color grading process. CDLs are mathematical prep for the first LUT.

I don't know where you got this from or if you just came up with it yourself. But there is no validity to this statement. LGG and SOP (aka CDL) are just different mathematical approaches to a color transform. They don't have a specific purpose beyond that. While it is true that a CDL is often applied prior to the LUT (in fact, it SHOULD be), that is just the way a basic color pipeline is constructed so that it can be passed unambiguously between platforms. By using that simplified pipeline, a DIT can create a grade on set using a combination of a CDL and a show LUT, and that can be passed to a dailies colorist, who can pass it to visual effects, who can pass it to the DI colorist (if desired), without any concern for what software any of them are using. That's a common use, but it's not a description of what a CDL is or represents.

It's something I made up myself, not as a definition, but as a description of its usage. Your explanation of its usage is excellent. But there remains a vital question to answer: why should a DIT create a grade based on a combination of a CDL and a LUT if LUTs alone can do everything? Your answer seems to be a combination of "because it's there" and "because it's platform-independent". Platform-independent I get. But why is it really there? Why can't we just have a Lin2Log LUT? Or a YourLog2MyLog LUT and skip the CDL entirely?

I think there's a deeper answer, which is "because LUTs can't do everything". In particular, the 33x33x33 (or whatever) cube is distributed evenly across each 0-to-1 dimension. No fixed kind of interpolation (linear, bi-linear, tri-linear, or tetrahedral) gets you out of the problem that somewhere in your image you're going to have closely neighboring pixel values that really want to be in different buckets so that they are transformed by different parts of the LUT, but, because of the fixed allocation of the LUT buckets, they cannot be.

Our two usage answers may not be entirely inconsistent. Experienced DITs could well know that LUTs work so much better with a little LGG or CDL conditioning ahead of them. And they might know intellectually that what a CDL is is nothing more than the mathematical transform (inputColor*slopeColor + offsetColor)^powerColor = outputColor, without making the explicit connection about how that math relates to the fixed buckets of the LUT. My point is that CDLs exist not just a means to codify and simplify a long-standing industry practice of how to construct a grade, but to give some color to why one needs both CDLs and LUTs to really get control over the full dynamic range of an image.

To summarize, if we want to create a LUT in which there's a distinctive transformation for each of the 10 stops of the Zone system, we likely need a CDL so that those 10 stops go into enough distinctive buckets that we can realize our Zone System goals.

 

[M Most]

It's something I made up myself, not as a definition, but as a description of its usage. Your explanation of its usage is excellent. But there remains a vital question to answer: why should a DIT create a grade based on a combination of a CDL and a LUT if LUTs alone can do everything? Your answer seems to be a combination of "because it's there" and "because it's platform-independent". Platform-independent I get. But why is it really there? Why can't we just have a Lin2Log LUT? Or a YourLog2MyLog LUT and skip the CDL entirely?

It's because in a typical pipeline (at least on a studio level show, but it should be on all shows) the LUT is intended to provide a proper transform from the camera's color space (typically some log space, like Arri LogC Wide Gamut, or Slog3/Sgamut3.cine) to the viewing space (usually Rec709). That transform is not variable. Any "look" management comes from the CDL. It's placed prior to the LUT so that all of the information from the camera is available (the LUT, in doing its job, can yield clipped or crushed values based on the exposure). The combination of the CDL (as a modifier, or call it a Look Management Transform...) and the single show LUT yields a "look" for each shot, and throughout the post pipeline - particularly when visual effects are involved - the CDL and the show LUT are provided to vendors as a viewing transform so that their results can match the dailies as a proper starting point, and to ensure consistency during editorial and previews.

There is, of course, also the fact that CDLs can be passed as notes in an EDL in a standard format, so they can be referenced (or applied) during editorial, and passed on to the DI as part of the conform. And the fact that there is only one CDL format (unlike LUTs), so there is little to no interchange issue. Nor is there a need to save and pass hundreds of separate LUTs. I could list more reasons, but I think that pretty much covers it.

 

[Marc Wielage]

I don't know where you got this from or if you just came up with it yourself. But there is no validity to this statement. LGG and SOP (aka CDL) are just different mathematical approaches to a color transform. They don't have a specific purpose beyond that. While it is true that a CDL is often applied prior to the LUT (in fact, it SHOULD be), that is just the way a basic color pipeline is constructed so that it can be passed unambiguously between platforms.

That is absolutely true. In fact, I'm not sure there's anything done in a CDL that can't also be done in a LUT. As far as I know, the processing is essentially identical -- only the tools used to create them are different.

People tend to ascribe some kind of magic to RedCine-X Pro, but to me it has very, very basic kind of color correction controls that you could duplicate in any decent software out there. I think RCX is fine for temp looks and checking footage out on the set, but beyond that it doesn't present even 1/10th of what you could do in what I call the Big 6: Baselight, Lustre, Mistika, Nucoda, Pablo, or Resolve. I think people around here get excited because RCX is free, but I think there are much better, more practical options out there for post -- especially for finishing.

 

[Michael Tiemann]

That is absolutely true. In fact, I'm not sure there's anything done in a CDL that can't also be done in a LUT. As far as I know, the processing is essentially identical -- only the tools used to create them are different. [...]

Marc, did you not read my first posting above (2nd post of this thread)? In any case, let me answer directly.

RED cameras supposedly capture 16.5 bits of dynamic range with somewhere between 12 and 16 bits per pixel (we don't know because Graeme and company won't tell us directly). Nevertheless, if we believe this, then for a LUT to produce the same mathematical result as a mathematical transfer function (which a CDL is) would require a 2^16 x 2^16 x 2^16 LUT (for 16 bpp) or at least 2^12 x 2^12 x 2^12 (for 12 bpp). That smaller LUT is 4096 x 4096 x 4096, which would require 64 giga pixel bins. If those bins are 16 bits, that's 128 GB of RAM just for the LUT. So in a theoretical sense you are correct, there is not anything done in a CDL that can't also be done in a (sufficiently large) LUT.

But when it comes to practical LUT sizes: 33x33x33 or 65x65x65, there absolutely are things that can be done in a CDL that cannot be done in a LUT. Namely, when too many of your pixels are all binned to the same LUT position, you'll get a blocky output which, in a more perfect world, would have preserved the slight differences between the pixels by sending those pixels to different buckets within the LUT. Interpolation can get you some of the way there, especially if all you want to do with your LUT is to approximate a CDL. But with a LUT + interpolation you run out of accuracy far faster than with a mathematical transformation like a CDL. And that can still be a problem for the pipeline downstream.

But this all missed the larger point, which is that the combination of a CDL + LUT, from a mathematical perspective, gives one a very powerful way to optimize the behavior of a LUT against a given input. And it means that one can get that optimal behavior even when all the camera teams each have a different idea of how they should expose for middle-tone gray. I'm not arguing that it's wrong to use the CDLs and the LUTs the way that the industry has for years. I'm arguing that there's math that reinforces the wisdom of their decision to use them as they do: together.

Which is why it would be great for DaVinci Resolve to treat the CDL as a first-class resource in the RED IPP2 Camera Raw section, and to follow through on supporting IPP2 by applying the CDL before the creative LUT.

 

[D Fuller]

Thisn is excellent stuff, guys. Thank you for the clear explanations.

 

[Dermot Shane]

still not getting why Michael can't put a lut after a grade in Resolve? what's that about?

 

[Michael Tiemann]

still not getting why Michael can't put a lut after a grade in Resolve? what's that about?

I want to load a CDL into resolve. The manual says nothing about CDL support except in discussing ColorTrace, where it offers this (on page 960):

Importing CDL Data Using ColorTrace

The ColorTrace CDL command lets you import ASC CDL file formats from other applications into DaVinci Resolve. DaVinci Resolve version 11.1 also added the ability to read DRX filenames from CDL files, allowing a CDL to load exported DaVinci Resolve grades.

There are three supported file formats:

* CMX EDL: An EDL with comments referring to CCC/CDL XML files, or even Slope, Offset, and Power (SOP) data within the comment area.

* CCC and CDL XML: A file format that contains various color correction looks, and even references.

To import CDL data into DaVinci Resolve:

1 If you’re importing CCC/CDL XML correction looks:

Open the Gallery page, right-click anywhere within the Stills tab, and choose “Import”
from the contextual menu.

When the Import Stills dialog appears, open the CDL/CCC files. When these are finished importing into the Gallery, an ASC logo will appear along with them.

****

However, when I point to an XML CDL file, the option to import is grayed out. So I cannot import it. The grading controls of Davinci Resolve are limited to Lift-Gamma-Gain, which isn't the same math as CDL. I cannot condition my Log3G10 data to match the expectations of my LUT without a CDL transfer function. The LGG transfer function screws things up.

So now I have two problems: no CDL support (neither upon import nor in any way within the R3D RAW control panel), and no good way to use my LUT inside of Resolve. Red Cine-X solves both problems elegantly, by giving me both the ability to import a CDL file and the ability to manually control CDL parameters. And by allowing me to feed my LUT with properly-massaged (post-CDL) data. Resolve, of course, offers many features that Red-CineX does not. But its support of IPP2, limited to debayer and a little bit of magic if you happen to choose Rec 709 as your input and output color spaces, doesn't do it for me.

 

[M Most]

The file for import must have an extension of .cdl or .ccc, not .xml. If it has that and it's still not importing, it's not formatted properly, either missing a tag or including some non-standard tag. Once imported, you drag the grade (it will come up in the gallery with an ASC symbol on the thumbnail) and it becomes a corrector node. When creating CDLs for export in Resolve, you must set Luma Mix to 0, and you must restrict yourself to using Lift, Gamma, Gain, Offset, and Saturation controls. The Offset directly maps to CDL offset. The Gain directly maps to CDL Slope, and Gamma directly maps to CDL Power. If you use Lift, Resolve calculates values for a rough CDL equivalent by manipulating both Offset and Slope. This is exactly what is done in other programs as well (Colorfront, Baselight, numerous others). Besides, as I've said elsewhere, the math used in a CDL is simply a way of expressing a transform in a common, directly exchangeable way. Once the grade is loaded, it doesn't matter whether you want to manipulate it further with those same controls or not. I don't understand why you seem to feel you can't manipulate the grade in Resolve when it comes in from a CDL simply because you don't have exactly the same parameters, although as I've just stated, you actually do have them.

The vast, vast majority of people here use Resolve as their one and only grading tool (we won't get into the why of that....). They seem pretty darned satisfied that DaVinci's interpretation of the IPP2 transforms is just fine. I don't know why you aren't.

 

[Michael Tiemann]

The file for import must have an extension of .cdl or .ccc, not .xml.

Roger that. My cdl file has a .cdl extension. For good measure, I copied the text from the resolve manual into a file I called example.cdl

This is the text from the manual:

Example CDL File

<ColorDecisionList xmlns=<94>urn:ASC:CDL:v0.5<94> >
<InputDescription> GeneralProducts M1 std thru GP M1 LUT4 </ InputDescription> <ViewingDescription> GP P1, DCI P3, Pathe color emul </ViewingDescription> <ColorDecision>
<MediaRef ref=<94>/some/Project/frame%250900-0954%5B.dpx<94>/> <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> </ColorCorrection> </ColorDecision> </ColorDecisionList>

That did not import.

I changed the <94> characters to ascii double-quotes (i.e., ")
And I changed the ” do ascii double-quotes (i.e., ")

Still no joy. My CDL file looks like this:

<?xml version="1.0" encoding="UTF-8" ?>
<ColorDecisionList xmlns="urn:ASC:CDL:v1.01">
<ColorDecision>
<ColorCorrection>
<SOPNode>
<Description></Description>
<Slope>1.1 1.1 1.1</Slope>
<Offset>-0.10184 -0.10184 -0.10184</Offset>
<Power>0.5 0.5 0.5</Power>
</SOPNode>
<SATNode>
<Saturation>1.00000</Saturation>
</SATNode>
</ColorCorrection>
</ColorDecision>
</ColorDecisionList>

Maybe I need to tweak some other part of my project/timeline so that the idea of interacting with a CDL is not alien to Resolve 14.2?

 

[M Most]

In the first one, get rid of the entire MediaRef line (in other words, delete <MediaRef ref=<94>/some/Project/frame%250900-0954%5B.dpx<94>/> ) and get rid of the id in the ColorCorrection tag (change <ColorCorrection id=”cc03340”> to simply <ColorCorrection> ). That should make it usable. In the second one, get rid of the information in the ColorDecisionList tag (change <ColorDecisionList xmlns="urn:ASC:CDL:v1.01"> to simply <ColorDecisionList> ). If neither of those changes give you something that Resolve will import into the Gallery, try changing the file extension to .ccc . Here is an example of something that definitely works:

<?xml version="1.0" ?>
<ColorDecisionList>
<ColorDecision>
<ColorCorrection>
<SOPNode>
<Slope>0.902835 0.919379 0.929504</Slope>
<Offset>-0.021038 -0.039963 -0.034350</Offset>
<Power>0.847374 0.823053 0.860297</Power>
</SOPNode>
<SatNode>
<Saturation>1.089300</Saturation>
</SatNode>
</ColorCorrection>
</ColorDecision>
</ColorDecisionList>


Use that as a template and replace the values with your own.

 

[Michael Tiemann]

In the first one, get rid of the entire MediaRef line (in other words, delete <MediaRef ref=<94>/some/Project/frame%250900-0954%5B.dpx<94>/> ) and get rid of the id in the ColorCorrection tag (change <ColorCorrection id=”cc03340”> to simply <ColorCorrection> ). That should make it usable. In the second one, get rid of the information in the ColorDecisionList tag (change <ColorDecisionList xmlns="urn:ASC:CDL:v1.01"> to simply <ColorDecisionList> ). If neither of those changes give you something that Resolve will import into the Gallery, try changing the file extension to .ccc . Here is an example of something that definitely works:

<?xml version="1.0" ?>
<ColorDecisionList>
<ColorDecision>
<ColorCorrection>
<SOPNode>
<Slope>0.902835 0.919379 0.929504</Slope>
<Offset>-0.021038 -0.039963 -0.034350</Offset>
<Power>0.847374 0.823053 0.860297</Power>
</SOPNode>
<SatNode>
<Saturation>1.089300</Saturation>
</SatNode>
</ColorCorrection>
</ColorDecision>
</ColorDecisionList>


Use that as a template and replace the values with your own.

I saved that file as example2.cdl and that did not work for me. However, as I've been poking around I found where I can begin to export CDL-related stuff from my timelines (Edit Pane -> Timeline -> Timelines -> Export) and so I'm going to see if I can generate a working CDL file for myself somehow. I have set Lum Mix to zero for all my clips, and as my new default in the Project Settings -> General Options -> Color tab.

 

[Michael Tiemann]

Replying to myself, I have discovered that the secret to getting Resolve to attempt to actually open a CDL file is to temp it with an EDL file. So now I'm going to spend some time trying to figure out how to create a nicely permissive EDL file that will basically let me import CDL files in some intuitive fashion. The most intuitive fashion, of course, would be to import them as part of the Camera RAW -> RED parameters. But I might be able to live with something else, provided the CDL is executed in the appropriate part of the grading pipeline (ie., after ISO and WB and before the Creative aka Input LUT).

 

[M Most]

Replying to myself, I have discovered that the secret to getting Resolve to attempt to actually open a CDL file is to temp it with an EDL file. So now I'm going to spend some time trying to figure out how to create a nicely permissive EDL file that will basically let me import CDL files in some intuitive fashion. The most intuitive fashion, of course, would be to import them as part of the Camera RAW -> RED parameters. But I might be able to live with something else, provided the CDL is executed in the appropriate part of the grading pipeline (ie., after ISO and WB and before the Creative aka Input LUT).

That's just not the case, at least not for everyone else. Right clicking in the Gallery pane and selecting Import should allow you to import a CDL file (or multiple CDL files) directly into the Gallery. That works for me and everyone I know, and has for a number of versions now.

 

[Michael Tiemann]

That's just not the case, at least not for everyone else. Right clicking in the Gallery pane and selecting Import should allow you to import a CDL file (or multiple CDL files) directly into the Gallery. That works for me and everyone I know, and has for a number of versions now.

I'm glad it works for you. I'll file a support case with BMD regarding my shiny new iMac Pro running Resolve Studio 14.2 on High Sierra. I was afraid that for some reason Resolve was being intentionally obscure or obtuse about supporting CDL files in any reasonable or logical way. If it is only a question of my own computer being unreasonable or obtuse, that's a much easier problem to solve.