I am currently confused with the workflow of using ACEScc/ACEScct as a color grading working space and not so sure about its workflow. From my knowledge and information in the provided ACES documents, is the correct workflow like:
IDT(ACES) --> ACEStoACEScc/cct --> color grading here --> ACEScct/cc to ACES --> LMT --> RRT+ODT
is this a recommended way to use ACEScc/cct space? or there is no need to transform from ACEScct/cc to ACES back.
From the figure, it is not clear if the working space needs to transform back to ACES space. But in document TB-2014-002, both the LMT and RRT requires the input space to be ACES(AP0).
Also, if the ACEScct/cc to ACES node is necessary, the sensitivity of the color grading tools or operators such as LGG, Log wheel, saturation, etc will be enlarged. If you make a change deltaE in working space, it will be amplified by the ACEScct/cc to ACES node, which is hard to control accurately, just like color grading before a log-709 LUT in normal YRGB space. As well as the keyer/qualifier has a different control experience.
Some colorists would like to start with log-like space and stretch into a normal view look. To achieve the same manipulation experience of the tool, I changed ACEScct/cc to ACES node to a wired AP1/rec709 to ACES（AP0/Linear) node so that the color grading working space between the ACEScc/cct and 709 would have the same experience of the tools used in common color correction flow. I know it is most probably incorrect process.
If anyone could help me to clarify a correct or recommended process to address both the grading tool manipulation experience and workflow problem. I really appreciate it.
Hi, ACES is just a toolset, in theory you want to translate back to ACES so at some point you can output ACES files, i.e. for VFX vendors or for mastering your IMF App5 package. The reason cc and then cct is to have a colorspace that is acceptable to use for colorists, so that their tool behave correctly, but more importantly if you want to have interoperability of color correction between systems, so you can use ASC-CDL based workflow. But you may want to use other spaces, at the end of the day there’s not such a thing as a perfect colorspace for everyone, what is important is interoperability. I’ve seen happy colorists with Arri LogC or even ADX as working space, and that can be made ACES compatible.
The OCIOFileTransform and OCIOCDLTransform nodes include drop-downs for the working space. So there should often not be a need to “sandwich” grades between colour space conversion nodes.
OCIOFileTransform also includes the option to use tetrahedral interpolation, which is often desirable.
I haven’t seen many difference between ACEScc and ACEScct myself (probably because our renders are overlit and quite bright) but there is an interesting thread about ACEScc vs ACEScct. Great read !
Hmm, if properly implemented, there shouldn’t be any difference in a render btween ACEScc and ACEScct. The difference only exists to make it more comfy for colorists with their tools, especially for dailies work so CDL data can be carried across.
No difference in a render indeed since we render in ACEScg. I was more talking about grading a render in Nuke using ACEScc or ACEScct. I only saw a small difference in shadows behavior (which is supposed to be the difference anyway between ACEScc/ACEscct).
)