1. Level Sets Framework Refactoring Arnaud Gelas, Kishore Mosaliganti, Nicolas Rannou, Lydie Souhait, Sean Megason Boston 02/03/2011

2. Outline Goals Principles Status o Traits o Fast Marching Image / Mesh Stopping Criterion Constrained Topology Shortest Path Computation Isotropic / Anisotropic o Level Sets / GPU Plan Requirements

3. Goal: Generic Level Set Framework Multi-level set support simultaneous evolution of level sets Multi-channel support Vector or tensor data segmentation Level set representation Mesh-based (unstructured), image, or parametric Terms used in the PDE Add/delete terms in the update equation Topological constraints Stopping criterion RMS, Iterations, target points

4. STATUS Discrete Level Set

5. Traits TInputDomain TNode TOutputDomain TSuperclass

6. Traits - Base Class template< class TInputDomain, class TNode, class TOutputDomain, class TSuperclass > class LevelSetTraits { public: typedef [...] class NodePair : public std::pair [...] };

7. Traits - Image Specialization template class ImageLevelSetTraits : public LevelSetTraits, Index, Image, ImageToImageFilter< Image, Image > >

8. Traits - Mesh Specialization template class MeshLevelSetTraits : public LevelSetTraits, typename TInputMeshTraits::PointIdentifier, Mesh, MeshToMeshFilter< Mesh, Mesh >

9. Fast Marching Code available at the following address: https://github.com/arnaudgelas/itkFastMarching Numbers: o 36 tests o Tested Fedora 13, 14 (64 bits) Ubuntu 10.10 (64 bits) Mac OS-X 10.5, 10.6 o Coverage: 80.49%

10. Stopping Criterion - Base Class class StoppingCriterionBase : public Object { public: virtual bool IsStatisfied() const = 0; virtual const std::string GetDescription() const = 0; };

11. Stopping Criterion - Examples Threshold on the current value o Equivalent to the current implementation of itk::FastMarchingImageFilter<> Reached Target Nodes (One, Some, All), with possible overshoot offset o Equivalent to the current implementation of itk::FastMarchingUpWindGradientImageFilter<>

12. Constrained Topology [Tustisson'10 - Insight Journal 778] Escher's Ants as Metaphor: Topological Marching for the Well-Composed, Genus Zero Crowd

13. Minimal Path Extraction [Mueller'08 - Insight Journal 213] Fast Marching Minimal Path Extraction in ITK

14. Isotropic / Anisotropic Isotropic Can be solved using current implementation Anisotropic Several possible schemes which one the best? make it easy to implement any of these methods

15. Requirements Possible performance improvement UpdateNeighbors() calls 2 * ImageDimension UpdateValue() Thread Pool ?

16. Fast Marching - Process ? Integration Process? o Should we struggle for its integration (backward compatibility) ? o Should we struggle a second time when integrating new level sets framework?

17. Fast Marching - Process ? update software guide? o When ? o How ? o Any constraint?

18. FUTURE WORK

19. Plan Git repository Discrete Representations o Domain Traits o Iterators o Dense Term container Propagation Advection Curvature Chan & Vese energy Multithread Reinitialization Stopping Criterion

20. Plan Discrete Representations Sparse –Constrained Topology –Multithread Real time algorithm [Shi] Parametric Representations Splines RBF

21. Discrete Level Sets - simplified view (a) while( ! m_StoppingCriterion->IsSatisfied() ) (b) { (c) for each level set ls_i in the level set container (d) { (e) for each nodes n_j in the domain of ls_i (f) { (g) for each term t_k in the term container (h) { (i) Compute Term Value t_k( n_j, ls_i ) (j) Compute Term Contribution for time step computation (k) } (l) Evaluate the updated level set function ( delta( ls_i( n_j) ) ) (m) } (n) } (o) Compute time step from CFL Condition (p) for each level set ls_i in the level set container (q) { (r) Update the level set function ls_i (s) Reinitialize to signed distance function (if requested by user) (t) } (u) }

22. GPU Involvement - 1 (a) while( !m_StoppingCriterion->IsSatisfied() ) (b) { (c) for each level set ls_i in the level set container (d) { (e) for each nodes in the domain of ls_i (f) { (g) for each term t_k in the term container (h) { (i) Compute Term Value t_k( n_j, ls_i ) GPU implementation during pixel updates at (i): Pixel neighborhood in image and level set is copied to GPU memory Terms are evaluated in the GPU function Each term will have a CPU and GPU implementation A term factory will call the GPU implementation Advantages: Minimal changes in the current proposed design Drawbacks: very bad according to performance

23. GPU Involvement -2 (a) while ( !m_StoppingCriterion->IsSatisfied() ) (b) { (c) for each level set ls_i in the level set container (d) { (e) for each nodes in the domain of ls_i (f) { (g) for each term t_k in the term container (h) { (i) Compute Term Value t_k( n_j, ls_i ) Entire while loop iteration (a) in GPU Everything is copied inside the GPU memory Advantages: Fastest solution in terms of performance Downside: memory limitation of the GPU (<2 Gb) Code duplication: CPU and GPU Note: Copy b/w memory 4Gb/s

24. GPU Involvement -3 In the last scenario, the code nesting is different: (a) while( !m_StoppingCriterion->IsSatisfied() ) (b) { (c) for each level set ls_i in the level set container (d) { (e) for each term in the term container (f) { (g) for each nodes in the domain of ls_i (h) { (i) Evaluate the updated level set function [... ] In this one the GPU Implementation will occur for the most nested for loop (g) Keep copying the level set and image in each iteration in the GPU Second most optimal implementation for GPU No code duplication

25. Questions and Comments ?