I know that the people behind ACES are working hard to get to concept streamlined in all stages of production. And, I know that this was discussed in recent threads about the future of ACES. But I would like to know what the power users of ACES are doing about monitoring on-set.
Is there any way to have a simple monitoring workflow in ACES?
Is there any way to have a custom LOOK that includes ACES as a base?
As of now, all I was able to do is to “extract” the IDT, RRT and ODT workflow to a LUT via Lightspace. I build a look in ACEScct in Resolve and then revert to YRGB and apply the “ACES LUT” (sorry for the term) at the end of my node tree. There’s a slight shift in gamma. But all in all it’s pretty “seamless”…
But, I’m afraid to send that on set. Cause I have no idea how this will react…
There are so many ways to do this, and it partly depends upon whether you are grading
on set or just want to see the output of a camera in an ACES-like mode. ACES proxy is
designed for a 10-bit output that can have a LUT applied to have the rendered RRT+ODT for a display
applied. But there are other ways, the IS-mini can be used as a LUT box if you have ACES proxy out.
Sony cameras can output ACES proxy with LUTS (see
I think Canon cameras also have some capability there.
I know that you can also use some LOGs outputs, convert them to ACES and then apply the RRT+ODT and
see it on a monitor. This can sometimes also be used if you have HDR monitors. If you don’t have at least a 33-cubed LUT, you need Tetrahedral interpolation in the LUT to avoid ‘scalloped’ (from arraypt to arraypt curvature).
If you are trying to grade with Resolve in the middle, I would think you would have the IDT on a 3D input LUT
to convert from camera-format to ACEScct. Then the 3D output LUT would be Acescct->aces->RRT+ODT_709 (or other)
But I haven’t tried that myself, and always need to check LUT resolutions and rendering to make sure it is delivering.
You may like to try the public beta of FilmLight’s Prelight. This can control a LUT box to upload looks on set, and includes full ACES support, including ACEScct, and does not require a camera with ACESproxy output. If you are doing the DI in Baselight you can use the full Baselight toolset to create looks, and save them as BLGs (with metadata linking them to the shots they were used on) but you an also use it in CDL mode to save looks for other systems.
I believe Prelight does not write the metadata associated to the shots the looks have been applied when exporting to other systems than Baselight proprietary BLG format, making of this an enclosing feature.
There is no doubt that FilmLight would prefer you to stay within the Baselight ecosystem, and the functionality is far more comprehensive in BLG mode. But as long as you restrict yourself to ASC CDL corrections, those can be exported to .cc files, EDLs or ALEs containing additional metadata.
What you may be thinking of is the fact that on release, the plan is to have a free version (Prelight) and a paid version (Prelight On Set) and one of the differences will be that BLGs exported by the free version will not contain the metadata necessary to automatically apply them to shots. Other differences planned are to have LUT box and SDI I/O support limited to the paid version.
The version currently in open beta is Prelight On Set, and includes all the metadata and hardware options.
What I want is to have an output in a ACES like mode… With a custom look that was built in Resolve. So a concatenation of ACES base with a look in a 3D lut.
@jim_houston: I,m just worried about making a base LUT of the IDT, RRT and ODT sandwiched together in Lightspace and sending that onset. Is this a viable option? I’m under the impression that this is not “OK”.
It’s great that the F5, f55 and F65 have them. But allot of people use FS7s also. And, I’d like to provide my clients with a custom look based on ACES…
And the IS-mini doean’t seem to support ACES. It’s the big unit IS-100…
@nick: Prelight is not a good option and I will not be able to use curves in a CDL.
You need to concatenate IDT, ACES to ACEScc(t), look grade, ACEScc(t) to ACES, RRT and then ODT together in that order. You would not want to add a look after a combination of IDT, RRT and ODT.
@nick I’ve tried your suggestion in Fusion. I’m close but the tiffs i’m exporting to verify if i’m coherent is clipped in the Highlights. I’ll look into this further.
Wasn’t there a problem with this in 1.0.3? I remember that I tried doing the IDT, RRT, ODT Lut in Lightspace (@steve) and this was an issue.
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.
