ACES 1.3 Reference Gamut Compression User Guide
The purpose of this document is to elaborate on suggested user workflows for on set, dailies, visual effects, and finishing using the ACES 1.3 Reference Gamut Compression (RGC). For detailed technical specifications, please refer to the Technical Documentation:
A common complaint from users of ACES has been the artifacts resulting from out of gamut values in source images. These artifacts are most known for appearing in highly saturated, bright LED light sources such as police car lights, stoplights, etc - but also show up frequently in LED sources used to light scenes. In an ACES workflow, these artifacts appear at two stages - first in the conversion from camera raw RGB via an Input Transform (IDT) into ACES AP0 - and second in the conversion from ACES AP0 into ACES AP1 (ACEScg and ACEScct). These out of gamut pixel values are problematic when their negative components cause issues in compositing, and may also produce visual artifacts when viewed through an ACES Output Transform.
A Look Modification Transform (LMT) referred to as the was created as a temporary solution, but this solution affected all pixels in the image, rather than just the problem areas. A new solution was needed which preserved colors within a “zone of trust”, only altering the most saturated values. The Reference Gamut Compression algorithm published in ACES 1.3 is intended to replace and deprecate the Blue Light Artifact LMT.
Various options were investigated, and the working group finally settled on a simple RGB ratio based algorithm which compresses values based on their distance from the neutral axis. This makes no attempt to ascertain the “correct” value for a pixel, since the nature of the problem means that these pixels may have no correct color. The algorithm is intended as a technical correction rather than an aesthetic look. It “heals” the problem pixels, to produce new RGB values which are less problematic when used in subsequent compositing or grading operations. Creative modifications are left for the user to apply as necessary downstream of the RGC.
The uses fixed values for the thresholds where compression begins, and for the amount of compression. These values have been calculated such that the colors of the ColorChecker 24 will remain unchanged, and that any colors that are within the encoding gamuts of all the commonly used digital cinema cameras (those with official ACES IDTs) will be brought within AP1, thus ensuring positive ACEScg values. In most workflows, these constants will be invisible to the user, as demonstrated in the screenshots from Resolve 17.4 below - the user has the option to apply the RGC at a project or a clip level.
In the example below, artifacts such as the magenta solarization seen on the nose of the Okja toy are greatly reduced by application of the RGC.
Though the algorithm itself and application to an image is relatively simple, there are many considerations to discuss for overall workflows for an ACES project, from on set through to finishing.
As visualized in the flowchart above, it is recommended (in the current absence of AMF for tracking) that most productions utilize the gamut compression in every area - from on set all the way to finishing. This means that at this time, for simplicity, the the RGC is “always on” by default in any viewing pipeline. Following the general ACES workflow philosophy, the RGC is only baked in to image data at the appropriate stage in the pipeline - which varies based on the needs of your production, as outlined in the flow chart and explained below.
- On Set
- Live Grading: if your production is utilizing an on set grading software, such as Pomfort Livegrade, use it to apply the Reference Gamut Compression. This will embed the RGC in the 3D LUT which is passed to the LUT box for viewing on a monitor.
- In-Camera: the production can create a 3D LUT of the appropriate size (normally 33x33x33 max) with the Reference Gamut Compression added to the existing viewing pipeline to load into the camera.
- Use a dailies generation software, such as Colorfront or Resolve, to import the original camera footage, and apply the Reference Gamut Compression as a part of your viewing pipeline for export to desired media.
- Use media supplied from dailies, and back from VFX, to verify media as work progresses. As editorial is largely offline and QT based, the media should have the Reference Gamut Compression as viewed on set baked into the files sent to editorial.
- Frame pulls for VFX should NOT have the Reference Gamut Compression baked in. The files should be debayered to AP0.
- VFX will have the flexibility to apply the RGC wherever is best for their compositing chain. This will often be the first node in the tree, but sometimes operations such as a despill on a bluescreen will need to be performed pre-gamut compression. Sending pulls to VFX in AP0 gives compositors the flexibility to fine tune and control their work.
- Once applied, the Reference Gamut compression should NOT be inverted before delivery.
- It is important that the RCG get applied to all WIP QT renders for review and editorial, so as to match dailies.
- Finishing software should have the ability to apply the RGC at a project, timeline, or clip level. This should give the colorist flexibility to choose what works best for the project.
- The RGC should be applied directly after the IDT, ideally before any scaling, grading, or other finishing work.
- In a pre-conformed timeline, apply the RGC as early as possible.
- If frames are coming back from VFX, it will be important to track those vs. non-VFX shots, so that the gamut compression is not applied twice.
Order of Operations
The order in which the various operations are applied to an image has a significant impact on the end result. In particular, any scaling will produce a different result depending on whether it is done before or after the RGC, since its removal of negative values can reduce some scaling artifacts. Some applications may give the user detailed control over order of operations, but in others the underlying processes are hidden. This is an important consideration when planning workflows.
In compositing in particular, there may be operations (edge despill in keying has been noted) where using the unmodified pixel values gives a preferable result. In these cases it may be necessary for the compositor to have access to both the original and gamut compressed image data in their node tree, choosing between them as necessary. For consistency, the RGC should still be applied at some other suitable point in the composite, such that the final renders delivered to DI still have the gamut compression applied as expected.
Since normal practice in VFX is to return images with any pixel not touched by the compositing process unmodified from the original pulls, one might think that the RGC should be inverted for deliverables, as is done with CDL corrections, for example. However, it is better to think of the RGC more like a spill suppression, which is part of the composite, and would not be inverted out at the end. Inverting creates the possibility that elements added during compositing (CGI originally created in ACEScg, for example) which have not had the RGC applied may produce extreme values on inversion. An inverse mode is included in the algorithm, but is provided only for edge cases where it proves unavoidable. Some education of the various stakeholders may be required to establish why inverting is not preferable.