Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-) It has never been SPI's intention to abandon this project, and we definitely want to continue having a

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's

Thanks for the responses everyone. I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this

Hello fellow color wizards, I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color

I would also bring up your concerns with Erik Strauss at Sony. As they founded the product they are still in control of it technically. Mark at Dneg has been talking about their planned changes for

Hi, I personally got very busy over the last year and I have been waiting to see Marks suggested changes to the core, so haven’t been involved as much as I would have liked. From brief conversations

Serious question, why not just publicly do a fork, and maintain it in the short term until the stewardship side of the official repository becomes clearer? At that point, the fork can be merged and

Thanks for the information Dennis. If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an

This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations

Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included

I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even

Hello all, This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide. Most of you are likely aware of the

I didn't check for ok in the code snippet I provided, but ok is True, and colorBuf.geterror() returns an empty string.

There is, you just weren't checking it: import OpenImageIO srcBuf = ImageBuf(src_path) colorBuf = ImageBuf() ok = OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear') if not ok :

I don't know where the ocio config could be coming from since I don't have an OCIO environment variable set, and I couldn't find any config files. When I run oiiotool --help it shows at the bottom:

In OIIO 1.6, if OCIO is disabled (support not compiled at build time, or no OCIO configuration file is found at runtime), all it knows how to do is convert between sRGB or Rec709 and linear. BUT... if

I'm using OpenImageIO-1.6.14-cp27-cp27m-win_amd64.whl which I downloaded from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ . I found it too much of a pain to build the source for Windows. This

Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong. Let's start from first principles. oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o

Also, which version of OIIO? -- Larry Gritz l...@...

It depends on the colorspaces defined in your config.ocio file set by your $OCIO environment variable. Which profile are you using from the examples or did you roll your own?