If you do that you are putting the grade before the IDT, when it should be after it.
If your material is LogC, for example, the difference caused by the incorrect order of operations may not be huge, but it’s still wrong and may account for what you are seeing. If you look at the graph where I plotted ACEScc, ACEScct and LogC on the same axes in this Mixing Light article, you will see that ACEScct is not a million miles from LogC.
But order of operations is very important. Not quite right is still wrong!
No. The IDT always comes first. It is the Input Device Transform, and is what takes the image from it’s native colour space into ACES.
Some implementations may hide some of the steps from the user, but the full sequence of operations is as I describe it.
I am describing it in full because that’s what you need if you want to build it yourself. IDTs transform to linear ACES, so you then need to go from that to the ACEScct working space before applying your grade. The input to the RRT has to be linear ACES, so you need to go back to that after the grade.
If you are building a Rec.709 LUT for LogC from the CTL files, for example, they need to be these operations in this order:
IDT.ARRI.Alexa-v3-logC-EI800.ctl
ACEScsc.ACES_to_ACEScct.ctl
Look_Grade (as CDL, CLF or whatever)
ACEScsc.ACEScct_to_ACES.ctl
RRT.ctl
ODT.Academy.Rec709_100nits_dim.ctl
And that’s without any LMT, such as a “show LUT”, which if implemented as per spec should go between steps 4 and 5.
Not with a simple one line ociobakelut command that I can post here! You would probably have to use several steps, involving ctlrender as well.
The easiest way would be to use OCIO in Nuke to build a node tree of all the required operations, and then bake that into a LUT.
When I first started building LUTs I usually used Nuke (or was I still using Shake back then – I forget) to build processes like this. Now I have written my own Python code library which does a lot of what I need. But Nuke is still useful for testing.
In fact, I just worked out a simpler way to do it entirely in Resolve.
Because Resolve bakes the RRT and ODT into LUTs it generates in ACES mode (which is frequently an unwanted effect, but useful here) you simply need to temporarily add steps 1 and 2 above to the front of your node tree (using DCTL) when exporting your LUT. The image will not look right while you do this (although because as I pointed out above, ACEScct is “not a million miles from LogC” it won’t look entirely wrong) but the LUT will be correct.
It makes no difference if the IDT is on or off. That is not included in the exported LUT. I suppose leaving it off makes the image look completely wrong, so reminds you to turn the temporary DCTL nodes off again!
I sell the S-Log3/S-Gamut3.Cine DCTL IDT, and made the LogC one available for free. I could make others if there was demand. What would people prioritise?
I am not a Fusion user, but Resolve does not explicitly separate the RRT, so I expect Fusion doesn’t either. The RRT is implicit in the ODT in many applications.
My assumption was based in that in Davinci Resolve the order of operations was that by selecting, Davinci Resolve Master, Project Settings <Color Science<, came first, in this order:
1 - Color Science: Turning on ACES selection, (ACEScc or ACEScct)
2 - IDT
3 - Color Management, ACES Input Transform
4 - Look Grade
5 - RRT
5- ACES Output (ODT) Transform.
Really, the step by step the user needs to go in DR for ACES, made me think that the >Color Science< ACES selection setting came before the IDT.
It seems to work very well. A slight shift in hue (more reds in the skin tones in ACES) in one look I tested but nothing critical… Just to resume here is what I did
In Resolve
Added a LOGc image
Turned on ACEScct (with IDT and ODT as usual)
Built a grade
Added 2 nodes before the grade
Node 1: LOGc IDT DCTL
Node 2: ACES to ACEScct DCTL
Exported a LUT
Switched back to YRGB added the LUT and compared with the ACEAcct still/look.
Does this seem correct @nick
And, will this work with the SLOG3 IDT?
Although I haven’t worked yet with LMT yet, (I believe a few are) if the LMT is part of the creative process, why is it that in the other of operations you have placed the LMT between step 4 and 5 and not between 2 and 3 or as an inclusive first item of step 3? Specially if it’s going to be used as a show LUT. I suppose that all further changes made on-set by the DIT should come after the show LUT, not before. Could you please elaborate on this? Thanks!
Because if you read TB-2014-010.pdf on this page, you will see that an LMT goes after the grade and before the RRT, and is applied to linear ACES data. An LMT modifies the look imparted by the RRT.
However I did say “if implemented per spec”, since the term LMT gets used more loosely to mean any fixed part of the grade which is not modified on a per shot basis.
Nick, thanks for pointing out the reading.
I did review the charts appearing in the TB-2014-010, Design, Integration and Use of ACES LMTs.
Thanks a lot for the clarification.
Since Davinci Resolve supports now LMT, I’m going to start experimenting with it.
Hum! I’ll probably better wait for the upcoming release of Scott Dyer article, LMTs Part 2.
Sorry for the late reply. I was grading for the last week…
@nick. I’m not sure I understand your question. But what I’M seeing is a slight shift in reds. IE: the ACES version a more reddish appearance to skintones etc… But, it’s very soft. I don’t think any DP could even see this when going back to ACES once in color grading.
When looking at your question I guess I could say it’s a little bit of both. It’s the lack of proper implementation for these types workflows and possibly the LUT approximation…
I was just referring to the fact that a LUT is a way of approximating a transform (which works very efficiently in hardware) but it can never be perfect, because some values are interpolated. Whether the inaccuracies are noticeable depends on the transform and the image.
Since you say that what you are seeing is subtle, it is probably caused by this.
If I may introduced myself, I’m the lead developer on the FilmLight Prelight software.
It is in fact possible to get metadata for shots (CDL SOP & SAT, tape, clip, scene, take, comment, etc) out of Prelight via ALE, which can be used to import the values into other systems.
You can also use Prelight to generate IDT and LMT+RRT+ODT LUTs in a vareity of formats, which allows colour corrections created into Prelight to be used in other systems. We are currently working on finishing up this part of our export code, so that you can generate ALE, CDL and cubes in one hit as a package.
Obviously there are advantages to using BLGs if you are working in a FilmLight ecosystem, but we want Prelight to be able to work standalone also.
Thanks for the update in the development of Prelight. I’m currently running the beta version.
It’s welcomed news to know that Prelight can be used as a stand alone color management and creative grading on-set application.
I’m pretty sure that for DITs and cinematographers, the ability to create IDTs in preproduction is a welcome news, specially for camera considered under a -generic- status, because the absence of manufactures providing their own IDTs.
I’m definitely looking forward to the final commercial release of Prelight.
