toggle quoted message
Show quoted text
Thanks for the email. In terms of testing OCIO with new IDT/ODTs,
are your transforms CTL programs, or have you formulated them in the
OCIO vocabulary. (luts, matricies, etc).
I believe you are the first to attempt to use it on Windows, though it
was always in our plan to add eventual support. I suppose now is the
time to get it in.
Have you made a branch of the git repository? Are you on github? I'd
love to see all the changes you've made. If you aren't familiar with
git and would prefer to send me diffs, that will be fine as well.
I'll try to find a Windows machine at work, so we can work through the
remaining compilation issues together. Then if any changes are needed
for cross-platform compatibility, we can get them in before the 0.8
2011/3/30 Marie Fétiveau <m...@...>:
Hello all !
I finally have some time to have look at OCIO ;)
In a few words, I'd like in a near future to set up in my studio a Color
Pipeline integrating IIF and OCIO improvements.
I'm part of a french project (HD3D²) which is already working on IIF. I'd
like to make a proof of concept and give one of my partner (using Windows) a
chance to test OCIO with some IDT/ODT we made.
For now my first goal is : compile OCIO tools (ociodisplay, ociocheck,
ocio2icc, ociobakelut, ocioconvert) for Windows.
My usual tools for building on Windows are Eclipse + Boost.build + Mingw
; I'm not used to MSVC and Cmake so much.
I first started with my favorite toolset with Cmake instead of boost.build.
But I quickly realized that to make OCIOdisplay works I'll have to compile
all OIIO plugins with Mingw (meaning a lot of dependencies which isn't
impossible but very time consuming).
Furthermore, as Nuke's dll are built with MSVC I might encounter some
troubles trying to mix MSVC and Mingw libraries.
On other projects, I tried pexports and friends, it did work but not always.
Consequently, as I needed some test tools fast, I changed my mind and
started to build everything using MSVC2010.
OIIO happened to be really easy to compile (thanks to pre-compiled
For OCIO, I had to change some piece of code :
- use boost::rand48 instead of srand48
- comment part between the "#pragma GCC visibility" in OCIOYaml.h
- use _fullPath instead of ::realpath
- use boost::shared_ptr + boost::dynamic_pointer_cast instead
of std::tr1::shared_ptr + std::tr1::dynamic_pointer_cast
- comment setStringVar and getStringVar because of some errors on
StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440:
'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>'
to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
- ... (some stuff about srand, isNan...)
I guess that these changes may have a bad impact but for the moment it
doesn't matter to me because I just need to see if I can get everything
I 'm not so aware of the GCC's visibility pragmas.
So that may be bad to have this part commented.
Anyway it builds and I get OCIO libs (static and dynamic) and exes.
But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find
out that no LUT file formats are recognized.
Each Lut format registers itself via the AutoRegister static variable but it
seems that this function is not even present it my exe whereas it is present
in the original .lib. This prevents my formats to be registered at startup.
I tried debugging and the file format list was actually empty.
I tried some options in the Visual project properties ( /OPT:NOREF for
example) but didn't find any that works.
So I tried to link dynamically with openColorIO and added in
#if defined _MSC_VER
#if defined EXPORT_DLL
#define OCIOEXPORT __declspec(dllexport)
#define OCIOEXPORT __declspec(dllimport)
It creates a .lib for the corresponding OpenColorIO.dll.
But when I run OCIOCheck.exe I get a crash when the program tries to load
So here I am, I won't have time to work on this until next week but I
thought that some people may have build this for Windows or/and may have
some advices for me ;)
Thanks for reading :)