Tiff read error when reading EXR file

[tjdcs]

Hi all,

I'm hoping to get some help when running a simple example. Something is probably missing in my environment config, but I'm at a loss of finding it.

I'm getting a tiff read error when reading exr

 ctlrender -ctl /var/folders/ss/58q74x5j7fs8zmz2x9f8ybz00000gn/T/tmpgui4jhl1.ctl -param1 exposure 3.0 /Users/tucker/Dev/colour/colour/examples/io/../../io/tests/resources/CMS_Test_Pattern.exr /var/folders/ss/58q74x5j7fs8zmz2x9f8ybz00000gn/T/tmpb1kr7hc0.exr -verbose -force
global ctl parameters:

       source file: /Users/tucker/Dev/colour/colour/examples/io/../../io/tests/resources/CMS_Test_Pattern.exr
  destination file: /var/folders/ss/58q74x5j7fs8zmz2x9f8ybz00000gn/T/tmpb1kr7hc0.exr
destination format: exr
       input scale: default
      output scale: default

Unable to read tiff file: Not a TIFF or MDI file, bad magic number 12150 (0x2f76)unable to read file /Users/tucker/Dev/colour/colour/examples/io/../../io/tests/resources/CMS_Test_Pattern.exr (unknown format).```

[michaeldsmith]

can you try testing with the more direct path to that input file and let me know if it gives the same error?

/Users/tucker/Dev/colour/colour/io/tests/resources/CMS_Test_Pattern.exr

I believe ctl_render tries to read the input file looking for the magic numbers that would idenity it has DPX, TIF and EXR, instead of just relying on the file extension

[tjdcs]

Same result.

CMS_Test_Pattern.exr.zip

[michaeldsmith]

are you sure you are using the most recent code available in the master branch?

I didn't get the error you are seeing when using the CMS_Test_Pattern.exr file you attached when using the ctl in /unittests/ctlrender/unity.ctl

Here are the steps I used to test after cloning the repo:

docker build --rm -f Dockerfile -t ctl:latest .
docker run -it --rm -v C:\\temp:/tmp/ ctl:latest
ctlrender -ctl ./unittest/ctlrender/unity.ctl /tmp/CMS_Test_Pattern.exr /tmp/out.exr

out.exr looks identical to the input file CMS_Test_Pattern.exr

[tjdcs]

I strictly followed installation instructions using brew on macOS. I can try a build from scratch now

[tjdcs]

Build from scratch worked great.

[michaeldsmith]

I think some of the instructions are out-of-date, the CTL repo had not been updated since 2014 so I volunteered to maintain it in May 2022. Since then, we've fixed a lot of bugs and extended support to many more platforms and OpenEXR3, so I think we should do a release soon. The brew CTL distribution may need a new release version number to trigger their repo to use the latest code, I'm not sure.

[tjdcs]

Sounds good. I'm trying to also become a better contributor to colour-science and need ctl-render to run some of our examples. Not something I'm particularly familiar with.

Anyway. This seems to be fixed. I'm having an issue with

exception thrown (oops...): CTL parameter 'aIn' not specified on the command line and does not have a default value.

now, but I assume that's some of your changes / bug fixes and we need to update on our side.

Tagging @KelSolaar for vis.

[michaeldsmith]

OK good to hear. My guess is that you are getting that aIn error because the CTL file you are using expects RGBA input but your input file is only RGB. To overcome this without changing the CTL file to only input RGB, you can provide this additional argument when running ctlrender
-global_param1 aIn 1.0
which will set the input A value to 1.0

Let me know if that fixes the exception.

[tjdcs]

Thanks. Perfect workaround for now.

Next up to debug is our fileIO. Did the output parameters / usage change at all?

[michaeldsmith]

i don't believe the output parameters or usage has changed. Are you getting other errors now?

[michaeldsmith]

Another work around is to write your CTL code to handle both RGB and RGBA input files and set a default value for aIn within the CTL code, like this:

void main
    (output varying half rOut,
     output varying half gOut,
     output varying half bOut,
     output varying half aOut,
     input varying half rIn,
     input varying half gIn,
     input varying half bIn,
     input varying half aIn = 1.0)
{  
  rOut=rIn;
  gOut=gIn;
  bOut=bIn;
  aOut=aIn;
}

[tjdcs]

Thanks for your help @michaeldsmith. Probably best that we re-write out CTL template to have defaults there.

I am solved on my other issues, but we would like to have a release soon if you think you've stabilized CTL. That way we can test against a release version.

Cheers,

[scottdyer]

ctlrender stopped working for me and started showing me the same error about Unable to read tiff file: Not a TIFF or MDI file, bad magic number 12150 (0x2f76)unable to read file...*.exr (unknown format).

I have tried reinstalling from source using cmake and get an error on the make when linking ctlrender. Any ideas on how to fix?

(Up to here, all builds fine, except for a few warnings of deprecated syntax)

... 
[ 68%] Building CXX object ctlrender/CMakeFiles/ctlrender.dir/format.cc.o
[ 69%] Building CXX object ctlrender/CMakeFiles/ctlrender.dir/compression.cc.o
[ 70%] Linking CXX executable ctlrender
ld: Undefined symbols:
  half::_eLut, referenced from:
      half::half(float) in exr_file.cc.o
  half::convert(int), referenced from:
      half::half(float) in exr_file.cc.o
  half::_toFloat, referenced from:
      half::operator float() const in libIlmCtlSimd.a[14](CtlSimdStdLibLookupTable.cpp.o)
  Imf_3_2::Header::Header(int, int, float, Imath_2_5::Vec2<float> const&, float, Imf_3_2::LineOrder, Imf_3_2::Compression), referenced from:
      exr_write(char const*, float, ctl::dpx::fb<float> const&, format_t*, Compression*) in exr_file.cc.o
  Imath_2_5::SingMatrixExc::SingMatrixExc(char const*), referenced from:
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
  Imath_2_5::SingMatrixExc::~SingMatrixExc(), referenced from:
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
  typeinfo for Imath_2_5::SingMatrixExc, referenced from:
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix33<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::inverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
      Imath_2_5::Matrix44<float>::gjInverse(bool) const in libIlmCtlSimd.a[15](CtlSimdStdLibMath.cpp.o)
  operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, half), referenced from:
      void Ctl::(anonymous namespace)::printFunc<half>(Ctl::SimdBoolMask const&, Ctl::SimdXContext&) in libIlmCtlSimd.a[16](CtlSimdStdLibPrint.cpp.o)
      void Ctl::(anonymous namespace)::printFunc<half>(Ctl::SimdBoolMask const&, Ctl::SimdXContext&) in libIlmCtlSimd.a[16](CtlSimdStdLibPrint.cpp.o)
      Ctl::SimdPushLiteralInst<half>::print(int) const in libIlmCtlSimd.a[19](CtlSimdSyntaxTree.cpp.o)
      Ctl::HalfLiteralNode::print(int) const in libIlmCtl.a[15](CtlSyntaxTree.cpp.o)
      Ctl::HalfLiteralNode::printLiteral() const in libIlmCtl.a[15](CtlSyntaxTree.cpp.o)
      Ctl::HalfType::evaluate(Ctl::LContext&, Ctl::RcPtr<Ctl::ExprNode> const&) const in libIlmCtl.a[17](CtlType.cpp.o)
      Ctl::HalfType::evaluate(Ctl::LContext&, Ctl::RcPtr<Ctl::ExprNode> const&) const in libIlmCtl.a[17](CtlType.cpp.o)
      ...
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [ctlrender/ctlrender] Error 1
make[1]: *** [ctlrender/CMakeFiles/ctlrender.dir/all] Error 2
make: *** [all] Error 2

[michaeldsmith]

@scottdyer it looks like your build may be trying to use version 3.2 of OpenEXR (Imf_3_2) while trying to use version 2.5 of IMath (Imath_2_5).

version 2.5 of Imath was part of ilmbase for years, but Imath was spun out of ilmbase when OpenEXR went to version 3, there is now a separate Imath 3 library [1] dependency in OpenEXR 3

My guess is that you may have both Imath 3 and Imath 2.5 (part of ilmbase) installed on your system somehow and CTL is trying to use Imath 2.5 with OpenEXR 3.2

Can you try uninstalling ilmbase on your system and re-running cmake?

If you still have issues, can you provide the cmake output text? It should look something like this:

cmake ..
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_BUILD_TYPE : ""
-- To use AddressSanitizer, use "cmake .. -DCMAKE_BUILD_TYPE=asan"
-- Found OpenEXR 3.2.1
-- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so (found version "4.3.0")  
-- found TIFF, TIFF_LIBRARIES : /usr/lib/x86_64-linux-gnu/libtiff.so
CMake Warning at ctlrender/CMakeLists.txt:53 (find_package):
  By not providing "FindAcesContainer.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "AcesContainer", but CMake did not find one.

  Could not find a package configuration file provided by "AcesContainer"
  with any of the following names:

    AcesContainerConfig.cmake
    acescontainer-config.cmake

  Add the installation prefix of "AcesContainer" to CMAKE_PREFIX_PATH or set
  "AcesContainer_DIR" to a directory containing one of the above files.  If
  "AcesContainer" provides a separate development package or SDK, be sure it
  has been installed.


ctlrender test executable: /usr/src/CTL/build/ctlrender/ctlrender
-- LibTIFF found, OpenEXR found, including TIF and EXR files in ctlrender unit tests
ctlrender test output folder will be created at: /usr/src/CTL/build/unittest/ctlrender/output
exrdpx build director: /usr/src/CTL/build/OpenEXR_CTL/exrdpx
exrdpx test executable: /usr/src/CTL/build/OpenEXR_CTL/exrdpx/exrdpx
exrdpx test output folder will be created at: /usr/src/CTL/build/unittest/exrdpx/output
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/src/CTL/build

[1] https://github.com/AcademySoftwareFoundation/Imath

[scottdyer]

Well yes, that appeared to be it. I was overlooking that mismatch in the library versions - I thought I had fully reinstalled openexr but part of the old stuff was still lingering. Cleaned that out then reinstalled openexr and the ctl installed beautifully with cmake. Or at least completed without errors. Thanks.

However, now when I run ctlrender, I get this error:

dyld[93627]: Symbol not found: __Z13iex_debugTrapv
  Referenced from: <8CF3302C-64B5-3719-9EFE-27CC2F4FABE3> /usr/local/bin/ctlrender
  Expected in:     <no uuid> unknown
zsh: abort      ctlrender

For reference, here is the cmake output:

(base) scott@Scotts-MacBook-Pro build % cmake ..
-- The C compiler identification is AppleClang 15.0.0.15000040
-- The CXX compiler identification is AppleClang 15.0.0.15000040
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_BUILD_TYPE : ""
-- To use AddressSanitizer, use "cmake .. -DCMAKE_BUILD_TYPE=asan"
-- Found OpenEXR 3.1.11
-- Found TIFF: /usr/local/lib/libtiff.dylib (found version "4.6.0")  
-- found TIFF, TIFF_LIBRARIES : /usr/local/lib/libtiff.dylib
ctlrender test executable: /Users/scott/src/ctl/build/ctlrender/ctlrender
-- LibTIFF found, OpenEXR found, including TIF and EXR files in ctlrender unit tests
ctlrender test output folder will be created at: /Users/scott/src/ctl/build/unittest/ctlrender/output
exrdpx build director: /Users/scott/src/ctl/build/OpenEXR_CTL/exrdpx
exrdpx test executable: /Users/scott/src/ctl/build/OpenEXR_CTL/exrdpx/exrdpx
exrdpx test output folder will be created at: /Users/scott/src/ctl/build/unittest/exrdpx/output
exr_ctl_exr build director: /Users/scott/src/ctl/build/OpenEXR_CTL/exr_ctl_exr
exr_ctl_exr test executable: /Users/scott/src/ctl/build/OpenEXR_CTL/exr_ctl_exr/exr_ctl_exr
exr_ctl_exr test output folder will be created at: /Users/scott/src/ctl/build/unittest/exr_ctl_exr/output
-- Configuring done (2.1s)
-- Generating done (0.2s)
-- Build files have been written to: /Users/scott/src/ctl/build

[michaeldsmith]

I've not seen that debugTrapv error before. Are you sure that your shell is not doing something else like running trap?

You could try compiling CTL for Release mode and see if that fixes this issue, by running cmake like this:

cmake .. -D CMAKE_BUILD_TYPE=Release

If that doesn't work, you could try following the steps I put together in the Mac release github workflow here:
https://github.com/ampas/CTL/blob/master/.github/workflows/mac_release.yml

Those steps compile and test CTL from source on Mac using either OpenEXR 2 or OpenEXR 3

If you need to use ctlrender soon and can't get it working natively on mac, you could also try using one of the dockers that I've included in the repo.

[michaeldsmith]

@scottdyer One other thing I thought of to share with you, I have not tested the recent CTL using the AcesContainer dependency. Trying out AcesContainer with CTL is on my todo list. Its possible that AcesContainer could be causing an issue for you. The Cmake output text you included above did not mention not finding AcesContainer, so I imagine you have AcesContainer installed on your machine. Can you confirm that? When I run cmake on systems without AcesContainer, I see cmake output message indicating AcesContainer was not found, like this:

#18 0.658 CMake Warning at ctlrender/CMakeLists.txt:53 (find_package):
#18 0.658   By not providing "FindAcesContainer.cmake" in CMAKE_MODULE_PATH this
#18 0.658   project has asked CMake to find a package configuration file provided by
#18 0.658   "AcesContainer", but CMake did not find one.
#18 0.658 
#18 0.658   Could not find a package configuration file provided by "AcesContainer"
#18 0.658   with any of the following names:
#18 0.658 
#18 0.658     AcesContainerConfig.cmake
#18 0.658     acescontainer-config.cmake
#18 0.658 
#18 0.658   Add the installation prefix of "AcesContainer" to CMAKE_PREFIX_PATH or set
#18 0.658   "AcesContainer_DIR" to a directory containing one of the above files.  If
#18 0.658   "AcesContainer" provides a separate development package or SDK, be sure it
#18 0.658   has been installed.

[scottdyer]

Thanks, I do have aces_container installed and all of ctlrender used to work just fine on my machine. I don't know at what point it stopped working but it was fairly recently so maybe macOS changed something or whatever since OpenEXRs seems to be acting weird recently in macOS in terms of thumbnail previews, etc.

Also, I will note that the docker did install fine but for practical reasons I still want to get ctlrender installed natively on my system. I'll keep trying things to make sure I don't have any lingering old versions being linked or something like that. I just don't know what the dyld[93627]: Symbol not found: __Z13iex_debugTrapv error I'm getting means so it's particularly hard to know what to do next besides just clean everything and try again from scratch (which I think I've done several times but I've got to be missing something...).

[michaeldsmith]

it looks like dyld is the mac dynamic library loader [1]. I will look into compiling CTL in static mode which may avoid the use of dyld.

[1] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dyld.3.html

[michaeldsmith]

@scottdyer I found what seems to be a related issue posted in the OpenEXR repo about iex_debugTrap, it seems to match your error message __Z13iex_debugTrapv very closely

AcademySoftwareFoundation/openexr#188

It looks like @meshula has posted a work around but I'm not sure it is relevant to the latest OpenEXR releases.

You could try cleaning out your OpenEXR install on your machine and recompiling OpenEXR from source.

[meshula]

That workaround would work, although I haven't seen a need for it in many years.

[michaeldsmith]

@scottdyer I've been able to replicate a iex_debugTrap issue that may be related to your issue, if I build openexr 2.5 with cmake argument -DBUILD_SHARED_LIBS=ON on a Mac

cd ..
git clone https://github.com/AcademySoftwareFoundation/openexr.git &&
        cd openexr &&
        git checkout RB-2.5 &&
        mkdir build &&
        cd build &&
        cmake -DBUILD_SHARED_LIBS=ON .. &&
        make &&
        make install

cmake .. -DBUILD_SHARED_LIBS=ON
make

then I run cmake on CTL with the same cmake argument -DBUILD_SHARED_LIBS=ON, and then run make, I get the compile error, below. Although, I think your error was a run-time error not a compile error.

[ 21%] Building CXX object lib/IlmCtlMath/CMakeFiles/IlmCtlMath.dir/CtlColorSpace.cpp.o
[ 22%] Building CXX object lib/IlmCtlMath/CMakeFiles/IlmCtlMath.dir/CtlLookupTable.cpp.o
[ 23%] Building CXX object lib/IlmCtlMath/CMakeFiles/IlmCtlMath.dir/CtlRbfInterpolator.cpp.o
[ 24%] Linking CXX shared library libIlmCtlMath.dylib
Undefined symbols for architecture x86_64:
  "iex_debugTrap()", referenced from:
      double Ctl::CG<double, Ctl::LSSOperator<double, Ctl::CRSOperator<double> >, Ctl::NullLinearOperator>::operator()<std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*> >(std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>) const in CtlRbfInterpolator.cpp.o
  "Iex_2_5::ArgExc::ArgExc(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)", referenced from:
      double Ctl::CG<double, Ctl::LSSOperator<double, Ctl::CRSOperator<double> >, Ctl::NullLinearOperator>::operator()<std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*> >(std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>) const in CtlRbfInterpolator.cpp.o
  "Iex_2_5::ArgExc::~ArgExc()", referenced from:
      double Ctl::CG<double, Ctl::LSSOperator<double, Ctl::CRSOperator<double> >, Ctl::NullLinearOperator>::operator()<std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*> >(std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>) const in CtlRbfInterpolator.cpp.o
  "typeinfo for Iex_2_5::ArgExc", referenced from:
      double Ctl::CG<double, Ctl::LSSOperator<double, Ctl::CRSOperator<double> >, Ctl::NullLinearOperator>::operator()<std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*> >(std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>, std::__1::__wrap_iter<double*>) const in CtlRbfInterpolator.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/IlmCtlMath/libIlmCtlMath.1.5.2.dylib] Error 1
make[1]: *** [lib/IlmCtlMath/CMakeFiles/IlmCtlMath.dir/all] Error 2
make: *** [all] Error 2
Error: Process completed with exit code 2.

I suspect your system still has some remnants of OpenEXR 2.5 lingering around, can you try again to clear those old versions out and try using OpenEXR 3.1 instead?

You could try compiling openexr 3.1 as static (using cmake argument -DBUILD_SHARED_LIBS=OFF) and then building CTL like normal, and then running ctlrender shouldn't try to load openexr shared libraries at run time which I think was causing your issue.

@meshula do you think CTL should implement your work around when CTL uses openexr 2.5 with cmake argument -DBUILD_SHARED_LIBS=ON ? I have tested this with openexr 3.1 and see any issues with using cmake argument -DBUILD_SHARED_LIBS=ON

[scottdyer]

I suspect your system still has some remnants of OpenEXR 2.5 lingering around, can you try again to clear those old versions out and try using OpenEXR 3.1 instead?

I have tried everything I could to remove all traces of OpenEXR 2.5 (or 3.1). I started by removing everything in the cmake install_manifest, but then went into /usr/local/include, src, and lib to manually removed anything else left that had an Ilm, Iex, Imath, OpenEXR, or CTL related prefix.

I then did a fresh install starting with Imath, then OpenEXR, then CTL, and still get the following error

dyld[16548]: Symbol not found: __Z13iex_debugTrapv
  Referenced from: <6C5220F1-81E8-3767-B303-19318FAFB139> /usr/local/bin/ctlrender
  Expected in:     <no uuid> unknown

[meshula]

looking here:

CTL/ctlrender/CMakeLists.txt

Line 17 in 111b104

target_link_libraries(ctlrender

maybe OpenEXR::Iex needs to be added to the cmake file?

[michaeldsmith]

@meshula I created PR #160 that adds the target_link_libraries() recommended by OpenEXR Porting Guide https://openexr.com/en/latest/PortingGuide.html, adding OpenEXR::Iex and others. Please let me know if you have any comments or suggestions on the PR. I also included a docker /docker/Dockerfile_ubuntu_22.04_openexr2_shared that replicates the issue which then gets fixed by the additions to target_link_libraries()

[michaeldsmith]

@meshula thanks for your review of PR #160, it has been merged with master. I just tried building OpenEXR RB-2.5 statically using -DBUILD_SHARED_LIBS=OFF and then tried to build CTL from the master branch, I get the errors below. Do you think this is an issue with OpenEXR RB-2.5 or the CTL codebase? Do you have any suggestions on how I can build OpenEXR RB-2.5 statically and use it with CTL ? I have also attached a Dockerfile that replicates the issue.

Dockerfile_ubuntu_22.04_openexr2_static_git_clone_CTL.zip

30.43 [ 69%] Building CXX object ctlrender/CMakeFiles/ctlrender.dir/compression.cc.o
30.46 [ 70%] Linking CXX executable ctlrender
30.54 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfDwaCompressor.cpp.o): in function `Imf_2_5::DwaCompressor::initializeBuffers(unsigned long&)':
30.54 ImfDwaCompressor.cpp:(.text+0x123c6): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x123ec): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x123f9): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x125fb): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x1295b): undefined reference to `compressBound'
30.54 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfDwaCompressor.cpp.o):ImfDwaCompressor.cpp:(.text+0x12965): more undefined references to `compressBound' follow     
30.54 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfDwaCompressor.cpp.o): in function `Imf_2_5::DwaCompressor::uncompress(char const*, int, Imath_2_5::Box<Imath_2_5::Vec2<int> >, char const*&)':
30.54 ImfDwaCompressor.cpp:(.text+0x13017): undefined reference to `uncompress'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x130dc): undefined reference to `uncompress'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x1498c): undefined reference to `uncompress'
30.54 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfDwaCompressor.cpp.o): in function `Imf_2_5::DwaCompressor::compress(char const*, int, Imath_2_5::Box<Imath_2_5::Vec2<int> >, char const*&)':
30.54 ImfDwaCompressor.cpp:(.text+0x16058): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x1608f): undefined reference to `compress2'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x16824): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x1684d): undefined reference to `compress2'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x168a2): undefined reference to `compressBound'
30.54 /usr/bin/ld: ImfDwaCompressor.cpp:(.text+0x168ca): undefined reference to `compress2'
30.55 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfPxr24Compressor.cpp.o): in function `Imf_2_5::Pxr24Compressor::compress(char const*, int, Imath_2_5::Box<Imath_2_5::Vec2<int> >, char const*&)':
30.55 ImfPxr24Compressor.cpp:(.text+0x45c): undefined reference to `compress'
30.55 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfPxr24Compressor.cpp.o): in function `Imf_2_5::Pxr24Compressor::uncompress(char const*, int, Imath_2_5::Box<Imath_2_5::Vec2<int> >, char const*&)':
30.55 ImfPxr24Compressor.cpp:(.text+0x7fe): undefined reference to `uncompress'
30.55 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfZip.cpp.o): in function `Imf_2_5::Zip::compress(char const*, int, char*)':
30.55 ImfZip.cpp:(.text+0x30b): undefined reference to `compress'
30.55 /usr/bin/ld: /usr/local/lib/libIlmImf-2_5.a(ImfZip.cpp.o): in function `Imf_2_5::Zip::uncompress(char const*, int, char*)':
30.55 ImfZip.cpp:(.text+0x376): undefined reference to `uncompress'
30.55 collect2: error: ld returned 1 exit status
30.56 make[2]: *** [ctlrender/CMakeFiles/ctlrender.dir/build.make:234: ctlrender/ctlrender] Error 1
30.56 make[1]: *** [CMakeFiles/Makefile2:556: ctlrender/CMakeFiles/ctlrender.dir/all] Error 2
30.56 make: *** [Makefile:146: all] Error 2

[meshula]

Hi Michael, all those missing symbols come from libz. In later versions of OpenEXR libz should be transitively supplied via CMake, however for 2.5 I think you will have manually add a -lz or the equivalent to the CTL cmake script to accomplish it.

[michaeldsmith]

@meshula thanks for your advice about explicitly linking to ZLIB in the CTL CMakeLists.txt files when using OpenEXR 2.x, I've added PR #162 that does this, see commit c4c51ec. Please let me know if you have any comments or further suggestions.