Date   

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


Re: An Academy Award for OpenColorIO!

Larry Gritz <l...@...>
 

Woot!



Jeremy Selan <jere...@...> wrote:

Woo-hoo!  I can't think of a better way to start 2014. :)

It goes without saying that OCIO is a community effort so I'd like to
give a *huge* thanks to all the developers, users, and overall
supporters who have helped make OCIO the success it's been. And kudos
to Rob, of course, for allowing us to open source it in the first
place. ;)

Also, hats off the the ASC-CDL developers! It's great to see multiple
color awards this year.

Cheers,
Jeremy

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: An Academy Award for OpenColorIO!

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

Woo-hoo! I can't think of a better way to start 2014. :)

It goes without saying that OCIO is a community effort so I'd like to
give a *huge* thanks to all the developers, users, and overall
supporters who have helped make OCIO the success it's been. And kudos
to Rob, of course, for allowing us to open source it in the first
place. ;)

Also, hats off the the ASC-CDL developers! It's great to see multiple
color awards this year.

Cheers,
Jeremy


Re: OCIO 1.0.9 released

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

Hi!

On Mon, Sep 23, 2013 at 01:00:37PM -0700, Jeremy Selan wrote:
I've just tagged the latest OCIO master as 1.0.9. There had been a
bunch of bugfixes in there, and it had been hurting our distros to not
have a tagged release with the lates.
Actually, this version FTBFS as you can see at [1].

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

Thanks in advance.

Cheers.


[1] http://debomatic-amd64.debian.net/unstable/pool/opencolorio_1.0.9~dfsg0-1/opencolorio_1.0.9~dfsg0-1.buildlog

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


Re: Force a refresh of context variables?

Mark Visser <mvi...@...>
 

On Monday, January 13, 2014 6:35:29 PM UTC-5, dbr/Ben wrote:
If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

Brilliant, I hadn't thought of that. Just stuck that into our viewer process gizmos and it works like charm.

I wasn't aware of the metadata trick, neat.

cheers,
-Mark


Re: Force a refresh of context variables?

Ashley Retallack <ashl...@...>
 

Or you can save the context data in metadata (if the import format supports it, like exr).

and use:

key1:SHOT
value1:[metadata "look"]


this will make it possible to do different looks based on the actual footage, rather than just an environment set during or before launching Nuke.


On 13 January 2014 23:35, dbr/Ben <dbr....@...> wrote:
If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

key1: SHOT
value1: [getenv SHOT]

..etc, then it will dynamically pick up changes to the SHOT env-var (without embedding the actual SHOT value in the Nuke nodes)

- Ben

On 14 Jan 2014, at 9:22, Mark Visser <mvi...@...> wrote:

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark

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



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: Force a refresh of context variables?

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

If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

key1: SHOT
value1: [getenv SHOT]

..etc, then it will dynamically pick up changes to the SHOT env-var (without embedding the actual SHOT value in the Nuke nodes)

- Ben

On 14 Jan 2014, at 9:22, Mark Visser <mvi...@...> wrote:

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark

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


Force a refresh of context variables?

Mark Visser <mvi...@...>
 

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark


Re: An Academy Award for OpenColorIO!

Andrew Hunter <and...@...>
 

Congratulations Jeremy! 


On Thu, Jan 9, 2014 at 9:10 PM, Dithermaster <dither...@...> wrote:
Congratulations Jeremy and everyone who was contributed to, supports, and uses OpenColorIO! Very well deserved.



On Thu, Jan 9, 2014 at 2:17 PM, Adam Martinez <amarti...@...> wrote:
Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
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.

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


Any new release planned?

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

I was asked by a user to rebuild OpenColorIO with OpenImageIO as a dependency so the additional cli tools are built. I didn't do this originally because I didn't want them mutually dependent on each other but it's not too much of a hassle so I'm working on it.

It's not a big deal to just rebuild OCIO with the new build requirement but I figured it might be worth checking to see if any new release is in the works before going to the trouble.

Thanks,
Richard


Re: An Academy Award for OpenColorIO!

Dithermaster <dither...@...>
 

Congratulations Jeremy and everyone who was contributed to, supports, and uses OpenColorIO! Very well deserved.



On Thu, Jan 9, 2014 at 2:17 PM, Adam Martinez <amarti...@...> wrote:
Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
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: An Academy Award for OpenColorIO!

Adam Martinez <amarti...@...>
 

Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

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


Re: An Academy Award for OpenColorIO!

Boudewijn Rempt <bo...@...>
 

Awesome!

On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on�OpenColorIO�at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.
From the press release:

To�Jeremy Selan�for the development of the�OpenColorIO�color�management framework.�
OpenColorIO�is an�open�source framework that enables consistent�color�visualization of motion picture imagery across multiple facilities and numerous software applications.
You can read the complete�press release online�and see the rest of the awardees as well.
Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of�OpenColorIO!
Sincerely,
Rob Bredow
--
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.

921 - 940 of 2209