[Bf-committers] Colour Managment

[Troy Sobotka]

On Apr 4, 2014 8:07 AM, "Tom Wilshaw" <tom.wilshaw at btinternet.com> wrote:
> 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.

Wider gamuts typically will require the clamp not only at the zero
luminance level, but also at the upper end for values that have been pushed
beyond their sRGB domain.

> 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.

Or XYZ.

As stated above, the conversion also yields invalid colors at the upper end
as well I believe.

The only method that I am aware of to maintain in-gamut values is to:

A) Linearize your space's data.
B) Scale data to 0-1.0 domain.
C) Matrix convert to smaller gamut via the aforementioned RGB to XYZ and
XYZ to RGB.
D) Clip out of gamut beyond 0-1.0.
E) Scale back to display referred values via the value from B.

> 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.

The current issue with ACES is that there was an aesthetic / design choice
baked in for film compatibility. This makes it difficult to ingest say,
sRGB and get 1:1 back via the RRTs. Using only the primaries of course
would deviate significantly from the ACES spec, and probably lead to
problems.

Within the Blender community, I believe this would cause more confusion
than desired.

Something like XYZ is likely a better fit, and is the 100% compatible with
the existing Blender paradigm.

Trim passes are already possible via OCIO.

> Could a move to ACES be affected
> simply by changing the OCIO config, or would the tools in the compositor
> require some recalibration?

You can obtain the official ACES OCIO configuration and use it.

The issue is that there are still some critical areas that are not color
managed, such as the color picker / wheel. Having the picker broken affects
even sRGB of course, but is much more obvious in wider gamuts.

Hopefully the picker / wheel and remaining pieces will be addressed in the
near future.

> 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".

With specific attention to the Blender community, it remains problematic
due to the RRTs. Many animators within the Blender community expect a
perfect 1:1 input to output chain, and this is currently impossible without
the aesthetic choices ACES had baked into the RRTs.

ACES by default would cause legacy problems here. XYZ however, would not.

> 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.

Agreed.

In theory, this is already somewhat possible by crafting custom OCIO
configs, but hopefully an OCIO node is soon on the horizon. It has been
needed for a while.

So the TL; DR is that ACES or any other space can be partially implemented
in Blender by changing the OCIO configs. The downside is that some areas
are still not color managed, with particular attention to the color wheel /
picker, which requires a perceptual curve change (to log for example) and a
primaries change.

With respect,
TJS