|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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!
|
|
|
|
Re: An Academy Award for OpenColorIO!
Boudewijn Rempt <bo...@...>
Awesome!
toggle quoted messageShow quoted text
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
|
|
|
|
Re: An Academy Award for OpenColorIO!
Ashley Retallack <ashl...@...>
Congratulations!! Very well deserved!
On 9 January 2014 17:35, Rob Bredow <r...@...> wrote:
--
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 |
|
|
|
|
An Academy Award for OpenColorIO!
Rob Bredow <r...@...>
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:
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
|
|
|
|
OpenColorIGo - Bindings for the Go language
Justin Israel <justin...@...>
Hey All, I had a need to use OpenColorIO for my image processing server, written in Go, so I started working on bindings. Thought I would share, just in case anyone is interested/involved in developing in Go: https://github.com/justinfx/opencolorigo I've got a majority of the read-only "consumption" aspects of the API implemented. My main interest was being able to get to the point of calling Processor:Apply() for a given environments config, so anything surrounding that code path is there. Suggestions/Contributions welcome. I'm not extremely experienced with OpenColorIO yet in practice. This was just a step I took, to be able to work our OpenColorIO pipeline into my image server. -- justin
|
|
|
|
Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes
"Matteo F. Vescovi" <mfve...@...>
Hi!
On Tue, Sep 24, 2013 at 03:42:15PM +0200, Matteo F. Vescovi wrote: Hi!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
|
|
|
|
Re: vd16 and alpha channels PS -> Nuke
Ashley Retallack <ashl...@...>
> If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer. Does this include if you have raw switched on in the read node and than do the unpremult -> OCIOColorspace -> Premult method?
On 28 November 2013 19:43, Troy Sobotka <troy.s...@...> wrote:
--
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: vd16 and alpha channels PS -> Nuke
Troy Sobotka <troy.s...@...>
The predivide has to happen prior to TRC inversion. If the issue is alpha / luminance based, the read node has a “Premultiplied” radio box. This should take the associated alpha image, predivide it, apply the inverted TRC / transfer curve, then apply the alpha again. If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer. With respect,
|
|
|
|
Re: vd16 and alpha channels PS -> Nuke
Ashley Retallack <ashl...@...>
Hi Troy, Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards? In which case it does not work as the colors are so different now the alpha associated with it multiple against the wrong value.
Or do you mean that the alpha it'self needs to be treated first, in which case how do I go about doing this to compensate for the values? Many thanks
Ash
On 22 November 2013 02:24, Troy Sobotka <troy.s...@...> wrote:
--
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: vd16 and alpha channels PS -> Nuke
Troy Sobotka <troy.s...@...>
Assuming I understand the issue...
On Nov 21, 2013 10:02 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color. If the alpha is associated, it must be predivided prior to linearization. The reason is due to a luminance collision. A standard sRGB or 709 inverted TRC looks at a value of 0.5 identically when alpha is associated. For example, a value of red 0.2 looks exactly the same as an associated alpha version of 1.0 red at 0.2 alpha. The resultant luminance will be off when linearized via an inversion of the TRC. Predivide if associated and you shouldn't have any issues. With respect,
|
|
|
|
Re: vd16 and alpha channels PS -> Nuke
Ashley Retallack <ashl...@...>
Cool, Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.
Cheers Ash
On 21 November 2013 17:27, Brendan Bolles <bre...@...> wrote:
--
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: vd16 and alpha channels PS -> Nuke
Brendan Bolles <bre...@...>
On Nov 21, 2013, at 8:54 AM, Ashley Retallack wrote:
I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards. You will get different results when comping in linear vs. video spaces. It's an order of operations thing and really can't be helped. Easiest thing is to comp the layers in video space and then convert the result to linear. If you're inserting an element in between, you might want to convert it to video space. The standard Over operation with fully opaque pixels should work the same in either case, but when you have transparency or other modes like Add, you will see changes. If you must comp those layers in linear, you can make color corrections and other adjustments to try to compensate for the differences you're seeing, but you won't be able to get it to match exactly. Brendan
|
|
|
|
vd16 and alpha channels PS -> Nuke
Ashley Retallack <ashl...@...>
Hi all, This may seem like a dumb question, but I've been scratching my brain for quite a while now. I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.
Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images. Hope that made sense. Cheers Ash 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: ICC color profile support?
dbr/Ben <dbr....@...>
Malcolm has done some work on being able to load ICC profiles in OCIO configs etc
toggle quoted messageShow quoted text
https://github.com/imageworks/OpenColorIO/pull/87 However Jeremy is hesitant to include lcms into OCIO's core (currently it's only used by the optional ociobakelut), so that pull-request is unlikely to be merged before OCIO gains a plugin interface - Ben Sent from my phone
On 13 Nov 2013, at 1:53, Paul Miller <ste...@...> wrote:
|
|
|
|
Re: ICC color profile support?
Paul Miller <ste...@...>
On 11/12/2013 9:37 AM, Mark Boorer wrote:
Hi Paul,I haven't done anything yet - just identifying my to-do list for migrating an existing lcms-based system to OCIO. My existing system just builds a 3D LUT which goes from the ICC profile to SRGB but it would be cleaner to just have it all integrated in one process in OCIO. It would be nice if there was an OCIO process stage that takes a raw in-memory icc profile data blob.
|
|
|