Added ociobuildicc app which will build a soft-proofing icc profile for a given working space. (added LCMS2 into

LGTM, committed. Thanks! -- Jeremy

Oh,https://github.com/dbr/OpenColorIO/commit/0247f16ae202eeb5316f695c1310dac523272a0e

LGTM - committed. -- Jeremy <malcolmh...@...> wrote:

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