Re: rv integration

Hugh Macdonald <>

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 use support it (Nuke, Mari, Silhouette, OIIO (for command-line)) that having RV do the same thing would be perfect in terms of keeping a nice consistent colour pipeline across the board.

I can't help you out with specific examples of how we'd want to use it, as we don't necessarily use it properly yet, but I just wanted to chuck out another vote of "yes please" from here.


Hugh Macdonald

+44(0) 20 3167 3860
+44(0) 7773 764 708

On 25 June 2012 00:32, Alex - <ale...@...> wrote:
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.


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.


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

D I S C L A I M E R : This email and any files transmitted with it are intended solely for the intended addressee, and may contain confidential information or material protected by law, copyright or other legislation.  If you have received this message in error, please return it to the sender or notify the sender by calling +44 (0)20 3167 3860, and immediately and permanently delete it. You should not copy it or use it for any purpose, nor disclose its contents to any other person. Only the intended recipient may place any reliance upon it. Nvizible Limited accepts no responsibility or liability for emails sent by its employees or personnel which are not sent in the course of its business or that of its clients.
Nvizible Limited, 3 Richfield Avenue, Richfield Place, Reading, Berkshire, RG1 8EQ .  Registered in England & Wales with Company Number: 6900121

Join to automatically receive all group messages.