Date 1 - 3 of 3
OCIO for Windows
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 :)
Jeremy Selan <jeremy...@...>
Marie,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 !
Marie Fétiveau <m...@...>
Hello Jeremy !toggle quoted message Show quoted text
Thanks for your reply ;)
The IDT/ODTs we made are not already expressed in CTL. They are simple "matrix + transfer function" that can also be computed into 3DLUT.
I also have some samples (created by IIF) that are in CTL. I looked at some of them and it seems that they also describes matrix + function or LUT.
So, as I don't have a CTL_ToSthElse function for now, I think I'll just formulate them in OCIO vocabulary (firstly).
I made a branch but I never used Git before.
That's a good oppotunity to become familiar with it.
I've just created a GitHub account and started to watch the OCIO project.
I merge my current version of the code with the last version on the remote master branch (good git training) but I didn't have time to check if it still compiles on MSVC. I guess it's not.
Please be aware that my modifications are tests draft ;p
Here's my first git diff : http://dl.dropbox.com/u/2979643/mfe_OCIO_git_diff_originmaster_forWindows.txt
On Fri, Apr 1, 2011 at 1:40 AM, Jeremy Selan <jeremy...@...> wrote:
|1 - 3 of 3|