Difference between revisions of "Projects:RegistrationDocumentation"
From NAMIC Wiki
Line 4: | Line 4: | ||
*considered is also a list of troubleshooting cases, i.e. a list of the most common sources of registration failure, again complete with dataset, tutorial and remedy. | *considered is also a list of troubleshooting cases, i.e. a list of the most common sources of registration failure, again complete with dataset, tutorial and remedy. | ||
*the organization of a use case hierarchy can be accomplished in several ways. The main categories are listed below. Not all combinations exist or are equally common occurrences. For example, a different-timepoint/contrast distinction is not necessary for inter-subject registration. | *the organization of a use case hierarchy can be accomplished in several ways. The main categories are listed below. Not all combinations exist or are equally common occurrences. For example, a different-timepoint/contrast distinction is not necessary for inter-subject registration. | ||
− | :#ORGAN: Brain, Head&Neck, Thorax, Abdomen&Pelvis, Limbs, WholeBody | + | :#'''ORGAN''': Brain, Head&Neck, Thorax, Abdomen&Pelvis, Limbs, WholeBody |
− | :#SUBJECT: intra-subject, inter-subject | + | :#'''SUBJECT''': intra-subject, inter-subject |
− | :#CONTENT: same_TimeOrContent, different_TimeOrContent | + | :#'''CONTENT''': same_TimeOrContent, different_TimeOrContent |
:#MODALITY: intra-modality, inter-modality | :#MODALITY: intra-modality, inter-modality | ||
− | :#CONTRAST: same_Contrast, different_Contrast | + | :#'''CONTRAST''': same_Contrast, different_Contrast |
:##MR, CT, PET+SPECT, US | :##MR, CT, PET+SPECT, US | ||
:##T1, T2, PD, T2s, DTI, MRPerfusion | :##T1, T2, PD, T2s, DTI, MRPerfusion | ||
− | :#VIEW: same_View, different_View | + | :#'''VIEW''': same_View, different_View |
==Reference Manual== | ==Reference Manual== |
Revision as of 15:19, 6 October 2009
Home < Projects:RegistrationDocumentationContents
Use Case Library
- this will contain a list of the most common scenarios encountered for Slicer Registration. Each case will contain a dataset, a parameter set, a guided tutorial with example result. The hierarchy will be represented graphically as a tree and as a list with links to the abovementioned data. The library will be as exhaustive as possible, containin brain and non-brain, different modalities (MRI, CT, PET/SPECT).
- considered is also a list of troubleshooting cases, i.e. a list of the most common sources of registration failure, again complete with dataset, tutorial and remedy.
- the organization of a use case hierarchy can be accomplished in several ways. The main categories are listed below. Not all combinations exist or are equally common occurrences. For example, a different-timepoint/contrast distinction is not necessary for inter-subject registration.
- ORGAN: Brain, Head&Neck, Thorax, Abdomen&Pelvis, Limbs, WholeBody
- SUBJECT: intra-subject, inter-subject
- CONTENT: same_TimeOrContent, different_TimeOrContent
- MODALITY: intra-modality, inter-modality
- CONTRAST: same_Contrast, different_Contrast
- MR, CT, PET+SPECT, US
- T1, T2, PD, T2s, DTI, MRPerfusion
- VIEW: same_View, different_View
Reference Manual
- This will contain detailed descriptions of each parameter and each control element within the slicer registration module. The description should help the user understand what exactly that function/parameter does and if/how useful it will be for their specific registration problem
- Preferred formats: Slicer Wiki, maybe PDF
User Manuals
- this documentation will discussing the main registration module functionality as a whole, focusing not on the individual controls but the main workflow.
formats: Slicer Wiki, PowerPoint.
- Also included in this category are Background Tutorials, explaining the basics of registration, formats: PowerPoint. Minimal understanding of the inner workings of a registration optimization algorithm is essential to understand and judge the results obtained and obtainable.
Training Video Tutorials
- These movies contain step by step instructions, running through each of the use-cases described above.
- An example of the features/character of a video tutorial is here: Media:VideoTutorialDemo_v1_0.mov
- video tutorials have become a popular and widespread form to document GUI interactions, particularly tutorials
- they can have almost the quality of direct tutoring
- they are compact in length and filesize (because the changes are local and small over time, MPEG compression is very effective with little quality loss), which makes them ideal for online distribution
- movie viewing capability is mainstream, i.e. all OS will have this capability, viewers can be downloaded for free
- the audio track can provide main instructions, motivation, commentary and an abundance of detail information at the right juncture, something very difficult to provide in other formats without overloading a tutorial
- the step by step interaction is captured unambiguously. We do not spend a lot of time and space in showing slides with screen captures.
- since they are easy to make and great software is inexpensive, potential use even for developer communication can be considered, e.g. to document complex bugs
- they have a low usage threshold, i.e. users are more inclined to watch a video than to dig through a power point presentation
- they are not all that useful for reference or main documentation material, e.g. a tutorial on main registration concepts is probably still better in PPT.
- formats: video files (quicktime, WMV, mp4 , Flash), optimized for streaming or download
Ideas for Developers
This will contain lists of ideas for GUI and function addition/improvements.
- Parameter Presets: To navigate the jungle of parameter settings and avoid complex GUI design efforts, all parameters are listed and controllable via a preset dropdown menu. The menu can then be labeled by use cases i.e. combinations of MR-MR, same contrast, inter-subject, inter-modality, fast, precise etc. Parameter sets can be saved to files and shared. Each preset becomes a menu entry. This will enable building a library of presets that can be shared among users also.
- Recursive DOF hierarchy: Both multi-resolution and the sequence of calls with increasing DOF could be implemented as a single recursive scheme. The caller provides an array of DOF and a matching array of resolution levels, which is processed by recursive calls with the first/last element taken from the list. A simulation Matlab program and example is here: Projects:RegistrationImprovement:RecursiveScheme
- The GUI can list the many combination as a single list of checkboxes for increasing DOF. The full list would be 3,6,7,9,12,b . The checked boxes provide the input string for the recursive call. Media:DOFHierarchy_GUI.jpg
- Tooltip link:direct links to Reference Manual from Widget tooltips? Can the static text or widget itself launch a link to the Reference manual entry on the Documentation Wiki? That would enable a one-click answer to "What does this button do?"
- Affine SVD: decomposition of affine into the 4 3DOF components: translation, rotation, scaling, shearing. Can an SVD do this for 12DOF vs. 3 DOF? Having values that relate directly to geometry can help greatly in evaluating and adjusting results. E.g. user can tell visually which of the 3 rotations is most out of alignment. Checking the result rotation angles already provides a quick check and valuable info about where things went awry if solution is suboptimal. Also enables to decouple individual elements, i.e. extract the shear component etc. The current "Transforms" module already does this for translation & rotation, but the scale and shear portions are missing.
- Offline WIKI: can the documentation WIKI be downloaded and used offline, e.g. for laptop users?
Links
- Developer efforts (Kitware): Projects:RegistrationImprovement
- Slicer Wiki: [1]
- Slicer Bug Tracker: [2]
- NAMIC registration:
- Contact: Dominik Meier : meier@bwh.harvard.edu