2017 Winter Project Week/SlicerShape

• 

  Projects List

• 
• 
• 
• 

Key Investigators

• Beatriz Paniagua (Kitware, Inc.)
• Johan Andruejol (Kitware, Inc.)
• JC Fillon-Robin (Kitware, Inc.)
• James Fishbaugh (NYU)
• Priscille de Dumast (UofM)

Project Description

Objective	Approach and Plan	Progress and Next Steps
SALT Shape AnaLysis Toolbox, will be a comprehensive software that will allow biomedical scientists to precisely locate shape changes in their imaging studies. SALT will enhance the intuitiveness and ease of use for such studies, as well as allow researchers to find shape changes with higher statistical power. Altogether this constitutes a crucial resource for the imaging field that will enable many and important new findings in biomedical imaging studies. SALT will be a packaged as a customized version of Slicer, but all different functional units of SALT will be disseminated as extensions as well and will contribute back to the platform. The main objective of this project will be touching base with the Slicer community and making sure our efforts are synergetic for other Slicer researchers.	We will have a breakout session 9am on Wednesday to talk about the different shape functionalities of Slicer, and how Slicer can help SALT and how SALT can help the platform. Come join us!! I would like to continue some discussions on how the customized versions of Slicer and Slicer co-exist. During Project Week 2016, there were discussions on how the new website was going to be and how the different Slicer eco-systems were going to be acknowledged, I wonder what happened with that. I would like to identify some key players and make a decision. I will get started developing the dissemination infrastructure and dashboards during the week I will get started developing a customized version of Slicer for SALT.	Dashboard created.

Breakout session notes

Slides

• Slicer.org bridging with all Slicer customizations available
  • We will need to change infrastructure of slicer.org to acknowledge all the different customized versions of the program. Bea will give this a go.
  • Tutorials, forums, mailinlists should be included there.

• Architectural design decisions
  • Improving support for vtkMRMLModelNode.
    • Visualization - Color maps, Surface pre-processing algorithms
    • Support for 4D support - Sequences
  • New vtkMRML*Node classes
  • S-reps

• Improving user experience
  • Providing a lot of feedback to the user
    • Quality of inputs and outputs
    • Speed, computation time
      • Obtain some sort of benchmarks of computational performance based on the OS requirements. kwsyslibrary can provide information of the program running. Another idea is to run a small subset of the batch processing and provide some information of how much did it take and how much the rest of the computation is going to take.
      • The user's frustration comes from the unexpected time delay when you run a method (expecting 1 min, waiting 1 h) Slicer has progress bars (Andras Lasso) is saying progress bar have phases and we should use it. They have a preview for parameter tuning and then they run the long method (preview on small data)
      • Running in separate process is good because you can kill the process anytime

• Thinking about the specific needs of the user base of slicerSALT
  • These methods take a lot of time to compute and usually involve a batch process
    • Greg Sharp SlicerRT has a stand-alone tool that submits and logs jobs into Slicer
    • Ron Kikinis' input is that Slicer is not really designed for not interactive things, but you can have non-interactive mode and run things
    • Girder has ways to submit jobs and save outputs into it (Breakout session tomorrow)