[Bf-committers] Blender OCIO

[François T.]

Hi,


> - 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.
>

what does that mean ? 8bit (or whatever) image are not converted to float
anyway ?

F


2011/8/10 Xavier Thomas <xavier.thomas.1980 at gmail.com>

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier