On Mon, Sep 23, 2013 at 3:36 PM, Jeremy Selan <jeremy...@...> wrote: > Ok, a couple of observations when trying to build for Fedora 19 x86_64 > > 1. I was using the pull 300 patch which is still

Can you clarify what you mean by this? I'm not sure what the "pull 300 patch" refers to. Yah, I'm seeing that too. Looks like the docs build target is hosed for 1.0.9; looking into it... Can you

Ok, a couple of observations when trying to build for Fedora 19 x86_64 1. I was using the pull 300 patch which is still open. It looks like parts of it were committed, but not all of it. I don't think

https://github.com/imageworks/OpenColorIO/tree/v1.0.9 Will send a link from now on! :) (Docs are in the process of rebuilding, the website will be updated momentarily).

Hi again!

Guess I got there too quick, don't see it yet on github... Also, although it's not difficult to find a link would be handy :) Thanks, Richard

I've just tagged the latest OCIO master as 1.0.9. There had been a bunch of bugfixes in there, and it had been hurting our distros to not have a tagged release with the lates. -- Jeremy **Version

We've just put out the 1.0.9 tag. Please see if this fixes things?

Oh - on further inspection I see you're compiling against yaml 0.5.1 This is a known issue, being tracked here: https://github.com/imageworks/OpenColorIO/issues/318 -- Jeremy <mfv.d...@...>

Hi! Good to know ;-) Well... I can test it, obviously ;-P Gonna let you know the results of the build with that parameter set. Thanks for your help. Cheers. -- Matteo F. Vescovi Debian

Awesome, thanks Sean! Does anyone on this list have experience working with the Nuke GPU path? This API is new to us, and we'd love to get some experienced eyes on this code. :) -- Jeremy

Thanks for this report. It looks to be a symbol visibility issue related to our use of yaml-cpp, so this is probably fixable by editing the top-level CMakeLists file's "USE_EXTERNAL_YAML" section. I

Hi, Apologies for bumping an old discussion, but I'm in looking for a similar set of features to the ones Nathan described, and as the discussion seemed to have fizzled out, I wanted to show my

Hi, I've finished my proof of concept, and it seems to be working quite nicely. I ended up needing to provide 3 strings for 3d transformations (which isn't too terrible) and I was able to implement

Modified CMake to only include this in the Linux builds. Contemplating implementing the GPU path on the other plugins, as well. https://github.com/imageworks/OpenColorIO/pull/328 Here's the specific

UPDATE: a test build on a Debian GNU/kFreeBSD64 porterbox now gives the results attached in the buildlog file, where fail is probably related to the recent upgrade to boost 1.54 in Debian. Hope it

Hi! The aim of a Debian Maintainer/Developer is to have a package building fine on all the supported archictures (actually, Debian supports 14 architectures officially, plus the unofficial

On Fri, Aug 30, 2013 at 9:11 AM, Mark Boorer <mark...@...> wrote: Hi Ben, * I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT. Even with a large 2**16 or 2**32 line LUT?

Hi Ben, My example where a 1D lut would be insufficient is where the source image is already in float linear, and a grading operation is to be applied in log (like saturation). Here negative values

There was discussion of a CTLTransform (Color Transform Language) in the past, although it would probably require OCIO to have a plugin interface for transforms, because having the OCIO core depend on