RV integration WIP


dbr/Ben <dbr....@...>
 

I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
import ocio_rv_custom
except ImportError:
in_space = cfg. parseColorSpaceFromString(path)
else:
in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben


Jeremy Selan <jeremy...@...>
 

Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben


Jordan Soles <jor...@...>
 

Hi,

I use RV and would be happy to test the integration...just let me know.

Thanks,
Jordan

On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...> wrote:
Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben




--
JORDAN SOLES
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles






Jon Stanley <jonnys...@...>
 

I'd be happy to help with this too.

Jon


On 2 February 2012 12:10, Jordan Soles <jor...@...> wrote:
Hi,

I use RV and would be happy to test the integration...just let me know.

Thanks,
Jordan

On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...> wrote:
Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben




--
JORDAN SOLES
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles







Hugh Macdonald <hugh.ma...@...>
 

I'm using OCIO in Nuke at the moment, and am in the process of getting RV properly integrated into Nuke as a flipbooker. I'd certainly be interested in helping test.

Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com

On 2 Feb 2012, at 01:10, Jordan Soles wrote:

Hi,

I use RV and would be happy to test the integration...just let me know.

Thanks,
Jordan

On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...> wrote:
Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben




--
JORDAN SOLES
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles







georges...@...
 

So would I/we.

George - BlueBolt

On Thursday, 2 February 2012 11:07:13 UTC, Hugh Macdonald wrote:
I'm using OCIO in Nuke at the moment, and am in the process of getting RV properly integrated into Nuke as a flipbooker. I'd certainly be interested in helping test.

Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com

On 2 Feb 2012, at 01:10, Jordan Soles wrote:

Hi,

I use RV and would be happy to test the integration...just let me know.

Thanks,
Jordan

On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...> wrote:
Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben




--
JORDAN SOLES
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles







Alex Fry <ale...@...>
 

Very interested..

Especially in the handling of per shot looks..

-Alex

On Thursday, 2 February 2012 11:07:13 UTC, Hugh Macdonald wrote:

I'm using OCIO in Nuke at the moment, and am in the process of getting RV
properly integrated into Nuke as a flipbooker. I'd certainly be interested
in helping test.
Hugh Macdonald
*n**vizible** – VISUAL EFFECTS
*
hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708
www.nvizible.com
On 2 Feb 2012, at 01:10, Jordan Soles wrote:
Hi,
I use RV and would be happy to test the integration...just let me know.
Thanks,
Jordan
On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...>wrote:
Ben,
Thanks for working on adding RV support!  Very cool.
Are any OCIO users out there currently using RV? (and looking to help in
the integration testing?)
I dont use RV on a daily basis, but I'm sure some of you folks do... ;)
-- Jeremy
On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python
support is non-beta \o/
(I should qualify that with "thirdparty OCIO integration, as my
affiliation with Tweak is no more than "happy user"!)
Only the very basic functionality is there currently (applying a colour
transform a source), but the rest should be relatively straight forward:
https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py
https://github.com/imageworks/OpenColorIO/issues/109
There's some things I'm not sure about:
1. Most important question: what should the default shortcut for "change
view" be?
For example, we use "d" to cycle between the View's, "raw", "lin2log"
and "project"them
Should there be a shortcut for switching display devices, or is this
uncommon enough to just belong in the menu?
(I'll make sure the shortcuts can be customised by env-var or something)
2. How best to allow customising "what colourspace is this" and "what
context variables for this source" functions? Particularly the former for
facilities where the "parseColorSpaceFromString" method will not work
I was thinking just have simple callback functions along the lines of:
try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)
..although this isn't ideal
3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on
input, of course), so the exposure control acts correctly and so on.. Then
the "look LUT" (applied just before viewer) does a SCENE_LINEAR to
output-colorspace.
However the last part is probably 3D, and has no prelut, so values >1.0
get clipped.
To create the look-LUT, what series of colour-transforms should I
perform?
Currently it does:
- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)
Should I use the allocation vars to create a prelut? Or would I be
better using the input_space like ociobakelut uses the "--shaperspace"? I.e:
- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use
allocation vars)
- input_space to output_space
Hope that makes sense - basically I need to bake out 2 LUT's - one from
input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space
4. Maybe a question for Tweak support, although I think Jim and such are
on this list(?) - can RV menu items be dynamically added/removed?
I was thinking of having a "OCIO > Display Device" menu which lists
"Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw",
"lin2log" etc
The View menu would need recreated when you change display, as the lists
are not necessarily the same. Is this possible?
Mostly just curious - there's a bunch of other ways the menu could be
structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw",
"OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)
5. Beyond the basics of "looking at an image with the correct display
transform", what other features would people like to see from the RV/OCIO
integration (either sooner or later)?
- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new
display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO,
but would be fairly easy to export the exposure/saturation/offset/etc
values as CDL)
Err, this email is slightly longer than I intended..
- Ben
--
*JORDAN SOLES*
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles
www.rodeofx.com


nhatpho...@...
 

Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat


Jeremy Selan <jeremy...@...>
 

It's our understanding that RV 4.0 ships with OCIO built-in so you shouldn't need to compile it yourself.


Give that a shot, and let us know what you find?

-- Jeremy


On Tue, Aug 27, 2013 at 10:37 AM, <nhatpho...@...> wrote:
Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.