Are there color transform / LUT formats you use that aren't supported by OCIO? It's easy to add them if you let us know! (hint, hint) These can even be internal formats that don't leave your building

Yes, as Bruno told, there are many tools in which it will be appreciable to have OFX ocio nodes... like Scratch too :) OK, that's a good option to let Tuttle's plugs mature. And I don't think that

Hmm... That makes things interesting. I'd love to get OCIO support (even in a limited form) in these apps. Is anyone on this list interested in compiling / testing an OFX plugin version of OCIO? --

Base light, Sony Vegas and Toxik do as well. Bruno Nicoletti

Hmm... I say if your plugins are not validated against the mainline OFX (or you wouldnt trust them to work in that context) to leave it out for now. There really no rush, so we can let the plugins

Good question, no quick answer :) TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !). TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us :

https://github.com/imageworks/OpenColorIO/pull/223 SetLoggingLevel wasnt being obeyed, if set before initialization. Now it works. - Jeremy

Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable? -- Jeremy 2012/2/20 Marie Fétiveau <m...@...>

ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). For the moment Tuttle is built

Cool! Can you tell use a bit about the integration? Have you added generic OFX support to OCIO? Or have you directly integrated it natively into TuttleOFX? -- Jeremy 2012/2/20 Marie Fétiveau

Hello ! TuttleOFX is now using OpenColorIO to read and apply LUT files on images. This give me the chance to thank you for your great work : it rocks ! Of course that's a tiny first step in the

https://github.com/imageworks/OpenColorIO/pull/221 Committing Jeremy's Look docs. Also and documented ociobakelut usage, part of which somewhat escalated from "ociobakelut --format icc" to my

This is now ready for a real pull-request: Internal image-procesing ops now go through a simple optimization framework as part of Processor creation. In this first code pass, ops that are exact

Ok, yaml-cpp 0.3.0 is now on it's way through the QA system for Fedora. Jeremy, Do you have a specific date in mind to incorporate your yaml fork? I have a fairly extensive patch to unbundle

https://github.com/imageworks/OpenColorIO/pull/219 We've had reason to experiment with actually using ocioconvert in our pipeline, but discovered that we needed to pass attributes to OpenImageIO,

Depends on the intent of the color cast. Say you're using a film emulation lut where the bright neutrals get mapped to a warm color, and the dark neutrals get mapped to a cool color. Having your

Yah, I looked into this implementation approach originally but didn't want to add too many virtuals before I knew exactly what was needed. But now that I see what fcns are actually being used, I'm

This is looking cool! I would be tempted to try and move some this into the base Op interface, mostly so in the future we can support plugin op optimisation if needed (moving truelight out as a plugin

I have some development under progress, not yet ready for review, but I thought it may interest people: https://github.com/imageworks/OpenColorIO/pull/218 During processor creation, this branch adds

Also FYI, I've been made a co-maintainer of yaml-cpp for Fedora so that should make things easier. Thanks, Richard