[Bf-vfx] Formats and Color

[Peter Schlaile]

Hi Troy,

> > but shouldn't Blender actually just work in float space, only
clamping the
> > value at the final rendering step and everything should be fine
> > and dandy? (still scratching my head on this one)
> The internal 32bpc format is not the issue.
> The issue is that many seem to think that defining a sufficiently deep
> linear system is enough. It is not.
> The internal space must be mapped to a known model so that all input,
> output, and manipulative transforms can be done within the model.

okay, I wasn't very precise in my question.

So: why is it exactly a problem to keep the workspace always in Linear RGB
granted, that we have a float precision pipeline that doesn't clip?

Or: what is the exact reason to use a different workspace color profile?
(besides nodes that clip values (which they shouldn't IMHO) and speed
reasons if for example input is YUV, transformations can be done in 
YUV and output is YUV).

My suggestion is: in a first step, keep the internal workspace of the
float pipeline in Linear RGB.

In a second step, we can make the whole pipeline color management aware, but
that is really a lot of work. And: I still can't see the benefit over
a truely float *and* HDR aware RGB pipeline.

Fun fact: the idea behind ACES looks like this: have the workspace *always* 
nailed to ACES colorspace. To finally end this workspace colorspace craziness 
and just work within the one and only workspace called ACES. 
In fact, the same thing, Blender already did. With a RGB float space, 
that shouldn't clip.

So: other direction could be: let's nail blender to ACES color space and
everything is fine :) Or just keep it the way it is, but do that properly.

But since the transform ACES <-> RGB seems to be a simple matrix multiplication,
I still can't see the benefit, sorry.

> In the end, properly collapsing the raw steel data to a high fidelity RGB
> triplet still permits white balancing.
> Nuke and other software does this, for example. ACES also has white point
> transforms in the 3D LUTs.
> Mr. Selan can iterate on the mathematics of this if asked.

Okay, I was wrong. White balance problems only arise, if you bake your white 
balance into the picture and save them into an OpenEXR which clamps to [0-1]
interval.

> The original DPX of the car, properly transformed, looked acceptable.

good.

Cheers,
Peter