[vtk-developers] Driving away your existing developers

[David Gobbi]

On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci <berk.geveci at kitware.com> wrote:

> One final note. Everyone please keep in mind that while there are quite a
> lot of contributors to VTK, certain parts of it are developed by only a few
> people. Core pipeline: I am it at this point. Rendering: by next year, it
> will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at
> Kitware does anything with imaging filters. We update them when we make
> changes to the pipeline or data model but that's it. So some of those are
> maintained and developed by others or they are some orphaned. This can only
> be addressed by either encouraging new (or existing) developers to take
> ownership or by removing those components all together.

I have tons of plans for the VTK imaging classes, but unfortunately I have
almost no resources so progress is slow.  Some examples:

1) Improving both the API and the performance for multi-threading.
Last year I worked with an intern to improve load sharing.  Never had
time to finish, because it wasn't the intern's main project.

2) Basic linear image registration in VTK.  I've finished it and it's
very robust (been using it for years), but refactoring so that it can
be contributed to VTK is an evening/weekend project and hence is
moving slowly.

3) Better image iterators.  I have a nice image iterator that iterates
over arbitrary shapes and also provides coordinate info while it
iterates.  I'd love to develop this further and contribute it, and I'd
especially love to wrap it, but it's out in left field as far as my
day job goes.

4) Better filters for going back and forth between image data and
polydata.  Lots of people use my vtkPolyDataToImageStencil filter,
but it has faults and I know exactly how to fix them, but I'll have to
wait until it comes up as a priority for one of my work projects.

5) Finally, a better overall structure for the imaging pipeline,
focused on the basics:
 a) scalar operation "functors" that can be plugged into filters
 b) interpolators, which I've already committed
 c) good image "region" descriptors (like my vtkImageStencilData)
 d) connectivity & morphological operations, I've got lots of un-committed stuff
 e) a replacement for the lousy vtkImageMathematics filter

Ideally I should write out a big roadmap (the items mentioned above
is just a fraction of the total), but it would be depressing because so
much of it feels like it's nothing more than a pipe dream.

And, as Berk mentioned, there isn't anyone in Kitware for me to
directly work with on this stuff.  And all the other VTK imaging
developers outside of Kitware are content to keep their work to
themselves, without contributing back to the VTK core.  Or at least,
that's the way it looks from my vantage point.

 - David