Generic Unicolour workflow:


In many cases this can be the most efficient workflow, still flexible and producing the best quality. The basic idea behind Unicolor is that it provides lossless and reversible conversions between a list of color curves and gamuts. 


 No LUTs involved, which can create quality issues. The processing precision is full FP32 math. 


 Lossless and reversible.


 You can grade in any curve and gamut you choose, using the "sandwich workflow" as follows:


- First you convert your input media into the grading space/curve. If you used RAW media, frequently the 'cameraParams" effects of Mistika allow to convert straight to your preferred gamut/curve. (for example Arri Log C is popular between colorists...), or any other you prefer. But for the case of HDR production it is recommended to use a PQ curve at his stage, as its response can be tricky for colour grading. Instead the conversion to PQ should be applied at a posterior effect after the colour grade.


- If the cameraParams controlled codec does not provide the desired grading gamut/curve combination, you can set it to some common format (like P3 gamut + linear light curve) and then use an Unicolor instance to convert that common format into the desired grading gamut/curve. This is the lower part of the sandwich.

 

- Past colour grading and other effects, you use an instance of Unicolor to convert from the  grading gamut/curve into the display or delivery gamut/curve - this is the upper part of the sandwich. 


- Unicolour can be partially  combined with ACES  workflows or not,  as Unicolour is a generic tool.


Important note: Please note that Unicolour and ACES-ODT can produce different results on inverse transformations. This is because Unicolour is a purely math function that is fully reversible.  Meanwhile,  many manufacturers and applications based on ACES-ODT typically apply their own Tone Mapping on this conversions, which is not reversible. Tone Mapping is also a creative decision, there is no fixed standard that works for all cases. Most of the color differences appearing after (supposedly) doing "the same" in different applications are caused by different interpretations of tone mapping.   

 


Pure ACES workflow:


Notice that Unicolour if fast and efficient but it only supports spaces that can be described in math only as a gamut plus a curve. ACES does not fit into this description. Its mathematical description   is too complex so it requires the use of  LUTs (which are slower to process and not necessarily reversible). And as the ACES ODTs were designed to be output-only they do not really work well in inverse mode. 


But in many cases you may be requested to produce a pure ACES workflow, typically at client request

 Please note that ACES workflow does not provide "more quality" (in some cases it can be the opposite...).  But what it is designed to provide is "more consistency" between different camera models, different display models, and exchange formats for  collaboration between different applications.  If you apply colour transformations at any stage  that are not ACES compliant then that part of the workflow may not be reproducible in other systems, even if the output images are still in ACES.  Of course this can be a problem or not,  it all depends on the planned workflow.

In this case the effects stack is pretty similar to the generic Unicolour workflow, but there will be some differences in order to complain with the ACES official workflow, with all its advantages and disadvantages. It would be as follows:


- Always do the  extraction of each camera raw to ACES, typically by using  the corresponding cameraParams effect set to ACES extraction, (if that is not available for your camera then do the extraction to the best supported  standard and convert to ACES with an Unicolour effect).  This step will also permit to equalise different cameras from different manufacturers as much as possible In a same lighting situation they should produce similar  colours once they are converted to ACES  (that is not counting lenses and camera intrinsic differences like resolution, noise, etc, but a decent mach should be possible when doing ACES extraction for all of them ).


- The resulting image will be linear (as per the ACES standard), so now it needs to be converted to a more suitable color space for color grading. The ACES official curve for this is ACES cc, so you will use the Unicolour effect to apply that curve.  (Please note that even if you could use an ACES effect to convert from ACES to ACEScc it would be overkill and much less efficient than Unicolour, as for this particular conversion there is an exact mathematical transformation available in Unicolour. And that is much faster and will produce identical results..) 


 - Apply the colour grading and other effects you need


- Apply ACES ODT effect, from  ACES + ACES cc  to  the desired color space for your particular display.  


- Finally,  if you want to produce a pure ACES master or a pure ACES version to collaborate with other ACES applications (ACES  is very extended as a exchange space for VFX ) remove the ACES-ODT and put an Unicolour effect from ACES cc to ACES linear, so you can deliver in this format. ( Technically you should never render files in "ACEScc" or "ACEScg".  The "official" ACES workflow concept says that you should only ever render and exchange Linear ACES files (e.g. Linear curve and "ACES Primaries")).


Also please note that ACES is a colour space much bigger than that one of your reference display.  That means that  delivering ACES images that were colour graded in a type of display will only look the same when later using ACES ODTs for similar displays.  There can be  significant visual differences when the ACES images are  converted to different colour spaces for other displays. And these differences can be much more significant than when converting between traditional colour spaces that had someway similar ranges.  


Notice that in this workflow , for deliveries as per the pure ACES specification, the upper Unicolor node converting from working space has been replaced by the Mistika ACES-ODT node. This node interpret the official ACES .ctl files from the different manufacturers. You can install additional .ctl files in the corresponding folder (SGO AppData/shared/ACES_V1.0 ).



Notes about rescaling ACES images


It is important to be careful about rescaling processes (Framing).  Rescaling works much better on Log images.  A rescale process applied on Linear images can reduce quality and produce "ringing" artifacts.  In the case of ACES you should do the framing on ACEScc (which is Log),  not in pure ACES (which is linear).  


For example, a convenient way is to apply  cameraParams extraction to ACEScc and then apply a Framing effect.