Multi-camera LOG workflow (A7S / Blackmagic / DJI) in YRGB Classic – Group Pre-Clip vs Post-Clip CST & Timeline Color Space

[Badi Soussi]

Hi everyone,

I'm working on DaVinci Resolve 20.3.2 in YRGB Classic (no Color Managed), on a multi-camera project mixing the following sources:

• Sony A7S – S-Log3 / S-Gamut3.Cine
• Blackmagic – ProRes / Blackmagic Film Gen 5
• DJI – D-Log M

Clips are organized into groups per camera. My Output Color Space is set to Rec.709 (Scene), for web and TV delivery.

---

Question 1 – CST placement: Pre-Clip, Post-Clip, or both?

Three approaches seem possible to me:

Option A – CST in Group Post-Clip only
One CST per group converts each camera's LOG directly to Rec.709 at output. Simple, but grading happens in different LOG spaces depending on the group. Is this an issue for cross-camera consistency?

Option B – CST in Group Pre-Clip only
Each LOG source is converted to a common space (e.g. DaVinci Wide Gamut) before grading. But what should the Timeline Color Space be set to in this case? And is a Post-Clip CST to Rec.709 still needed?

Option C – CST in both Pre-Clip and Post-Clip

• Pre-Clip: LOG → DaVinci Wide Gamut (one CST per group/camera)
• Post-Clip: DaVinci Wide Gamut → Rec.709 (shared across all groups)
• Timeline Color Space: DaVinci Wide Gamut

This feels like the most rigorous approach. Is this the recommended practice in YRGB Classic, or is it overkill for a standard Rec.709 delivery?

---

Question 2 – What does Timeline Color Space actually do in YRGB Classic?

In YRGB Classic, does the Timeline Color Space have any direct impact on the grade when everything is handled manually with CSTs? Or is its role limited to scopes and a few specific tools?

---

Question 3 – LOG vs Rec.709 as Timeline Color Space: impact on tools

I've noticed that some tools — particularly the Chroma Warp — behave differently depending on whether the Timeline Color Space is set to Rec.709 or a logarithmic space like DaVinci Wide Gamut.

Is it correct to set the Timeline Color Space to DWG and the Output Color Space to Rec.709 (Scene) in YRGB Classic? Do color space aware tools operate within the declared Timeline Color Space, which would justify working in a wide space for greater precision?

---

Thanks in advance for your input!

 

[Rajneesh Kassin]

I think it's kind of "dealer's choice" -- there is no one way and no "best way."

I've been using CST Input (aka IDT) nodes in pre-clip, then CST Output (aka ODT) nodes in post-clip for awhile now. Be aware that if you apply a "Look" in the Post-Clip node, like Film Emulation or an extreme color change, it always has to end with the correct CST Output node. I generally use a DWG/DV Int timeline color/gamma space, and output to Rec709/2.4 these days. For very simple projects, doing the whole thing in Rec709/2.4 is not a crime against god -- working in Display-referred will still work provided you have a calibrated display and a color-managed Blackmagic output device, like a Decklink or UltraStudio.

Node Stack Layers are another way to handle this, but that's an extra degree of complexity I try to avoid, because of the clash with grade rippling. MultiMaster Trim Manager in Resolve 21 presents some other ways of handling different CST Out / ODT possibilities.

 

[Tony Sal]

Badi,

A key element when developing your workflow and node tree is implementing a "Strict Discipline" throughout the process so that handing off the project to another team member or yourself in the near or distant future will not result in pulling your hair out because the node tree or workflow was a one off hack and now makes no sense for your future self.

I spent many hours creating a node tree exclusively at clip level which allows me to view all my operations (I call this the pilot cockpit approach) so that I do not have to bounce back and forth between pre, post and timeline level which I personally wish to avoid. I did this approach so that six months or later if I open up a Resolve project I can instantly see at a glance exactly what work was done.

However as Rajneesh has stated there is no "Best way". As a single owner/operator it comes down to what works and is most time efficient for yourself, clients needs, deadlines and budget.

I recommend stress testing your workflow and node trees with a test project to determine the pros and cons versus what needs to be revised. Keep in mind you are not creating a one off workflow or node tree as whatever you create must be able to work for present and future projects as well as allowing for easy expansion and revisions if needed.

In my case when working with multi camera clips I created a baseline fixed node tree which has an empty node #1 which is reserved for the camera CST and the final node for the ODT. I can easily create revised gallery stills of that baseline node tree with specific camera OETF and color gamut related node # 1 CST which is then globally applied to camera original clips sorted at keywords or group level which speeds up the process.

 

[Rajneesh Kassin]

I spent many hours creating a node tree exclusively at clip level which allows me to view all my operations (I call this the pilot cockpit approach) so that I do not have to bounce back and forth between pre, post and timeline level which I personally wish to avoid. I did this approach so that six months or later if I open up a Resolve project I can instantly see at a glance exactly what work was done.

I sympathize with the difficulty in bouncing back and forth between Pre-Clip, Clip, Post-Clip, and Timeline. I created a bunch of Streamdeck macros with dedicated buttons to get there, and it's been rock-steady with Resolve 20.

With Resolve 21, they changed the UI and "in theory" you can get to all the Group Grades and Layers with Keyboard Customizations, but they're broken for me in Resolve 21 build 48. I'm assuming those will be working soon.

I'm still a little suspicious of Node Stack Layers, but Group Grades can actually be a pretty good way to work. I concede that everybody works differently, and I'm coming from the world of longform; it'd be different for people working in commercials, shorts, music videos, and so on.

 

[Pepijn Klijs]

Any transform you place in post group will not allow you to grade the image after that transform, which is something to consider.

 

[Clark Bierbaum]

In my case when working with multi camera clips I created a baseline fixed node tree which has an empty node #1 which is reserved for the camera CST and the final node for the ODT. I can easily create revised gallery stills of that baseline node tree with specific camera OETF and color gamut related node # 1 CST which is then globally applied to camera original clips sorted at keywords or group level which speeds up the process.

Big fan of this way of working so future me or others can understand what “flow” of the grade is. I “share” grades with a client so they can render locally and do minor tweaks and we have found this workflow and labels make for clean exchange of grades.

 

[Tobias Wiedmer]

I personally don’t like to have shotwise CSTs in the pre/post group as I like to use groups for scenes. That’s why I have the input transforms as dctls and load it via input lut. if you don’t have those you could theoretically also use actual LUTs. that way the node tree is clean more like a color managed project. setting the correct timeline colourspace is important for some colortools and also the node colorspaces. output colourspace is less important IMO but still good to set it right for metadata default, scopes and generally speaking also for DolbyVision. BTW you mentioned DLog-M. I have built a special input transform for it (it is not the same like DLog).

 

[Shebbe Klaasen]

Option C – CST in both Pre-Clip and Post-Clip

• Pre-Clip: LOG → DaVinci Wide Gamut (one CST per group/camera)
• Post-Clip: DaVinci Wide Gamut → Rec.709 (shared across all groups)
• Timeline Color Space: DaVinci Wide Gamut

This feels like the most rigorous approach. Is this the recommended practice in YRGB Classic, or is it overkill for a standard Rec.709 delivery?

I wouldn't call this overkill, just a normal manual managed pipeline that can be deployed consistently across projects and fairly quickly at that if you save some stills for predefined conversions you often use.

There are a few reasons to prefer this approach over your other mentioned options.

About option A (grade each log, then convert to 709):
- Using non color aware tools that operate directly on incoming r/g/b can feel/look weird depending on what the working gamut is it's applied on. This becomes worse or at least inconsistent when shot to shot working space is different within one project when grading multiple cameras.
- Shot/scene/look matching and copying becomes difficult as decisions are based on one working space and may not translate to the other.
- DaVinciDRT (what your CST applies by default when tone mapping) does this on the incoming gamut rather than it's own rendering space. This can cause minor to extreme image appearance inconsistencies depending on what the input gamut was. It is therefore another reason to stay away from multiple input spaces that convert directly to 709 if CSTs is what you want to use.

An extreme example would be this blue light bar scene of which left is converted from AP0/Linear -> DWG/I -> 709 and right from AP0/Linear -> 709.


About option B (convert to one space and 'grade your way to 709'):
- Grading directly on log towards a display can be a choice, but not using some form of image formation post grade (CST, LUT, ACES etc) can cause a ton of consistency and quality issues. It's very difficult to manually 'tone map' an image with typical grading tools.
- The same reason as A, it is difficult to 'normalize' log data if the gamut is not angled in a suitable way against the target display gamut. Some colorists may prefer the direct relationship between the tools you use and the output signal/scopes, but without good image formation (tone mapping, DRT, LUT etc) it is very tricky to effectively shape the image without breaking consistency.

In YRGB Classic, does the Timeline Color Space have any direct impact on the grade when everything is handled manually with CSTs? Or is its role limited to scopes and a few specific tools?

- The timeline definition is used in color space aware tools and their scopes.
- Converting a node's color space or gamma will use the timeline definition as the source to convert from. This is useful for converting to linear for example when doing white balance through Gain wheel. Or if you need a linear signal for effects like lens blurs or glows to generate realistic ranges for them.
- When using a CST, wherever you leave it to "use timeline" it will use the project timeline definition as it's value. Has it's benefits but I personally prefer to always define it in absolute sense.

For the above mentioned any of those nodes should only be placed in the pipe where the incoming image data matches that of the timeline otherwise a mismatch would be present.
Logically as soon as this mechanism is utilized anywhere in the grade, the direct impact it has would be that changing it after the fact changes it's internal conversions and thus the image. So just like global management you ideally set this up first thing.

Question 3 – LOG vs Rec.709 as Timeline Color Space: impact on tools

I've noticed that some tools — particularly the Chroma Warp — behave differently depending on whether the Timeline Color Space is set to Rec.709 or a logarithmic space like DaVinci Wide Gamut.

Is it correct to set the Timeline Color Space to DWG and the Output Color Space to Rec.709 (Scene) in YRGB Classic? Do color space aware tools operate within the declared Timeline Color Space, which would justify working in a wide space for greater precision?

If they are color space aware, they will only function as intended if they're used in the pipe where the image data matches that of the timeline. It doesn't mean they'll break otherwise, but if you ever have artifacts/negative values/clipping, that is probably a place to look first. A semi exclusion to this is HDR wheels since that can have it's own overrides via it's dots menu if necessary.

Speaking from my own experience, I always run manual management with node pre/post or pre/timeline (we only do grading in Resolve so we can do timeline level stuff) and it works every time. Whenever I deal with Rec.709 material that doesn't need to be mixed and matched with log I almost always grade display referred directly on it. No point making things more complicated if not necessary.

I think in the ideal, grading software and/or the user would only ever provide/use rigid color aware tools which would make the working space choice virtually irrelevant if the tools and ecosystem were designed well. Each tool would have it's own suited environment and nothing ever happens in a user driven intermediate state. But I guess lift/gamma/gain/offset and other typical non aware tools will probably stick for a long time still...