This is great :D I generated a LUT without issue, and it was as close as I would expect from Photoshop... Only nitpick'y problem I can see is the --outputfile argument seems to be redundant given

ociobuildicc --description="spi-vfx log test" --workingspace compositing_log --viewspace sRGB /Users/malcolm/Library/ColorSync/Profiles/spi-vfx_compositing_log_test.icc sure, it depends on how

Malcolm, This is awesome! I've wanted to have icc export for so long, this is hugely appreciated. (We'll use it at SPI immediately) * What are the command-line arguments used in your example? I'd

Also added Little CMS to LICENSE file Commit: https://github.com/malcolmhumphreys/OpenColorIO/commit/8ff296f8ab234ea7b06704036037bf2a132ebd6a .malcolm

Attaching some slightly larger examples :)

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