[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [50503] branches/soc-2011-tomato: Color Management: finish pipeline changes

[Sergey Sharybin]

Hi,

yes it'll be eventually nice to support color picking role, but that's a
tricky part.

First of all it'll work for only display and view which color picking role
was designed to work and it wouldn't work for any other display/view.
Meaning if you'll want to have, say, XYZ monitor as default you'll need to
modify the config file. It's not so bad so far since if you're using XYZ
screen you'll be considered advanced user.

But the thing is -- we need to keep as much compatibility as it's possible
with previous versions, meaning that we need to support old behavior with
Color Management disabled, which is currently emulated via tweaking input
image spaces and display device. In this case using color picker role would
break compatibility.

Anyway, we can not deliver everything at once and we need to make a release
in couple of weeks. So as soon as it's not breaking compatibility and
behaves pretty much as it's expected by most of current users/pipelines i
wouldn't mind having current behavior in release and support color
picking/texture painting roles after that.

Remember that apart from color spaces we also need to bunch of bugs form
the tracker before the release...

On Tue, Sep 11, 2012 at 11:02 PM, Xavier Thomas <
xavier.thomas.1980 at gmail.com> wrote:

> Hi,
>
> First , I have to say; you did a awsome job on this colormanagement
> project, it is a plesure to see it evolve.
>
> I would just like to comment on the following comment:
>
>
> > 3D viewport is supposed to be working in sRGB space, no tonemaps would be
> > applied there. This is another case where compatibility breaks in
> > comparison
> > with old color management pipeline, but supporting display transformation
> > would be tricky since it'll also be needed to make GLSL shaders, textures
> > and so be aware of display transform.
> >
> > Interface is now aware of display transformation, but it only uses
> default
> > display view, no exposure, gamma or curve mapping is supported there.
> > This is so color widgets could apply display transformation in both
> > directions. Such behavior is a bit counter-intuitive, but it's currently
> > the only way to make color picking working smoothly. In theory we'll need
> > to support color picking color space, but it'll be also a bit tricky
> since
> > in Blender display transform is configurable from the interface and could
> > be used for artistics needs and in such design it's not possible to
> figure
> > out invertable color space which could be used for color picking.
> >
> > In other software it's not so big issue since all color spaces, display
> > transform and so are strictly defined by pipeline and in this case it is
> > possible to define color picking space which would be close enough to
> > display space.
>
>
> I think that the OCIO philosophy here is to use the display/view transform
> for the image viewers only. With one selection per image view so you can do
> multidisplay with different monitors type (sRGB, and rec709HDTV can be
> common) and/or have 2 view on the same monitor with different look (Normal
> and Film). For the color picker the UI OCIO define a specific role
> "color_picking" with I think can be non configurable in Blender and set to
> a default sRGB. This still allowing advanced user to modify it in the OCIO
> config. For this Blender would need to cache a color transformation for
> each image viewer and another for the UI.
>
> Xavier
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin