Date   

Review: OCIO::SetLoggingLevel(...) fix

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

https://github.com/imageworks/OpenColorIO/pull/223

SetLoggingLevel wasnt being obeyed, if set before initialization. Now it works.

- Jeremy


Re: OCIO + TuttleOFX

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

Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?

-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>

ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie









Re: OCIO + TuttleOFX

Marie Fétiveau <m...@...>
 

ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie








Re: OCIO + TuttleOFX

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

Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>

Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie







OCIO + TuttleOFX

Marie Fétiveau <m...@...>
 

Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie






Review: docs: ociobakelut, Photoshop ICC, looks

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

https://github.com/imageworks/OpenColorIO/pull/221

Committing Jeremy's Look docs. Also and documented ociobakelut usage, part of which somewhat escalated from "ociobakelut --format icc" to my experiences trying to make Photoshop match sane applications..


Re: Pre-Review: Op Collapsing

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

This is now ready for a real pull-request:

Internal image-procesing ops now go through a simple optimization framework as part of Processor creation. In this first code pass, ops that are exact inverses of their neighbors cancel out and are removed.


As far as I know, this code is good to go.  The matrix collapsing is not in yet, but I dont want to sit on what I've got thus far any longer.

-- Jeremy


yaml-cpp 0.3.0 updates submitted to Fedora

Richard Shaw <hobbe...@...>
 

Ok, yaml-cpp 0.3.0 is now on it's way through the QA system for Fedora.

Jeremy,

Do you have a specific date in mind to incorporate your yaml fork?

I have a fairly extensive patch to unbundle yaml-cpp, tinyxml, and
lcms and it would probably be a good idea to have your fork merged
since my patch will probably not be 100% acceptable as is and will
need some tweaking.

Thanks,
Richard


Review: ocioconvert: pass arbitrary attributes to OIIO

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

https://github.com/imageworks/OpenColorIO/pull/219

We've had reason to experiment with actually using ocioconvert in our
pipeline, but discovered that we needed to pass attributes to
OpenImageIO, largely to reduce bitdepths/image quality settings from the
maximum.

(Submitted on behalf of Peter Hillman)


Re: combining a File-Based LUT Transform and a Display Transform?

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

On Wed, Feb 1, 2012 at 10:29 AM, Brendan Bolles <bre...@...> wrote:
On Jan 30, 2012, at 12:19 PM, Jeremy Selan wrote:

> The downside is that in this approach you can have a color cast to the 'grayscale' output of 'r,g,b,l' modes (if the viewing transform doesnt map gray to gray), but this is not typically a concern in practice. (and is often desired anyways in some cases)


This is the thing that would seem the weirdest to me - looking at the red channel and seeing it have a color cast.  I'm not sure why that would ever be "desired".  The film look in the spi-vfx config makes a cast.  I'm pretty sure no other program does that.

Depends on the intent of the color cast.

Say you're using a film emulation lut where the bright neutrals get mapped to a warm color, and the dark neutrals get mapped to a cool color. Having your 'luma' mode to this too may look a bit odd.

But say your output device is a DCI P3 projector, where equal code values map to a very greenish white point.   Your output 3D lut may instead be mapping all values equally to a more pleasing white point, in which case if we '1d-ified' the luma mode all of a sudden you'd jump between the color and luma modes and the image would all of a sudden become greenish.


Consider a grayscale image, where you're toggling between luma mode and color mode.  Would the artist expect the image to change or not?  In the current implementation, they would appear identical.


At the same time, I agree that when you want to look at just the red channel, you probably want to see the image data pre-LUT.  Maybe a really smart implementation would do lin->log->red or lin->sRGB->red instead of lin->film->red when just the red channel was being viewed.

In the old SPI library (the internal predecessor to OCIO) when viewing individual channels we dynamically computed a version of the 3D viewing lut that didnt have any crosstalk. (which makes input equal code values always map to output equal code values) but this always felt a bit too magical for my tastes, and also looked weird on the DLP.. (greenish)


-- Jeremy

 

Brendan



Re: Pre-Review: Op Collapsing

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

Yah, I looked into this implementation approach originally but didn't want to add too many virtuals before I knew exactly what was needed.  But now that I see what fcns are actually being used, I'm fine with moving the functions that everyone implements (isSameType, isInverse) to the base.

In terms of future plugin support, I think that's a side issue anyways as this API is currently internal, and can be refactored in any way that proves needed going forward.

-- Jeremy


On Sat, Feb 4, 2012 at 4:57 AM, Malcolm Humphreys <malcolmh...@...> wrote:
This is looking cool!

I would be tempted to try and move some this into the base Op interface, mostly so in the future we can support plugin op optimisation if needed (moving truelight out as a plugin say).

maybe something like:
bool Op::isSameType(const OpRcPtr & op)
bool Op::isInverse(const OpRcPtr & op)
bool Op::combinable(const OpRcPtr & op)
OpRcPtr Op::combine(const OpRcPtr & op)

.malcolm

On 03/02/2012, at 11:14 PM, Jeremy Selan wrote:

I have some development under progress, not yet ready for review, but I thought it may interest people:
https://github.com/imageworks/OpenColorIO/pull/218

During processor creation, this branch adds an internal optimization pass that makes for more efficient color processing.
https://github.com/jeremyselan/OpenColorIO/blob/opt/src/core/OpOptimizers.cpp

But the most interesting consequence is that this allows for transforms which were not previously possible:

Say you have 2 colorspaces: A and B.  Both of these these colorspaces apply the same 3D lut, but B then also applies an additional matrix.

Previously, it would not have been possible to compute the processor to go directly from A to B because an inverse 3d lut is needed.
old op chain:   LUT3D (inv) -> LUT3D (forward) -> matrix

However, the new optimizer will detect that the same 3dlut is being applied in a row in both an inverse and forward direction, and they will cancel out! (This works even if the nesting is deep.)

new op chain: matrix

Remaining tasks:
- substantially more unit tests
- matrix concatenation.

-- Jeremy





Re: Pre-Review: Op Collapsing

Malcolm Humphreys <malcolmh...@...>
 

This is looking cool!

I would be tempted to try and move some this into the base Op interface, mostly so in the future we can support plugin op optimisation if needed (moving truelight out as a plugin say).

maybe something like:
bool Op::isSameType(const OpRcPtr & op)
bool Op::isInverse(const OpRcPtr & op)
bool Op::combinable(const OpRcPtr & op)
OpRcPtr Op::combine(const OpRcPtr & op)

.malcolm


On 03/02/2012, at 11:14 PM, Jeremy Selan wrote:

I have some development under progress, not yet ready for review, but I thought it may interest people:
https://github.com/imageworks/OpenColorIO/pull/218

During processor creation, this branch adds an internal optimization pass that makes for more efficient color processing.
https://github.com/jeremyselan/OpenColorIO/blob/opt/src/core/OpOptimizers.cpp

But the most interesting consequence is that this allows for transforms which were not previously possible:

Say you have 2 colorspaces: A and B.  Both of these these colorspaces apply the same 3D lut, but B then also applies an additional matrix.

Previously, it would not have been possible to compute the processor to go directly from A to B because an inverse 3d lut is needed.
old op chain:   LUT3D (inv) -> LUT3D (forward) -> matrix

However, the new optimizer will detect that the same 3dlut is being applied in a row in both an inverse and forward direction, and they will cancel out! (This works even if the nesting is deep.)

new op chain: matrix

Remaining tasks:
- substantially more unit tests
- matrix concatenation.

-- Jeremy




Pre-Review: Op Collapsing

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

I have some development under progress, not yet ready for review, but I thought it may interest people:
https://github.com/imageworks/OpenColorIO/pull/218

During processor creation, this branch adds an internal optimization pass that makes for more efficient color processing.
https://github.com/jeremyselan/OpenColorIO/blob/opt/src/core/OpOptimizers.cpp

But the most interesting consequence is that this allows for transforms which were not previously possible:

Say you have 2 colorspaces: A and B.  Both of these these colorspaces apply the same 3D lut, but B then also applies an additional matrix.

Previously, it would not have been possible to compute the processor to go directly from A to B because an inverse 3d lut is needed.
old op chain:   LUT3D (inv) -> LUT3D (forward) -> matrix

However, the new optimizer will detect that the same 3dlut is being applied in a row in both an inverse and forward direction, and they will cancel out! (This works even if the nesting is deep.)

new op chain: matrix

Remaining tasks:
- substantially more unit tests
- matrix concatenation.

-- Jeremy



Re: yaml-cpp

Richard Shaw <hobbe...@...>
 

Also FYI, I've been made a co-maintainer of yaml-cpp for Fedora so
that should make things easier.

Thanks,
Richard


Re: RV integration WIP

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







Linux windowing stack rework (long term)

Kai-Uwe Behrmann <ku...@...>
 

Hello dear colour experts,

Xorg and OpenICC will have a track on Fosdem next weekend[1]. Part of this will be presentations about colour management in compositing window managers and Wayland. The later is the upcoming new windowing system. On top of this shall run the traditional X11 protocol, which is currently used by all major Linux desktop systems.

In it's current early incarnation the Wayland prototype supports only 8-bit buffers. Their most concern is a fast desktop and potentially handheld experience combined with eye candy window compositing. A good thing is the new architecture targets at easier application to display synchronisation for video playback. Wayland is expected in the coming 3-5 years to appear on production systems. Once it is in place, it is likely to become mandatory inside the Linux displaying stack.

Now my questions to you.
What are fundamentials you want to see preserved to do your colour work?
Do you see a special need or desire, what could be improved regarding colour displaying on Linux? E.g. this could be speed concerns, the use of certain display technology or others topics.
What are your thoughts about colour management in this mix?

I would like to include your concerns into the expected discussion if fit.

kind regards
Kai-Uwe Behrmann
--
www.openicc.info


[1] http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012


Re: RV integration WIP

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







Re: RV integration WIP

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






Re: RV integration WIP

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


Re: yaml-cpp

Richard Shaw <hobbe...@...>
 

On Wed, Feb 1, 2012 at 11:14 AM, Jeremy Selan <jeremy...@...> wrote:
We're looking at 0.3.0  (which maintains the current yaml API).   I talked
to the developer, and the new API is a bit too in flux / untested to want to
jump to it in the short term.

I've got a branch of OCIO where I've been playing with 0.3.0:
https://github.com/jeremyselan/OpenColorIO/tree/yaml
I build my own yaml-cpp 0.3.0 packages tried your branch (it took me a
while to update my patch) but it now builds and pass the current tests
so that's promising.

Thanks,
Richard

1381 - 1400 of 2227