2011/8/3 Brecht Van Lommel <[email protected]> > Hi, > > On Mon, Aug 1, 2011 at 5:36 PM, Ton Roosendaal <[email protected]> wrote: > > Matt wrote a very nice summary of what he intended to work sofar: > > http://lists.blender.org/pipermail/bf-vfx/2011-July/000124.html > > I agree 100% with what was written here, and think it's the way to go. > Adding options in the image datablock, image save, render ouput and > viewer.
I also agree 100%. The only issue I see is that it would also need a option for properties window (for the color pickers) and adding a colorspace selector for each window/area with color pickers would be a bit overkill > Probably the first thing to get from OCIO is a way to get a > list of supported color spaces, and functions to convert entire images > and individual colors between two spaces. > That is actually the only thing I have done so far. At startup it loads the config.ocio and then load the list of colorspaces, displays and views in G.main.colorspaces and G.main.displays (views are in a list inside the display structure). I also did a function to convert an entire image and RNA helpers to get the list of available colorspaces. Per pixel transformation is easy to add. > Beyond that OCIO also has a way to specify color configuration for > multiple applications, if those support reading these configurations. > I'm not sure of how much immediate use this is for Blender users > (since it requires other applications to pick up this as a standard as > well), but what I think it would come down to is that it would control > the (default) values for these new color options. OCIO permit to specify different configuration even for the same application. So you can use different colorspace for each project/show. However, according to http://opencolorio.org/workflow/spi_workflow.html : While the list of colorspaces can be show specific, care is taken to maintain similar naming to the greatest extent feasible. This reduces artist confusion. Even if two color spaces are not identical across shows, if they serve a similar purpose they are named the same. Example: We label 10-bit scanned film negatives as lg10. Even if two different shows use different acquisition film stocks, and rely on different linearization curves, they are both labelled lg10. My intent was to deliver a Blender default config.ocio with the datafiles. This config would contains most of the usefull colorspaces (linear, sRGB, rec709, log, Redlog, ...). But users could overwrite the config.ocio file in the userdata directory to force blender to use a specific config. Maybe a user prefs otpion could be added for the user to easily select a different config. Users using config different than the default config comming with blender (or config similar but customized with additional "looks" from "on set" calibration ) should distribute the config.oci file with the blend file. This introduce possible problems when loading a blend file with images using colorspaces that are not present in the config curently in uses by blender. One of the biggest issue I have code wise is the problem with bf-blenderkernel depending on the ImBuf lib wich depends on bf-blenderkernel. I can work arround dependency compilation issue with forward declaration but adding some functions to try to detect the colorspace when loading a new image file will add to the bad level call mess. As Ton advised, I will resume all my ideas/plans in a email and send it to this list and bf-vfx, sorry to take this much time. Xa _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
