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 <[email protected]> > 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- ____________________ François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
