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 libraries).
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 compiled.
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 opencolorabi.h :
#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 OpenColorIO.dll...
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 :)