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, probably the most popular between colorists...), or any other you prefer.
- 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.
- 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 hat 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 ttraditional 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 (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.