Hi
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.
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:
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
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
@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.
Thanks!!
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!).
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?
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.
Edit:
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?
@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?
Thanks
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.
I am facing a similar issue. Trying to build the latest VTK-9.2.6 with vtkDicom, but everytime I am trying to import vtk in python, it gives dll load failed error.
Python version: 3.10.9 anaconda3
visual studio version: 2019
My best guess is that Python is refusing to load the gdcm DLLs because they aren’t in Python’s DLL path.
As a test, you can importing vtk like this:
import os
gdcm_path = "C:/Program Files/GDCM 3.0/bin"
with os.add_dll_directory(gdcm_path) as token:
print("importing CommonCore")
import vtkmodules.vtkCommonCore
print("importing RenderingOpenGL2")
import vtkmodules.vtkRenderingOpenGL2
print("importing all of VTK")
import vtk
You can also try copying the GDCM DLLs into Anaconda’s Library/bin folder.
