Notes

Notes

Todo

• Add boolean operation module (based on network editor). It's also good for clipping side-branches and capping.
• Add script for editing label maps.
• Write vmtk-cfd input file generator.
• Level set segmentation: intermediate save option. Allow a binding (with Ctrl+q?) along the script.
• vmtksurfaceclipper: add possibility to force box orientation along XYZ (for Lattice-Boltzmann simulations).
• Compile against ITK4 (and remove dependency of vmtk ITK classes on vtkVTKTIK). This will solve the git protocol issue with SuperBuild (IN PROGRESS).
• Remove q/e binding (and similar bindings) upon input text interaction.

Fixes

• Fix quadratic projection for meshes with boundary layers (for every wedge in the boundary layer, apply same (or reduced) shift of mid-side nodes))
• Surface remeshing: avoid skrewy collapse for coarse meshes on small tubes
• Adapt flow extensions to flipped normals
• Level sets: undo chance after merging (in general: undo should be added to level sets, clipping, ...)

Jots

• Similarly to the BROWSER option, insert the QUERY option (could be useful in cases like vmtkimageviewer -ifile foo.vti - -pipe vmtkmarchingcubes -l QUERY - -pipe vmtksurfaceviewer)
• Level set initialization: limit to interactive box (either just for isosurface or for all)
• Write triangle reorientation class based on consistently oriented normals
• Add capping based on vtkWeightedTransformFilter
• Add script based on vtkImplicitModeller
• Manual segmentation using: seeds -> RBF -> level set seeking minima of RBF.
• Implement vmtkcenterlineselector

Structural improvements

vtkvmtkCenterlines

• Create a new data type, vtkvmtkCenterlines derived from vtkPolyData (and that uses the vtp file format). This will greatly simplify vmtk code and potentially incorporate functionality now in vtkCenterlineUtilities etc. Right now the code is almost procedural, just to preserve vtkPolyData unmodified. It would instead be way better, from a design point of view, to have new data types (that could use the same file formats as their ancestors storing additional information in arrays) and simpler filters and operations. This would also simplify managing trees or networks of centerlines. Also, vtkvmtkCenterlines could be a base class that could have several specializations (e.g. centerlines meeting at a bifurcation center or not).

• centerline splitting and grouping is not bullet-proof. It can fail in very weird situations. It would be good to review the code (and maybe lifting the tree assumption)

• branch clipping should use a connectivity criterion (region growing?) to ensure avoiding islands in strange geometries

• write script for computing eikonal solution on the Voronoi diagram starting from centerlines (it's useful for incrementally adding more detail to the tube description). The code is there in vtkvmtkNonManifoldFastMarching but it initializes from interseceted edge endpoints, not from the actual intersection points.

• write class with Voronoi saliency measurements (not using centerlines, like sphere ratios etc)

• write selective smoothing filter

• implement image orientation strategy

• use concrete array types (vtkIntArray, vtkDoubleArray) and call DeepCopy when fetching the array from PointData or CellData: DeepCopy handles eventual type casting.

• implement support for oriented images

• offset attributes on unsplit centerlines