Date   

Re: Reversed transform for a OCIO::DisplayTransform

Joseph Slomka <joseph...@...>
 

Remember that colorspaces can be defined to and from the reference. You can manually define the inverse and come up with an inverse 3d lut for the color picker that is close enough to fully inverted.

I don't believe that OCIO inverts any 3d luts, even if you had a unity lut where rgb in = rgb out.

Typically the design of OCIO does not automatically do anything that will get you into trouble. You have to deliberately make those choices. 


Example code below.

-Joseph

cs = OCIO.ColorSpace(family='kodak',name='kdk2383')
cs.setDescription("kdk2383: Kodak Vision stock")
cs.setBitDepth(OCIO.Constants.BIT_DEPTH_UINT10)

# this sets the conversion to reference XYZ from film log
groupTransform = OCIO.GroupTransform()
groupTransform.push_back(OCIO.FileTransform('2383_to_bt1886.3dl',interpolation=OCIO.Constants.INTERP_LINEAR))
groupTransform.push_back(OCIO.ColorSpaceTransform(src='bt1886', dst='lxyz'))
cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_TO_REFERENCE)
config.addColorSpace(cs)

# this sets the conversion from reference XYZ to film log values
groupTransform = OCIO.GroupTransform()
groupTransform.push_back(OCIO.ColorSpaceTransform(src='lxyz', dst='bt1886'))
groupTransform.push_back(OCIO.FileTransform('bt1886_to_2383.3dl',interpolation=OCIO.Constants.INTERP_LINEAR))
cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_FROM_REFERENCE)
config.addColorSpace(cs)


On Fri, Apr 11, 2014 at 4:29 PM, Kevin Wheatley <kevin.j....@...> wrote:
As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a turning point which results in there being multiple cases where two values of x give y having the same value, when generalised into a 3D LUT this problem becomes even more difficult to invert in a general sense even in typical outputs this is not necessarily going to give you predictable outcomes (typical for a display transform emulating another device/output especially a subtractive one like film prints or other CMY(K) outputs). These 3D luts often feature gamut compression which is where a lot of the loss comes from.

In specific cases there can be techniques to invert, but these need hand selecting, which is probably why OCIO won't do it, something like Argyll CMS or another ICC profile tool might do something for you, which might be interesting to implement, alternatively the CTL code has a scattered data interpolation code that might work.

Kevin


On Fri, Apr 11, 2014 at 10:29 PM, Piotr Stanczyk <piotr.s...@...> wrote:
From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
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/d/optout.

--
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/d/optout.

--
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/d/optout.


Re: Reversed transform for a OCIO::DisplayTransform

Kevin Wheatley <kevin.j....@...>
 

As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a turning point which results in there being multiple cases where two values of x give y having the same value, when generalised into a 3D LUT this problem becomes even more difficult to invert in a general sense even in typical outputs this is not necessarily going to give you predictable outcomes (typical for a display transform emulating another device/output especially a subtractive one like film prints or other CMY(K) outputs). These 3D luts often feature gamut compression which is where a lot of the loss comes from.

In specific cases there can be techniques to invert, but these need hand selecting, which is probably why OCIO won't do it, something like Argyll CMS or another ICC profile tool might do something for you, which might be interesting to implement, alternatively the CTL code has a scattered data interpolation code that might work.

Kevin


On Fri, Apr 11, 2014 at 10:29 PM, Piotr Stanczyk <piotr.s...@...> wrote:
From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
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/d/optout.

--
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/d/optout.


Re: Reversed transform for a OCIO::DisplayTransform

Piotr Stanczyk <piotr.s...@...>
 

From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
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/d/optout.


Reversed transform for a OCIO::DisplayTransform

Dmitry Kazakov <dimu...@...>
 

Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov


Uses of OCIO Looks?

Rod Bogart <bog...@...>
 

If you are using Looks heavily (and successfully), I’d like to hear from you.

Currently, the documentation is somewhat inaccurate on the format of the definition and usage of Looks, so I’m wondering to what degree folks have taken advantage of them.

They seem to be a great way to build pipelines with intentional steps (i.e. separate operations for Neutral Grades and Primary Grades followed by an overall Show Look). The specification of process_space is super helpful to allow LUTs to operate on the kind of data they expect. And they can be applied with +/- to allow specific inversion setups. So, that’s all good.

Any info you can share would be appreciated: positive results, hassles, example configs, whatever.

Thanks in advance,
RGB


Re: Allow config's context to be replaced?

Nathan Rusch <natha...@...>
 

Ah cool, that could be quite handy.

Just for posterity, the biggest problem with trying to take a dynamic approach in Nuke is timing. Ideally, when a user opens a script, one would be able to look at the incoming script path, decide what config they need, load it into the process environment, and then proceed to load the script. However, because the `onScriptLoad` callback currently runs after all of the nodes being loaded from the script have been created, swapping out the config will screw up any saved knob values on config-dependent OCIO nodes.

I've requested the current callback be broken into beforeScriptLoad and afterScriptLoad callbacks, but I'm not very optimistic about a change like that ever being implemented. It's possible to handle most of the cases where switching is required by monkey-patching nuke.scriptOpen with your own function and handling things in there, but in the end, the $OCIO environment variable is the only foolproof way to go.


-Nathan


On Thursday, February 6, 2014 7:21:45 PM UTC-8, Jeremy Selan wrote:
Cool.

In the medium term, we hope to do a cleanup of the OCIO API to make it
easy to install as a system library in a binary compatible manner.
That way, should similar circumstances arise again you could just load
the latest OCIO on your system and then move the library that ships
with the commercial app out of the way.

If memory serves, Mari ships with a recent OpenColorIO.so, so if you
have an install of that it would probably work to copy the .so from
Mari into the Nuke install.

-- Jeremy

On Thu, Feb 6, 2014 at 6:24 PM, Nathan Rusch <nath...@...> wrote:
> Foundry bug ID is 40576 in case anyone comes across this later and wants to
> poke them about it.
>
>
>
> On Thursday, February 6, 2014 9:54:26 AM UTC-8, Nathan Rusch wrote:
>>
>> Thanks Jeremy. Good to know I'm not missing something.
>>
>> Unfortunately The Foundry have a tendency to drag their feet when it comes
>> to updating third-party libraries, so they're still shipping OCIO 1.0.7
>> (even in Nuke 8... a little disappointing). I've got a request in with them,
>> and I'll throw the reference number in this thread once I get one back in
>> case anyone else wants to help apply more pressure. Tweak also seem to be
>> using 1.0.7 in RV 4 as well.
>>
>> Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it
>> looks like I may be stuck with replacing the config outright or swapping out
>> the OCIO libraries that ship with Nuke. I'll hold out hope for the future
>> though...
>>
>> Thanks again for the info.
>>
>>
>> -Nathan
>>
>>
>> On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:
>>>
>>> It was definitely our intent to have a setCurrentContext, that looks
>>> like an oversight.
>>>
>>> In the meantime, can you see if your config object has a
>>> "addEnvironmentVar" option?  This was introduced rather recently, so I
>>> am not sure if it's available in Nuke, but this would allow you to
>>> modify value of existing entries in the context, and also add new
>>> ones).
>>>
>>> -- Jeremy
>>>
>>> On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <nath...@...> wrote:
>>> > Hey all,
>>> >
>>> > I'm wondering if there has been any thought or discussion internally
>>> > about
>>> > allowing a config's Context to be replaced in place. I've been looking
>>> > at
>>> > ways to change the context variables of the active config on the fly
>>> > using
>>> > the Python bindings, and actually having them affect the existing
>>> > processing
>>> > environment, but after perusing the library and binding sources, it
>>> > seems
>>> > there isn't any way to do this currently.
>>> >
>>> > Some of the machinery is already there: You can get an editable copy of
>>> > the
>>> > active config's current context and modify its context variables to
>>> > your
>>> > heart's content. However, at that point, there isn't really anything
>>> > useful
>>> > you can do with that object unless you're actually doing color
>>> > processing
>>> > yourself. I was hoping to find a way to inject the updated context back
>>> > into
>>> > the currently active config via Python, to affect all future processor
>>> > lookups within Nuke, but there's a distinct lack of symmetry to the
>>> > interface in that regard.
>>> >
>>> > What I'm hoping for:
>>> >
>>> > config = ocio.GetCurrentConfig()
>>> > ctx = config.getCurrentContext().createEditableCopy()
>>> > ctx.setStringVar('FOO', 'BAR')
>>> > config.setCurrentContext(ctx)  # <-- The missing link
>>> >
>>> > Unless I'm mistaken, the only way to do something like this right now
>>> > (at
>>> > either the C++ or Python level) would be to modify the process
>>> > environment
>>> > (not ideal), and then call
>>> > ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels...
>>> > dirty.
>>> >
>>> > Now, I'm guessing this isn't the first time you've crossed paths with
>>> > an
>>> > idea like this, so I feel like it's worth asking: Am I overlooking
>>> > something
>>> > blatantly obvious here? I've done my best to sniff out any existing
>>> > functionality like this, but haven't found anything. However, if this
>>> > is in
>>> > fact a nonexistent feature, I'm wondering if there is a specific reason
>>> > for
>>> > excluding it, and if you would be willing to consider adding it in the
>>> > future.
>>> >
>>> > Thanks for any information,
>>> >
>>> > -Nathan
>>> >
>>> > P.S. In the case of Nuke, I know it's possible to work around this
>>> > using
>>> > node-level context overrides and making Nuke do the environment lookups
>>> > for
>>> > you using TCL, but that's far from an ideal solution when a simple
>>> > context
>>> > replacement would let me do the same thing much more cleanly (and
>>> > doesn't
>>> > address other applications).
>>> >
>>> > --
>>> > 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-d...@....
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


Re: OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Agreed.  I inserted unistd.h above the #elif, and it compiles fine on 10.9.

RGB

On Feb 9, 2014, at 5:23 PM, Colin Doncaster <colin.d...@...> wrote:

It looks like PathUtils.cpp needs unistd.h included.  

Looking at the source there’s:

#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
#include <unistd.h>
extern char **environ;
#endif

so I’m not too sure how one would want to rework those conditionals. 

Mavericks headers are closer to Linux now, there’s a few projects I’ve rebuilt now that require the __APPLE__ defines to compile. 

Cheers

On Feb 8, 2014, at 6:14 PM, Rod Bogart <bog...@...> wrote:

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB

--
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.


--
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.


Re: OSX 10.9 compile expectations?

Colin Doncaster <colin.d...@...>
 

It looks like PathUtils.cpp needs unistd.h included.  

Looking at the source there’s:

#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
#include <unistd.h>
extern char **environ;
#endif

so I’m not too sure how one would want to rework those conditionals. 

Mavericks headers are closer to Linux now, there’s a few projects I’ve rebuilt now that require the __APPLE__ defines to compile. 

Cheers

On Feb 8, 2014, at 6:14 PM, Rod Bogart <bog...@...> wrote:

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB

--
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.


Re: Digest for ocio...@googlegroups.com - 3 Messages in 1 Topic

Joseph Goldstone <jgold...@...>
 


On Feb 9, 2014, at 12:43 PM, <ocio...@...> <ocio...@...> wrote:


No, but 338 does:


Rod, if you can have a go at this, it would be much appreciated; I’ve lived in a Mac monoculture for so long that I have no clue how to produce modern portable headers.

—joseph


Re: OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Thanks.

Yes, it is the master branch. I have not yet spent time on the fix, but I believe you are correct; it should just be headers.

RGB

On Feb 8, 2014, at 4:46 PM, Jeremy Selan <jeremy...@...> wrote:

I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
I can't test this at home. (Sounds like a good weekend project
though).

When I browse the open issues list,
https://github.com/imageworks/OpenColorIO/issues?state=open

there is a topic for compiliation problems on 10.9,
https://github.com/imageworks/OpenColorIO/issues/340

but it doesn't mention getcwd.

I'm not sure how you did the git checkout, but can you confirm if
you're on master or instead the tagged 1.0.9 release? The sha for
master is 63c6bde2, the sha for 1.0.9 is 2b12063e22

We'd very much welcome a patch if you'd like to take a stab at getting
this working. (probably a simple header fix?) :)

-- Jeremy

On Sat, Feb 8, 2014 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
"Clone in Desktop" to download software
Cmake (with defaults) to populate build dir
cd build
make
[ 38%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error:
no member named 'getcwd' in the global namespace
::getcwd(path, MAXPATHLEN);
~~^
1 error generated.

Will continue to debug, but thought I'd ask if someone has been here first...

RGB

--
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.
--
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.


Re: OSX 10.9 compile expectations?

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

I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
I can't test this at home. (Sounds like a good weekend project
though).

When I browse the open issues list,
https://github.com/imageworks/OpenColorIO/issues?state=open

there is a topic for compiliation problems on 10.9,
https://github.com/imageworks/OpenColorIO/issues/340

but it doesn't mention getcwd.

I'm not sure how you did the git checkout, but can you confirm if
you're on master or instead the tagged 1.0.9 release? The sha for
master is 63c6bde2, the sha for 1.0.9 is 2b12063e22

We'd very much welcome a patch if you'd like to take a stab at getting
this working. (probably a simple header fix?) :)

-- Jeremy

On Sat, Feb 8, 2014 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
"Clone in Desktop" to download software
Cmake (with defaults) to populate build dir
cd build
make
[ 38%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error:
no member named 'getcwd' in the global namespace
::getcwd(path, MAXPATHLEN);
~~^
1 error generated.

Will continue to debug, but thought I'd ask if someone has been here first...

RGB

--
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.


OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB


Re: Allow config's context to be replaced?

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

Cool.

In the medium term, we hope to do a cleanup of the OCIO API to make it
easy to install as a system library in a binary compatible manner.
That way, should similar circumstances arise again you could just load
the latest OCIO on your system and then move the library that ships
with the commercial app out of the way.

If memory serves, Mari ships with a recent OpenColorIO.so, so if you
have an install of that it would probably work to copy the .so from
Mari into the Nuke install.

-- Jeremy

On Thu, Feb 6, 2014 at 6:24 PM, Nathan Rusch <natha...@...> wrote:
Foundry bug ID is 40576 in case anyone comes across this later and wants to
poke them about it.



On Thursday, February 6, 2014 9:54:26 AM UTC-8, Nathan Rusch wrote:

Thanks Jeremy. Good to know I'm not missing something.

Unfortunately The Foundry have a tendency to drag their feet when it comes
to updating third-party libraries, so they're still shipping OCIO 1.0.7
(even in Nuke 8... a little disappointing). I've got a request in with them,
and I'll throw the reference number in this thread once I get one back in
case anyone else wants to help apply more pressure. Tweak also seem to be
using 1.0.7 in RV 4 as well.

Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it
looks like I may be stuck with replacing the config outright or swapping out
the OCIO libraries that ship with Nuke. I'll hold out hope for the future
though...

Thanks again for the info.


-Nathan


On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:

It was definitely our intent to have a setCurrentContext, that looks
like an oversight.

In the meantime, can you see if your config object has a
"addEnvironmentVar" option? This was introduced rather recently, so I
am not sure if it's available in Nuke, but this would allow you to
modify value of existing entries in the context, and also add new
ones).

-- Jeremy

On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <nath...@...> wrote:
Hey all,

I'm wondering if there has been any thought or discussion internally
about
allowing a config's Context to be replaced in place. I've been looking
at
ways to change the context variables of the active config on the fly
using
the Python bindings, and actually having them affect the existing
processing
environment, but after perusing the library and binding sources, it
seems
there isn't any way to do this currently.

Some of the machinery is already there: You can get an editable copy of
the
active config's current context and modify its context variables to
your
heart's content. However, at that point, there isn't really anything
useful
you can do with that object unless you're actually doing color
processing
yourself. I was hoping to find a way to inject the updated context back
into
the currently active config via Python, to affect all future processor
lookups within Nuke, but there's a distinct lack of symmetry to the
interface in that regard.

What I'm hoping for:

config = ocio.GetCurrentConfig()
ctx = config.getCurrentContext().createEditableCopy()
ctx.setStringVar('FOO', 'BAR')
config.setCurrentContext(ctx) # <-- The missing link

Unless I'm mistaken, the only way to do something like this right now
(at
either the C++ or Python level) would be to modify the process
environment
(not ideal), and then call
ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels...
dirty.

Now, I'm guessing this isn't the first time you've crossed paths with
an
idea like this, so I feel like it's worth asking: Am I overlooking
something
blatantly obvious here? I've done my best to sniff out any existing
functionality like this, but haven't found anything. However, if this
is in
fact a nonexistent feature, I'm wondering if there is a specific reason
for
excluding it, and if you would be willing to consider adding it in the
future.

Thanks for any information,

-Nathan

P.S. In the case of Nuke, I know it's possible to work around this
using
node-level context overrides and making Nuke do the environment lookups
for
you using TCL, but that's far from an ideal solution when a simple
context
replacement would let me do the same thing much more cleanly (and
doesn't
address other applications).

--
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-d...@....
For more options, visit https://groups.google.com/groups/opt_out.
--
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.


Re: Allow config's context to be replaced?

Nathan Rusch <natha...@...>
 

Foundry bug ID is 40576 in case anyone comes across this later and wants to poke them about it.


On Thursday, February 6, 2014 9:54:26 AM UTC-8, Nathan Rusch wrote:
Thanks Jeremy. Good to know I'm not missing something.

Unfortunately The Foundry have a tendency to drag their feet when it comes to updating third-party libraries, so they're still shipping OCIO 1.0.7 (even in Nuke 8... a little disappointing). I've got a request in with them, and I'll throw the reference number in this thread once I get one back in case anyone else wants to help apply more pressure. Tweak also seem to be using 1.0.7 in RV 4 as well.

Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it looks like I may be stuck with replacing the config outright or swapping out the OCIO libraries that ship with Nuke. I'll hold out hope for the future though...

Thanks again for the info.


-Nathan


On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:
It was definitely our intent to have a setCurrentContext, that looks
like an oversight.

In the meantime, can you see if your config object has a
"addEnvironmentVar" option?  This was introduced rather recently, so I
am not sure if it's available in Nuke, but this would allow you to
modify value of existing entries in the context, and also add new
ones).

-- Jeremy

On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <nath...@...> wrote:
> Hey all,
>
> I'm wondering if there has been any thought or discussion internally about
> allowing a config's Context to be replaced in place. I've been looking at
> ways to change the context variables of the active config on the fly using
> the Python bindings, and actually having them affect the existing processing
> environment, but after perusing the library and binding sources, it seems
> there isn't any way to do this currently.
>
> Some of the machinery is already there: You can get an editable copy of the
> active config's current context and modify its context variables to your
> heart's content. However, at that point, there isn't really anything useful
> you can do with that object unless you're actually doing color processing
> yourself. I was hoping to find a way to inject the updated context back into
> the currently active config via Python, to affect all future processor
> lookups within Nuke, but there's a distinct lack of symmetry to the
> interface in that regard.
>
> What I'm hoping for:
>
> config = ocio.GetCurrentConfig()
> ctx = config.getCurrentContext().createEditableCopy()
> ctx.setStringVar('FOO', 'BAR')
> config.setCurrentContext(ctx)  # <-- The missing link
>
> Unless I'm mistaken, the only way to do something like this right now (at
> either the C++ or Python level) would be to modify the process environment
> (not ideal), and then call
> ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty.
>
> Now, I'm guessing this isn't the first time you've crossed paths with an
> idea like this, so I feel like it's worth asking: Am I overlooking something
> blatantly obvious here? I've done my best to sniff out any existing
> functionality like this, but haven't found anything. However, if this is in
> fact a nonexistent feature, I'm wondering if there is a specific reason for
> excluding it, and if you would be willing to consider adding it in the
> future.
>
> Thanks for any information,
>
> -Nathan
>
> P.S. In the case of Nuke, I know it's possible to work around this using
> node-level context overrides and making Nuke do the environment lookups for
> you using TCL, but that's far from an ideal solution when a simple context
> replacement would let me do the same thing much more cleanly (and doesn't
> address other applications).
>
> --
> 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-d...@....
> For more options, visit https://groups.google.com/groups/opt_out.


Re: Allow config's context to be replaced?

Nathan Rusch <natha...@...>
 

Thanks Jeremy. Good to know I'm not missing something.

Unfortunately The Foundry have a tendency to drag their feet when it comes to updating third-party libraries, so they're still shipping OCIO 1.0.7 (even in Nuke 8... a little disappointing). I've got a request in with them, and I'll throw the reference number in this thread once I get one back in case anyone else wants to help apply more pressure. Tweak also seem to be using 1.0.7 in RV 4 as well.

Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it looks like I may be stuck with replacing the config outright or swapping out the OCIO libraries that ship with Nuke. I'll hold out hope for the future though...

Thanks again for the info.


-Nathan


On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:
It was definitely our intent to have a setCurrentContext, that looks
like an oversight.

In the meantime, can you see if your config object has a
"addEnvironmentVar" option?  This was introduced rather recently, so I
am not sure if it's available in Nuke, but this would allow you to
modify value of existing entries in the context, and also add new
ones).

-- Jeremy

On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <nath...@...> wrote:
> Hey all,
>
> I'm wondering if there has been any thought or discussion internally about
> allowing a config's Context to be replaced in place. I've been looking at
> ways to change the context variables of the active config on the fly using
> the Python bindings, and actually having them affect the existing processing
> environment, but after perusing the library and binding sources, it seems
> there isn't any way to do this currently.
>
> Some of the machinery is already there: You can get an editable copy of the
> active config's current context and modify its context variables to your
> heart's content. However, at that point, there isn't really anything useful
> you can do with that object unless you're actually doing color processing
> yourself. I was hoping to find a way to inject the updated context back into
> the currently active config via Python, to affect all future processor
> lookups within Nuke, but there's a distinct lack of symmetry to the
> interface in that regard.
>
> What I'm hoping for:
>
> config = ocio.GetCurrentConfig()
> ctx = config.getCurrentContext().createEditableCopy()
> ctx.setStringVar('FOO', 'BAR')
> config.setCurrentContext(ctx)  # <-- The missing link
>
> Unless I'm mistaken, the only way to do something like this right now (at
> either the C++ or Python level) would be to modify the process environment
> (not ideal), and then call
> ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty.
>
> Now, I'm guessing this isn't the first time you've crossed paths with an
> idea like this, so I feel like it's worth asking: Am I overlooking something
> blatantly obvious here? I've done my best to sniff out any existing
> functionality like this, but haven't found anything. However, if this is in
> fact a nonexistent feature, I'm wondering if there is a specific reason for
> excluding it, and if you would be willing to consider adding it in the
> future.
>
> Thanks for any information,
>
> -Nathan
>
> P.S. In the case of Nuke, I know it's possible to work around this using
> node-level context overrides and making Nuke do the environment lookups for
> you using TCL, but that's far from an ideal solution when a simple context
> replacement would let me do the same thing much more cleanly (and doesn't
> address other applications).
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


Re: Allow config's context to be replaced?

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

It was definitely our intent to have a setCurrentContext, that looks
like an oversight.

In the meantime, can you see if your config object has a
"addEnvironmentVar" option? This was introduced rather recently, so I
am not sure if it's available in Nuke, but this would allow you to
modify value of existing entries in the context, and also add new
ones).

-- Jeremy

On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <natha...@...> wrote:
Hey all,

I'm wondering if there has been any thought or discussion internally about
allowing a config's Context to be replaced in place. I've been looking at
ways to change the context variables of the active config on the fly using
the Python bindings, and actually having them affect the existing processing
environment, but after perusing the library and binding sources, it seems
there isn't any way to do this currently.

Some of the machinery is already there: You can get an editable copy of the
active config's current context and modify its context variables to your
heart's content. However, at that point, there isn't really anything useful
you can do with that object unless you're actually doing color processing
yourself. I was hoping to find a way to inject the updated context back into
the currently active config via Python, to affect all future processor
lookups within Nuke, but there's a distinct lack of symmetry to the
interface in that regard.

What I'm hoping for:

config = ocio.GetCurrentConfig()
ctx = config.getCurrentContext().createEditableCopy()
ctx.setStringVar('FOO', 'BAR')
config.setCurrentContext(ctx) # <-- The missing link

Unless I'm mistaken, the only way to do something like this right now (at
either the C++ or Python level) would be to modify the process environment
(not ideal), and then call
ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty.

Now, I'm guessing this isn't the first time you've crossed paths with an
idea like this, so I feel like it's worth asking: Am I overlooking something
blatantly obvious here? I've done my best to sniff out any existing
functionality like this, but haven't found anything. However, if this is in
fact a nonexistent feature, I'm wondering if there is a specific reason for
excluding it, and if you would be willing to consider adding it in the
future.

Thanks for any information,

-Nathan

P.S. In the case of Nuke, I know it's possible to work around this using
node-level context overrides and making Nuke do the environment lookups for
you using TCL, but that's far from an ideal solution when a simple context
replacement would let me do the same thing much more cleanly (and doesn't
address other applications).

--
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.


Allow config's context to be replaced?

Nathan Rusch <natha...@...>
 

Hey all,

I'm wondering if there has been any thought or discussion internally about allowing a config's Context to be replaced in place. I've been looking at ways to change the context variables of the active config on the fly using the Python bindings, and actually having them affect the existing processing environment, but after perusing the library and binding sources, it seems there isn't any way to do this currently.

Some of the machinery is already there: You can get an editable copy of the active config's current context and modify its context variables to your heart's content. However, at that point, there isn't really anything useful you can do with that object unless you're actually doing color processing yourself. I was hoping to find a way to inject the updated context back into the currently active config via Python, to affect all future processor lookups within Nuke, but there's a distinct lack of symmetry to the interface in that regard.

What I'm hoping for:

config = ocio.GetCurrentConfig()
ctx = config.getCurrentContext().createEditableCopy()
ctx.setStringVar('FOO', 'BAR')
config.setCurrentContext(ctx)  # <-- The missing link


Unless I'm mistaken, the only way to do something like this right now (at either the C++ or Python level) would be to modify the process environment (not ideal), and then call ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty.

Now, I'm guessing this isn't the first time you've crossed paths with an idea like this, so I feel like it's worth asking: Am I overlooking something blatantly obvious here? I've done my best to sniff out any existing functionality like this, but haven't found anything. However, if this is in fact a nonexistent feature, I'm wondering if there is a specific reason for excluding it, and if you would be willing to consider adding it in the future.

Thanks for any information,

-Nathan

P.S. In the case of Nuke, I know it's possible to work around this using node-level context overrides and making Nuke do the environment lookups for you using TCL, but that's far from an ideal solution when a simple context replacement would let me do the same thing much more cleanly (and doesn't address other applications).


Re: OCIO 1.0.9 released

"Matteo F. Vescovi" <mfve...@...>
 

Hi again!

On 2014-01-17 at 17:33, Matteo F. Vescovi <mfve...@...> wrote:
Actually, this version FTBFS as you can see at [1].
[1] is now attached to avoid unavailability due to build machine
refresh.

Former versions didn't have this kind of problem.
Is there any change I should care about?
So, any advice?

TIA.


--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A
Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUu
YXNjIg0KQ29udGVudC1EZXNjcmlwdGlvbjogRGlnaXRhbCBzaWduYXR1cmUNCg0KLS0tLS1CRUdJ
TiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMjIgKEdOVS9MaW51eCkN
CkNvbW1lbnQ6IERlYmlhbiBwb3dlcmVkIQ0KDQppUUljQkFFQkNBQUdCUUpTNjhtQ0FBb0pFS1VH
TmJ5L0FsZHNjYkVRQUorNXN0dDRqZlpNNmJUZ0hCSGtFVFg1DQo2N2FSUERxRWhwT2NWS2psK1V5
alozcDRESEZsMjFmYzUxemtKZ2FiNkhOeEFSUk8vYjB3NStmbjdFTHJnajBHDQpNR1NsQ0JxbERD
VmI1RVEvZ2xxeEcxV0VKWDVPUHhtbHpQc0VJd0k2SGlTSkE5dnRGNHJBdEc5WXhpTlg3czdZDQpL
M2w0bVJqdWlHSnVRd21HSGppNzdpa1pWMzBLQ2N0dU54QWVKdjM1SVFRTzRTeTlKWDZNVnA1bHhs
dXQ5aXZuDQpYMzh1QWx0dTZDYmlmaE81a1JYekh1MWtOTUw3dFI2MXlvRHJHZ3hjOVVmU2loSlg5
N0VCWEZ3Ulg1eXhyalBQDQpTbTB6N05oTWIwYktyTUM2MTUrdXBhcmMyOGVVMVV2NnNMbllTczh6
Uk9qNlliNEs2Y2o4RlczMzJjMDIxTktsDQpqUXVZZ0pIdXBic0lwekpXOHhjTHoyUU9XNStrWURo
d0hSN01PRG9LM3MyZmdKbVJGYUdpNHRjUXJYQ0pHdkFQDQpFUVJUekJVVmJOeEVDbjAzWVZZTGlu
Z1pacDB4STZiOVpURmdIUy9uN3pBK1RZZWJDRGFJK1pDcHhoMXlON2pMDQpVaHlGeEtyWUZ3S2h3
UTFkaUVsMVdDS21nRXVwVkhIcnlHSGo5SEIzY3NKcFJBMWlpekc2MktFSkxVRjliVDB3DQpGajQ2
VjlOdmpacjVEalp6N1BUckJsU2wrSzQ5VkhFaE5odThLZFh1ek0ybDVEdUo5dUp4MzBoVmhUeSs2
VW1IDQptenFYb3lpQkJXLzIxcXlhVEJPSnBKRHBZbk55djBndFNSTndwaEJrdisrekh0WHJBUnEz
VWNVN3VnOTg0cmQvDQpkb2NUY1NESFlMTWw4aU9MV2lpeg0KPTZOdG4NCi0tLS0tRU5EIFBHUCBT
SUdOQVRVUkUtLS0tLQ0K


Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

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

Hi Matteo can you checkout https://github.com/imageworks/OpenColorIO/pull/345 and see if this solves the issue for building against yaml-cpp-0.5.x? before we merge this into master.

.malcolm


On 12/12/2013, at 2:41 PM, Matteo F. Vescovi wrote:

Hi!

On Tue, Sep 24, 2013 at 03:42:15PM +0200, Matteo F. Vescovi wrote:
Hi!

On Mon, Sep 23, 2013 at 10:03:32PM +0200, Matteo F. Vescovi wrote:
Gonna check it tomorrow afternoon CET ;-)

Just tested and added a link to buildlog in #318 issue.

Any news on this front? OCIO is stuck to v1.0.8 in Debian because we
already have yaml-cpp 0.5.x in sid/unstable suite and now OCIO is ftbfs
against this new version.
Could you possibly let me know what's the plan here?

Thanks in advance.

Cheers.

--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A

--
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.


Re: An Academy Award for OpenColorIO!

Andrew Britton <andrew.d...@...>
 

Congrats and great job!

- this message sent using an e-approved device

901 - 920 of 2201