Date   

Re: Regular Expression LUT matching

nhatpho...@...
 

It should pick the latest filename of all matches in alphabetical/numerical order so that in case we have

./001/0001/fromJeremy_v001_cin_srgb.cube
./001/0001/fromJeremy_v002_cin_srgb.cube
./001/0002/fromEditorial_v001_cin_srgb.cube

it would default to the latest version of each shot.

Now looking into FNMatch I think it's even more suitable than regex because it's simple and keeps the config easy to maintain.




Am Donnerstag, 29. August 2013 10:24:34 UTC-7 schrieb Jeremy Selan:

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatp...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



--
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: Regular Expression LUT matching

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

Is there a specific use case for this, it just feels dangerous.. Could we not just support ordered multiple luts? Eg. "/foobar/blah.lut:/cheese/foo.csp".

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

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatpho...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.


Re: Regular Expression LUT matching

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

Interesting idea.  Not currently possible, very do-able.

What if multiple luts match the specified pattern?  Which would be selected? Or would this be an error?

What are your thoughts on full regex vs just fnmatch?  (fnmatch would get you wildcards and seq match).

FNMATCH
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq


 The only challenge is that we'd have to make sure it works on windows too (I've never tried regex or posix fnmatch on win).

-- Jeremy




On Wed, Aug 28, 2013 at 11:36 PM, <nhatpho...@...> wrote:
Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat



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


Regular Expression LUT matching

nhatpho...@...
 

Hi!

In a scenario where the LUT name consists of some known variables and an arbitrary string I would like to use something like regular expressions to match the LUT file. For example,

./001/0001/fromJeremy_cin_srgb.cube
./001/0002/fromEditorial_cin_srgb.cube

it would be useful to write in the config file:

${SEQ}_${SHOT}/([A-Za-z]*_cin_srgb.cube)

I don't know if that's possible, but it would be handy though.

Thanks,


Nhat




Re: RV integration WIP

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

It's our understanding that RV 4.0 ships with OCIO built-in so you shouldn't need to compile it yourself.


Give that a shot, and let us know what you find?

-- Jeremy


On Tue, Aug 27, 2013 at 10:37 AM, <nhatpho...@...> wrote:
Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat

--
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: RV integration WIP

nhatpho...@...
 

Any news on this?

We'd be highly interested in RV support for OCIO as all our bigger shows are using OCIO as the default colorpipeline.

Last time we tried to compile OCIO for Windows it wasn't that easy and we haven't picked that up ever since, but I'd offer to continue and help.

Thanks,


Nhat


Re: [pyOpenColorIO] get LUT type ?

Marie Fétiveau <m...@...>
 

Thanks, that did the trick !

++
Marie


On Wed, Aug 21, 2013 at 8:03 PM, Jeremy Selan <jeremy...@...> wrote:
Not directly.

The issue that makes this complex is that some lut files (such as csp) can contain both 1D and 3D luts together.  So the distinction between what should be considered 1-D, vs 3-D isn't always clear.  From OCIO's perspective even a CDL transform (.cc) is considered a 'LUT'.  Which would that be?

One alternative idea that may suffice for your needs would be to get the processor object (specific to the LUT file), and then call:

> processor.hasChannelCrosstalk()

I believe this is appropriately answered for all the lut types, and would let you accurately determine whether a 1-D plot is sufficient to graph the color transform.  It would also 'just work' then for all the underlying transform types, even those that use CDLs, log allocations, etc.

-- Jeremy




On Wed, Aug 21, 2013 at 7:38 AM, Marie Fétiveau <m...@...> wrote:
Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  



--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.


Re: [pyOpenColorIO] get LUT type ?

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

Not directly.

The issue that makes this complex is that some lut files (such as csp) can contain both 1D and 3D luts together.  So the distinction between what should be considered 1-D, vs 3-D isn't always clear.  From OCIO's perspective even a CDL transform (.cc) is considered a 'LUT'.  Which would that be?

One alternative idea that may suffice for your needs would be to get the processor object (specific to the LUT file), and then call:

> processor.hasChannelCrosstalk()

I believe this is appropriately answered for all the lut types, and would let you accurately determine whether a 1-D plot is sufficient to graph the color transform.  It would also 'just work' then for all the underlying transform types, even those that use CDLs, log allocations, etc.

-- Jeremy




On Wed, Aug 21, 2013 at 7:38 AM, Marie Fétiveau <m...@...> wrote:
Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  



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


Sci-Tech Request

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

Folks,

As you may have noticed, ASC-CDL was selected for Sci-Tech consideration this year under the category of "Digital workflow specifications for managing color".


We are interested in providing the Academy with additional information on OpenColorIO as a potential example of related technology.

Our Request:
If you have used OpenColorIO on a motion-picture production, and are comfortable sharing this information with the Academy, please let us know.  Specifically, a listing of the motion-picture titles which used OCIO, and the facility associated with the work, are most helpful at this time.

Example:
Sony Imageworks
    - Oz The Great and Powerful
    - The Amazing Spider-Man
    - Cloudy With A Chance of Meatballs 2

If you'd prefer to not post publicly, feel free to email me directly.

Also, by no means are we only interested in large titles, or those produced in the US.  We would love to hear about *all* uses, both big and small!  You also don't have to be a VFX facility. We are equally interested in uses at post-houses, on-set, mastering facilities, etc. The only requirement is that it was used in motion-picture production.

The Academy deadline for submitting this information is this Tuesday, Aug 27th.  So realistically, we'd need to get all responses by this Monday, Aug 26th to be of help.

Regards,
Jeremy


[pyOpenColorIO] get LUT type ?

Marie Fétiveau <m...@...>
 

Hello !

I wrote a python script to plot 1D and 3D LUTs.
It uses pyOpenColorIO to read and process LUTs and matplotlib to plot them.

For the moment, I have to specify manually if the LUT is 1D or 3D to plot a curve or a cube.

So the question is : is there a way to get this information from OpenColorIO and through the binding ?

Thanks !

Marie
  




Patch for the getActiveViews env issue

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

Hi guys,

I noticed there is an issue with getting the active Views list when it has been overridden in the environment using OCIO_ACTIVE_VIEWS. 

I've attached a patch that will fix this.

Also I noticed that getDisplays always returns only the active ones and not all the displays, where as getActiveDisplays returns all of them. Is there a reason for this? I have not changed this functionality as I don't know what other applications (hiero , Nuke Mari etc) this might affect.



Great project 

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 |


3rd annual Open Source "Beer of a Feather"

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

For those of you attending SIGGRAPH 2013 in Anaheim next week, we will be once again holding an event for developers and users of VFX-specific open source projects. It's a great chance to meet in person with people on the other end of the mail lists.

When: Wed. July 24, 2013, 5:00pm - 7:00pm

Where: Tangerine Grill and Patio
1030 West Katella Avenue, (at the Anabella Hotel)
http://tangerinegrillandpatio.com‎

How it works:

Our kind sponsors will charge up a tab, and we'll be able to get drinks and
appetizers until the funding pool runs out or we lose the reserved room at
7pm (after which I think we're still able to retreat to the main bar).

With proper lubrication in hand, relax and enjoy the company of your fellow
open source developers.

Your generous sponsors:

Digital Domain
Double Negative
DreamWorks Animation
Industrial Light and Magic
Luma Pictures
Method Studios
Peregrine Labs
Pixar Animation Studios
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital

*Special thanks to Erik Strauss and Andrew Watkins of SPI, and Colin Doncaster of Peregrine Labs, for going above and beyond the call of duty to secure a venue under shockingly difficult circumstances.

Feel free to echo this to other VFX open source mail lists that I may have missed.

--
Larry Gritz
l...@...


Re: converting LUTs

Sean Looper <sean....@...>
 

You can use ociobakelut for this purpose.


-sean



On Wed, Jul 3, 2013 at 11:52 PM, Paul Damstadt <paul.d...@...> wrote:
Hi,

The convert utility seems to only convert a given image from one color space to another. How can I convert the LUT itself?
Specifically, I am trying to convert Iridas .CUBE to Lustre .3dl

Plz help. Thanks,
Paul
  

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


converting LUTs

Paul Damstadt <paul.d...@...>
 

Hi,

The convert utility seems to only convert a given image from one color space to another. How can I convert the LUT itself?
Specifically, I am trying to convert Iridas .CUBE to Lustre .3dl

Plz help. Thanks,
Paul
  


Re: Thoughts on layering of multiple config files

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

Hi Ben,

I did see your responses to Hugh's thread after he pointed me to it. However, once again, the discussion seems to be centered around the idea of nesting or referencing config files, whereas I'm mainly interested in being able to layer config files together for very specific overrides. I'll try to sketch my thoughts out a little more clearly:
  • Base configuration lives at `/path/to/base.config` (this could be facility-wide or show-specific; that part isn't important).
  • Set up OCIO environment var in the same way you might set up $PATH, except with OCIO configs
    • export OCIO=/path/to/sparse/override.config:/path/to/base.config
  • OCIO creates a Config object from the environment by doing the following:
    1. Load the configuration file found at the *back* of the $OCIO variable (in the above case, the "base config")
    2. Working from back to front, load each config definition onto the Config instance that was created in step 1.
    3. Only sanity-check the resulting Config instance after all paths have been loaded.
In this example, the file `/path/to/sparse/override.config` would be able to, say, replace a single ColorSpace definition with a more complex set of transforms or add a Look by *only* containing the desired additional or override definitions (and, say, the ocio_profile_version key). If the sparse file defined a ColorSpace with a name that matched the name of a ColorSpace in the "base config," the sparse file's definition would replace it purely based on the order in which the config files appear on the $OCIO variable.

This would allow for overrides without requiring any preprocessing of the YAML data (to, say, resolve includes), any syntactical changes to the configuration files, or any alterations to any *existing* configurations. We use this same kind of thing to manage stored preferences/recent settings for pipeline operators at different contextual levels (show, shot, element, action, user). It allows each type of preference to be as sparse as possible to avoid writing out the same data many times, and for a given application or scenario, the order in which these contextual preferences "squash" each other can change (in the case that duplicate preference keys are possible).

The main scenario I can see for deploying this type of config "patching" is when the crazy requests start rolling in from production near the end of a show, when it is often critical to be nimble. You are correct that even this type of extension would give anyone more wiggle room to break things, and that it wouldn't provide a way to remove things from the final Config. However, I don't really see this layering idea being the standard way of doing things, but simply an added dimension of flexibility.

There is currently nothing stopping anyone from manually breaking an existing configuration with a text editor, or writing a malformed definition from scratch, and it isn't OCIO's responsibility to prevent them from doing this. In that same spirit, it wouldn't be OCIO's responsibility to prevent someone from trying to combine two configuration files that don't result in a valid Config object.

Hope this helps clarify my thoughts a little more, and how they differ from the idea of referencing or including configuration files between each other.

-Nathan



On Thursday, June 27, 2013 8:09:13 AM UTC-7, dbr/Ben wrote:

Jeremy's reply to https://groups.google.com/forum/#!topic/ocio-dev/okBHXi1ibnM sums up most of my concerns about this feature nicely..

Merging two arbitrary YAML configs seems like a direction in which madness lies.. There's lots of cases where the behaviour would be non-obvious, e.g:
* parent defines and uses a 'linear' space, child also defines a 'linear' space with, say, different allocation - what happens?
* Does a file-reference in the parent search the child search_path?
* If there's a base config, can I not inherit a specific colorspace?
* ..and a bunch more I haven't fully thought through (like "would you need to control the order in which views are merged?", "in the child config, could you remove a colorspace from the parent?")


Limiting the scope a bit might make things clearer, e.g something like

colorspaces:
  - !<IncludeColorspaces> {src: "/path/to/shared/base.ocio", include: [srgb, "*log"], exclude: ['badlog']}
  - !<Colorspace>
     name: ...

Where this would just include the colorspace definitions, but ignore anything like the search_path from the included file. If the included config requires LUT's in a certain location, this path would be added to "search_path" as usual.


That said, I don't really understand the benefit of this.. While the current "one config.ocio per project" setup involves some duplication of colorspace definitions etc, I don't see this as a downside.. Either a colorspace never changes (in which case, copying-and-pasting is little hassle), or the colorspace needs changed (in which case, it's useful being able to update new projects without fear of breaking current/finished projects)

It'd be good to have a few clear explanations of workflows where the nested configs would be beneficial (beneficial over alternative approaches like copy-pasting-and-modifying, or Python-generated configs)
- Ben


Re: Thoughts on layering of multiple config files

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


Jeremy's reply to https://groups.google.com/forum/#!topic/ocio-dev/okBHXi1ibnM sums up most of my concerns about this feature nicely..

Merging two arbitrary YAML configs seems like a direction in which madness lies.. There's lots of cases where the behaviour would be non-obvious, e.g:
* parent defines and uses a 'linear' space, child also defines a 'linear' space with, say, different allocation - what happens?
* Does a file-reference in the parent search the child search_path?
* If there's a base config, can I not inherit a specific colorspace?
* ..and a bunch more I haven't fully thought through (like "would you need to control the order in which views are merged?", "in the child config, could you remove a colorspace from the parent?")


Limiting the scope a bit might make things clearer, e.g something like

colorspaces:
  - !<IncludeColorspaces> {src: "/path/to/shared/base.ocio", include: [srgb, "*log"], exclude: ['badlog']}
  - !<Colorspace>
     name: ...

Where this would just include the colorspace definitions, but ignore anything like the search_path from the included file. If the included config requires LUT's in a certain location, this path would be added to "search_path" as usual.


That said, I don't really understand the benefit of this.. While the current "one config.ocio per project" setup involves some duplication of colorspace definitions etc, I don't see this as a downside.. Either a colorspace never changes (in which case, copying-and-pasting is little hassle), or the colorspace needs changed (in which case, it's useful being able to update new projects without fear of breaking current/finished projects)

It'd be good to have a few clear explanations of workflows where the nested configs would be beneficial (beneficial over alternative approaches like copy-pasting-and-modifying, or Python-generated configs)
- Ben

On 27/06/2013, at 3:42 AM, Nathan Rusch wrote:

Thanks for the information everyone.

It sounds like the general thoughts in this direction so far are leaning toward the idea of nesting or referencing configurations within each other. While I think this could certainly be useful, it really seems like a layering system would be far simpler to implement, as well as to actually make use of.

My basic thought is that the different configuration files would be completely blind to each other, and it looks like Config::Impl::load() could be safely called once for each file found on the environment variable. With this approach, the burden of making sure you aren't adding references to undefined transforms or colorspaces could fall on the end user (at least initially). Among other things, this would allow for, say, a single application to easily override the definitions for certain transforms, looks, etc. without requiring what would otherwise be a carbon copy of the original config file.

What are the general reactions to configuration layering vs. nesting, or thoughts on the implementation side?

-Nathan


P.S. Also, just for reference, Hugh pointed me to a topic he started in 2011 that pertains to the nesting/cross-referencing of configurations (I wasn't using the right search terms, so I didn't see it): https://groups.google.com/forum/#!topic/ocio-dev/okBHXi1ibnM.



On Tuesday, June 18, 2013 1:05:41 PM UTC-7, Malcolm Humphreys wrote:
I was hoping we could use a combination of anchors and references (http://en.wikipedia.org/wiki/YAML#References) with some kind of special '#include some_other_$(SHOW).ocio' which would be resolved before it gets to the yaml parser inside OCIO.

Support for anchors and references would also allow to reduce a lot of duplication in current profiles while also opening up the possibility of using data from profile segments that get #included.

.malcolm

On 18/06/2013, at 5:55 AM, Rob Molholm wrote:

Hey folks,

Although implementation of issue #282 below is still ideal, I have been testing a combination of FUSE and OCIO, using FUSE as a way to abstract database queries, presenting results as "virtual" OCIO configurations to the calling application (using the filesystem hierarchy for baked context).   This does have its limitations, but it is one way to centrally manage several configurations.  FUSE also works across multiple platforms, which is a bonus.

In production we're pretty much doing as mentioned-- we have a baseline OCIO configuration, which is carried over and modified by a script for each project, and also baked for contexts within a project where the OCIO contexts do not work

...and speaking of including/merging configurations- has it ever been floated to add an OCIO config file as one of the supported file types of OCIOFileTransform?    there'd have to be an additional argument to specify a specific color space (or look) out of the included file, but this could be a way of bringing in known complex/grouped transforms, rather than relying on the basics in a single file.  The source path of the file transform would be subject to the current context, so you definitely could get crazy with this.  Not sure how dependancies from the included color space would be resolved either...

-rob


 
On Jun 17, 2013, at 6:12 PM, Jeremy Selan <jere...@...> wrote:

Hi.

Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea.  See this existing issue for more information, or to add your thoughts:

In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...

Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.

-- Jeremy



On Mon, Jun 17, 2013 at 12:41 PM, <nath...@...> wrote:
Hey all,

I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.

I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.

How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...

Thanks for any thoughts,

-Nathan

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


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


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


--
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: Thoughts on layering of multiple config files

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

Thanks for the information everyone.

It sounds like the general thoughts in this direction so far are leaning toward the idea of nesting or referencing configurations within each other. While I think this could certainly be useful, it really seems like a layering system would be far simpler to implement, as well as to actually make use of.

My basic thought is that the different configuration files would be completely blind to each other, and it looks like Config::Impl::load() could be safely called once for each file found on the environment variable. With this approach, the burden of making sure you aren't adding references to undefined transforms or colorspaces could fall on the end user (at least initially). Among other things, this would allow for, say, a single application to easily override the definitions for certain transforms, looks, etc. without requiring what would otherwise be a carbon copy of the original config file.

What are the general reactions to configuration layering vs. nesting, or thoughts on the implementation side?

-Nathan


P.S. Also, just for reference, Hugh pointed me to a topic he started in 2011 that pertains to the nesting/cross-referencing of configurations (I wasn't using the right search terms, so I didn't see it): https://groups.google.com/forum/#!topic/ocio-dev/okBHXi1ibnM.



On Tuesday, June 18, 2013 1:05:41 PM UTC-7, Malcolm Humphreys wrote:
I was hoping we could use a combination of anchors and references (http://en.wikipedia.org/wiki/YAML#References) with some kind of special '#include some_other_$(SHOW).ocio' which would be resolved before it gets to the yaml parser inside OCIO.

Support for anchors and references would also allow to reduce a lot of duplication in current profiles while also opening up the possibility of using data from profile segments that get #included.

.malcolm

On 18/06/2013, at 5:55 AM, Rob Molholm wrote:

Hey folks,

Although implementation of issue #282 below is still ideal, I have been testing a combination of FUSE and OCIO, using FUSE as a way to abstract database queries, presenting results as "virtual" OCIO configurations to the calling application (using the filesystem hierarchy for baked context).   This does have its limitations, but it is one way to centrally manage several configurations.  FUSE also works across multiple platforms, which is a bonus.

In production we're pretty much doing as mentioned-- we have a baseline OCIO configuration, which is carried over and modified by a script for each project, and also baked for contexts within a project where the OCIO contexts do not work

...and speaking of including/merging configurations- has it ever been floated to add an OCIO config file as one of the supported file types of OCIOFileTransform?    there'd have to be an additional argument to specify a specific color space (or look) out of the included file, but this could be a way of bringing in known complex/grouped transforms, rather than relying on the basics in a single file.  The source path of the file transform would be subject to the current context, so you definitely could get crazy with this.  Not sure how dependancies from the included color space would be resolved either...

-rob


 
On Jun 17, 2013, at 6:12 PM, Jeremy Selan <jere...@...> wrote:

Hi.

Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea.  See this existing issue for more information, or to add your thoughts:

In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...

Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.

-- Jeremy



On Mon, Jun 17, 2013 at 12:41 PM, <nath...@...> wrote:
Hey all,

I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.

I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.

How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...

Thanks for any thoughts,

-Nathan

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


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


--
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: Thoughts on layering of multiple config files

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

I was hoping we could use a combination of anchors and references (http://en.wikipedia.org/wiki/YAML#References) with some kind of special '#include some_other_$(SHOW).ocio' which would be resolved before it gets to the yaml parser inside OCIO.

Support for anchors and references would also allow to reduce a lot of duplication in current profiles while also opening up the possibility of using data from profile segments that get #included.

.malcolm

On 18/06/2013, at 5:55 AM, Rob Molholm wrote:

Hey folks,

Although implementation of issue #282 below is still ideal, I have been testing a combination of FUSE and OCIO, using FUSE as a way to abstract database queries, presenting results as "virtual" OCIO configurations to the calling application (using the filesystem hierarchy for baked context).   This does have its limitations, but it is one way to centrally manage several configurations.  FUSE also works across multiple platforms, which is a bonus.

In production we're pretty much doing as mentioned-- we have a baseline OCIO configuration, which is carried over and modified by a script for each project, and also baked for contexts within a project where the OCIO contexts do not work

...and speaking of including/merging configurations- has it ever been floated to add an OCIO config file as one of the supported file types of OCIOFileTransform?    there'd have to be an additional argument to specify a specific color space (or look) out of the included file, but this could be a way of bringing in known complex/grouped transforms, rather than relying on the basics in a single file.  The source path of the file transform would be subject to the current context, so you definitely could get crazy with this.  Not sure how dependancies from the included color space would be resolved either...

-rob


 
On Jun 17, 2013, at 6:12 PM, Jeremy Selan <jeremy...@...> wrote:

Hi.

Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea.  See this existing issue for more information, or to add your thoughts:

In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...

Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.

-- Jeremy



On Mon, Jun 17, 2013 at 12:41 PM, <natha...@...> wrote:
Hey all,

I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.

I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.

How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...

Thanks for any thoughts,

-Nathan

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


--
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: Thoughts on layering of multiple config files

Rob Molholm <robert....@...>
 

Hey folks,

Although implementation of issue #282 below is still ideal, I have been testing a combination of FUSE and OCIO, using FUSE as a way to abstract database queries, presenting results as "virtual" OCIO configurations to the calling application (using the filesystem hierarchy for baked context).   This does have its limitations, but it is one way to centrally manage several configurations.  FUSE also works across multiple platforms, which is a bonus.

In production we're pretty much doing as mentioned-- we have a baseline OCIO configuration, which is carried over and modified by a script for each project, and also baked for contexts within a project where the OCIO contexts do not work

...and speaking of including/merging configurations- has it ever been floated to add an OCIO config file as one of the supported file types of OCIOFileTransform?    there'd have to be an additional argument to specify a specific color space (or look) out of the included file, but this could be a way of bringing in known complex/grouped transforms, rather than relying on the basics in a single file.  The source path of the file transform would be subject to the current context, so you definitely could get crazy with this.  Not sure how dependancies from the included color space would be resolved either...

-rob


 

On Jun 17, 2013, at 6:12 PM, Jeremy Selan <jeremy...@...> wrote:

Hi.

Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea.  See this existing issue for more information, or to add your thoughts:

In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...

Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.

-- Jeremy



On Mon, Jun 17, 2013 at 12:41 PM, <natha...@...> wrote:
Hey all,

I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.

I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.

How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...

Thanks for any thoughts,

-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.
 
 


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.
 
 


Re: Thoughts on layering of multiple config files

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

Hi.

Unfortunately the ability to layer ocio configurations isnt implemented yet, though we do consider it a really good idea.  See this existing issue for more information, or to add your thoughts:

In the meantime, we handle this at SPI using python scripts to build configurations for each show. The code is generally similar to this...

Not quite as elegant as being dynamically read on the fly, but it has suited our needs to a high enough degree that this has been a low priority for us in the interim.

-- Jeremy



On Mon, Jun 17, 2013 at 12:41 PM, <natha...@...> wrote:
Hey all,

I hope I'm not spawning a duplicate discussion thread; I did some searching around, but couldn't find anything.

I'm wondering if there has been any discussion about allowing multiple config files to be used to build a single runtime configuration by layering multiple (possibly sparse) definitions on disk. Similar to the PATH environment variable, the final configuration would be built from the "bottom" of the OCIO variable's path list up, allowing files of higher precedence to replace existing definitions within the configuration (to facilitate overrides), as well as add items to it. One goal of this would be to make it easy to propagate changes to "static" pieces of a core OCIO configuration across many shows.

How are people currently handling the possibility of changes to what might be considered the "core" of your OCIO configuration? One option seems to be to have the build script for each show's configuration load a "baseline" config and then amend it or replace certain items (assuming this is possible)...

Thanks for any thoughts,

-Nathan

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

1021 - 1040 of 2233