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.

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.

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.

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.

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.