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

Andy, The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created. As for the second suggestion I think it is part of a bigger problem. There

I'd like to see two things added, which I feel represent a conservative take on how to add chromaticity data without going "too far." 1) An XYZ role. This won't solve all the problems, but it does

I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc. What *is* required is a method to query metadata about the reference,

Hi, I came across this thread. Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I

Hi, I know it is an old question but I could not find a working solution. Is there a walkthrough to build OCIO including PyOpenColorIO on Windows? Or something precompiled that might work? My current

This is timely, I was going to raise the issue of whether it's appropriate for OCIO to be colorimetry intelligent or not. Where OCIO would define the chromaticites per colorspace, as Malcolm

I loved this idea when Mark originally hinted at it at SIGGRAPH, but frankly, it would probably require some deeper sculpting unless someone can figure out an elegant solution for the parser on each