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

_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers

Reply via email to