More Pythonic VTK wrapping

[estan (Elvis Stansvik)]

Sounds good to me!

[Jens_Munk_Hansen]

I like the idea of a more python VTK wrapping. Have anybody considered how you will go the other way around. Say that you have a pipeline and after execute would like to serialize it to get the names of the filters and all their parameters to be able to easily construct the pipeline again based on this information.

Thanks in advance.

[dcthomp (David Thompson (Kitware))]

You intend for vtkAlgorithm to be iterable (iterating over connections)? There are several interpretations of what iterating an algorithm might mean:

• iterate upstream input connections
• iterate downstream output connections
• iterate output data (points, cells, field data, …)

If you intend to iterate connections (upstream or downstream), then what happens for algorithms with multiple inputs/outputs? Say I had

p = (vtkSphereSource, vtkSphereSource >> vtkTransform) >> vtkAppendPolyData

How would one know to write

(sphereA, (sphereB, transform)), append = p.upstream()

to recover the pipeline without already knowing the structure? Or if you intend merely to return the structure for users to process, a use case for how it would be processed might help motivate the feature. The above is one potential interpretation, but did you also intend to capture non-default parameters? What about multiple ports vs. multiple connections on a single port?

[Jens_Munk_Hansen]

@dcthomp

users to process, a use case for how it would be processed might help motivate the feature. The above is one potential interpretation, but did you a

I would just like to return the structure of the pipeline for a user to be able to establish all input connections and perform Update() and GetOutput() on an output port.

[dcthomp (David Thompson (Kitware))]

1. Setting up input connections should have been done already (how else could you get upstream filters?).
2. You should not need to call Update() on anything but the terminal filter(s).
3. If you want to call GetOutput() on upstream filters, how will you know which one in the pipeline you want?

There is already a way to traverse the pipeline, it is just not very pythonic. But without a good use case, there is not a strong motivation to make it easy (it comes with the cost of maintenance and may conflict with unforeseen use cases that arise in the future).

[Jens_Munk_Hansen]

1-2) I know that. 3) I picture a situation where I have a pipeline and an output, i.e. I have just called Update() and GetOutput() on a filter (not necessarily a terminal filter). Then, I would like to get the information needed for establishing a pipeline (perhaps only a fraction of the pipeline) to produce the output that I just received.

The state of the output is uniquely determined by the filter in the pipeline and input data. For this situation, it would be awesome if it was possible to query a list of parameters for a given object. I know how this is done in ParaView and this can be achieved by replacing the macros, vtkSetMacro, vtkSetBooleanMacro etc.

[lassoan (Andras Lasso)]

@dcthomp

p = (vtkSphereSource, vtkSphereSource >> vtkTransform) >> vtkAppendPolyData

I’ve just quickly browsed through this thread and my only comment is that I’m not sure if the syntax that uses bitwise shift operator for building and connecting pipelines “pythonic”. Using >> to connect filters is an interesting, very compact syntax that C++ developers who used streams can relate to, but it may not look familiar at all to Python developers.

If the goal is still what the topic title is - More Pythonic VTK wrapping - then it might worth getting some feedback from Python developers (those who have never seen C++ code) to see if they like the proposed API.

[berk.geveci]

Thank you for your input Andras. But after several rounds of voting, we settled on >> and I put a decent amount of time into making it work. I am afraid that it is too late to change.

[jaswantp (Jaswant Panchumarti (Kitware))]

Appreciate your feedback!

@lassoan

If the goal is still what the topic title is - More Pythonic VTK wrapping - then it might worth getting some feedback from Python developers (those who have never seen C++ code) to see if they like the proposed API.

Yes, that has been the goal since the beginning and the operator choices were open for public votes. I think we can still choose something else if the python developers in our community come up with a better alternative. However, it would take some effort to replace existing code.

Berk, more or less has taken inspiration from fenics’ use of << operator in python.

More Pythonic VTK wrapping

While it may be nice to easily define pipelines, I wonder if >> or | really are pythonic in some way, so it still will be a “custom VTK stuff”. But I’m not a day to day python user, so I defer to them I have seen the use of custom operators. Examples: pyTorch, numpy etc added the @ operator for matrix multiplication (which took me a while to figure out!), Fenics uses the << operator to output vis data. I believe what is pythonic about it is using a shorthand to perform an opera…

[lassoan (Andras Lasso)]

Maybe just try to keep things as open as possible (don’t bet everything on that Python developers will be happy to use >>) and try to go to places for feedback where the target audience is (ordinary Python developers are not represented well in a discussion in the Development category of the VTK forum).

[berk.geveci]

Sounds good. Btw, we did have some folks from the Python vis community (from pyvista and vedo).

[amaclean (Andrew Maclean)]

Here is an example that displays Gaussian and Mean curvatures of a surface along with normals colored by elevation.
There is also a text widget and scalar bar widgets. With respect to these, there are a lot of positioning parameters.

Most of the properties of VTK classes are initialized when they are instantiated.
While I was doing this I came across issues where I wanted to use the VTK constants, however they are usually created in the C++ code by #define.... I considered several approaches e.g dictionaries and named tuples, however the best solution I found was to use the Python data class. This has the big advantage that the defined VTK constants are visible and are constants. Just like in the C++ code.

Have a look at CurvaturesNormalsElevations and How to handle #defines

You will see that, after defining the data classes, we just use them in the relevant VTK class:

        glyph_mapper = vtkPolyDataMapper(scalar_range=v['scalar_range_elevation'],
                                         lookup_table=v['lut1'],
                                         scalar_mode=MapperScalarMode().VTK_SCALAR_MODE_USE_POINT_FIELD_DATA,
                                         scalar_visibility=True,
                                         color_mode=MapperColorMode().VTK_COLOR_MODE_MAP_SCALARS)

[amaclean (Andrew Maclean)]

An update, I have done more work on dataclasses and I now believe I have a “useful” solution. In my opinion, this makes initializing the VTK classes even better. Being able to now initialize by using variables from dataclasses in the constructor of a VTK class is fantastic!

Please look at How to handle #defines using dataclasses and VTKDataClasses.

So far, around 218 classes in 65 examples have been used with no particular issues. I have mentioned a couple of little things that I have seen here: PythonicAPI hints and here: Python hints

@berk.geveci FYI

[mwestphal (Mathieu Westphal (Kitware))]

So it looks like this has settled now, great!

Updated URL: https://examples.vtk.org/site/PythonicAPIComments/

Should this be documented in docs.vtk.org ?

[amaclean (Andrew Maclean)]

It is pretty stable, I haven’t added anything new to it for a while now. I have currently written about 250 examples covering 490 classes with no major issues. The only outstanding issue is set/gets with an index.
So, yes, I think it would be a good idea