<div dir="ltr">I would love to see more of your excellent work, David, and I'd want to make use of it, but I'd argue that at least some of it, perhaps registration, may not belong in VTK itself.<div><br></div><div>
Speaking for myself from my experience in the slicer project, I can say that we end up putting a lot of our functionality in classes that don't belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of which adds functionality that is independent of our slicer application, but adds a layer of dependencies that nobody would want to see in VTK itself.</div>
<div><br></div><div>On my wishlist for VTK would be a better way for new developers to contribute their work so that it's easily usable by others but doesn't have to pass the gauntlet of reviews and comments and be in VTK before it is easily usable by others. I'd like to see an experience more like npm for node, where anyone can publish a domain-specific set of code and other people can use it or not as they see fit. Node itself remains small and it rarely changes, but the ecosystem is quite vibrant. It allows a lot of diversity, but amazing interoperability and reusability.</div>
<div><br></div><div>In slicer we have something similar now with the Extension Catalog, where developers can offer code (either pure VTK or things that work at the VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform nightly builds and test it on all platforms, this code is in reasonable shape for other people to draw from, either in slicer or elsewhere. Typically these extensions are in github repositories, so they have their own wikis, issue lists, pull requests, etc. We hope that slicer itself actually gets smaller over time and generally doesn't need to change very much or very often.</div>
<div><br></div><div>I would love to see something similar in VTK proper. Right now VTK has a lot of modules that are quite domain specific, such as Chemistry and Geovis which I do not envision using myself. I would have preferred to see that code exist in a different repository where people who needed it would have the option of including it in their superbuild process. Others could safely ignore it. I would even argue that half (or more) of the current modules don't really belong in the 'actual' VTK and should be moved out. If there were a good place to put some of this kind of code it might also be a good spot for libraries like vtkITK and vtkTeem. In fact I would argue that if it weren't actually in VTK's repository, a project like vtkChemistry might attract more participants and have more features (but I can't prove that of course).</div>
<div><br></div><div>So basically I'd say that VTK is currently too big and should get smaller, while the community is too small and should get bigger.</div><div><br></div><div>-Steve</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
<br>
> One final note. Everyone please keep in mind that while there are quite a<br>
> lot of contributors to VTK, certain parts of it are developed by only a few<br>
> people. Core pipeline: I am it at this point. Rendering: by next year, it<br>
> will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at<br>
> Kitware does anything with imaging filters. We update them when we make<br>
> changes to the pipeline or data model but that's it. So some of those are<br>
> maintained and developed by others or they are some orphaned. This can only<br>
> be addressed by either encouraging new (or existing) developers to take<br>
> ownership or by removing those components all together.<br>
<br>
I have tons of plans for the VTK imaging classes, but unfortunately I have<br>
almost no resources so progress is slow. Some examples:<br>
<br>
1) Improving both the API and the performance for multi-threading.<br>
Last year I worked with an intern to improve load sharing. Never had<br>
time to finish, because it wasn't the intern's main project.<br>
<br>
2) Basic linear image registration in VTK. I've finished it and it's<br>
very robust (been using it for years), but refactoring so that it can<br>
be contributed to VTK is an evening/weekend project and hence is<br>
moving slowly.<br>
<br>
3) Better image iterators. I have a nice image iterator that iterates<br>
over arbitrary shapes and also provides coordinate info while it<br>
iterates. I'd love to develop this further and contribute it, and I'd<br>
especially love to wrap it, but it's out in left field as far as my<br>
day job goes.<br>
<br>
4) Better filters for going back and forth between image data and<br>
polydata. Lots of people use my vtkPolyDataToImageStencil filter,<br>
but it has faults and I know exactly how to fix them, but I'll have to<br>
wait until it comes up as a priority for one of my work projects.<br>
<br>
5) Finally, a better overall structure for the imaging pipeline,<br>
focused on the basics:<br>
a) scalar operation "functors" that can be plugged into filters<br>
b) interpolators, which I've already committed<br>
c) good image "region" descriptors (like my vtkImageStencilData)<br>
d) connectivity & morphological operations, I've got lots of un-committed stuff<br>
e) a replacement for the lousy vtkImageMathematics filter<br>
<br>
Ideally I should write out a big roadmap (the items mentioned above<br>
is just a fraction of the total), but it would be depressing because so<br>
much of it feels like it's nothing more than a pipe dream.<br>
<br>
And, as Berk mentioned, there isn't anyone in Kitware for me to<br>
directly work with on this stuff. And all the other VTK imaging<br>
developers outside of Kitware are content to keep their work to<br>
themselves, without contributing back to the VTK core. Or at least,<br>
that's the way it looks from my vantage point.<br>
<br>
- David<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br>
<br>
The information in this e-mail is intended only for the person to whom it is<br>
addressed. If you believe this e-mail was sent to you in error and the e-mail<br>
contains patient information, please contact the Partners Compliance HelpLine at<br>
<a href="http://www.partners.org/complianceline" target="_blank">http://www.partners.org/complianceline</a> . If the e-mail was sent to you in error<br>
but does not contain patient information, please contact the sender and properly<br>
dispose of the e-mail.<br>
<br>
</blockquote></div><br></div>