Difference between revisions of "2017 Winter Project Week/SlicerShape"
From NAMIC Wiki
Jfishbaugh (talk | contribs) |
|||
Line 36: | Line 36: | ||
| | | | ||
<!-- Progress and Next steps bullet points (fill out at the end of project week) --> | <!-- Progress and Next steps bullet points (fill out at the end of project week) --> | ||
− | * Dashboard created. | + | * Got started with setting up the testing infrastructure |
+ | ** Dashboard created. | ||
+ | ** [https://github.com/Kitware/slicerSALT Repository created] | ||
+ | * Important design decisions were made thanks to the breakout session | ||
+ | ** Batch processing approaches | ||
+ | ** Slicer interaction | ||
+ | * Some modules have started to make progress and have working prototypes | ||
+ | ** James | ||
+ | ** Priscille | ||
|} | |} | ||
− | |||
− | |||
− | |||
==Breakout session notes== | ==Breakout session notes== | ||
Line 47: | Line 52: | ||
* Slicer.org bridging with all Slicer customizations available | * 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. | ** 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, | + | ** Tutorials, forums, mailing lists should be included there. |
* Architectural design decisions | * Architectural design decisions | ||
Line 69: | Line 74: | ||
*** Ron Kikinis' input is that Slicer is not really designed for not interactive things, but you can have non-interactive mode and run things | *** 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) | *** Girder has ways to submit jobs and save outputs into it (Breakout session tomorrow) | ||
+ | |||
+ | |||
+ | ==Background and References== | ||
+ | <!-- Use this space for information that may help people better understand your project, like links to papers, source code, or data --> |
Revision as of 13:56, 13 January 2017
Home < 2017 Winter Project Week < SlicerShapeKey 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 |
---|---|---|
|
|
|
Breakout session notes
- 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, mailing lists 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 support for vtkMRMLModelNode.
- 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
- Providing a lot of feedback to the user
- 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)
- These methods take a lot of time to compute and usually involve a batch process