<div dir="ltr">Hi,<div><br></div><div>I didn't get your first question about ccl_device, but it is in the TODO to have basically have the same color management as in Blender. In fact, it's already kinda happening for packed images (because OIIO is not used in this case and all the colorspace settings form the Image datblock are being respected).<br></div><div><br></div><div>Basically the rough plan is to do it all on the image load. There's simply no other way since you can't do OCIO calls from the kernel (and probably shouldn't because of the performance issues). Float images will be simple to handle, byte are more tricky and i can't tell you atm what's the best approach here.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 6:18 AM, Troy Sobotka <span dir="ltr"><<a href="mailto:troy.sobotka@gmail.com" target="_blank">troy.sobotka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">While slowly moving toward making Blender fully color managed and color aware, I discovered that Cycles has hard coded color work in util_color.h.<div><br></div><div>What are the pitfalls to coding the ccl_device stanzas that need to be avoided? Has any thought been given as to have Cycles be color managed via OCIO?</div><div><br></div><div>With respect,</div><div>TJS</div></div>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div>