Date   

Review: Exposed Processor GPU functions to python

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

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

First step in the development of the Mari OCIO viewer plugin.

-- Jeremy


Review: Benign header cleanup

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

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

Removed OpenColorABI.h. Simpler just to put all the compiler specific
stuff in one header, OpenColorTypes.h
This doesnt effect ABI or code compatibility.

closes GH-57


Review: First pass at a ICCTransform

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

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

Had sometime on the plane so did a first pass at a ICCTransform, which will be needed for 'iv color profiles/LUTs' on the https://github.com/OpenImageIO/oiio/wiki/GSoC-Idea-Page.

Would like some feedback on where the filepath resolution should be? It's easy for me to add this in the Op but most other things have this in the Transform, is this where this logic should sit?

I have not implemented the setInputMem(const void * inputPtr, int size) functions yet, but have added these to the transform interface, these would be used when loading icc profile embedded in file headers.

.malcolm


Review: Updated Nuke OCIODisplay, added config.getCacheID(), context.getCacheID(), ClearAllCaches()

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

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

nuke ociodisplay: ocio_populate_viewer works again
nuke ociodisplay: Renamed viewer knobs to "gain" and "gamma". This
allows them, when used as ViewerOps, to be driven by the existing
monitor interface.
nuke ociodisplay: added prototype for channel swizzling support. This
can't be enabled though until the OCIO cpu path supports alpha channel
handling (otherwise 'alpha' visualization wont be supported)
nuke ociodisplay: Added context support (per shot support)
core library: configs, and contexts can report cacheIDs.
Added OCIO::ClearAllCaches(), which will drop all cached information
about files on disk. (Will cause luts to be reloaded on next use)

closes GH-46
closes GH-15

-- Jeremy


Interesting article: How to use github effectively

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

Not directly related to OCIO, but I thought those github users on the
list may enjoy this article:
http://lumberjaph.net/dancer/2011/03/06/how_to_use_github_effectively_for_your_project.html

My favorite tip: if you include in your commit comment text such as,
"closes GH-123", it will automatically close the specified issue, and
link to the commit. How cool!

-- Jeremy


Review: FormatRegistry cleanup

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

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

This adds a bit more infrastructure behind the internal FormatRegistry. This checkin fixes the make test error in Baker.cpp, so format ordering is longer at the mercy of the static registration order. This also allows clients (such as ociobakelut) to report supported lut formats for both reading and writing.

There's some code cleanup related to Formats too. FileFormats only need to implement the Write function if they want to support writing. Otherwise, they can leave the implementation blank.

This checkin maintains both binary and source compatibility.


-- Jeremy


Review: removing boost as a dependency

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

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

Removed boost dep from the code based, you now need gcc >= 4 to get access to std::tr1::shared_ptr

This has only been tested on OSX, doing a bit of reading we might need a different #include for different gcc versions. "#include (GCC 4.1) or #include (GCC 4.3)"

.malcolm


Re: Review: First pass at TruelightTransform and TruelightOp

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


As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...hm, I do indeed. Might have a look at this when I have a bit of spare time - could be useful in conjuction with the Houdini LUT Baker! Should be straight-forward enough, although last time I done something with cineSpaceAPI, I lost several days to an incredibly obscure linker bug *mutters*

If you can send me the header, I'm happy to flesh something out.

I didn't get around to it before I left DRD but I was hoping to use the lut baker to build a tool to take advantage of the lutio table which you might find interesting.


You could effectively have something like this.
.ocio "ocioToHoudini '%s' stdout.lut" "ocioFromHoudini stdin.lut '%s'"

If you did this you could support per shot dynamic grades, where you could feed houdini the ocio profile and it could spit out a lut baked for the current context. This would save rendering out graded plates or baking out luts for everyshot for lighting.

.malcolm

On 23/02/2011, at 6:03 PM, Malcolm Humphreys wrote:

Hi,

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?  

Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no support. If host apps are written correctly this shouldn't cause problems.

I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

Depending on how many display devices are in play it's nice to have this dynamic. But most of the time the transform will be used in defining a colorspace to be used with ociobakelut into different lut formats.

You obviously implemented this with a workflow in mind, would you elaborate?

From time to time new display devices come into play and truelight can be used for device -> device mapping eg. a whole heap of diffrent monitors turnup halfway through a production, which need to look the same/similar to the current set.

I prefer that all the tools for modelling these transforms and baking luts are all in one place.

I really want a ocio profile to describe all the color decisions on a show + ways to regenerate luts formats even ones that the ocio profile uses. 

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

I have written it so that you can have profiles with the <!TruelightTransform> even if OCIO hasn't been built with it. In most host apps this wont be a problem as these wouldn't be used directly in production display lookups.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

Agreed, I think this is a happy middle ground. Profiles are still interoperable while opening up the opportunity for 3rdParty OCIO enabled commercial apps to get truelight support if they wanted it.

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...

I did say I wanted a plugin interface :)

.malcolm

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm






0.7.7 Released

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

Version 0.7.7 (March 1 2011):

    * Lut baking API + standalone app (ociobakelut)
    * Truelight runtime support (optional)
    * Cinespace (3d) lut writing
    * CSP prelut support
    * Boost argparse dependency removed
    * SanityCheck is more exhaustive
    * FileTransform supports relative path dirs
    * Python enhancements (transform kwarg support)
    * Makefile enhancements (OIIO Path)
    * Processor API update (code compatible, binary incompatible)

-- Jeremy


Re: Review: First pass at TruelightTransform and TruelightOp

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

Thanks for the error text, that was definitely a bug. (Introduced by me).   This is now fixed in the latest master branch, and I've updated the v0.7.7 tag.

-- Jeremy

On Wed, Mar 2, 2011 at 6:42 AM, dbr/Ben <b...@...> wrote:

When building from the current imageworks HEAD revision (ce75762bdfaec287db029986cdc17d6f136b7447), I get:

    src/core/TruelightOp.cpp: In member function ‘virtual OpenColorIO::v0::OpRcPtr OpenColorIO::v0::<unnamed>::TruelightOp::clone() const’:
    src/core/TruelightOp.cpp:191: error: cannot allocate an object of abstract type ‘OpenColorIO::v0::<unnamed>::TruelightOp’
    src/core/TruelightOp.cpp:49: note:   because the following virtual functions are pure within ‘OpenColorIO::v0::<unnamed>::TruelightOp’:
    src/core/Op.h:102: note: virtual void OpenColorIO::v0::Op::writeGpuShader(std::ostream&, const std::string&, const OpenColorIO::v0::GpuShaderDesc&) const
    src/core/TruelightOp.cpp: In function ‘void OpenColorIO::v0::CreateTruelightOps(OpenColorIO::v0::OpRcPtrVec&, const OpenColorIO::v0::TruelightTransform&, OpenColorIO::v0::TransformDirection)’:
    src/core/TruelightOp.cpp:385: error: cannot allocate an object of abstract type ‘OpenColorIO::v0::<unnamed>::TruelightOp’
    src/core/TruelightOp.cpp:49: note:   since type ‘OpenColorIO::v0::<unnamed>::TruelightOp’ has pure virtual functions
    make[2]: *** [src/core/CMakeFiles/OpenColorIO.dir/TruelightOp.cpp.o] Error 1
    make[1]: *** [src/core/CMakeFiles/OpenColorIO.dir/all] Error 2

Using OS X 10.6.6 with GCC 4.2.1, and running "cd build && cmake ../ && make" (Truelight isn't installed/enabled) - I'm quite possibly doing something stupid, but the error seemed bug'y

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...hm, I do indeed. Might have a look at this when I have a bit of spare time - could be useful in conjuction with the Houdini LUT Baker! Should be straight-forward enough, although last time I done something with cineSpaceAPI, I lost several days to an incredibly obscure linker bug *mutters*


On 23/02/2011, at 6:03 PM, Malcolm Humphreys wrote:

Hi,

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?  

Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no support. If host apps are written correctly this shouldn't cause problems.

I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

Depending on how many display devices are in play it's nice to have this dynamic. But most of the time the transform will be used in defining a colorspace to be used with ociobakelut into different lut formats.

You obviously implemented this with a workflow in mind, would you elaborate?

From time to time new display devices come into play and truelight can be used for device -> device mapping eg. a whole heap of diffrent monitors turnup halfway through a production, which need to look the same/similar to the current set.

I prefer that all the tools for modelling these transforms and baking luts are all in one place.

I really want a ocio profile to describe all the color decisions on a show + ways to regenerate luts formats even ones that the ocio profile uses. 

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

I have written it so that you can have profiles with the <!TruelightTransform> even if OCIO hasn't been built with it. In most host apps this wont be a problem as these wouldn't be used directly in production display lookups.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

Agreed, I think this is a happy middle ground. Profiles are still interoperable while opening up the opportunity for 3rdParty OCIO enabled commercial apps to get truelight support if they wanted it.

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...

I did say I wanted a plugin interface :)

.malcolm

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm






Re: Reloading Context's env

"dbr/Ben" <b...@...>
 

Aha, the key/value parameters sound great. Much less hacky solution than reloading env variables (which is a slightly flawed idea)!

In your example, I don't understand what "context.name1" and "context.value1" refer to. Would these be specified in a multiline-string input, or are they knob name/values, or...?

I'm not sure how you could create a reasonably elegant UI using Nuke's current knob types.. Simply adding/removing knobs dynamically would make it difficult to, say, allow nuke.knobDefault("OCIODisplay.context.value2", "[getenv SHOT]"), but I wonder - is it possible/practical to determine what context variables have been used in a config, and dynamically create a knob for each - e.g a knob named "mynode.context_SHOT" - probably not..

Oh, one minor/unrelated question - if a context variable fails to match, conceptually, should there be a way to specify a default value? For example, say I use "${SHOT}.csp" for the main viewer LUT. When someone someone is working on a shot without a LUT, the colourspace will error with "cannot find file newshot.csp" (i.e the SHOT context variable is set correctly, but points OCIO to a non-existant file)

Anyway, must go and sleep. I preemptively apologise if this email is full of errors/typos!

On 02/03/2011, at 4:23 AM, Jeremy Selan wrote:

Hi Ben,

Thanks for the note.   I was actually just looking at addressing this issue on our end! (if you had waited a week you may have never noticed).

The issue is actually two-fold.

First, I really dont want to consider the envvars themselves to be mutable. (The envvars are just the context defaults.)  So what we're going to do is on all the nuke nodes add a "context" group, where you have key value string pairs open by default.   So in your case, you could for example set
context.name1 = "SHOT"
context.value1 = "ab-123"
and these will take priority over the default values, allowing you to change SHOT (or any other envvar) as needed dynamically.

The second issue is actually this one:

The nuke node's cacheIDs only are built based on the knob values, not the underlying OCIO cache ID.  What this means is that if you load a common image (marci), render with a default display node, quit nuke, change the OCIO to a similar config but with a different film lut, relaunch nuke, and view marci... You'll get the old image if it's still in the disk cache.  (Note you can avoid this with the clear disk cache menu option).  But the better solution is to feed nuke the real cacheid, then everything will work automatically.

-- Jeremy

On Tue, Mar 1, 2011 at 3:25 AM, dbr/Ben <b...@...> wrote:
Today I've configured OCIO for a small project at RSP. It was perfectly straight forward, but I encountered a problem..

In short, with the Nuke OCIODisplay node, the env-variables are never reloaded (e.g if changed via os.environ['SHOT'] = 'ab-123')

For example, I have a colourspace that uses ${SHOT}, and have configured Nuke to register OCIODisplay nodes for this. If i launch Nuke with:

env SHOT='ab-123' nuke

..it applies ab-123.csp, as expected, and everything is great.

Then, say I open a script from another shot, cd-654. A new Nuke instance opens, an onScriptOpen callback sets $SHOT (by parsing the script's location), and again all is great, it applies cd-654.csp

The problem is when Nuke doesn't launch a new instance, but the shot changes. Most commonly by opening a script in a clean Nuke instance, e.g:

env SHOT='ab-123' nuke

Then "File > Open" a script from cd-654

The callback changes os.environ['SHOT'] correctly, but the LoadEnvironment call is only performed once (presumably when the first OCIO node is created).


Anyway, this might just be an extremely longly worded +1 for the "flush-cache API method" ticket (can't remember the issue number, and Github's HTTP appears to be down..), but...

I wonder if it's reasonable to expect the OCIODisplay node to call this method somehow? Or if it'd be something I'd have to call, e.g:

def reload_context():
   if nuke.thisKnob().name() == "file": # Current filename has changed
       cfg = PyOpenColorIO.GetCurrentConfig()
       cfg.context.reload()
nuke.addOnKnobChange(reload_context, nodeClass = "Root")

..or if there is a better solution to this problem?

- Ben



Re: Review: First pass at TruelightTransform and TruelightOp

"dbr/Ben" <b...@...>
 

When building from the current imageworks HEAD revision (ce75762bdfaec287db029986cdc17d6f136b7447), I get:

    src/core/TruelightOp.cpp: In member function ‘virtual OpenColorIO::v0::OpRcPtr OpenColorIO::v0::<unnamed>::TruelightOp::clone() const’:
    src/core/TruelightOp.cpp:191: error: cannot allocate an object of abstract type ‘OpenColorIO::v0::<unnamed>::TruelightOp’
    src/core/TruelightOp.cpp:49: note:   because the following virtual functions are pure within ‘OpenColorIO::v0::<unnamed>::TruelightOp’:
    src/core/Op.h:102: note: virtual void OpenColorIO::v0::Op::writeGpuShader(std::ostream&, const std::string&, const OpenColorIO::v0::GpuShaderDesc&) const
    src/core/TruelightOp.cpp: In function ‘void OpenColorIO::v0::CreateTruelightOps(OpenColorIO::v0::OpRcPtrVec&, const OpenColorIO::v0::TruelightTransform&, OpenColorIO::v0::TransformDirection)’:
    src/core/TruelightOp.cpp:385: error: cannot allocate an object of abstract type ‘OpenColorIO::v0::<unnamed>::TruelightOp’
    src/core/TruelightOp.cpp:49: note:   since type ‘OpenColorIO::v0::<unnamed>::TruelightOp’ has pure virtual functions
    make[2]: *** [src/core/CMakeFiles/OpenColorIO.dir/TruelightOp.cpp.o] Error 1
    make[1]: *** [src/core/CMakeFiles/OpenColorIO.dir/all] Error 2

Using OS X 10.6.6 with GCC 4.2.1, and running "cd build && cmake ../ && make" (Truelight isn't installed/enabled) - I'm quite possibly doing something stupid, but the error seemed bug'y

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...hm, I do indeed. Might have a look at this when I have a bit of spare time - could be useful in conjuction with the Houdini LUT Baker! Should be straight-forward enough, although last time I done something with cineSpaceAPI, I lost several days to an incredibly obscure linker bug *mutters*


On 23/02/2011, at 6:03 PM, Malcolm Humphreys wrote:

Hi,

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?  

Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no support. If host apps are written correctly this shouldn't cause problems.

I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

Depending on how many display devices are in play it's nice to have this dynamic. But most of the time the transform will be used in defining a colorspace to be used with ociobakelut into different lut formats.

You obviously implemented this with a workflow in mind, would you elaborate?

From time to time new display devices come into play and truelight can be used for device -> device mapping eg. a whole heap of diffrent monitors turnup halfway through a production, which need to look the same/similar to the current set.

I prefer that all the tools for modelling these transforms and baking luts are all in one place.

I really want a ocio profile to describe all the color decisions on a show + ways to regenerate luts formats even ones that the ocio profile uses. 

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

I have written it so that you can have profiles with the <!TruelightTransform> even if OCIO hasn't been built with it. In most host apps this wont be a problem as these wouldn't be used directly in production display lookups.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

Agreed, I think this is a happy middle ground. Profiles are still interoperable while opening up the opportunity for 3rdParty OCIO enabled commercial apps to get truelight support if they wanted it.

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...

I did say I wanted a plugin interface :)

.malcolm

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm





Review: moved pystring, tinyxml, md5 into ext

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

As part of cleaning up the code base for stable I have moved these things so they live in ext with everything else.

Moved pystring, tinyxml, md5 into ext, built with hidden symbol visibility so they are not part of the ABI.

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

.malcolm


Re: Review: replaced BOOST test with OIIO test

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

Now in a new pull request with cleaned up history
https://github.com/imageworks/OpenColorIO/pull/78

On 01/03/2011, at 1:05 PM, Malcolm Humphreys wrote:

I'm going to start to use branches from now on, so that pull requests work as expected. btw have you thought about making a github user for the dev-list so that it could receive the pull requests?

https://github.com/malcolmhumphreys/OpenColorIO/commit/03373f79950854266efd9ae95af2fb0907b20939

I have added some bits to the OIIO unittest.h header so that it lets us swap out our usage of Boost for unit tests, this might need to change a little when committing this back to OIIO.

* replaced BOOST test with OIIO test, added OIIO_TEST_APP, OIIO_TEST_SETUP, OIIO_ADD_TEST, OIIO_CHECK_NO_THOW, OIIO_CHECK_THOW, OIIO_CHECK_CLOSE in an effort to remove boost as a build dependancy
* added a OCIO static target that gets built by default
* added ext/oiio with plans to move argparse and strutil to this location

.malcolm


Re: Reloading Context's env

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

Hi Ben,

Thanks for the note.   I was actually just looking at addressing this issue on our end! (if you had waited a week you may have never noticed).

The issue is actually two-fold.

First, I really dont want to consider the envvars themselves to be mutable. (The envvars are just the context defaults.)  So what we're going to do is on all the nuke nodes add a "context" group, where you have key value string pairs open by default.   So in your case, you could for example set
context.name1 = "SHOT"
context.value1 = "ab-123"
and these will take priority over the default values, allowing you to change SHOT (or any other envvar) as needed dynamically.

The second issue is actually this one:

The nuke node's cacheIDs only are built based on the knob values, not the underlying OCIO cache ID.  What this means is that if you load a common image (marci), render with a default display node, quit nuke, change the OCIO to a similar config but with a different film lut, relaunch nuke, and view marci... You'll get the old image if it's still in the disk cache.  (Note you can avoid this with the clear disk cache menu option).  But the better solution is to feed nuke the real cacheid, then everything will work automatically.

-- Jeremy


On Tue, Mar 1, 2011 at 3:25 AM, dbr/Ben <b...@...> wrote:
Today I've configured OCIO for a small project at RSP. It was perfectly straight forward, but I encountered a problem..

In short, with the Nuke OCIODisplay node, the env-variables are never reloaded (e.g if changed via os.environ['SHOT'] = 'ab-123')

For example, I have a colourspace that uses ${SHOT}, and have configured Nuke to register OCIODisplay nodes for this. If i launch Nuke with:

env SHOT='ab-123' nuke

..it applies ab-123.csp, as expected, and everything is great.

Then, say I open a script from another shot, cd-654. A new Nuke instance opens, an onScriptOpen callback sets $SHOT (by parsing the script's location), and again all is great, it applies cd-654.csp

The problem is when Nuke doesn't launch a new instance, but the shot changes. Most commonly by opening a script in a clean Nuke instance, e.g:

env SHOT='ab-123' nuke

Then "File > Open" a script from cd-654

The callback changes os.environ['SHOT'] correctly, but the LoadEnvironment call is only performed once (presumably when the first OCIO node is created).


Anyway, this might just be an extremely longly worded +1 for the "flush-cache API method" ticket (can't remember the issue number, and Github's HTTP appears to be down..), but...

I wonder if it's reasonable to expect the OCIODisplay node to call this method somehow? Or if it'd be something I'd have to call, e.g:

def reload_context():
   if nuke.thisKnob().name() == "file": # Current filename has changed
       cfg = PyOpenColorIO.GetCurrentConfig()
       cfg.context.reload()
nuke.addOnKnobChange(reload_context, nodeClass = "Root")

..or if there is a better solution to this problem?

- Ben


Reloading Context's env

"dbr/Ben" <b...@...>
 

Today I've configured OCIO for a small project at RSP. It was perfectly straight forward, but I encountered a problem..

In short, with the Nuke OCIODisplay node, the env-variables are never reloaded (e.g if changed via os.environ['SHOT'] = 'ab-123')

For example, I have a colourspace that uses ${SHOT}, and have configured Nuke to register OCIODisplay nodes for this. If i launch Nuke with:

env SHOT='ab-123' nuke

..it applies ab-123.csp, as expected, and everything is great.

Then, say I open a script from another shot, cd-654. A new Nuke instance opens, an onScriptOpen callback sets $SHOT (by parsing the script's location), and again all is great, it applies cd-654.csp

The problem is when Nuke doesn't launch a new instance, but the shot changes. Most commonly by opening a script in a clean Nuke instance, e.g:

env SHOT='ab-123' nuke

Then "File > Open" a script from cd-654

The callback changes os.environ['SHOT'] correctly, but the LoadEnvironment call is only performed once (presumably when the first OCIO node is created).


Anyway, this might just be an extremely longly worded +1 for the "flush-cache API method" ticket (can't remember the issue number, and Github's HTTP appears to be down..), but...

I wonder if it's reasonable to expect the OCIODisplay node to call this method somehow? Or if it'd be something I'd have to call, e.g:

def reload_context():
if nuke.thisKnob().name() == "file": # Current filename has changed
cfg = PyOpenColorIO.GetCurrentConfig()
cfg.context.reload()
nuke.addOnKnobChange(reload_context, nodeClass = "Root")

..or if there is a better solution to this problem?

- Ben


Review: replaced BOOST test with OIIO test

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

I'm going to start to use branches from now on, so that pull requests work as expected. btw have you thought about making a github user for the dev-list so that it could receive the pull requests?

https://github.com/malcolmhumphreys/OpenColorIO/commit/03373f79950854266efd9ae95af2fb0907b20939

I have added some bits to the OIIO unittest.h header so that it lets us swap out our usage of Boost for unit tests, this might need to change a little when committing this back to OIIO.

* replaced BOOST test with OIIO test, added OIIO_TEST_APP, OIIO_TEST_SETUP, OIIO_ADD_TEST, OIIO_CHECK_NO_THOW, OIIO_CHECK_THOW, OIIO_CHECK_CLOSE in an effort to remove boost as a build dependancy
* added a OCIO static target that gets built by default
* added ext/oiio with plans to move argparse and strutil to this location

.malcolm


Review: Processor API Rejigger

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


Processor class now uses the pimpl pattern, so new functions can added in the future without impacting ABI compatibility. This patch maintains source code compatibility, but breaks the ABI interface. Will be worth it prior to 0.8 lockoff though.

The rest of the OCIO API used this approach, this one class was the only omission. The reason it was not done initially was the incestuous relationship between the Config and the Processor, but this is now solved by making the Processor Impl friends with the Config class. (Note that this doesn't change the existing relationship usage patterns, just clarifies it in terms of the code).


Re: Review: First pass at TruelightTransform and TruelightOp

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

Hi,

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?  

Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no support. If host apps are written correctly this shouldn't cause problems.

I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

Depending on how many display devices are in play it's nice to have this dynamic. But most of the time the transform will be used in defining a colorspace to be used with ociobakelut into different lut formats.

You obviously implemented this with a workflow in mind, would you elaborate?

From time to time new display devices come into play and truelight can be used for device -> device mapping eg. a whole heap of diffrent monitors turnup halfway through a production, which need to look the same/similar to the current set.

I prefer that all the tools for modelling these transforms and baking luts are all in one place.

I really want a ocio profile to describe all the color decisions on a show + ways to regenerate luts formats even ones that the ocio profile uses. 

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

I have written it so that you can have profiles with the <!TruelightTransform> even if OCIO hasn't been built with it. In most host apps this wont be a problem as these wouldn't be used directly in production display lookups.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

Agreed, I think this is a happy middle ground. Profiles are still interoperable while opening up the opportunity for 3rdParty OCIO enabled commercial apps to get truelight support if they wanted it.

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...

I did say I wanted a plugin interface :)

.malcolm

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm




Re: Review: First pass at TruelightTransform and TruelightOp

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

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?   I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

You obviously implemented this with a workflow in mind, would you elaborate?

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm


1761 - 1780 of 2242