Remove VTK dependency

[madsendennis]

Scalismo currently relies on the VTK library for many computations. This dependency is the main reason that Scalismo does not easily run in a container environment.
To make that work, VTK itself also needs to be installed in the container (which makes the containers a lot larger).

The VTK library is also often far from fast - probably due to converting to/from the vtk format.

I would therefore suggest to eventually have the VTK dependency removed from Scalismo.

This would have implications on:

• Mesh decimation
• Mesh I/O
• Tetrahedral mesh

And a lot of:

• Image I/O and operations

Maybe some of the things are not needed to be supported in the future, which is why I opened this ticket as a discussion as well to hear more view points on this "problem".

[marcelluethi]

@madsendennis Thanks a lot for all your efforts for removing vtk. I think with what you have provided so far we should bring us very close. I don't worry so much about the image part. We have a pure java nifti reader/writer. Image operations such as Gaussian smoothing are, as far as I know, not often used. We could just move them into a separate module. The module could, in essence just provide a converter between scalismo and vtk objects. In that way, a user could use all of vtk from Scalismo, without us having to invest a lot of effort in providing a tight integration.

[madsendennis]

I discussed another possible move with @Andreas-Forster .
To move everything (non-vtk) to a new library scalismo-core. Scalismo would then depend on this library + still include all the current VTK functionality. In this way, normal users will not see a difference in using scalismo, but we would then have a scalismo-core with a much smaller footprint, more appropriate for production use.
The main disadvantage as I see is that every update to scalismo-core will also trigger an update to scalismo and then scalismo-ui and scalismo-faces.

[marcelluethi]

This is another good possibility. Maybe its even just a difference in naming. The difficulty with the transitive updates seems manageable.

I have a preference for making Scalismo itself simpler rather than carving out the core. After the work you have now contributed, all essential functionality that are needed to write full shape modelling applications is there. If we name this Scalismo, we can tell users that they can get more functionality by combining it with the VTK library (at the expense of a couple of hundred MB footprint and reduced portability). This feels to me different than offering a library called Scalismo, which has a footprint of 300 MB, but you can reduce it to a few MB by using only its core. I guess at this level it's just psychology.

It might however, make a practical difference in terms of maintenance. Maintaining Scalismo (withouth VTK and other native libraries) is a very manageable task. Adding natives adds a lot of overhead. If at some point we feel overwhelmed by the complexity of maintaining VTK libraries, we can independently stop supporting it, while still providing full maintenance for Scalismo. Especially now that web alternatives to scalismo-ui start to emerge, this could be a likely trajectory in the next few years.

@Andreas-Forster What do you think?

[madsendennis]

After discussing the "problem" offline with @marcelluethi and @Andreas-Forster , the path forward is to try and make scalismo into a lightweight native scala library.
All VTK dependent functionality will be moved to another repo scalismo-vtk. The main implication is that support for all .vtk files is dropped in scalismo and moved to scalismo-vtk. This means that until a substitute format is found, formats such as: ScalarMeshField, LineMesh, TetrahedralMesh, ScalarVolumeMeshField and .VTK reader/writer for e.g. TriangleMesh is not included in the scalismo library.

[madsendennis]

In the future scalismo will not contain any vtk components. These components have been moved to scalismo-vtk, which depends on scalismo. Furthermore, all Active Shape modelling (ASM) aspects have been moved to scalismo-asm (as it also had some vtk dependencies and is rarely used).
A release branch has been created with native components merged in and vtk removed: https://github.com/unibas-gravis/scalismo/tree/release-1.0
When this branch is stable, it will be the foundation for a 1.0.0 scalismo release.