You need permission This form can only be viewed by users in the owner's organization. Try contacting the owner of the form if you think this is a mistake. Learn More.

Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to

Thanks, yeah I should have linked the PR in the post. I'll try and get more eyes on that to test, though I'm sure it's fine, then we can pull that through to get things kicked off. As for Labels, I'd

This all sounds good to me! I would be happy to help out auditing/tagging the issues in GitHub. The current labels seem fairly reasonable to me - "feature" for new things, "bug" for bugs, internal

Troy, would you be able to wrap this into an Issue on GH? With the coming addition of labels, this will be classified as a feature request.

On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements. Having spent plenty of time ramming into the problems, I believe that

Hello all, and happy new year! I'd like to start a formal discussion around the steps we will take to give OCIO a breath of life. Hopefully we can work to make 2017 a year of progress. So in that

Hi Meiwa, It's a bit hard to remotely debug from the info you've provided, but the general answer is that you'd want to bring your Linear source (presumably in Arri Wide Gamut primaries) into a V3LogC

Dear Andrew, I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome. The output lut generate an over-expose image. Is that because there is

No, 64 bit only. I used the default cmake settings, though I did run cmake and build with cygwin in my path (so "patch" would work when building tinyxml). I'll look into the v0 vs v1 issue - that

Is this 32-bit or 64-bit? If 32-bit, did you change the default calling convention in your project (__cdecl vs __stdcall)? Undecorated headers with .lib files that use the default convention will fail

Are you using the proper generated headers? Are you overriding so version in CMake? All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major

I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same

This strikes me as clean, sensible, and very viable in short term. I also believe that this discussion could wander off into colour quackery and OCIO bloatification without keeping a guiding bit of

> I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility. Yes, this is exactly my concern and the

I like option A. I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility. Personally, I'd rather see

Hi, Sorry I have been a bit busy getting up to speed with a job. I have been musing some ideas with Robert Molholm about this separately and wanted to mention it to see what you think. The basic

Agree. The question then is, how to specify the XYZ transform. I added it in the above patch in a manner much like the luma tag. Is this a workable step forward? It would seem that we could depreciate

Troy, The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing.

My issue with best practices is that they will fail where not implemented, which means an entire user interface stack or potentially shaders, algorithms, and a whole slew of other things fall apart