I think that's a perfect description of all the terminology. I'm thinking a glossary section (front page of webpage?, inside the FAQ?) would be appropriate. I'm thinking of naming the class that

I would think looks would be something separate from views. Terminology we currently have: - Transform - functions that transform RGBA data - ReferenceSpace - a space that connects ColorSpaces -

Replaced config->getRoleNameByIndex() with config->getRoleName() - getRoleNameByIndex returned the colorspace name not the role name, also ..ByIndex seemed redundant in the signature. Added

LGTM

Commit: http://github.com/jeremyselan/OpenColorIO/commit/d37b316cd8354216b4d89b85c06ab08108b5d1cc A pretty trivial change, include python.h first when building pyglue. Some linux installations are

Cool, no pressure just wanted to know if this was the direction we were thinking of going. .malcolm

Yes, I like it. Just haven't had a chance to update the code and re-submit yet. Sorry... -- Jeremy <malcolmh...@...> wrote:

Did you have any thoughts on this?

Could this not be part of the API? the core could just keep around the list that was in the profile as the default list and then the active would either be a copy of this or what was ever dynamically

Would the 'view' terminology be able to encompass your concept of looks? Id it does then I'm onboard -Joseph

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