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

Oh, and also note that OCIO ships with some example images, http://code.google.com/p/opencolorio/downloads/detail?name=ocio-images.1.0v4.tgz if you'd like to confirm the color processing is working

Boudewijn, Kudos on the quick integration again! Can I see the code? Is there a repo you can point us to? Looking further at your example screenshot, I notice that you have gamma set to 2.2, and

Congrats! I can't wait to download it and give it a test. We'll certainly update opencolorio.org and list Krita! :) -- Jeremy

Oh, and being very cheeky... I wouldn't mind Krita being in the list with compatible software. Here's a patch with a draft :-) -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org,

Oh my goodness! That was fast! We'll pick up this branch and put it through its paces. Then once we've bashed it around enough it may be safer to decide to merge into the trunk. What do you think? On

Hi! So... Basically Krita now supports OpenColoriO :-). I've used the display example as suggested and implemented both the CPU and the GPU path. Everything seems to be working fine, and fast. See

The docs you link to are an outdated version on my fork of the project (the domain being dbr.github.com), the up-to-date docs are at: http://opencolorio.org/ Richard - the Truelight thing you refer to