<div>Hi, </div><div><br></div><div>Here is my ideas/interrogations regarding the my blender-ocio integration experiment.</div><div><br></div><div>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:</div>
<div>- small incremental steps</div><div>- any contributor/tester is welcome.</div><div>- be patient</div><div><br></div><div>Some Things to knows:</div><div>- 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.</div>
<div>- 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, ...)</div>
<div><br></div><div><br></div><div>Some of the interrogations I have since I began working on this:</div><div><br></div><div>- 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 ;)</div>
<div><br></div><div>- 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:</div>
<div><br></div><div>ConstConfigRcPtr* config = OCIO_getCurrentConfig();</div><div>ConstColorSpaceRcPtr* colorspace = OCIO_configGetColorSpace(config, "colorspace_name");</div><div>// do something here</div><div>
OCIO_colorSpaceRelease(colorspace);</div><div>OCIO_configRelease(config);</div><div><br></div><div>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.</div>
<div><br></div><div>- BKE_colormanagement</div><div>This seems to be the appropriate place to write the blender color-management system (relying on the OCIO C API).</div><div>*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?</div>
<div>*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)?</div><div>*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.</div>
<div><br></div><div><br></div><div>- DNA data</div><div>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).</div>
<div><br></div><div>-ImBuf</div><div>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.</div>
<div>So instead of using:</div><div><br></div><div>IMB_float_from_rect(ibuf);</div><div><br></div><div>which would assume the "rect" ibuf is sRGB and convert it automaticaly to linear. We should use:</div><div><br>
</div><div>IMB_float_from_rect_nocolormanagement(ibuf);</div><div>BKE_colormanagement_apply_transform(ibuf, "sRGB", "composite_linear");</div><div><br></div><div>- Log images</div><div>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.</div>
<div> </div><div><br></div><div>-Compositing nodes</div><div>Some additional nodes might be needed/useful:</div><div>A color-space transform node that takes an input and output colorspace and apply the resulting transformation to the composite buffer.</div>
<div>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.</div><div><br></div><div><br></div><div>- 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)?</div>
<div><br></div><div><br></div><div>Xavier</div>