OpenEXR ( http://www.openexr.com/ ) related material.
NOTE:
You may need the Microsoft Visual Studio 2005 (SP1) C/C++ run rime libraries too if you get error messages about manifest files, etc. (This is NOT the .NET Microsoft redistributable!)
Get the installer for the runtime libraries from Microsoft itself.
OR: try this local copy of the same (as was distributed with the MSVC2005 SP1 setup which was used to create the executable[s] above.
For UNIX, please refer to the OpenEXR web site for further documentation.
... you must have Microsoft Visual Studio 2005 (SP1) installed; open the OpenEXR 'sln' solution in the '.\OpenEXR\vc\vc8\OpenEXR' directory and build. Presto. Well, almost... (see the requirements below)
OpenEXR requires the zlib source code and MSVC2005 project files as well, which are available here (zlib).
Note that I always use this directory layout for all my projects; make sure the OpenEXR and zlib archives are both 'extracted here' in the same base directory (that would be '3actual' for myself but you can put them elsewhere as long as all source code trees share the same 'root' directory):
.../prj/
0download/ -- downloaded source codes, muck
1original/ -- CVS snapshots for externally tracked projects (e.g. pavuk, OpenSSL, crm114, ...)
2intermediate/ -- scratch directory for mix&merge 1original and 3actual. Mostly unused.
3actual/ -- where the actual development takes place.
4patch/ -- when 'patch files' have to be produced, it's done here.
5archive/ -- CVS/SVN/etc. RCS storage *plus* source tree snapshot archives storage: the backups!
6distribute/ -- stores externally distributed archives and files (files you find on-line on this site).
7testconfig/ -- test arena for those projects that require a significant local test setup (crm114, ...)
The 'Deploy' target directory has been moved one(1) directory up into the OpenEXR directory; I do not use the 'Deploy' files but the second copy which always is the <active_solution>/bin directory. Yes, all projects include the projects for all libraries so I can build from source all the way in one fell swoop. Saves hassles on collecting distributable binaries + DLLs as well.
MSVC2005 project files have been 'treated' so there's no dependency on VC7/VC6 'inheritance project templates' anymore. Those have bitten me in my behind too often not to care about this.
Few source files have extra content (one header file defines more than just PI/2, compare to original OpenEXR CVS source code) and the eLUT/toFLOAT tools have been patched very slightly to allow both UNIX and Win32/64 to produce byte-identical output files (standard I/O redirection on Win32 (XP Pro SP2) at least adds gratuitous CR's to every LF line break).
CreateDLL tool is always used as a Win32 binary, even when compiling Win64 x64 or IA64 OpenEXR binaries. This is done because it allows for cross-platform compilation on a Win32-based development system, targeting x64 and/or IA64-based test/production systems.
CreateDLL is also used in other projects of mine, so some bits may not be all too relevant for OpenEXR as it comes in the box, but the changes are relevant for my other projects for sure.
WARNING:
This is highly experimental stuff.
... and you'll need the zlib code too, if you want to build from source out of the box.
All Win32 binaries assume a SSE capable CPU. Adjust the compile settings when you have older equipment. (SSE is supported by the oldest AMD AthlonXP family, where Autodesk 3d Studio MAX 2009 has a serious issue with those CPUs regarding Mental Ray, despite the minimum requirements still okaying AthlonXP CPUs. Later versions and anything after that does support SSE2 as well; these projects do not use that CPU feature.)
CreateDLL now supports x64/IA64. (experimental)
Thanks to Robert Durnin and Jesse Lehrman for calling these in.
Q: When you use the OpenEXR projects (or header files) you get one of these linker errors?
foobar.obj : error LNK2019: unresolved external symbol "private: static unsigned short const * const half::_eLut" (?_eLut@half@@0QBGB)
referenced in function "public: __cdecl half::half(float)" (??0half@@QEAA@M@Z)
foobar.obj : error LNK2019: unresolved external symbol "private: static union half::uif const * const half::_toFloat" (?_toFloat@half@@0QBTuif@1@B)
referenced in function "public: __cdecl half::operator float(void)const " (??Bhalf@@QEBAMXZ)
A: You are using the OpenEXR dynamically loadable libraries (DLL's) — which is the default — and did not #define OPENEXR_DLL in either your own project settings or in your source code before the OpenEXR headers are #include<>d.

Explanation: In MSVC, static member variables need to be explicitly exported and imported when using these across DLL boundaries. Despite all the magic performed through the OpenEXR CreateDLL tool, you still need to explicitly tell MSVC to declspec(__dllimport) such static member variables or you're SOL. That's what the OPENEXR_DLL #define takes care of for you.
Then put this bit of bogus code somewhere in your own application and compile and link. When the _eLut and _toFloat linker errors show up, you know what to do... ;-)
Test code:
#include <Iex.h>
#include <half.h>
float test_linker_for_openEXR(void)
{
// bogus code to make sure the float/half transforms are hit (eLUT / toFloat)
half h(0.3);
float v;
h *= 2.0;
v = h;
while (v < 2)
v++;
h = v;
v -= h / 0.5;
return v;
}
Q: It doesn't rain but it pours missing member function linker errors for the OpenEXR DLLs?
A: You're sure you still have the linker options for all the OpenEXR library projects (and all the other projects which use the OpenEXR CreateDLL tool) configured to produce a debug-level MAP file (even in 'Release' builds, and don't worry, CreateDLL in the post-build action will strip the DLL anyhow).
Be aware that the .MAP file export will only 'work' for CreateDLL if you make sure the Linker setting /OPT:NOREF (a.k.a. 'Keep Unreferenced Data') is turned on. This is not the default, so you'd better check.
Remarks: Note that I already took care of this issue in the MSVC projects that come with the local OpenEXR source download below, but you may have inadvertently changed those settings along the way — or, God forbid, I screwed up.
Yet, as the Germans say, "Vertrauen ist gut, Kontrolle ist besser." ("Trusting is good. Checking is better.")


Note: the 7z (7zip) downloads are strongly advised as those will be faster to download (and smaller too). For anyone who does not want to use 7zip for compelling religious reasons (like alarmingly restrictive enforced company policies), we provide a .tar.bz2 file as an alternative for some files. Click on the "bz2" links instead to download these - when available.
| Compiles on: Platform |
Files / Archives | Date/Time | Quality | Notes |
|---|---|---|---|---|
|
|
plus zlib support source code:
|
2008-10-31 | Beta | contains experimental code and all precompiled debug and release .DLL and .EXE binaries |
|
|
plus zlib support source code:
|
2008-09-01 | Beta | contains experimental code and all precompiled debug and release .DLL and .EXE binaries |
|
|
Microsoft Visual Studio 2005 SP1 Redistributable PackageYou'll need to install this if you cannot run the compiled executables on your Windows platform:
|
2008-05-24 | Production | Mirror from Microsoft. |
(c)Copyright 2001-2009, Gerrit E.G. Hobbelt (Ger Hobbelt a.k.a. [i_a] ) - Hebbut.Net