Difference between revisions of "2013 Summer Project Week Breakout Session:RT"
From NAMIC Wiki
Line 35: | Line 35: | ||
** Push as much as possible to the CTK level (selection in the tree etc.) | ** Push as much as possible to the CTK level (selection in the tree etc.) | ||
** Possible project for the London hackfest | ** Possible project for the London hackfest | ||
+ | |||
+ | === DICOM export === | ||
+ | * Vocabulary: Import / Export, Load / Save | ||
+ | * Location | ||
+ | ** DICOM browser? | ||
+ | ** Patient Hierarchy? | ||
+ | * Handling private tags | ||
+ | ** Commercial systems can (should) be expected to load RT data without any private tags | ||
+ | * Test re-loading back to Slicer, compare all tags except for UIDs |
Revision as of 20:34, 20 June 2013
Home < 2013 Summer Project Week Breakout Session:RTBack to Summer project week Agenda
Contents
Agenda
Patient Hierarchy
- Briefly present already implemented features and internals (Csaba)
- Discuss integration into Slicer core
- Name of the module and the common classes (SubjectHierarchy?)
- Propose SubjectHierarchy name to Ron
- What and how to generalize from SlicerRT's Patient Hierarchy
- Explore other use cases for SubjectHierarchy (Reporting/SR, Longitudinal (such as Andrey's PET/CT))
- Make sure there are no conflicts with other hierarchies (Time, etc.)
- Minimize the duplication between DICOM DB tags and PatientHierarchy attributes
- Exceptions: Modality, ?
- Suggested tasks according to loaded data, even set toolbar icons
- CLI improvements (project page)
- Support other module types: qMRMLNodeComboBox level, add to hierarchy when creating new node
- Future ideas
- Greyed-out entries from remote DICOM DB objects
- Name of the module and the common classes (SubjectHierarchy?)
Handling deformable transforms
- Meeting minutes of the Monday meeting about this
- Transforms are generally ITK objects, utilize the ITK algorithms directly?
- Invertable transforms: if non-invertable, then estimate, e.g. by converting BSpline to deformation field
- Create a roadmap so that work can start on this
- Later
- Dicom Spatial Registration Objects (SRO), Greg needs both rigid & deformable
- Registration results stored in DICOM, part of the standard
- Matrices and vector fields (possibly no BSpline)
- Implement importing these objects (in a new import plugin)
New DICOM browser
- Plan for integrating it into CTK trunk, Screenshots
- Have a superset of columns for the visualizing tables, and then define a subset on the user level
- Roadmap for accommodating those changes Slicer core
- Push as much as possible to the CTK level (selection in the tree etc.)
- Possible project for the London hackfest
DICOM export
- Vocabulary: Import / Export, Load / Save
- Location
- DICOM browser?
- Patient Hierarchy?
- Handling private tags
- Commercial systems can (should) be expected to load RT data without any private tags
- Test re-loading back to Slicer, compare all tags except for UIDs