VTK 9.1 Python overloaded method call broken

It appears that vtkDICOMReader.GetMetaData.Get overloaded Python methods are broken in vtk 9.1. Tested in both Python 3.9 and 3.10, same result, so not Py-version specific.

I’m building VTK with the remote vtkDICOM module. Had been on 9.0 for a while, wanted to move to 9.1. Everything built as expected, but then the first test I ran showed an error on previously working code.

The usual background boilerplate:
vtk git tag v9.0.1 (shown below as 9.0.7068-EF)
vtk git tag v9.1.0 (shown below as 9.1.7251-EF)

Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] on win32
cmake version 3.22.1

Python 3.10.3 (tags/v3.10.3:a342a49, Mar 16 2022, 13:07:40) [MSC v.1929 64 bit (AMD64)] on win32
cmake version 3.22.3

Microsoft Windows [Version 10.0.19043.1586]
– The C compiler identification is MSVC 19.16.27045.0
– The CXX compiler identification is MSVC 19.16.27045.0
cl Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64

My minimal reproducer, overload.py.

import vtk

print(vtk.vtkVersion().GetVTKSourceVersion())

reader = vtk.vtkDICOMReader()
reader.SetFileName('tests/images/IM615')
reader.Update()

metadata = reader.GetMetaData()
#print(metadata)

print(metadata.Get(vtk.DC.StudyDescription))
print(metadata.Get(vtk.DC.ImagePositionPatient))

I’ve got my own wheel database, so I simply pip-install my local builds.

> pip install vtk==9.0.1
> py -3.9 overload.py
9.0.7068-EF
LEG LENGTH
0.000000\0.000000\0.000000

I get the following error for both Get calls, so it’s not unique to one of the DC tags.

> pip install vtk==9.1.0
> py -3.9 overload.py
9.1.7251-EF
Traceback (most recent call last):
  File "overload.py", line 12, in <module>
    print(metadata.Get(vtk.DC.StudyDescription))
TypeError: arguments do not match any overloaded methods

I diff files between 9.0.1 and 9.1.0, first the generated code. build/CMakeFiles/vtkDICOMPython/vtkDICOMMetaDataPython.cxx - no diffs in overload table, only substantial diffs appear to be docstrings. Here’s a snippet from that code, identical in VTK 9.0 and 9.1, across both Python 3.9 and 3.10; I think above example is supposed to go through the s1 variant.

static PyMethodDef PyvtkDICOMMetaData_Get_Methods[] = {
  {nullptr, PyvtkDICOMMetaData_Get_s1, METH_VARARGS,
   "@W vtkDICOMTag"},
  {nullptr, PyvtkDICOMMetaData_Get_s2, METH_VARARGS,
   "@W vtkDICOMTagPath"},

Ok, maybe the enumeration type has changed… Remote/vtkDICOM/Source/vtkDICOMTag.cxx and .h - no changes at all.

I then look at differences in the Python wrapper code, Wrapping/PythonCore/vtkPythonOverload.cxx - no changes in overload handling.

My assumption is that there’s something going on in the argument parsing and/or passing before it gets to vtkPythonOverload::CallMethod, but I’m sort of stuck there.

Anyone have some clues as to where I might poke to chase this down? @dgobbi?

The enumeration type isn’t being recognized as a valid argument for the vtkDICOMTag constructor anymore.

The generated code used to have these single-argument overloads for the vtkDICOMTag constructor:

static PyMethodDef PyvtkDICOMTag_vtkDICOMTag_Methods[] = {
  {nullptr, PyvtkDICOMTag_vtkDICOMTag_s3, METH_VARARGS,
   "@E DC.EnumType"},
  {nullptr, PyvtkDICOMTag_vtkDICOMTag_s4, METH_VARARGS,
   "@W vtkDICOMTag"},
  {nullptr, nullptr, 0, nullptr}
};

But now it just has this:

static PyMethodDef PyvtkDICOMTag_vtkDICOMTag_Methods[] = {
  {nullptr, PyvtkDICOMTag_vtkDICOMTag_s3, METH_VARARGS,
   "@W vtkDICOMTag"},
  {nullptr, nullptr, 0, nullptr}
};

The problem might have been introduced by 7903d3f1, but I haven’t confirmed yet.

I can fix the issue by removing the “; WRAPEXCLUDE” from the entry in vtkDICOM-hierarchy.txt:

DC::EnumType : enum ; vtkDICOMDictHash.h ; vtkDICOM ; WRAPEXCLUDE

I’ll work on a patch for vtkWrapHierarchy.c to properly handle enum types in namespaces.

Thanks, David. Absolutely no hurry on my part, I’ll just keep digging around and see if I can find anything else related.

I’ve submitted a fix (!9062). Thanks for reporting the issue.

1 Like

I merged your fix, rebuilt and tested. All looks good, thanks!