I am currently testing several workflows, and right now I’m curious about what would be the correct export settings to create a LUT to be applied in Resolve from Nuke.
My current setup is a Nuke in ACEScg workspace, in there I bring an ACEScg render which I will do some grading/tone mapping operations.
After that I am creating a CMS Pattern (cube size 33 to match Resolve’s), pipe it to these grading operations, and GenerateLUT after that.
My question is if I need to apply any colorspace transformation to the CMS Pattern before or after the grading operations for the LUT to be properly interpreted in Resolve.
I can see that Resolve has an option to process LUTs either in AP1 (ACEScc) or AP0 which makes me wonder if I need to transform the CMS into cc before generating the LUT or some extra steps along those lines.
A LUT (or grade) needs to be applied in the same space in all applications to give the same result. I can’t tell from your screenshot exactly what you are doing, but if for example you have a grade in Nuke which applies gain in linear ACEScg, and you want to bake that into a 3D LUT to use in ACEScct in Resolve, the LUT needs to combine a transform from ACEScct to ACEScg, the grade, and then a transform back to ACEScct.
Hey Nick, huge thanks for taking a look at this.
Sorry for the small screenshot, so I took the time today to make a proper demo scene, that explains things better.
I understand the concept of doing the grading operations on a certain colorspace and then reverting back to the display color space.
Currently I tried to do this, where I did a grade to match a fairly quick gamma adjust from the Arnold Render view to put the concept to test as both are ACEScg and sRGB ODTs.
Though my test of just changing the export onto ACEScct didn’t worked as expected, I’m attaching the .nk and a screenshot. The color space transform connected to the GenerateLUT goes to ACEScct and this is how it looks when applied in Resolve.
The image in Resolve is imported with an ACEScg IDT and its being viewed through an sRGB ODT.
Sorry for the long post and thanks a lot for all the help!
You appear to be doing your grade in display referred Output - sRGB so the OCIOColorSpace nodes are going back and forth to that. That’s not an approach I would recommend in a ACES pipeline, but ignoring that for a moment, and assuming you need to match the result in Resolve…
You need the transforms to go from “what the colour space currently is” to Output - sRGB and back. So while in Nuke that is ACEScg, in Resolve it will be ACEScct. So when generating the LUT, the OCIOColorSpace nodes either side of it need to go to and from ACEScct, not ACEScg.
That’s brilliant, exactly what I was looking after! Thanks a lot for taking the time and looking at my example file.
I’m aware of the first part where I’m doing the grade in display referred is not the correct way, I was just trying to understand the color transformation steps matching it with workspaces that were both ACEScg.
I understand very clear now how I am supposed to do the color transforms in order to bring them into resolve, in practice this color transformations are actually going to be processed in code, but I needed a visual example to explain to the programmers how the color needs to be treated. This works perfectly!
you said you just wanted to understand the workflow.
I would like to understand what you are you looking for if you don’t mind me asking:
What would be your advantage to use a a less precise and limited operation such as a 3D-LUT in Resolve when you can do (and already did) the same operation in Nuke (without baking it into a LUT) and just render out your content with the ODT or your choice?
Thanks a lot for taking a look! I know that all my recent posts are on the Mastering section of the forum, but actually all of these workflow and colorspace knowledge that I needed to understand is meant to be used on a game engine.
Right now there are some in engine implementations that are taking some time, so for the sake of the questions (and because I have no other way to post example files) I chose Nuke, which also helps me to visually explain to other members of the team what’s happening to the color, but in practice instead of Nuke it will be the game engine that is performing those tasks.
What’s gonna happen is: inside the engine, the game is rendered in ACEScc, we color correct in realtime using Resolve, bake the LUT and then apply the resulting LUT in our game. We have to bake it because doing those analytical color transformations will be expensive (and you know, in games any milisecond that we can save counts).
You render in ACEScc inside the game engine? I always thought the calculations are done in scene linear and then transformed into a log space so that you can apply a LUT.
That would be correct on current implementations, but if we want to do HDR grading and converge color operations to an ACES pipeline, the “apply LUT” step has to happen before, not doing that would imply to do a LUT for every ODT.
So, for this new implementation we will have a development only “grading mode” output that we feed into Resolve, we chose ACEScc for this where our pretoned linear data gets converted into this format, then we apply a viewing/tonemap LUT (which is the operation that I was struggling to figure out in this post) and then do the grading which will be exported from Resolve back to the engine (without the viewing LUT).
Hi Nick!
One quick question though, when the CMS Pattern gets the first OCIOColorspace [in ACEScct out Output-sRGB], what’s the CMSTestPattern initial colorspace then? ACEScg?
The CMS pattern values represent ACEScct values, because that’s what the image state will be in Resolve. Although you mentioned ACEScc above. You should pick one or the other and be consistent.
Oh sorry Nick, yeah I did meant ACEScc, I’m totally making sure the working spaces match, definitely being extra careful with that.
I was just in doubt because Nuke’s working space is ACEScg so I assumed everything created like constants, checkers, etc, would inheretely be ACEScg due to that, and thus maybe another color transform would be required.
