I am working on a patch right now but it looks like you may be able to use CMAKE_TOOLCHAIN_FILE in the meantime. You would make a file Toolchain-osx-fat.cmake with: SET(CMAKE_OSX_ARCHITECTURES x86_64

I agree that the default behavior for the CDLTransform should not change. It would most likely break some facilities color pipelines if we did change the default. Many other tools do implement CDL

I would like to build fat binaries with x86_64 and i386 architecture support. I've tried passing the flag -DCMAKE_OSX_ARCHITECTURES=x86_64;i386 to cmake, but it appears that flag isn't being

Robert, Although we can conform to anything For our on-set tools we have made a match to how Nuke's OCIOCDLTransform node works. This made the most sense because our main goal with CDL is to allow

According to the ASC-CDL standard "To maintain intended behavior of signs under exponentiation, we limit the Slope and Offset combined value to 0 to 1 (inclusive)..... out = Clamp((in*slope) +

Hi, I get a Yaml related warning message when building OCIO (branch: master 64adcad300adfd166280d2e7b1fb5c3ce7dca482) I'm on CentOS 6.5, and here's my cmake log: Here's the warning message: I'm

We notice that there is undesirable interaction between the new displayCache and the set of active displays. Previously, it was reasonable to have displays which were not in the active list. However,

On Apr 21, 2014 1:53 PM, "Dmitry Kazakov" <dimu...@...> wrote: > But, speaking truly, I didn't fully understand what is 1D transform... is it some term? Could you give me a link to some info or

Hi, Jeremy! Thank you for clarifications about 3D-lut! I google'd for it and now I think I understand why the reverse transformation is not possible. But, speaking truly, I didn't fully understand

Hi! A bit more info to add to the conversation. Apologies for now chiming in sooner... As folks have noted, in many real-world color configurations the viewing transform is includes a 3D-LUT in the

Hi, All! Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors

For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed

Remember that colorspaces can be defined to and from the reference. You can manually define the inverse and come up with an inverse 3d lut for the color picker that is close enough to fully

As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a

From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. Piotr

Hi, all! I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able

If you are using Looks heavily (and successfully), I’d like to hear from you. Currently, the documentation is somewhat inaccurate on the format of the definition and usage of Looks, so I’m

Ah cool, that could be quite handy. Just for posterity, the biggest problem with trying to take a dynamic approach in Nuke is timing. Ideally, when a user opens a script, one would be able to look at

Agreed. I inserted unistd.h above the #elif, and it compiles fine on 10.9. RGB

It looks like PathUtils.cpp needs unistd.h included. Looking at the source there’s: #if defined(__APPLE__) && !defined(__IPHONE__) #include <crt_externs.h> // _NSGetEnviron() #elif