I would definitely go if there was one, and probably drag a couple colleagues with me. I don't have that much to present, as we're only just on the verge of rolling it into the new cycle of projects,

Team OpenColorIO, Is there interest in having an OCIO Birds of a Feather this year? Would you attend? I am not inclined to prepare a presentation (like the last two years), but if there is interest

Re-sending this review request (code by Brian Hall) https://github.com/imageworks/OpenColorIO/pull/278 - Enables GPU accelerated OCIO on iOS devices, including ipad. One interesting implementation

Thanks for the explanation Ben. I've made it so a component called "ocio_context" appearing in the node will cause a context to be used and initialized with string props that appear in there.

As far as I'm aware, the only interesting difference between the CPU and GPU paths is the GPU doesn't currently do tetrahedral 3D LUT interpolation (it'll fall back to

Excellent! I have OCIO in our build system and integrated into our (new) renderer so things are going well. I have some questions (below) Yes it makes sense. The one thing I'm missing here is how you

Super excited about getting RV support. Can't wait! Allow me to take a stab at some of your questions. This will probably be a lengthy reply... Per-shot CDLs / OCIO::Contexts are two sides of the

That's up to the user: krita can use the env var, or you can manually select a config file. yeah, it's part of the package. On centos5, the krita tarbal contains everything -- it's practically a

Hi Boudewijn, I've hooked a copy of this and will get it set up here so we can test it off. I assume the OCIO bits rely on the OCIO env var to find the correct profile(s)? Is OCIO rolled in, or do

This is up to date with git master of yesterday and includes the ocio-based lut docker. I tested on a clean centos5 64 bit vm and everything worked. To make the lut docker work, you need to have an

Thanks for the info everybody. Sounds like: * source_setup -> python (which is already in the queue) * per-shot looks (CDL, etc) So right now I'm thinking that anywhere rv currently has a LUT

+1 for per shot looks; we use them extensively. Right now we do this by baking all the looks out and having a package load the appropriate one into the Look LUT. We pull metadata from shotgun, so a

Hi Jim, That's great to hear - I was actually planning on asking someone at your end about this some time this week, but no longer! We have yet to properly get into OCIO here, but so many of the tools

We are using a modified version of source_setup. On that note, are there any plans to rewrite source_setup in Python rather than MU? Per shot looks are a priority for us. Ideally we would like to

Hi Jim, Really excited you're looking into this. Our main priorities with using OCIO in RV would definitely being able to combine several transformations into 'Looks' that work for per-shot CDLs and

Hi Jim, In our case, it's not embedded in the meta data of the filename but tied more generally to either the shot/sequence/show...we then modify the source_setup (as you had suspected) based on the

Hi all, I'm looking into full OCIO integration into an upcoming version of rv. I was wondering if people could describe some of their workflows and/or how they might want to use OCIO in rv ideally.

Dear Sir / Madam, Good Afternoon. Kindly give me a solution below mentioned mail. -- Thanks & Regards, ChellaSundar SR System Administrator EFX - Prasad Corporation Ltd.

Thanks, got it! -- Boudewijn Rempt

Sure: https://projects.kde.org/projects/calligra/repository/show?rev=krita-lut_docker-rempt . Big fat warning: first cut implemenation, it's cool and seems to work, but lots of cleaning up to do. The