It seems that the call to Update() is not sufficient to guarantee that the scalar range values are up-to-date by the time I call GetSpacing(), because depending on how I run my program, I get either the correct result or not. When I run my program (debug build) normally, the values are 0.0. When I run it via the debugger, the values are correctly corresponding with the volume being read. So there must be a timing-related issue here.
Any suggestion on how to make sure that I don’t access data before the volume has been fully read ?
Strangely, the error code is NoError in both cases (running with and without debugger). I observe the issue on Ubuntu, but not on MacOS. Using VTK 8.2.0.
I should probably make a minimal example that generates the issue.
Yes, same input data, same code. The only difference is whether I run the executable with or without the debugger (from Qt Creator IDE). Really puzzling.
This is just one of the many issues with the DICOM reader bundled with VTK by default. I would strongly recommend to use @dgobbi’s excellent vtkDICOM library instead.
To reduce confusion among users, it would be great if the legacy DICOM parser could be removed from VTK and vtkDICOM could be included as an optional VTK remote module. @ben.boeckel I know that you are not a fan of VTK remote modules, but this is another good example where it would be very useful to be able to build VTK with proper DICOM support with the flip of a CMake flag. VTK Python wheels should be also built with vtkDICOM added (instead of the old flawed DICOM parser).
On a general note: if it is not obvious to everyone yet, sscanf should not be used in a library for converting text to double (as a library cannot dictate what locale the application must use). Instead C++ streams and imbue(std::locale::classic()) can be used - as it is done already in vtkDICOM and at a number of places in VTK. Unfortunately, there are still a lot of legacy sscanf usages in VTK IO classes.
My intent is to get vtkDICOM into the VTK repository, and I’m around 75% of the way there. Ben has been supporting the effort via code reviews. However, I cannot say when I’ll be finished.
I’m just worried because I see VTK losing ground against hundreds of new, immature, low-quality Python visualization packages. Having a small VTK core and a network of independently maintained packages would go a long way in preserving VTK’s relevance and keeping its development sustainable. For example, you can merge vtkDICOM, but you don’t want to merge and take the ownership of all the other potentially interesting modules.
The remote module concept has proven to work well for ITK (they have now more than 40 remote modules), so it would be an obvious solution to port it to VTK as well, but of course there could be other approaches, too. I understand if nothing is done because there other priorities, no funding, etc. but there should be at least a desire to build a healthy ecosystem of contributed libraries around VTK.
Sure, I want this too. Rendering, IO, Filters, etc. should all be separate projects (if not repositories) as far as I’m concerned, but these are political issues that are hard to progress given the momentum today. ParaView embedding VTK is a blocker to any real progress of splitting VTK anyways, so that’s my main concern right now on this front.
The main problem I see is that if I have remote modules A, B, and C and you have A, B, and X. We need a brand new, from scratch VTK build to combine them at all. I can’t “just add X” (nor can you “just add B”) if remote modules are how they work. If, instead, they use VTK as an external dependency (just like any other dependency they may have), we could just do VTK+A+B+C+X as separate builds and be done with it. This kind of thing basically makes pip install vtk a crapshoot of what is actually included and why I don’t want to include any of them in the official wheels. There is support for building your own as you see fit with whatever options you want though.
It is unfortunate that Python has a poor (no?) solution for non-Python dependency links between Python packages, but I don’t know how one would expect us to solve that for them. Anaconda is probably better there since it acknowledges things like C++ libraries and linking between packages and offers real install prefixes (rather than a directory extracted somewhere nothing else looks at by default).