Hi,<div><br></div><div>Good to see you here Matt. There was effectively some discussion about the pipeline but if I recall well everybody ended agreeing that the pipeline you set-up is OK and just need to be made "configurable", ie letting the option to the user to force a specific color space for some specific input/output.</div>
<div><br>The open questions was: </div><div><br></div><div>- Wich CMS to uses? Apparently only lcms2 and OpenColorIO can handle properly 32bit flat imagery. OpenColorIO seems to be the preferred choice because it is oriented CG/Vfx and tightened to OpenImageIO which might make his way into blender (Cycles). However some people where disappointed that OpenColorIO does not handle the full ICC 4.2 spec. Personally I think it is not necessary and people making graphics for printing (CMJK but often still images and not animation) should do the CG in blender linear and the color correction/composting in a program more intended for the purpose (Gimp, Photoshop, ...)</div>
<div><br></div><div>- We need a good proposal for specifying the display profile(s), ideally one that would work with multi-display, calibrated display and professional studio monitors. One settings in the user prefs do not cut it. One settings for each image viewer or compositor window/area type would not make it clear which profile to use in the UI for the color pickers. Personally I would go with a setting per window (real window, not area) and put it in the info bar next to the render engine selection.</div>
<div><br></div><div>-We should take more care of the info that does not need conversion. For example if you store world position and normals in a buffer to do some relighting in the compositor, even if the values are stored in an image they should not be handled by the CMS, or the CMS should recognize those and just use a pass-trough.</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">2011/7/18 <a href="mailto:j.bakker@atmind.nl">j.bakker@atmind.nl</a> <span dir="ltr"><<a href="mailto:j.bakker@atmind.nl">j.bakker@atmind.nl</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Matt,<br>
<br>
Thanks for this clear explanation! It gives me understanding about the<br>
ideas behind blender's colour management. Possible steps could be:<br>
<br>
a) Which CMS to use and why?<br>
b) Link the chosen CMS to blender's image loading and writing (there has<br>
been several discussions on OpenEXR compatibility the last week on IRC)<br>
c) Attach to the display routines, replace colour management inside blender<br>
d) Apply CM in other area's like compositor, color picker, multi-display<br>
setup and others<br>
<br>
a, b & c IMO is a project on its own. After that d could be a simple step.<br>
A task that needs to be designed with care is the blender internal renderer<br>
multilayer openexr (save buffers).<br>
<br>
This project looks like a large undertaking to get it working in all areas<br>
(but also with big benefits).<br>
<br>
BTW I saw a compositor node that converted the internal color information<br>
to rec709 and back again. If I understand correctly this needs to be<br>
revisited?<br>
<br>
Jeroen.<br>
<br>
<br>
--------------------------------------------------------------------<br>
mail2web LIVE – Free email based on Microsoft® Exchange technology -<br>
<a href="http://link.mail2web.com/LIVE" target="_blank">http://link.mail2web.com/LIVE</a><br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Bf-vfx mailing list<br>
<a href="mailto:Bf-vfx@blender.org">Bf-vfx@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-vfx" target="_blank">http://lists.blender.org/mailman/listinfo/bf-vfx</a><br>
</div></div></blockquote></div><br></div>