[Bf-committers] Colour Managment

[Tom Wilshaw]

What we want to discuss is the
possibility of further integration of the ACES/IIF colour management system
into Blender. We don't know how familiar you are with this system so we
apologise if any of this seems patronising. Conversely, if any of this is
unfamiliar we would refer you to the Wikipedia page (http://en.wikipedia.org/wiki/Academy_Color_Encoding_System)
and more importantly the ACES documentation (https://www.dropbox.com/sh/nt9z9m6utzvkc5m/ebopy8K7Y6).
The document “ACES_v1.0.1” which is an overview of the system.
 
Currently, if importing footage or
images from a wide gamut source into Blender, it is necessary to convert it to
the native sRGB working space. This can be done on scene linear data with a 3x3
matrix, but doing so causes those RGB values which fall outside the sRGB gamut
to be represented with one or more negative RGB values; this can present
problems for some compositing operations. The ACES gamut can accommodate all
current and likely future gamuts without negative values because it encompasses
the entire visible spectrum. Of course, sRGB material will fit into this gamut
fine, so no compatibility issues should arise due to using existing sRGB material.
 
If Blender's native working space
were ACES, then we could create a camera to ACES matrix from the Macbeth chart,
mix with other sources including CG renders with a wide gamut, and output to
any display type we wanted. All of this without having to contend with
compositing images with negative RGB values.
 
We would be interested to know how
these issues were addressed on Project Mango with the Sony F65, from Sebastian
Koenig's post it sounds as if the gamut was clipped or negative values were
accepted, but we could have misinterpreted this.
 
ACES also allows the creation of
trim passes for output displays other that the mastering display without
additional colour correction by employing a variety of ODTs, although Blender's
current implementation addresses this. However, for wider gamut releases, such
as DCPs, it would be better to have a wider gamut source than sRGB, to better
fill the range of available colours and give a richer and more realistic
result. This is one instance where a move to ACES would be beneficial to
content created entirely within Blender, rather than live action footage only.
 
Could a move to ACES be affected
simply by changing the OCIO config, or would the tools in the compositor
require some recalibration? I suppose changes would have to be made to render
engines, or would just giving ACES texture images and colour pickers give ACES
renders? The ACES RICD flare component would have to be added if it isn't
currently. Prior to the start of the next open movie seems like a great time to
fully switch to ACES; not only would it make compatibility between studios
easier and help different programs to share images (both are amongst the main
aims of the ACES initiative), it would also allow the creation of a wider gamut
DCP.
 
Although one of us is capable of
some coding, a project like this is currently beyond our ability, however we
would be very happy to contribute to documentation for users, as well as help
in any way we could with testing.
 
Another aspect of this system is the
IDT. Whilst the creation of IDTs according to the ACES specification would
require the integration of the CTL, as well as a complex experimental set up
with the camera in question, an approximation which meets the required behaviours
listed in the Academy's IDT specification can be achieved with a linearization
LUT and a matrix. We have created a program to derive the matrix, although this
is a work in progress and could be greatly improved. There are many academic
papers on the creation of linearization LUTs, although we have yet to implement
one, as we have taken this information from a DNG tag for our own camera. For
high end cinema cameras, the manufacturers provide IDTs in CTL, but these can
be converted to OCIO LUTs and matrices.
 
We sent this to Ton, who advised us
to send it to the mailing list. He raised the point that “filmers prefer Aces,
but animation/vfx pipelines (apparently) not. Blender is about the latter”. Our
understanding is that ACES is extremely beneficial for visual effects pipelines
because they mix so many different sources of images. For example live action
footage from film scans or cinema cameras, background plates and textures from
DSLRs, CG renders and matte paintings. The differences between these sources
are minimised in an ACES workflow. For animation ACES could improve the
finished result by providing a wider range of colours, even when mapped to a
low gamut output by the ODT, and by better handling high dynamic range renders
through the RRT’s pleasing tone rendering. In many ways, the change to an ACES
workflow would be largely invisible to an end user.
 
As an aside, but whilst discussing
colour management, we have often thought that the addition of an OCIO node
would be a very helpful feature. Some operations, such as green screen keying,
work better on low dynamic range sources, and the ability to convert to log and
back within a node tree would be extremely helpful (see Jeremy Selan's
"Cinematic Color", p. 35).
 
Owain and Tom Wilshaw