VTK 9 build help

I’m trying to build vtk 9 with the python wrapper and including some modules I need (in particular the vtkDICOM), the mesa and building the static libraries.
The aim is to be able to use the vtkGDCMImageReader or the vtkDICOMReader in a project.

Just for information I followed these guides: GDCM/INSTALL.txt at master · malaterre/GDCM · GitHub and https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/dev/build.md. Moreover, I’m building it on a CentOS (so the cmake3 and the python executables in /opt/).

First thing I tried was to compile the gdcm 3.0.10 library including the vtk 9.0.1 build and from there generating the vtkgdcm lib in order to import the vtkGDCMImageReader in python but without any luck since I couldn’t even finish the configure part with cmake.

Then I tried the reverse: compiling the vtk enabling the gdcm (and passing a build configured only with the shared libs on) with the parameters that follows:

cmake3 \
  -GNinja \
  -D OSMESA_INCLUDE_DIR:PATH=/opt/mesa/include \
  -D OSMESA_LIBRARY:FILEPATH=/opt/mesa/lib/libOSMesa.so \
  -D Python3_EXECUTABLE:FILEPATH=/opt/python3/bin/python3.7 \
  -D Python3_INCLUDE_DIR:PATH=/opt/python3/include/python3.7m \
  -D Python3_LIBRARY:PATH=/opt/python3/lib/libpython3.7m.so \
  -D GDCM_DIR=/opt/build/gdcm/gdcm-build \

This step worked and also compiling it with ninja produced the wrapper and the wheel I needed.
Testing it, however, gives this error:

Traceback (most recent call last):
  File "test.py", line 7, in <module>
    import vtk
  File "/opt/python3/lib/python3.7/site-packages/vtk.py", line 30, in <module>
    all_m = importlib.import_module('vtkmodules.all')
  File "/opt/python3/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/opt/python3/lib/python3.7/site-packages/vtkmodules/all.py", line 14, in <module>
    from .vtkDICOM import *
ImportError: libgdcmMSFF.so.3.0: cannot open shared object file: No such file or directory

Do you have something to suggest? Thanks


PS: I need the vtkGDCMImageReader in particular since it seems that it is the only one to read compressed images. I also tried simpleITK but it is too slow when reading images.

The vtkDICOMReader is able to read compressed images, too, as long as it is built with USE_GDCM=ON.

My approach is to build GDCM with GDCM_USE_VTK=OFF, i.e. build the GDCM libs but not the vtkGDCMImageReader. Then, for VTK, I enable the vtkDICOM module and set USE_GDCM=ON. That allows vtkDICOMReader to use GDCM for decompression.

In short, it is not necessary to build vtkGDCMImageReader. You can just use the GDCM libs with the vtkDICOMReader.

Thanks for the quick response.
Unfortunately that’s not working for me. I tried what you said but it still gives me the same error when trying to import vtk from the wheel I previously created.
For the gdcm I built them enabling only the shared_libs bool while I used the same command posted above for the VTK.
Do you know if there is something that doesn’t work exactly between the two versions?
Tomorrow I can post the entire process with commands I used if needed

The error is telling you that libgdcmMSFF.so.3.0 isn’t in your runtime library path.

Have you tried adding the directory that contains the gdcm libraries to your LD_LIBRARY_PATH? After installing gdcm, did you remember to run ldconfig?

Another option is to build gdcm with static libraries.

@dgobbi Sorry to keep you waiting but in the end I solved the issue and now it is working on linux. Now I have a similar issue on windows. To build vtk I followed this guide https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/build_windows_vs.md and, after the visual studio build and install I created the wheel. After that I installed the wheel but importing it I get this error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\owner\AppData\Roaming\Python\Python37\site-packages\vtk.py", line 31, in <module>
    all_m = importlib.import_module('vtkmodules.all')
  File "C:\Program Files\Python37\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Users\owner\AppData\Roaming\Python\Python37\site-packages\vtkmodules\all.py", line 14, in <module>
    from .vtkDICOM import *
ImportError: DLL load failed: The specified module could not be found.

This is not related to the gdcm since compiling without it raises the same error. In your opinion what could be wrong?

Edit: I saw that a similar error is thrown if I remove from the Path the dll’s path. If done, the error is risen form the .vtkCommonCore’s import.

It’s very similar to the problem you saw on Linux: it’s a problem with the runtime library path.

On Windows, unfortunately, Python does not tell you the name of the DLL that it needs (it says “DLL load failed” but it does not say which DLL … it’s a very unhelpful error message!).

Please make sure that the PATH is set correctly, so that it contains all VTK DLLs, as well as all GDCM DLLs. Also, note that if you upgrade to Python 3.8, the PATH is handled in a different way.

If you solve a problem, it’s helpful to other people if you say how you solved the problem (since a lot of people read read the answers).

God sorry, I’m so stupid, I renamed the gdcm folder so the Path was not valid anymore… I’m sorry if I wasted your time and thanks

One more thing.
For the windows build I had to add to the Path also the vtk’s dll folder that was created during the installation process. However the same dlls are already present in the python wheel I managed to produce. How can I use them instead of the installed ones?

Remember to always add EVERYTHING you need to the Path/LD_LIBRARY_PATH before posting!

Just to add some infomation @dgobbi :

this is the content of the wheel produced from the vtk build process, which is pretty much the same as the one produced after installing vtk on the system.
If I add this directory to the Path everything goes fine but if I don’t do it I get the error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\owner\AppData\Roaming\Python\Python37\site-packages\vtk.py", line 31, in <module>
    all_m = importlib.import_module('vtkmodules.all')
  File "C:\Program Files\Python37\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Users\owner\AppData\Roaming\Python\Python37\site-packages\vtkmodules\all.py", line 14, in <module>
    from .vtkCommonCore import *
ImportError: DLL load failed: The specified module could not be found.

from the vtkCommonCore, meaning that the gdcm are not involved in this problem.
I was hoping to avoid adding more things to the Path, considering that these dlls are already present in the wheel.

in the following screenshot you can see what dependecies the vtkCommonCore.pyd is searching
as you can see the vtkWrappingPythonCore and vtkCommonCore are not found but these are indeed inside the wheel in the Release folder. Did I configured something wrong during the cmake process?

In the wheel, the DLLs should be in the same folder as .pyd files (in other words, there should not be a Release folder). My guess is that the Release folder was created by Visual Studio.

@ben.boeckel is Visual Studio supported for wheel builds, or is it necessary to use Ninja?

Using ninja actually solves this issue. It creates the dlls in the vtk_modules folder with the .pyd.

@dgobbi Moreover, do you know why there is so much size difference between the linux wheel and the windows one?
I see that in the windows one there are also some .pdb and .ilk files that I don’t think they belong there (this ultra-sized wheel was created with ninja while the one with visual studio actually doesn’t have these files). Do you know if there is some parameter to specify to avoid this behaviour?

Use -D CMAKE_BUILD_TYPE=Release to specify the configuration.

Multi-config generators are generally untested for anything other than local builds (this includes Ninja Multi-Config). There’s some logic attempting to work for them, but it’s tricky in general and I don’t think the wheels have gotten any of it applied to them.