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 point RV and Nuke at the same config and have it just work.

Regards
Alex

On Sat, Jun 23, 2012 at 5:48 AM, Tzuen Wu <tzue...@...> wrote:

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 LUTs, as well as being able to use the OCIO definition to set the context in which a  LUT is applied (Which we've been using the prelut for lin2log as an example)

For Nuke and 3D apps, we're using show definitions to communicate colorspace, although for the most part we are keeping to a complete linear workflow on the artist side.

Best,
Tzuen

On Jun 22, 2012, at 11:43 AM, Jim Hourihan wrote:

>
> 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.
>
> * Specifically for facilities that use OCIO with nuke or other software, how is file colorspace communicated to the application? Are you using sony's method of incorporating that meta data into the file name? Right now its looking like rv's source_setup would need to handle this but I'm probably missing something.
>
> * Beyond file data linearization and display correction what would the priority be of using OCIO for e.g. multiple looks, per-shot CDL, changing the context, etc.
>
> I also have a few questions for developers:
>
> * On the GPU path how is a prelut (aka shaper lut) generated and used? In the ociodisplay example's main it looks like there was an intention to have one but the example doesn't use it.
>
> * Is the GPU path fully functional compared to the CPU path?
>
>   -Jim
>
>