[Bf-committers] Blender OCIO

[Xavier Thomas]

Hi,

Here is my ideas/interrogations regarding the my blender-ocio integration
experiment.

My plan is to replace the current color-management code with code relying on
the OCIO library, and make the current colormanagement pipeline configurable
by the user. Because I do not have much time to dedicate to this project, I
want to follow those rules:
- small incremental steps
- any contributor/tester is welcome.
- be patient

Some Things to knows:
- Blender use color-management only for float images. I do not plan and
changing this. For quick operation of some of the Blender features (3d view
texturing, sequencer, ...) I think it is best to keep things that way.
However a flag to force converting some image to float when loading them
would be usefull.
- OCIO needs a config file containing the list of color-spaces, display/view
transformations, roles, ... So Blender would need to provide a default
configuration. Users can overwrite the default configuration but in this
case there could be problem when exchanging blender files that was created
with different config (missing colorspaces, different name for the
same color-space, ...)


Some of the interrogations I have since I began working on this:

- Color management would become mandatory and the property
"rendersetting.use_color_management" would be removed. This would make
OpenColorIO a mandatory dependency for compiling, so I included the OCIO
source in "extern". OCIO comes with its own mandatory dependencies (tinyxml
and yaml-cpp, both patched). For now I didn't change the way those
dependencies are compiled: using the CMake ExternalProject macro that unpack
the tgz containing the source, patch it and compile it. I am not sure if
those dependencies can stay in "extern/ocio/ext" or if I should add a
directory in "extern for" each of those libraries (extern/tinyxml and
extern/yaml-cpp). It is not a big deal really but it would be better to
decide on this before working more on the building systems (for now only
CMake is working). Once a decision is taken if somebody want to contribute
for Scons and tests on Windows/Mac I am cool with it ;)

- In "extern/ocio" I added 2 files "ocio-capi.h" and "ocio-capi.c". Those
contains just a basic C API to access the OCIO lib from blender C code. The
API is very close to the original OCIO API and complete enough for loading a
config and its content (main color-spaces and display/views) as well as
for applying transform to a whole buffer or use the per pixel
transformations. The main issue at this level is that OCIO uses shared
pointer in C++ so it made it a bit difficult to write an simple C API. To
work around this you should call a function to release each pointer to OCIO
objects after using them. Like this for example:

ConstConfigRcPtr* config = OCIO_getCurrentConfig();
ConstColorSpaceRcPtr* colorspace = OCIO_configGetColorSpace(config,
"colorspace_name");
// do something here
OCIO_colorSpaceRelease(colorspace);
OCIO_configRelease(config);

This is a bit annoying but not a big deal because this API will only be used
in BKE_colormanagement which will provide a easier API to use in other place
of the Blender source. Anyway, if one of you have a better way to do this I
am all ears.

- BKE_colormanagement
This seems to be the appropriate place to write the
blender color-management system (relying on the OCIO C API).
*There seems to be no consistent naming for the functions in there. Should I
prefix the public functions with BKE or a new prefix BCM or not at all?
Also, I used camelCase for the functions name is that OK or should it be all
lower case with _ between words?
*Is the use of the global G (G.main) OK to store the info needed by the
color management system (list of colorspaces in the config for example)?
*I added in there some helper functions to get RNA EnumProperty arrays of
available choice for color-spaces/display. This would be needed in different
places in the RNA system (Images properties, save image operators, some
nodes, viewers, ...). Maybe this belongs in the makesrna code, I am not
sure.


- DNA data
For the data that will be saved in the blend file, I plan to add char[32]
properties to the DNA structures for saving color-space name (in the Image
structure for example). Like this is is possible to match different blend
file with different OCIO config file. When loading a blend file, we can mach
color-spaces by name and detect color-spaces used in the blender file that
are missing in the OCIO config (and warn the user about this).

-ImBuf
For the moment the color-space conversion is done in the ImBuf library (in
divers.c) when converting a 8bit image to a float image and the other way
around. I plan on removing the color-space conversion from the ImBuf library
and instead call the functions of BKE_colormanagement instead. OCIO work
only "in place" on float data anyway.
So instead of using:

IMB_float_from_rect(ibuf);

which would assume the "rect" ibuf is sRGB and convert it automaticaly to
linear. We should use:

IMB_float_from_rect_nocolormanagement(ibuf);
BKE_colormanagement_apply_transform(ibuf, "sRGB", "composite_linear");

- Log images
The current color-management code by Matt does not handle the transformation
of image in log colorspace. This is done by the dpx image loader code for
now. It will need to be investigated a bit more.


-Compositing nodes
Some additional  nodes might be needed/useful:
A color-space transform node that takes an input and output colorspace and
apply the resulting transformation to the composite buffer.
A file tans-from node, that load a transform from a file (ASC-CDL, 1D LUT or
3D LUT) and apply it to the composite buffer.


- Is the WindowManager init exit functions a good place for
the color-management init/exit functions (loading color-spaces list form the
OCIO config and freeing them)? What about background rendering, without
window(manager)?


Xavier