[Bf-committers] Colour Managment

Troy Sobotka troy.sobotka at gmail.com
Tue Apr 8 00:25:22 CEST 2014

On Apr 7, 2014 9:09 AM, "Tom Wilshaw" <tom.wilshaw at btinternet.com> wrote:

> We
> think that, from a technical viewpoint, XYZ would be an excellent
solution. The
> main problem we see is that, with the exception of Y, it is not intuitive
> artists. "A small adjustment to the Z channel" just doesn't convey the
> sort of readily interpretable information that one gets in RGB. We
suppose the
> tools could work in RGB, but process in XYZ, but this will add extra
> and complexity, along with a (perhaps insignificant) performance change.

This would only apply to your working space. It is entirely realistic to
make your color picker the primaries of your wide gamut display etc.

OCIO provides aliases that handle all of this quite readily.

Sadly, Blender's color wheel / square is not color managed yet, and as
such, it dumps pure display referred values to the output. This effectively
prevents an artist from selecting colors properly.

> Our
> current approach is to:
>         1. Linearise
> (we got a 1D LUT from DNG EXIF tag, it just needed scaling).
>         2. Matrix
> convert, without any clipping.

> ACES RICD). A precisely calibrated light source is also used. In our case,

> tungsten lighting and tungsten white balance. We used published data for
> Macbeth chart sRGB code values. The results of applying the linearization
> matrix on input through our OCIO config, and then using sRGB and RRT on
> gives a very similar appearance to the camera manufacturer's 3D LUT for
> conversion to REC.709. There are some small issues due to experimental
> which we are working on.

There is a much easier method. Leverage Argyll to recognize the IT8 and
generate a matrix, then use the resultant matrix as an OCIO transform. ;)

> As
> you can see, none of this is clipped, but it can provide processing

The issue is that with scene referred data it is deadly tricky to calculate
the out of gamut values.

Hence why I suggested a simple scale to a known value (1.0) and scaling
back. While at the 1.0 scaled values, anything beyond 1.0 or negative is
out of gamut, and can be noted.

Note this obviously only applies to a down gamut. An up gamut with wider
primaries will likely hold the smaller gamut.

> None of these numbers would need to be negative if ACES, or XYZ, were
> When we render with the RRT all of these values get gamut mapped in in a
> pleasing way.


> Why
> couldn't Blender use the ACES primaries, but keep the current options of
> "default" and "RRT" output?

Because to the best of my knowledge, the ACES standardization is intended
to achieve just that, and is intended to be accepted in whole.

The above approach you outlined is precisely what ToS did I believe. That
said, it doesn't quite qualify as ACES, and at that point, XYZ may work
more ideally.

> Another
> approach would be to incorporate an LMT for sRGB material, but I agree
> this would probably cause more problems than it solved.


> I
> know that using only the primaries from ACES would be a deviation from the
> spec, but Blender could incorporate the ACES spec so that those who want
to use
> ACES can do so fully, whilst also allowing deviations for those who want
a more
> traditional video style workflow. What problems would this cause?

Likely none, but again, using XYZ is equally viable, with the upside that
many matrices are readily available for XYZ.

> >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
> >even sRGB of course, but is much more obvious in wider gamuts.
> >Hopefully the picker / wheel and remaining pieces will be addressed in
> >near future.
> Personally
> this has never given me major problems, as a lot of colour work is done
by eye
> or with the scopes, so the adjustments are subjective and relative. I
> know enough about the internal workings of these tools to really comment.

You have to fully understand what I am communicating to appreciate the
issue. Crappy sRGB display? That is what you see. Wide gamut Eizo? You see
wide the particular wide gamut primaries for that display. DCI-P3
projector? That is what you see.

In this sense, there is a huge discontinuity with what you see and your
internal data. There is no way to select colors correctly.

> However, if Blender was to move to a wider gamut, would this need to be
> before setting up colour management for the colour wheel?


> by default would cause legacy problems here. XYZ however, would not.
> Again,
> would it be possible to use the ACES space, and then clip out of gamut or
> dynamic range stuff for sRGB or REC.709 outputs if people select

This is precisely what I was suggesting via XYZ; it would be entirely
invisible, unless someone opened up an EXR saved natively, and even then,
it is very likely any post house would be easily able to interpret it.
Perhaps even easier than sRGB / 709 primaries because XYZ (and ACES) are so
wide that it becomes clear immediately the color space is wrong when
viewing under sRGB.

> How
> was the F65 wide gamut footage handled on Tears
> of Steel? Was the out of gamut stuff clipped off?

IIRC, it was a plain matrix transform to 709 / sRGB from ACES primaries in
the EXRs.

> In
> summary then:
>         1. Do
> we agree that having a wide gamut working space, ideally one that
> the full visible range, would be good for Blender?

Some might. ;)

>         2. If
> so, and the choice is between XYZ and ACES, which way would you choose?

ACES may overcome this issue, but in the meantime, I would lean to XYZ when
32 bit float is available.

> The
> actual gamut is the same, and ACES has the advantage of being an RGB

So is XYZ. If you look at ACES primaries sources dumped raw to sRGB, it
looks equally wonk.

>         3. Why
> couldn't the ACES space be used, but with more flexible input and output
> options? The entire ACES spec could be encompassed within this larger
> for full compatibility?

Again, this is the Academy's choice and pace. Currently, the sRGB (and
other such spaces) issue exist.

Until it is _officially_ negotiated, it still feels unsuitable.

Great for camera encoding etc., but still some rough edges in this context.

With respect,

More information about the Bf-committers mailing list