HiGuys, Thanks for yourinvestigations around Python 3. OCIO does notcurrently support Python 3. But it would be appreciated to have a pull requestfixing the Python 3 support :-)

First, an apology for igniting the naming debate. Second, a huge congrats on reaching consensus on the naming of the ExponentTransform and its sibling. Part of me wants a PowerToe T shirt though... I

My guess is that it hasn't been updated for Python3 yet... There are some incompatible changes. You can try a converter and see if it takes care of the errors but beware any unintended side

Congrats!

Congratulations Larry! That is good news. S

By unanimous vote of the Academy Software Foundation's Technical Advisory Council, OpenColorIO has been adopted into the organization as an official ASWF incubating project. (We graduate from

I downloaded the latest OCIO code from GitHub (1.1.0) and I was able to compile OCIO using "Visual Studio 2015" as-well as pyOpenColorIO against Python27. However when I tried to compile it against

What does “it looks horrible“ mean? Perhaps providing an example image(Marcie)? Have you tried the same conversation in Nuke with the same config.ocio and does it look different?

Hello OCIO Just tryin to do a simple conversion in RV I have a LINEAR EXR that I want to take from Linear to AlexaV3LogC but when do this and then place on it, it looks horrible. What am I doing

Thanks for the info Sean. On my side, it's more a question of how much data the typical configuration files relies on. For Aces, it's something like 70 LUTs and 270Mb of data. That's why I was

Hello, I'd honestly say it depends on the time you have and your grasp of what problems you're trying to solve. In truth the larger hill of difficulty is from generating you're own luts and/or

Hi, During my integration of the OCIO library, I have mainly used the configuration files that can be obtained from the OCIO website, mainly nuke and Aces. I was wondering what is the typical use

It took me a bit of time mucking to get the allocation variables set properly. If you set your allocation variables type to lg2, the math for the lower and upper variable is the same as it is in an

Thanks for your answer Troy. I started to play with the latest version with the revamped GPU path. I'll have to wait for the official release to integrate it though. For now, I'll continue to see if I

There's two issues at work, both of which are important. The first is the deeper GPU issue that the ever wise Mr. Hodoul has fixed with the completely reworked GPU code path. That is a massive issue,

I traced it in the getGpuLut3D and what I see is that when it applies the LogToLin, this will clamp all negative values of the Lut1d. The resulting operation is 2^-15 -> 0.0000305. When the Lut1d is

I didn't investigate whether this is the exact same issue but this might be related to the issue you are experiencing. The bug: https://developer.blender.org/T56055 The fix:

Having a realistic timeline for OCIO v2 is quite challenging for now. Patrick.

Thanks for the confirmation Patrick! Also, in latest release, 1.1, I can see the same kind of behaviour. Let's say for the Nuke-default configuration, if I go from linear to SRGB, the resulting 3d LUT

Here is the github issue: #622