[Bf-vfx] Formats and Color

[François T.]

lots of chitchat for a known issue which as been there for ages ^^. So much
chat that I actually lost what was the point of all this (and yet I did
follow the discussion from the beginning).
Plus since you concentrate color space on standards and known ones. but
with many cameras/hardwares comes LUT as well. So its not just about
converting a few spaces to another of the one we know as for today. And for
sure its not just an issue around the Sony Camera. Think about 5D and its
cinestyle LUT, or C300 and all its profiles ? yes those are not color
space, yet transformation very good to use
A popular CM engine with lots of LUTs is already there. it let you do any
transformation. Why is there still some arguments on the topic there ? I
honestly don't follow anymore.
Even the OCIO engine with a LUT node would make as many transformation as
needed for advance user. You might want to make things simple for most of
the user, which is totally fine. But there is even great use to convert in
the middle of your process to some different Color space (for keying or
color grading for instance).
Its more complex that just interpreting the input and the output, it can
have so many uses, and like Troy said it already exists and Xavier have a
proof of concept if I'm not mistaking.

I feel this is like the endless story :p


F.


2012/4/9 Troy Sobotka <troy.sobotka at gmail.com>

> 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
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>
>


-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20120409/e372217b/attachment.htm