[Bf-committers] blender-ocio

[Xavier Thomas]

2011/8/3 Brecht Van Lommel <brechtvanlommel at pandora.be>

> Hi,
>
> On Mon, Aug 1, 2011 at 5:36 PM, Ton Roosendaal <ton at blender.org> wrote:
> > Matt wrote a very nice summary of what he intended to work sofar:
> > http://lists.blender.org/pipermail/bf-vfx/2011-July/000124.html
>
> I agree 100% with what was written here, and think it's the way to go.
> Adding options in the image datablock, image save, render ouput and
> viewer.


I also agree 100%. The only issue I see is that it would also need a option
for properties window (for the color pickers) and adding a colorspace
selector for each window/area with color pickers would be a bit overkill


> Probably the first thing to get from OCIO is a way to get a
> list of supported color spaces, and functions to convert entire images
> and individual colors between two spaces.
>

That is actually the only thing I have done so far.
At startup it loads the config.ocio and then load the list of colorspaces,
displays and views in G.main.colorspaces and G.main.displays (views are in a
list inside the display structure).

I also did a function to convert an entire image and RNA helpers to get the
list of available colorspaces. Per pixel transformation is easy to add.


> Beyond that OCIO also has a way to specify color configuration for
> multiple applications, if those support reading these configurations.
> I'm not sure of how much immediate use this is for Blender users
> (since it requires other applications to pick up this as a standard as
> well), but what I think it would come down to is that it would control
> the (default) values for these new color options.


OCIO permit to specify different configuration even for the same
application. So you can use different colorspace for each project/show.
However, according to http://opencolorio.org/workflow/spi_workflow.html :

While the list of colorspaces can be show specific, care is taken to
maintain similar naming to the greatest extent feasible. This reduces artist
confusion. Even if two color spaces are not identical across shows, if they
serve a similar purpose they are named the same. Example: We label 10-bit
scanned film negatives as lg10. Even if two different shows use different
acquisition film stocks, and rely on different linearization curves, they
are both labelled lg10.

My intent was to deliver a Blender default config.ocio with the datafiles.
This config would contains most of the usefull colorspaces (linear, sRGB,
rec709, log, Redlog, ...). But users could overwrite the config.ocio file in
the userdata directory to force blender to use a specific config. Maybe a
user prefs otpion could be added for the user to easily select a different
config.

Users using config different than the default config comming with blender
(or config similar but customized with additional "looks" from "on set"
calibration ) should distribute the config.oci file with the blend file.

This introduce possible problems when loading a blend file with images using
colorspaces that are not present in the config curently in uses by blender.

One of the biggest issue I have code wise is the problem with
bf-blenderkernel depending on the ImBuf lib wich depends on
bf-blenderkernel. I can work arround dependency compilation issue with
forward declaration but  adding some functions to try to detect the
colorspace when loading a new image file will add to the bad level call
mess.

As Ton advised, I will resume all my ideas/plans in a email and send it to
this list and bf-vfx, sorry to take this much time.

Xa