What's the best way to adjust the OCIO processor if I want to display a depth map, possibly with gain control?

I've just pushed out updated OCIO configurations and updated reference images. Both can be downloaded from opencolorio.org: http://opencolorio.org/downloads.html Changes: - Minor update to the nuke-de

Looking at: https://github.com/imageworks/OpenColorIO/pull/192#issuecomment-3490984 got me thinking so I tried importing PyOpenColorIO in python and it worked fine for me. After that I decided to look

https://github.com/imageworks/OpenColorIO/pull/210 https://github.com/imageworks/OpenColorIO/issues/184 ociobakelut now has icc export support, removing the need for ocio2icc This also adds additional

Troy, This difference in srgb luts between the spi-vfx profile and nuke-default is a bit more complicated than a simple 1D vs. 3D white-point difference. I only have a moment to answer this question r

The OCIO website has been update to provide a list of compatible applications. http://opencolorio.org http://opencolorio.org/CompatibleSoftware.html If anyone has additions or comments, please let me

Congratulations! And thanks to Paul for all his efforts to make this happen. In the next few weeks I'm going to be updating the OCIO website to list all of the applications shipping with OCIO (it's a

I'm happy to announce that Silhouette 4.5 was released today with OCIO as its native color management solution. I want to thank Jeremy for his help (and a great library that is really easy to work wit

I had previously gotten a win64 DLL build from the cmake output. I've just opened up the visual studio solution and added a win32 configuration. It seems to build everything properly until it tries to

Version 1.0.3 (Dec 21 2011): * Tetrahedral 3dlut interpolation (CPU only) * ociocheck and Config.sanityCheck() have improved validation * Mari: updated examples * Makefile: misc updates to match distr

https://github.com/imageworks/OpenColorIO/pull/209 OCIO_LINK_PYGLUE allows pyglue to skip python linking. Default value is 'YES' (current behaviour). PyOpenColorIO.so is not useful in apps unless the

Review: Virtual member refactoring and OCIOColorSpace channel swizzling bug Made a bunch of the Nuke plugin members virtual. Also, fixed a bug in OCIOColorSpace where setting the "channels" knob to 'a

https://github.com/imageworks/OpenColorIO/pull/204 https://github.com/imageworks/OpenColorIO/issues/203 Config::sanityCheck will now fail when duplicate color spaces with the same name are encountered

Are you doing this in qt or pyqt? -- Jeremy

Thanks, Jeremy et al. As usual, once the pieces are in place, works as intended. -blake -- as seen on T.V.

I'm working on a new set of color picker controls that are properly managed with OCIO. For simple pots I can just transform each color before painting with my toolkit (I'm not going through OGL for th

Hi Malcolm and Jeremy, Thanks for the docs page. It is very helpful. Clearer now on how to have a single ocio config for a show. And yes, Jeremy that would be excellent if you can show me (or add to t

Hi OCIO developers, First, apologies if this is not strictly a dev question. I have a real-world case for per-shot grade LUTs in an application that uses OCIO color management (Katana). Reading over s

I wouldn't be too concerned with it. My expectation is that the image processing + getProcessor calls would dwarf by many orders of magnitude the PackedImageDesc allocation time. But if you're curious

In less than a week I've converted Silhouette's entire color conversion pipeline over to OCIO. I wanted to thank Jeremy and everyone else who gave me advice. It was much easier than I anticipated!