[Bf-committers] Colour Managment

Tom Wilshaw tom.wilshaw at btinternet.com
Sun Apr 20 17:33:24 CEST 2014

Sorry for the delay in replying.

I see what you mean now about the colour wheel. Is there a projected time for fixing this issue?

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

It works just as well in Python, and as you suggest, we have been using the matrix as an OCIO transform within Blender.

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

Could you elaborate on this? Is it because sRGB or REC.709 assumes things are normalised?

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

Hence the need for a wider working space within Blender.

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

Whilst this is true, the primary aim of the ACES project is to allow interchange of images between different pieces of software and post production or animation facilities. In this regard, provided Blender's input and output of EXRs is within the ACES spec, it doesn't matter so much if deviations occur for display reffered outputs/deliverables.

"with the upside that 
many matrices are readily available for XYZ"

There are some matrices available for ACES, and this will increase in the future. It is not too difficult to create matrices when they are required.

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

In terms of opening EXRs natively, the obvious solution is to use OCIO Display, with the same config as Blender or other programs on the system. Although any post house should be able to interpret it with either set of primaries, it would be easier if they only had to deal with one. There is a move towards ACES within the industry.

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

It does, but code values are still rather more intuitive in ACES by virtue of it being RGB based. For example, a mid grey card, an inportant reference in visual effects, should read 0.18, 0.18, 0.18 in ACES. In XYZ, it reads 0.1715, 0.1800, 0.1816. Although it is possible to remember this, it is simpler if the accuracy of neutral colours can be ascertained simple by checking to see if they have equal code values.

"Until it is _officially_ negotiated, it still feels unsuitable. "

Would it be worth trying to discuss this on the ACES Google Group (https://groups.google.com/forum/#!forum/AcademyACES)? If ACES becomes as ubiquitous as they seem to hope then the sRGB/REC.709 response to the RRT will become an issue in the remastering of legacy content, especially in TV.

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

ACES is not that great for camera encoding; if you are shooting with anything less than 16 bits, and 10 and 12 bits are common in cameras, it makes very little sense to encode with primaries significantly wider than the physical primaries of the sensor as this wastes limited resources. For cameras, as for displays, the most sensible encoding is using the physical primaries, ACES comes into its own with the exchange of material from a variety of sources in high bit depth, i.e. in postproduction, and in programs such as Blender.

A move to XYZ would fulfill our own needs well enough for working with the cameras that we do, however it doesn't seem like the best long term decision for Blender itself. ACES is an open standard which is set to become increasingly common. Blender might do better to be ahead of this trend, rather than effect a move to XYZ only to have to move to ACES at a later date in order to satisfy users in these fields.

Do you think it would be worth trying to gather the opinions of other users who use Blender for visual effects or postproduction (or even animation)? We might start a Blender Artists thread and see what a few other people think? Many artists don't follow the mailing list.

Owain and Tom Wilshaw

More information about the Bf-committers mailing list