Oh, and have we agreed to use 'View' rather than 'Alias'? I'm cool with that... -- Jeremy

Would this syntax preserve Display order? I think that's important. -- Jeremy

Malcom, I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to

Hi Joesph, Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called

Malcom, I like your layout. I think that calling the The name change will allow the opportunity to have a list of default display that can be different from what the active displays are. I think

Hi, Ok thats a bit clearer. But I think having this as a flat list is not so nice. After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of

Here's a chunk from spi-vfx with the new options: displays: - !<Display> {device: sRGB, alias: Raw, colorspace: nc10} - !<Display> {device: sRGB, alias: Log, colorspace: lg10} - !<Display>

This sounds like a good solution, much less error prone than storing the dropdown in the node itself. The J_3Way node (http://major-kong.blogspot.com/2010/01/jops-10v1a5-released.html ) has a nice UI

Good point. I've renamed the first section "A contrived example", which just explains using env-vars to find a LUT. The second example is more practical, and applies the grade, then a lin-to-log/3D

Hi Ben, I love docs :) (because of my horrible memory) My main comments would be I would tend to aim 'contexts' being used as part of the complete viewing transform. Right now it reads as though we

LGTM .malcolm

LGTM Begin forwarded message:

Hi, Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as

Nice job on the docs. By all means, check them in! (Even partial docs are better than nothing). :) I like this, but I'm not sure that there's a nuke UI widget rich enough for this behavior. What

This is great. Nice and intuitive \o/ !<FileTransform> {src: grades/grades.ccc, cccid: "beauty/${SEQ}/${SHOT}"} ..or, could split the grades into one file per seq and do ({src:

Commits: http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613 http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a Issue: htt

Commit: http://github.com/jeremyselan/OpenColorIO/commit/7ffb711edea3b4b3c4aa0ad046c15de8f70b936e I added a call to get the cacheID for the shadertext on the processor object. Note that querying the

Commit: http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452 Issues: https://github.com/imageworks/OpenColorIO/issues#issue/25 https://github.com/imageworks/OpenC

Sure that sounds great, i'll fix that. I don't remind removing them altogether. I was really just adding them to match the old functionality of getRoleNameByIndex() which returned the colorspace

Thanks! I like the intent, but have two minor issues: First, the trivial: I'd prefer to never allow NULL values as return types from const char * functions. Please use an empty string