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:
