[Bf-vfx] Formats and Color

[Troy Sobotka]

Lengthy post. Apologies.

On Apr 9, 2012 1:59 AM, "Peter Schlaile" <peter@ <peter at schlaile.de>
schlaile.de <peter at schlaile.de>> wrote:

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

Andrew said it best - the linear float is the model, not the space. There
is linearization, where said values fit on a linear ratio scale (again,
linearization only asserts ratios, not value positions), and finally
chromacities.

Red is not red. Green is not green. And blue is not blue.

How each value relates is tied to the color space.

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

Simply, all color and perception is relative. A proper space defines not
only "hardware" based reference points, but also viewing conditions.

YCbCr (YUV is a misnomer as it specifically is analog) would be a good
example of a model without a space. Within YCbCr there is rec709, rec60,
240m etc. Each of those have _different_ transfer characteristics.

In plain terms, the Cb and Cr describe different intentions within each
space.

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

It would only be "a lot of work" if a library were not available, complete
with interaction of over a decade of color data.

We already at times define a color space in Blender. For example, all
inputs from JPG, TIFF, etc., use the linearization of sRGB. The
chromacities are unaccounted for.

To highlight the fact that RGB values are more codes in the modern era, I
would suggest looking at a sample image with an adjusted gamut.

http://www.gballard.net/psd/go_live_page_profile/Browser_Color_Test_.jpg

Again, until one knows a source space and a destination space, no
transforms can take place.

So defining a working space is nothing more than defining the destination.
For output, it defines the source.

We could of course create a custom Blender space and create hundreds of
LUTs to convert to and from known spaces.

Or we could simply rely on the vast body of LUTs and ICCs already out there
and leverage a library.

Remember, Blender is already defining color spaces at times, albeit in an
inconsistent and incomplete manner.

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

Again, RGB is not a space. It is a model. The limits lie in the space
itself, which at times is sRGB.

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

There is _no_ proper without defining a destination space.

This should leave no confusion. It cannot be done.

Ton said:
> For the rest of it, I have the impression it's all being made too
complicated. Let's try to stick to design ideas for an efficient workflow
for Blender, which is for 3d artists (who are not color experts)
specifically. I am sure we can keep it nice simple, and still satisfy
strict color quality demands :)

At the core is a very simple discussion. Source space. Destination space.

The simplest way to make this clear is to state, beyond a shadow of a
doubt, that no one has any clue what they are looking at without color
management. Full stop.

I would hope that this statement is relevant to any artist, 3D or otherwise.

With utmost respect,
TJS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20120409/a1c693d9/attachment.htm