Using LUTs With Resolve Color Management || Davinci Resolve 17 Tutorial

This video details the best way I've found to use a LUT, specifically a film print emulation lut, in a color-managed workflow within Davinci Resolve and still get normal behavior.
Enjoy!

[@carlos.sierra]

Dude. Thank you so much. This is exactly what I've been looking for!!! You earned my sub. Hopefully, you can keep making more!

[@sergiofermin5482]

THANK YOU! Amazing examples.

[@mindthebumpproductions]

Thank you, Errick! I've been looking all over for this as the Color Managed really means a break with my usual workflow. It's surprising to me how little attention this issue has been getting. Thank you so much once again. :)

[@ErrickJackson]

Glad this could help!

[@jean-david-ouellette]

Thanks a bunch for this information! This was the last key for me to start considering the Davinci Wide Gamut workflow. You rock!

[@cody_t]

Thank you! I love color management and have been using 709-A since I grade on a MacBook a lot of the time.

[@AMeza-fb7ko]

Nice tutorial, man. Keep them coming!

[@ErrickJackson]

Absolutely will! Glad you liked it!

[@RolandAyala]

Great stuff! Thanks so much.

[@ianharper6015]

Thank you for a really helpful video.

[@santark7]

Genus ! Thank you !!!!!

[@petrub27]

EVERYTIME A KZbinR APPLIES A LUT , MUST SAY BOOM

[@ErrickJackson]

First rule of being a KZbin Colorist for sure haha

[@Freddd95]

Great stuff, I made two corrections though that worked better for me: 1. Use cineon film log instead of arri logC 2. Don't select "use timeline" on the CSTs, instead specify Davinci Wide Gamut / Davinvi Intermediate.

[@ErrickJackson]

Yes, good callout. I noted after the fact that I should have stated LogC was a personal choice over Cineon for the somewhat gentler curve, but not technically correct. In hindsight, also not warranted since I could have just lessened contrast pre-LUT to my taste. On the Use Timeline setting, you can indeed use it, but you need to have the correct OOTF selected (which you’ll need to check regardless when doing a transform loop inside of an RCM workflow). Admittedly, I don’t think I was aware of this fact back when I made this video. But still good callouts nonetheless, so thank you for noting it. And it could be worth making an update to this video with more current information since it’s been a couple of years. I’ll try to do that soon. Cheers!

[@ivanlondon]

Thanks for the info, still trying to get my head around it... When you say "Don't select "use timeline" on the CSTs, instead specify Davinci Wide Gamut / Davinvi Intermediate" is this in the first or second node where CST is applied inside the compound node?

[@Freddd95]

@@ivanlondon It's on both of them! So inside the compound node there is one CST at the beginning and one at the end. - On the first CST, input color space should be Davinci Wide Gamut and input gamma should be Davinci Intermediate. (Output is Rec.709 - Cineon film log) - On the last CST, use the same settings but in opposite order: Rec.709 - Cineon film log for input and Davinci Wide Gamut - Davinci Intermediate for output. Hope this helped!

[@Nueztoy]

Tenga usted un millon de likes y una suscripcion, gracias

[@jorgeventura1854]

GREAT!! DO MORE LIKE THIS !!!

[@Endimione17]

Good; there's only a thing I'd like to point: if it's gonna be used some popolur LUTs (for Arri Alexa) in the first 'color space transform' node of the pipeline, do not convert the Output Color Space in Rec709 ('cause the last CST will be just set on Rec709) but in ARRI Alexa color space. This way the transformation of ARRI LogC is perfectly matching the proper color space. On the contrary, for Film Print Emulations (as in this tutorial) your pipeline is totally correct.

[@ErrickJackson]

You're absolutely correct. Something I should have put in the video, and really the overarching point, is always transform to the input color space and gamma that the lut you're using expects. So, as you're saying, using something like the Arri K1S1 Lut would need Arri Alexa/LogC as an input.

[@superhuskey268]

Great video! This is one of the only videos I've seen where it addresses using FPE in RCM. However I want to ask you about the following: So I tested both RCM and CST workflow, choosing the same options for both to see if they both produce the exact same image. -RCM - for the RCM workflow, in the project settings, I set the Input Color Space to "Blackmagic 4.6k film", the "Timeline Color Space" to Davinci Wide Gamut Intermediate and the Output Color Space to "Rec709 2.4". Then on the nodes, I created a CST going from DWG -> Rec709 2.4 (choosing DWG as input color space because that is what the Timeline space is right now in RCM settings). Then another CST after that which goes Rec709 2.4 -> Cineon. Then another node with the FPE. Then another CST after that going from Rec709 2.4 -> DWG, following your video to go BACK to the DWG Timeline space AFTER the FPE LUT (since the FPE is converting to Rec709 and the RCM will convert to Rec709 anyway at the end of the project). -CST - for the CST (non-color managed workflow), the project setting is set as Davinci YRGB, the Timeline Color Space is "DWG Intermediate" and the Output Color Space is "Rec709 2.4". Then the first CST is Blackmagic 4.6k film -> DWG. Then the next CST is DWG -> Rec709 2.4 (so I can view properly in Rec709 display output but grading in DWG space). Next CST is Rec709 2.4 -> Cineon. Then next node contains the FPE. I compared both images and it looks pretty much 99.9% the same except for a TINY, TINY difference, which when I use Image Wipe to compare the two and wipe across, I can barely see the difference unless I look extremely closely at the screen and the only way I can tell is by looking at the ever so slight changes in my Scope/Parade. Shouldn't both images be EXACTLY the same? Since one method is just going via the RCM route and the other is CST route? p.s. I also tried your way of just selecting "Use Timeline" for the Input Color Space on the CSTs (in the RCM workflow). This produces an image that is the most different from the two above. I thought this method of "Use Timeline" would produce a similar image to the CST workflow but it's slightly different. The two images produced using the methods above for RCM and CST produces the closest match (differences barely visible to the eye unless viewing the changes on the parade). What are your thoughts?

[@ErrickJackson]

Hi! This video admittedly deserves an update, as there are some small things I would change in the process today, but I'll answer based on what I've presented in the video. Now, correct me if I'm misreading, but your RCM and CST workflows seem to have some redundant nodes. You shouldn't need to make two nodes going from DWG to Rec709 and then Rec709 to Cineon. It's sufficient to simply go from DWG/Intermediate to Rec709/Cineon, apply the lut in the next node, and then go from Rec709/2.4 back to DWG/Intermediate in your final node. That aside, presumably, the results between the RCM and CST workflows should be the same, but there are some assumptions Resolve makes that you may need to account for. This is also true for the Use Timeline approach that I outlined. 1) RCM: If not directly selected, your Timeline Space in the settings will automatically tonemap for 1000 nits peak vs manually selecting a higher or lower peak. I typically manually select 10000 nits as most cameras can actually capture that much luminance in their log spaces. When you get to your CST nodes inside an RCM workflow, whether manually selecting your spaces or using the Use Timeline setting, it may do you well to manually select your luminance peaks. For scene-referred to scene-referred (log to log), making sure all of your nit values you select in the RCM settings map in can help. For scene to display (log to gamma) or vice versa, your display gamma result will typically peak at 100 nits for an SDR space. So in this case: 1st node: DWG/Intermediate input to Rec709/Cineon output, 10000 nits input to 10000 nits output, Saturation mapping On 2nd node: FPE lut 3rd node: Rec709/G2.4 input to DWG/Intermediate output, 100 nits input to 10000 nits output, Saturation mapping Off 2) CST: This largely follows the same rules as the RCM path. However, you'll manually select tonemapping standards in your CST going from camera source to DWG (ensuring the max 10000 nits capture gets piped in). Your final two nodes in the stack would be the 1st and 2nd nodes I outlined above, with no need for the third node because you'll already be in Rec709 Gamma 2.4 at the end, thanks to the LUT. Now things between those two should be the same. However, there is one final setting to confirm that also should be considered when using the Use Timeline setting. At the bottom of the CST plugin, you have options for Forward and Reverse OOTF as well as Chromatic Adaptation. You can leave CA turned on at all times; it doesn't hurt. Forward OOTF is a transfer function used to help accurately tonemap a gamma transformation from Scene-referred to Display referred gamma (such as LogC gamma to Gamma 2.4). Reverse OOTF is a transfer function used to help accurately tonemap a gamma transformation from Display-referred to Scene-referred gamma (such as Gamma 2.4 to LogC). Regardless of which workflow you're using, check that Resolve is not assuming your endpoint incorrectly. Forward OOTF should only be selected in a Log to Display scenario. Reverse OOTF should only be selected in a Display to Log scenario. Log to Log (like the RCM first node) and Display to Display (Fixed Gamma to Fixed Gamma) shouldn't have either OOTF selected. Particularly when Use Timeline is selected, Resolve tends to select one of them when it shouldn't. The only node in this situation that should have an OOTF selected is the 3rd node of the RCM workflow, because we are going from Rec709/G2.4 back to DWG (display-referred to scene-referred) and thus needs the Reverse OOTF selected. I don't think I did that in the video, but this is the approach you should use in this scenario. Any further differences in the workflows from scopes perspective may have to do with some internal mechanics of the RCM settings that we don't have access to. However, I honestly think you should end up with matching results from this. Hopefully that wasn't too complicated an explanation. Let me know if anything needs further clarification, and thanks for watching the video, friend!

[@cf3572]

@@ErrickJackson this was complicated but brilliantly explained ☺️

[@JimRobinson-colors]

Really great information in this. Thank you for that. I am going to see if I can tweak this a bit and combine how I usually apply the Kodak LUT - Good solution here, as using the Davinci managed has all kinds of highlight and shadow roll offs that made it difficult to use with LUTs as the input wasn't what the LUT author was using to create the LUT in the first place. I'll have to experiment, but if you have the saturation levels pulled in the Gamma limiter, have you tried that little push after that node, instead of before? Seems to me that pushing the saturation before is just pushing more information into the limiter. Kind of like an audio compressor, the gain needs to be made up after the signal - not before, because pushing it before just makes the compressor work harder.Just a thought - good information Errick . the only video I have seen on this topic specifically.

[@ErrickJackson]

Appreciate it, Jim! I should've mentioned in the video that my use of Arri Log C instead of Cineon gamma was a personal choice and Cineon is the technically correct input. But that aside, results tend to look pretty solid. As to the Gamut Limiter point, I'll have to mess with it more because, working out the order of operations since making this video, I do think it may benefit from being placed at a different point in the node stack. But honestly, I feel like Gamut Limiter is more a band-aid to the general problem of how to deal with extreme saturation; something ACES and RCM is still working at (such as with the ACES 1.3 update). Pushing after the Limiter node (but before the CST/LUT, yes?) may be the answer. The thing I'm not yet clear on with the Gamut Limiter is if it actually acts on the entire information range or just performs rounding operations on the edge of the saturation range for the chosen color space. Gotta do some testing there (or find some documentation). Lately I've been experimenting with Look Designer 2.4 and Dehancer since they are able to work directly with color information in wider spaces as opposed to this method of constraining that color information down to Rec709. The beauty of RCM is not just that different camera sources can be conformed to one working space but also that you can ideally output to practically any delivery space you want. And the one area where I think this Print Emulation method may fail is trying to use it for HDR grading. Since I don't yet have an HDR mastering monitor, it's not something I can test yet, but I don't imagine stretching a Rec709 output back to a DCI-P3/Rec2020 HDR master would look....great. And since HDR delivery is becoming more prevalent, I need to make sure my emulation approach doesn't fall apart there. Anyway, glad it was helpful and hopefully I'll be able to bring answers to the other questions I'm currently grappling with.

[@ozzmanzz]

I bow before the master!

[@ErrickJackson]

Haha I'm no master; I keep it simple. I love an automated system, but I also love the few LUTs that I use. I knew there had to be a way to make it work seamlessly.

[@MarkToddOsborne]

Great info. Gamut Limiter best part! Cheers - MTO

[@ErrickJackson]

Thanks Mark! Glad you found it helpful.

[@PolyRev]

Thank you !

[@PolyRev]

I got a question, for the BRAW on the compound LUT first node what output gamma will I put if I am shooting on BRAW GEN 5?

[@PolyRev]

Is it black magic design film or black magic design pocket 6k gen 4? BTW I am using BMPCC6K

[@seasideshutterworx]

Thank you for this video it really is much appreciated. How would you incorporate the x rite colour checker into danvinci colour management?

[@ErrickJackson]

I have to be honest, I've yet to actually balance using the color checker balancing tool. If I have a frame provided, I typically just use it to white balance with my offset/global wheel. I'll have to do my research and get back to you on it.

[@77dris]

YOU ARE MY HERO! For the past couple months I've been asking this question EVERYWHERE and looking all over KZbin for answers to this question and there was NOTHING out there. People in Resolve forums would just tell me basically "don't use LUTs in a DWG Color Managed workflow". SO frustrating. Then out of the blue your video was recommended to me and it was THE answer! Question... if I have LUTs that are using rec709 gamma, would I just use that instead of cineon or arri (as per your recommendation) gamma?

[@ErrickJackson]

The specific settings I used in this video are for that specific lut. Generally speaking though, the workflow is the same for any lut. You want to transform from whatever space you're working in to whatever space the LUT is expecting; then you transform from whatever space your LUT outputs back to whatever space you're working in. A transform loop, if you may. So if you're using a lut designed for Rec709 Gamma 2.4 already, you would set your CSTs to accomodate for that. As for the responses you've gotten in forums, it's understandable. DWG is a relatively new workspace and there are not a ton of good luts designed for it. And in particular, this workflow is a bit of a hack in the sense that adapting a Rec709 lut to work in a wide-gamut HDR-supportive workflow may not bode so cleanly for non-Rec709 deliverables, such as P3 or Rec2020 HDR exports. This ultimately depends on the nature of the LUT though so it's not necessarily a universal rule. And nowadays, there are some decent DWG luts out there as well as plugins that support it. The idea that LUTs shouldn't used in an RCM workflow as an overarching rule though is ludicrous. It's just math.

[@cf3572]

I think I read your post when a guy said you either use luts or rcm 😂

[@alexander.starbuck]

Hey Errick, thanks for the great tutorial! :) One question: what do the "Timeline color space" and "Output color space" dropdowns in "Color management" settings do? If we are NOT using Davinci color management. I'm always confused by these two settings Usually, I do my color management via Color space transform nodes in my pre-group and post-group level, since that way I can put LUTs and other plugins how I see fit and not have to worry about final Davinci conversion. I group clips by different cameras, then input transform to some large color space, like LogC, work in that and output to Rec.709 or P3. Thanks! :)

[@ErrickJackson]

So when you're working in Davinci YRGB, the Timeline color space is essentially a tag for the toolset in Davinci Resolve. Certain tools, like the HDR Panel, are color-space aware. They will operate photometrically accurate in relation to the selected Timeline Space. So if you're working in LogC at the clip level, you could set the Timeline space to Arri LogC and your HDR Wheels + a few other tools would respond appropriately for that space. An example is if you did a +1 exposure increase with the Global wheel in the HDR Panel, it would be an almost perfect match to doing the same operation in the raw tab or exposing one stop up in camera; the difference being the highlight and shadow areas rolloff slightly to the white and black point instead of hard clipping. The "Output color space" setting is for your export tag. When you export from Resolve, it will tag the file with a color space and gamma so that other software can properly display the file when someone views it. Previously, you would have to manually set this tag in the Deliver page if you worked non-color-managed. However, now you can set it in the project settings and it will automatically tag the file(s) upon exporting. Basically an ease of use feature that helps you not forget to tag your footage. Keep in mind that you should still only be mastering in a color space and gamma your monitor is calibrated and set for; consequently, you should also only be tagging your footage with that setting as well. Otherwise, it will be interpreted incorrectly to the way you mastered it. Another important note is that these settings are project wide. Meaning if you have multiple timelines in the same project, those settings will still apply. So make sure you keep that in mind when you're setting up your project settings and when you're using any color-space aware tools. If you find yourself needing to deviate from the settings on an individual node basis (after a CST for example), you can manually set the color space and gamma for those tools on that particular node. Hope that helps!

[@alexander.starbuck]

@@ErrickJackson THANK YOU, Sir! Spectacular reply and now it's complately clear 🤗.

[@philipp9550]

Very nice! Was looking for that for quite a while. One question: I’m working on a 120min project and the final play out gonna be a rec709 and a p3 version. Normally I just had to change that in the color management settings. But now I have to manually change that in all the node if I understand that correctly?!

[@ErrickJackson]

No, you shouldn't have to do that. The node stack in this tutorial is basically so that you go from Timeline space to LUT input/output and back to Timeline. So the timeline space is still what feeds into the final output transform you select in color management settings. You can still just change your output from P3 to Rec709 and vice versa. Consider also that the method I outlined in this video isn't super ideal in so much as adapting a Rec709 lut to an HDR color management enviroment is stretching the use case a bit. But with a robust enough LUT (like the Resolve film luts) it should work fairly cleanly. So all in all, you should be good!

[@philipp9550]

@@ErrickJackson thanks so much!

[@Freddd95]

Thanks! Two questions regarding 7:12 - if the LUTs are designet for Cineon Film Log as input gamma, why do you choose Arri LogC? Also, I can only choose between Arri LogC3 and C4 (using Resolve 18). Is C3 the equivalent to what you are using here?

[@77dris]

He did that just as a personal choice. He has admitted that technically Cineon would be correct.

[@vishalzparadize]

Subscibed.

[@ErrickJackson]

Thank you! Glad you found this helpful!

[@CiprianMunteanuVideographer]

It’s great 👍🏻 But i have one issue: when i am in split screen and i try to color match, the videos looks very strange. What can i do? Thx

[@ErrickJackson]

That's interesting. That shouldn't be the case; it isn't something I've run into myself. Is this inside your GUI display or also on your clean feed out display?

[@romanvailcreative6574]

This is incredible... I have always been wondering why the LUTs just look "too much". But one thing... I basically copied all the settings I could see in video but for the compound node section... what do I do with Apply Forward OOTF / Apply Inverse OOTF / Use White Point Adaptation? (Leaving that off seems to lift bottom of curve, enabling it seems to make the LUTs "too much" again. Thank y

[@ErrickJackson]

On the first CST node, Inverse is on by default; on the second CST node, forward is on by default. I leave these turned on and they should be left on. Truthfully, the technically correct gamma input for the film emulation luts in Resolve is Cineon, not Arri LogC. Because of that, the crushing you're seeing in the low end is actually because LogC is a flatter gamma curve than Cineon and the resulting gamma curve on the other side of the LUT is slightly flatter than Rec709/Gamma 2.4. If you set the gamma on the first CST to Cineon instead of LogC, you would actually get the intended response. The reason I use LogC is that I like the gentler curve and can compensate for it upstream. As for the White Point Adaptation, this a recent addition to the CST ofx. If I'm not mistaken, it is there to compensate for the white point difference there is doing ACES transforms using the CST ofx vs the ACES Transform ofx. Outside of transforms that involve ACES, it should have no effect whatsoever. Even with ACES, it's correcting for a D60 vs D65 white point, which may be inconsequential for your grade. But regardless, leaving it on causes no harm to your transform or lut usage. Hope that answers your questions!

[@romanvailcreative6574]

@@ErrickJackson Awesome. I will give it a go and see... this is definitely one, in not the one, best video on this subject. Period. Thank you so much!!!!

[@romanvailcreative6574]

It's also interesting... keeping input CST with Cineon gamma and Forward OOTF, with Forward OOTF on output CST -- slightly better result with Cineon. Think this is ok?

[@JimRobinson-colors]

Forward OOTF should be used to go from a large gamut to a small gamut. And inverse is the other way, although the inverse OOTF clamps it a bit, so it is subjective.

[@cf3572]

Great video, thanks a lot! But I have one last question which wasn’t answered in the comments… what if I want to use 2 luts? On my current project I use the Linny Lut (sucomo) for bmd colorscience 5 and a Film emulsion Lut. I would need to setup a construct of cst nodes to go from linny lut (outputs 709 gamma 2.2) to the colorspace the second Lut uses as input, then the second and then back to dwg, correct? Thanks!

[@ErrickJackson]

Yes, that structure would be correct. Just asking because I use the Linny Lut as well: are you using Linny alone + a second lut or Linny with one of their pre-applied B prints + a second lut? If it’s the first, I believe the standalone Linny lut converts to Cineon, so as to be compatible with one of their SPK print LUTs or any other Cineon-based print lut. Additionally, if your second lut expects Cineon, you would be able to just drop it after the Linny lut. If it’s the second, be careful. The Brim’s prints are strong and two prints stacked might stretch your signal more than you like. I personally use the Linny + B4 or Linny stand-alone + SPK print in a transform loop: DWG->Arri, LUT(s), 709-> DWG. (Mine are the Arri version)

[@cf3572]

@@ErrickJackson hello 👋 well I just bought the linny Lut a few days ago and still playing around with it. We have the bmd version and shoot a lot with Ursa 12k. For now I used it like you, - linny with b1-b3 / depends on the contrast in any given shot, without any other Lut. But I want to try out how it looks if I use the plain linny Lut and use nitrate filmconvert afterwards. I‘ll keep you updated when I tried it. B4 is so heavy in contrast, do u lower the Lut in opacity?

[@ErrickJackson]

@@cf3572 No, B4 doesn’t bother me. If I want less contrast, I’ll pull back contrast through the slider or LGG wheels in a prior node. Since the SPK LUTs are also designed for Rec709/G2.2 output, I use B4 just to match those others. I have a compound node template saved that I just drag over to my Look development tree. It goes from timeline to Linny Input, and Linny Output back to timeline; so all I have to do is choose the Linny lut or SPK I want to use and does the transform from Gamma 2.2 automatically. I personally think the B1-B4 LUTs are only really necessary as quickly available monitoring LUTs. But in Resolve, I manage contrast pre-LUT anyway, so choosing between them isn’t really necessary.

[@CiprianMunteanuVideographer]

Now that DaVinci Resolve 17.4 is out should we make some changes or everything is still the same? I am talking about the fact they introduced in 17.4 that Automatic color management and SDR or HDR color processing mode.

[@ErrickJackson]

No, nothing has changed with those new settings. Automatic color management is the same as the previous system, just simpler presets. Selecting SDR working space changes your working space to Rec709 Gamma 2.4; selecting HDR working space sets it to Rec2020 Intermediate. Similarly, for your outputs: SDR Rec709 = Rec709 Gamma 2.4; SDR Rec2020 = Rec2020 Gamma 2.4; HDR HLG = Rec2100 HLG; and HDR PQ = Rec2100 ST2084 EOTF. These are all settings you can manually select yourself, but Resolve now offers quick presets for them since they are some of the most common working and output spaces. However that's all they are: presets. None of the underlying math has changed. My personal standard setup currently is Rec2020 Intermediate working space and Rec709 Gamma 2.2 (sRGB adjacent) output space for most any project. Generally speaking, I could use the HDR working space and SDR 709 Output space in the Automatic settings and be just fine. Still, don't forget to set your clip input color spaces if your footage isn't raw footage or doesn't have color space tags in the metadata. Hope that helps.

[@CiprianMunteanuVideographer]

@@ErrickJackson thank you so much for your time

[@amitdutt9782]

First CST node if I use Rec709/Arri LogC I am getting weird color with Gen 5 BMPCC6K raw - But if I use ARRI Alexa/Arri LogC then I am getting predictable colors - any thought?

[@ErrickJackson]

That’s odd. Hard to say what it could be. Rec709 is the expected color space input for that particular LUT. (If you’re using a different LUT, you need to make sure you use the right input for it. The Arri 709 lut for example expects Arri Alexa/LogC.) I can’t imagine what is allowing the Alexa color space to render normally when run through that print lut. And running Resolve Color Management, it shouldn’t matter what footage you’re inputting as long as it’s correctly assigned, and with Braw, the assignment is automatic. If you’d like, DM me on Instagram (@ejacson) and I can perhaps dig into what is happening.

[@PolyRev]

@@ErrickJackson Bro same issue

[@Endimione17]

@@PolyRev Only if You use film print emulations, You have to convert the output color space in Rec709; otherwise if you use some popular LUTs (for ARRI Alexa), you have to convert in 1st CST node: Output Color Space - ARRI Alexa, Output Gamma - ARRI LogC; the rest of the pipeline is the same; this way it works

[@DastanZhumagulov]

Hmm, I'm using quite a lot of non standard Log to Rec709 conversion with my BMPCC4k BRAW files, so I guess Davinci Color Management is a no go for me. Looks like too many potential failure points there

[@ErrickJackson]

Yes, this is the situation where I wouldn’t recommend it. If your lut isn’t doing some sort of technical transform where the output color space is known, the results using this method are going to be unpredictable. This is why I primarily use this method with film emulation luts or the occasional technical transform if absolutely necessary; they’re typically binding a technical transform with the film stock characteristics in a way that’s pretty predictable. Otherwise, I’m sticking to RCM’s regular Rec709 transform.

[@slava_gost]

@8:57 Input Gamma should be ARRI LogC!

[@ErrickJackson]

No. After the lut is applied, we are in Rec709 Gamma. So we have to transform from Rec709 back out to Timeline Space.

[@slava_gost]

@@ErrickJackson I know. It's just you've got both Input Color Space and Input Gamma set for Rec.709. I'm not satisfied with the lut when I do that. The colors look so washed-out. It's fine and dandy though when Input Gamma is back to ARRI LogC accordingly to the first node's Output Gamma.

[@ErrickJackson]

​@@slava_gost That shouldn't be the case; perhaps your project settings are a bit different. The idea is the lut expects Rec709 color space and Cineon gamma (though we're using Log C) and that's what the first CST maps to. The lut then receives that Rec709/Cineon input and performs its transform. That transform is in two stages: the color transform remaps the Rec709 input into the primaries associated with the Kodak 2383 lut within the same Rec709 color space it received as input; the gamma transform maps the Cineon gamma input to a Rec709 gamma. So the output of the LUT is now Rec709 color space and gamma. The third CST takes that output point from the LUT and remaps back out to the timeline space. Hence the Rec709 color space and gamma settings for the input. That way the final ODT transform will give us the intended effect. If your footage is coming out washed out, there are a few areas that could be an issue. 1. Your IDT: make sure your footage has the appropriate input color space selected both in the project color management settings and the clip level (ex. if you have Arri LogC footage, set your project input to Arri LogC and/or right-click the clip change input color space to Arri LogC.) This way Resolve is interpreting your footage correctly. 2. Your ODT: make sure your output space is appropriate for your display. If you're viewing on a Rec709 display, your output should be set to Rec709. If DCI-P3, set to that. etc. If set to something different than your display, your perception of your footage will be inaccurate 3. Make sure you're feeding into the lut what it is expecting. The Kodak 2383 Lut expects Rec709/Cineon, but if I used the Arri K1S1 Lut, for example, it expects Arri Wide Gamut and Arri LogC. Even in this video, while I am using Arri Log C as the input gamma, that is technically the incorrect gamma for the LUT to behave as it should. I'm personally okay with it because I understand what the functional difference between the LogC and Cineon gamma curves are in the LUT's response and can compensate, but the lut isn't technically behaving as it should be. (it doesn't account for the behavior you're mentioning though. Washed out colors aren't quite what the response should be.) Additionally, if you're feeding in a wider gamut than Rec709 (such as P3, Arri Wide Gamut, RED Wide Gamut, ACES, Davinci Wide Gamut, etc), that absolutely could result in washed-out colors as the LUT isn't receiving the intended color space and will transform inaccurately from what you're expecting. This is most easily noticed by a severe lack of proper saturation. 4. You could actually just have really low contrast, low saturation footage. This method I laid out is meant to provide the correct transform path for using the lut, but "correct" doesn't always mean "pleasing" and you may just need to punch in more contrast and saturation to your taste. I typically do for my own style of grading. If you're getting this issue with all of your footage across multiple projects, then I suspect it's a problem more in the vein of one of the previous notes. Sorry if that's super long-winded, but I just wanted to be thorough as there are a number of ways for the structure to go south. BUT if you continue to have problems, DM me on Instagram @ejacson and I'll see if I can help further.

[@TheSanjaySathian]

@@ErrickJackson if we are in rec 709 and gamma 2.4 right then why did you input gamma as rec 709 instead of gamma 2.4 ? as u open the lut in notepad it shows this # Resolve Film Look LUT # Input: Cineon Log # : floating point data (range 0.0 - 1.0) # Output: Kodak 2383 film stock 'look' with D55 White Point # : floating point data (range 0.0 - 1.0) # Display: ITU-Rec.709, Gamma 2.4

[@pollloxxx]

man all this is a bad practice. if you working space is DWG davinci intermedia, your first CST Is from the log of the camera (logC, Slog, log3g, etc) TO your working space (DWG_davinci intermedia), this is apply an IDT manually , you cant decide use logC (because you like it), you have to use the log of the camera, remember, is an IDT!!!, and after if you want to use this LUT of davinci you need to use another CST before the lut (DWG to CineonLog), this it's not a matter of taste, this is Math, dont even matter if you think that logC is enough flat fot the lut. You are doing and teaching BAD things

[@ErrickJackson]

Well you’re right about one thing. I arbitrarily used LogC instead of Cineon at the time without mentioning that Cineon is the correct input for the Resolve lut. I’ve mentioned in other comments that I should’ve at least clarified that. However, on the camera source, when working color-managed, the IDT to timeline space is set up in project settings. So the nodes are already working in DWG, which is why I went from Timeline to Rec709/LogC (yes, should use Cineon), LUT, and then lut output back to timeline space. Generally speaking, there’s nothing wrong with that string of operations other than the potential annoyance with trying to adapt an SDR lut to an HDR workflow if you end up delivering, for example, a P3-D65 PQ output. At that point, a lot rides on Resolve’s tonemapping math to decide what to do with the 100+ nit information. Lastly, this video is pretty old so my workflow has changed a lot, including with the gamut limiter idea. Most of my LUTs are built for color-managed environments. However I do still have some display-referred LUTs I really like that I’ll use inside of a transform loop for SDR delivery. Again, that math is fine.