See Also: Slicer3:Editor
- 1 Iterative design proposals for Slicer3 Editor module
- 1.1 Editor design sketch 5. GENERATION 1 ROI Toolbox and Editor Module draft
- 1.2 Editor design sketch 4 (ROI toolbox):
- 1.3 Editor design sketch 3 (Editor module -- see toolbox below):
- 1.4 Editor design sketch 2:
- 1.5 Editor design sketch 1:
- 1.6 General User feedback on existing Slicer2 editor module:
- 1.7 Region drawing:
- 1.8 Label map editing:
- 1.9 Label map saving:
- 1.10 From label maps to models:
- 1.11 Schematics illustrating some challenges in existing Slicer2 editor:
- 1.12 KidDefib Project Feedback
- 2 PNL RA Slicer3 Editor Meeting February 26, 2008
Iterative design proposals for Slicer3 Editor module
Working project: design iterations and user feedback on this page.
Editor design sketch 5. GENERATION 1 ROI Toolbox and Editor Module draft
Below is a proposed set of "generation 1" functionality excerpted from the design above (including label maps but no vector-based ROI definition). This plan would target, as a first priority, development of the functionality contained in Slicer2, in order to support transition of Slicer2 users to Slicer3. Later development could incorporate the vector-defined ROIs and accompanying functionality (including overlapping ROIs) identified in the design above. Shown below are the ROI toolbox first, which would be available from the Slicer3 toolbar, and the mock-up Editor Module below it.
General feedback on draft designs
Please contribute your thoughts about the draft design here!
Draft design is looking great.
PreviewEdit is an excellent idea, along with making multiple versions with undo & redo functions. This would eliminate traveling across the Viewer to the Menu. I very much like the idea of a floating GUI panel for editing (changing colors, especially to black “0” for editing outline, very useful). Would this idea be the same as a floating color palette? The ‘eye-dropper’ would have to be somewhat small.
As for saving the Label map, origLM / newLM (or some other tagging) would be fabulous. This would help with training boundary areas as well as help with editing process.
I would suggest NOT changing colors of ROI for the Editor preview, but use dashes / broken lines to indicate the ROI working on as opposed to the solid lines.
I agree with not changing the hot-keys, and that the “Outline labelmap” should be by default “off” – maybe this could be worked out along with the editor preview tab?
As for editing ROI, selecting points & vertices & moving them is an excellent idea. I’m not sure if “snap the slice viewer to slices that contain anatomical markers” is the same thing. Some of the structures we’re outlining (e.g., hippocampus, amygdala, entorhinal cortex) are next to each other but in some planes it is difficult to see the boundaries. Editing a superior-anterior line in a few slices while drawing the next ROI would be much easier than it is now. This is not the same as “overlay & composite multiple label maps over a single grayscale image”, which would also be great. Slicer2.7 let’s me make more than one ROI / labelmap, but then I donot have the option to only select to show the hippocampus, for instance, without the amygdala. It was too cumbersome to create individual labelmaps for each ROI per case. Also, making the “double-assigned regions very visually conspicuous” is useful with this. Not sure how hard that would be (a voxel receiving 2 tags for color automatically becomes white)? The idea of applying editing operation to multiple label maps at once sounds good but I’m not sure if I understand. Would it be something like selecting both the hippo & amyg ROI and edit 5 anterior slices and both ROIs change voxel selection?
Using a threshold on an existing labelmap would help a great deal with editing, especially with atrophy. Per case, after a ROI is created, if you could determine the ‘threshold’ for the gray matter, say between 53 & 81, and then select some tab that will assign “0” for any voxels within the ROI area that is below 53 or above 81, that would shorten edit time.
I didn’t understand sub-voxel issues, although I create a 0.65^3 matrix out of our ~1^3 voxels. Would the ROI work better without a snap-to-voxel center? I think it would make the shape less sharp. (Maybe this would take care of smoothing in model?)
I personally liked Editor design sketches 2 & 3 –> sketch 2 with #3 drop-down frame w/icons on the left of the menu box. Are there plans for keyboard controls for the individual icons? I know this might become complex, and time & money are important considerations. I occassionally accidentally hit the down arrow key and change the Mode, but I can see how this could be important if you went with the “Mouse mode / Draw type” in sketch 2. I like the idea of disabling widgets when not needed (after selecting color, line / stroke thickness, draw type & style) and then keyboard function or Menu tab for changing to another label or stats or modeling.
Under Notes, I think I understand the flow of commands as: Guides = objects (unclosed polylines & vertices) make into ROIs = objects (closed polylines & vertices) make into Labels = volume data. Multiple keyboard uses is helpful for multiple selections.
It would be beneficial to us if our ROIs written in Brains could be read and manipulated in Slicer.
I’m not sure if Sketch 3 is the only design with the tool/function icons but I like them better than the words. Also, if it’s possible to design, as some of the icons are part of a “loop” if they could all be one color (but maybe not same color as the planes are currently). Tara McHugh, Dartmouth Medical School
Editor design sketch 4 (ROI toolbox):
Sketch of the way a subset of ROI-definition-and-editing tools are exposed application-wide in Slicer3, with a jump-button to the editor module. The Editor module will contain a superset of that functionality.
Interface (in a panel that drops down when the toolbar menubutton is clicked) is shown below, along with icon that displays it, and mouse-mode button that indicates active mode when any of the tools are selected. The 'pin-open" icon in the lower right can be clicked to turn the drop-down panel into a top-level frame that stays open while you work. The frame can be re-positioned on the desktop and dismissed with one click.
Icons below are drafts -- they can be refined to make their representation stronger.
- Labels are volume data
- ROIs are objects (polylines and vertices)
- Guides are objects (unfilled, unclosed polylines and vertices)
- Guides, ROIs and their vertices can be selected
- Guides can be converted to ROIs
- ROIs can be converted to Labels
- Ctrl-click for multiple selection
- Shift-click for: selecting all objects of one type (in selection tools) or snapping-to-0,90,45-degrees (in draw tools)
- All tools will have hotkeys
- Tools used in tight loops will have spatially clustered hotkeys
- Useful here to use fiducials as "bread crumbs" in different slice planes, and quickly navigate between them while working
- Need a way to visually indicate persistent tools (paint, draw freehand polyline ROI, etc.) and mouse modes Slicer-wide.
- Default persistent tool is "select an ROI" (maybe there's a better choice?)
- ROI toolbox will have a subset of editor module functionality. If both panels are open at the same time, they must both show what tools are selected (if the tools are shared in both) when those tools are persistent. So we will need to encapsulate this info properly (in a MRML node).
- Should read/write Brains-compatible ROI format
- Shoudl read DICOMRT format (when support is available)
Editor design sketch 3 (Editor module -- see toolbox below):
Sketch of the editor module (current prototype and proposed design, to be compatible with Editor toolbox (subset of Editor module tools available application-wide). The figure below shows the editor module prototype currently available in Slicer3, and a design for organizing and exposing existing and proposed functionality. The design proposal includes all ROI toolbox functionality, plus some advanced features that may require more careful parameterization. (See ROI toolbox description and interaction design below for more information).
Editor design sketch 2:
Revised sketch that incorporates some additional points from user-session (in progress):
- addressing the 'select mode' (rubber box, lasso, pick)
- ability to keep points and lines visible (lines drawn one-pixel wide and in some reserved non-label color, and points drawn in some stylized way like 1voxel x 1 voxel square outlines) until deleted?
- should there by two separate polygon and filled-polygon modes (is this ever useful?)
- integrating a "sub-voxel" draw mode, making its behavior visually distinct from the usual snap-to-vox-center-and-include draw mode.
- thinking about how "preview-and-apply" might work: Assume that the preview box is checked by default. Preview shows the line and point representation (should it also show a preview of the final stroke and fill in the label color before "Apply" is clicked?). The stroke and fill (if appropriate) are "officially" generated when "Apply" is clicked, but should be undoable.
- Render, Interact, and Scope: are these used consistently across Effects panels? Various of these widgets appear in several Effects panels, so does it make sense to bring them out into the persistent top part of the GUI panel -- and just disable them (grey them out) for Effects for which they're not relevant?
- Also, "active label" or "working label" or "output label" appear frequently in different effects panels. Can we consolidate the functionality they offer across effects and bring them out to the persistent part of the GUI? Below is undoubtedly wrong, but serves as a placeholder.
- Note: floating tool palette brought up with "Editor toolbox" toolbar icon, and floating color select/pick palette brought up by Editor-bound hotkey.
We also will need to list out a set of hot-keys that everyone agrees upon.
Questions and Feedback on editor design sketch 2:
- Ok to bring the label statistics/metrics into a separate "Label report" panel in the Editor module? (easy to find)
- The "runtime report" -- do you need a "start/stop" timer on here? How do you use this?
- Not sure yet how to consolidate functionality across "working label, output label, and Render, Interact and Scope" (We can think about how to do this together) -- Does it make sense to you to have something like this as an Editor-wide specification (with widgets disabled when they're not relevant to a particular editor effect) or would you prefer to have the selector inside each Effects panel.
- Are the icons understandable?
- Anything obviously or subtly impacting region drawing workflow that we should fix/improve?
Editor design sketch 1:
Based on the above sketch, here's a first draft of an editor module redesign, using the Draw effect as an example. Effects palette has been replaced with icons (these are stand-ins for now). Possible pop-up editor toolbox and color selection palettes are also shown to the side. This is meant to be used as fodder for discussion with users and developers. The sketch tries to maintain similarity to the Slicer2 GUI to maximize the transfer of skills to the new package -- but there will be changes; we should discuss these. Some relevant questions:
- what works and doesn't work in this layout
- are there changes that can streamline ROI drawing and editing more?
- notice that there's a "P" for Paint added to the tool palette -- other things to add, consolidate, or remove (like Dr2?)
- in the example, I've added a spline drawing style to the palette.
- no rubberband or lasso tools are present for selection -- but this mayy be useful
- is it ok for "label statistics" to go in separate section? (might let user pick all labels or one label; select output to text file and name file; and report voxel value max, min, mean, std. dev., volume)
- note: the editor icons are placeholders -- would be nice to design image icons in the palette if possible.
General User feedback on existing Slicer2 editor module:
- In Slicer2 workflow, “apply” is currently being used as a “preview” and “undo” is used to back out of an unsatisfactory operation. In Slicer3, instead of “apply” and “undo”, we should consistently implement “preview”, and “apply”. Though these may be implement the same operations programmatically, the concept of preview has less implicit stress for the user, who won’t worry that their original data may become unrecoverable.
- Visual cue: Should we assign a reserved color or visual appearance for ‘Editor preview’ so that in complicated visualizations, it will be clear which regions are being affected by the operation in preview?
- Provide multiple undo and redo as well.
- Inside editor module, users agree that having the hidden slice controller (which reappears on mouse-over) is very useful. However, sometimes while scrolling thru slices using the slice controller’s scale, the mouse travels off the controller bringing focus back to the slice window by mistake, and resulting in unintended drawing in that slice. This is very frustrating and requires time to clean up. We need to consider a workaround that
- Editing is done in all orientations, but the original acquisition plane is used, when possible, to make challenging decisions. Feature request: Might be good to visually indicate which of the slice viewers is displaying slices in the plane of acquisition.
- Nobody we spoke to is using the Draw2 module, though having a simple spline tool in addition to points, lines and polygons to draw regions would be nice.
- Within the editor, it would be nice to have a single location in which a user can: ask for a statistics/metrics report (including intensity min, max, mean, std.dev., and volume) for a single region or for all defined regions, and to have the option to save this information out to a text-file. Currently, MeasureVol module will give volume measurements for all labels (user can’t select a single one) and writes a text file; and Editor->Details Drawmode has the intensity statistics, no volume measurements, and no ability to write the text file.
- Existing hot-keys: Strong recommendation not to remap. Very efficient keyboard operations are used by everyone we spoke with: left hand using index and ring fingers on right and left arrows to move between slices, middle finger on up arrow to apply a point, and on shift key to view in all slice planes simultaneously; right hand moves the mouse to specify point location. Remapping the up and down arrows to also move between slices would strongly impact what has become very natural and efficient keyboard drawing.
- Might be useful in some cases to have coarse region-specification tools like rectangle, circle, oval.
- Absolutely need to be able to draw polygons that may, under some circumstances be self-intersecting.
- “Outline labelmap” should be off by default, not on. This feature is only infrequently used by this group in a pathological way, to approximate the viewing of two labelmaps at once (one in Foreground, and a different one outlined in the label map layer).
- Strong agreement among all users: Need multiple undo and multiple redo commands for drawing.
- When drawing regions, PNL doesn’t much use the magnifier window in Slicer2’s lower left panel. Instead, users often zoom in and out repeatedly in the slice plane in which they’re working. Feature request: In this context, a simple interface that remembers the current working zoom-factor, and lets a user zoom in, out and snap back in one click or with hot-keys (Ctrl+, Ctrl-, Ctrl0?) could be useful (and save a lot of mouse click-and-drag time).
- One strategy for specifying an ROI is to identify first and last plane in which the region must be drawn, to draw these, then outline in the middle slice plane, then fill in all slices between. Feature request: Might be handy to have a simple interface for setting and clearing “keyframes” which bracket a ROI, or snap the slice viewer to slices that contain anatomical markers.
- When drawing a region, if points or vertices on lines, polygons are wrong, instead of deleting and starting over, users select offending points or vertices and move them. Good ways to select and move points
- Selecting points or vertices: might be useful to have lasso or rubber band tool to select points or vertices, rather than having to individually click on them.
- In Editor->Effects Draw: Draw/Select/Move modes are good. May want to modernize some of the drawing and painting tools and exploit common paint software conventions: How about: Path editing section on GUI that includes tools for outlining a path with pencil (points), with lines (vertices), or polygon (vertices), and using a paintbucket fill? Plus the options to select points/vertices, move them or delete them. Then a painting section on the GUI that lets user choose brush tool, set brush-size, shape and brush-mode (Threshold paint is an idea that raised a lot of excitement). We should mock this up. Offer all current functionality, just modernized, and a few more tools.
- Feature request: a tool to report the length of a curved line drawn in the Editor (used for instance, to measure length of curvature lines drawn along sulci).
- One concern is with making principled sub-voxel decisions, and designing tools that assist that decision. Worth thinking about this issue more deeply.
- Tools to assist in region drawing: in a very zoomed-in view in the slices windows, it might be nice to see the intensity values of each voxel as annotations on the voxels – often decisions about whether to include a voxel or not are based on an intensity range, and having this information at hand might make such decisions faster and less error-prone.
- Having the ability to quickly toggle interpolation might also assist in voxel inclusion decisions.
- Having a hot-key or icon/hot-key to toggle crosshairs in the slice viewers would be useful; the crosshairs are often used to most clearly inspect an individual voxel in all slice views.
Label map editing:
- Average time per case: Editing a label map (such as output from EMSegmenter) takes between 20 minutes and an hour per case.
- Edited label maps are most often saved as new label maps; so that data remains from each step in the process.
- Ability to use "threshold" on existing labelmaps (for instance to remove all below 53 and all above 81). Clarification: does this mean remove all labels in a selected label map with ID below 53 and above 81?
- Strong agreement among all users: Need multiple undo and multiple redo commands for editing.
- Strong agreement among all users: We need the ability to simultaneously overlay and composite multiple label maps over a single grayscale image.
- Ability to edit a single label map while viewing several label maps simultaneously.
- Ability to apply an editing operation to multiple label maps at once.
- Context: Island removal: When editing a label map (such as output of EMSegmenter), often scan thru the entire label volume, find the minimum size of an island user wants to keep, and then sets the island removal size to ensure it remains, but that smaller ones will be removed. User applies the operation and scans thru volume to ensure nothing valuable was filled. If results are not good, undo is used to restore to previous state. Recommendation: would be nice to get a preview that visibly demarcates all islands that will be removed under the current island size threshold, so a user can scan through the map and make sure it looks good before applying.
- Behavior of remove island, under the “Scope” and “Native” and “Active” configurations is not clear to everyone (people have different interpretations of how this might behave, no tooltips on “Native” and “Active”, and help text is incomplete).
- Automatic save island: Remove island can be configured to move automatically from slice to slice. Save island must be applied manually for each slice. Can this have an automatic mode as well?
- Possibility to draw a label in multiple slices at once.
- Rethink the behavior of the various options in Editor->Effects and Editor->Details: In Editor->Effects, for all a user selects an effect, and then is transported to the Editor->Details to configure and apply the effect. Editor->Details panel also contains icons for all effects, but not for “measure island”, “save island” and other effects in the “more” pull-down menu. Must go back to the Editor->Effects panel to choose these effects. Recommendations: make behavior consistent and include icons for “measure island” and “save island” in the Editor->Details panel; perhaps collapse Editor->Effects and Editor->Details into a single panel and eliminate panel-jumping altogether. Editor sketches that illustrate the current coarse module navigation in Slicer2 and ideas on redesign are shown at the end of this section. Feedback on these is encouraged: might this simplify workflow? Will this possibly cause any unintended obvious problems? What can we do to modify and refine these?
- Editor toolbox popup menu: The same icons presented in the Editor GUI panel for all editor effects could be presented in a small floating “editor toolbox” panel. This floating GUI panel could control the main Editor GUI panel just as its icons do, but by being positioned closer to the slice being edited can save mouse-travel time.
- When editing a label map and changing a voxel from one label to another: Functionality to switch between different label-colors quicker, (e.g. Charlie suggests that, like in paint, switch label-colors using a hot-key: if you're drawing a labelmap in 11, you could also edit in 0 by holding down CTRL.) Or, hot-key or mouse click could bring up floating color palette with eye-dropper: users selects new label color by selecting it from palette, then palette disappears on mouse-out.
- Threshold or threshold-paint. It would be nice to be able to preview the regions of an image that will be affected by the thresholding operation as intensity range is adjusted.
- Propagation Tool (feature suggestion): Ability to propagate a drawn line (e.g. drawn on a 3D surface) medially to the gray/white interface. The result would be a surface that separates different regions of the cortex. These surfaces, the cortex surface and the interface between white and grey matter would outline an ROI. In a matter of moments, then, you could have outlined and rendered an entire ROI for one side. Request: can users describe this in more detail?
- Cortical drawing tool (3D drawing tool): In order to make drawing significantly faster, particularly for ROI which are complicated, it would be very helpful to be able to draw ROI on the 3D cortical surface where they are often clearest.
- When using the VolumeMath module to edit one label map with another, a clear description of what each math operation does should be provided
- When adding two label maps together in the VolumeMath module, regions in both maps which overlap will be assigned a new color (which may be difficult to visually notice in a complicated display) which will require an additional editing step. In that step, areas of overlap will need to be assigned to one of the two overlapping regions. In the case of label map volume math, it might be useful to make these double-assigned regions very visually conspicuous to avoid errors – perhaps by allowing a user to explicitly choose a unique label for all overlapping regions.
Label map saving:
- Option to save a labelmap but keep the former version in the MRML tree. (Detailed explanation: "when you edit a labelmap, then save it under a different name, you have to add the edited labelmap separately to the "data" table before you can see it in the drop-down menus (e.g. for the various modules, or to change the active labelmap in different views). Is there a way to automatically add the renamed labelmap to the data table?" Suggestion: May be good to have option to create a new label map (newLM) as a copy of an existing loaded label map (origLM), and then edit newLM. Then, both of these label maps should be represented in the scene.
From label maps to models:
- "model editor": update the model automatically when the corresponding labels change instead of re-creating models. In the current workflow to generate acceptable models, the user must repeatedly modify label maps, create the models, modify labels, delete and re-create models, and so on. Would be nice to simplify this workflow.
- Modelmaker: would be nice to have the option of creating models whose polygons follow exactly the faces of the voxels used to create them so no additional smoothing is added to the label mapped representation. (Doug)
Schematics illustrating some challenges in existing Slicer2 editor:
challenges with existing design: The schematic below illustrates how all effects are not available to be selected/configured on the Editor->Details GUI panel, and how users must hop between the two panels to select, configure, and apply these effects.
The sketch below suggests consolidating the Editor->Effects and Editor->Details panel into one, so that effect selection, configuration and apply are all available in one location. The sketch also includes the idea of replacing apply-undo with preview-apply in the workflow, and tries to identify functionality that should be persistently displayed for all editor effects (rather than re-displaying in multiple configuration panels).
KidDefib Project Feedback
1. Add Slicer 2 Tools (Thresholding, Save Island, Remove Island, Change Island, Draw)
2. Subvolume Tool: Allow specification of subregions where tools (like thresholding or level sets) are applied. Resultant label map must maintain registration with originatl NRRD CT volume.
3. Smoothing Tools: Allow output of ".vtk surface" from "ModelCreation" as a smoothed label map in NRRD format
4. Incorporate more ITK smoothing tools at the label map stage.
5. View where can see adjacent label map ghosted in real time to help with alignment when segmenting manually or using threshold paint.
6. Default compression for all NRRDS
PNL RA Slicer3 Editor Meeting February 26, 2008
Minutes by Charlie Davidson plus some comments in italics by Steve Pieper
Dear All, We met today to discuss Slicer 3 development and PNL RA's input at this stage. I figured it's best to send everything so it's all in one place... Let me know if you'd like a summarized version.
SLICER3 FUNCTIONS NOTES
- search module is an alphabetical (substring) search. additionally, recently used modules, with arrows to go back and forth. there also exists a "home".
- also, there are favorites buttons. - can use wildcard in add files.
- up,down,left,right all scroll through slices
- space key = editor toolbar, scroll for slices, shift is same (though diff), z does (will do) something , c color picker, e does toggle colors and black...? yes, e toggles between black (0) and your current color
- whatever is in label layer for panel you're drawing in will be what you draw on. for global operations, (e.g. models) RED is 'master'.
- to fade globally, link and then fade
- if hit apply twice will crash, if "click" apply, may crash. use "A" shortcut to apply for now. seems to happen in draw, whereas PAINT seems to work better. this crash was fixed just after the meeting so it should go away in the next nightly build
- SCENE SAVE: check at beginning selects which.
- smudge is like Slicer 27's "auto"
- ctrl Z and ctrl Y will be undo and redo
- instead of "shift" for non-panning slice coregistration, can use "P" to lay down fiducial, link panels, then if you move fiducial around, should move slices same way as slicer2 shift. space bar, + and - buttons (or fiducial list) can scroll through fiducial list
- grid on/off is on left side.
- paint over and threshold options:
-- exist in all 'drawing/painting' type fxns
-- can set threshold, click "apply" (global), or "use for (paint)", (thresholds painting)
-- if paint over is on(?), only things that are "0" will get drawn on. actually paint over on means you can paint anywhere, paint over off means only 0 values painted
- LEVEL TRACING
-- an outlining method...
-- also SIMPLE REGION GROWING module (generates labelmap from seed point), level tracing works differently
-- level tracing: when move from slice to slice, you're always picking "altitude" in histogram in a different way. may be bumpy.
- change island and remove island, erode, dilate, are all 3D right now, not fully implemented yet. will hopefully have slice, multi-slice, etc. versions later.
- with Lauren's tool, you can create a scalar field based on image volume (e.g. create scalar overlay based on volume and model, then manip using models panel). made specifically for freesurfer stuff, but ... this is called Probe Volume module
- Slicer3 CTRL+S brings up save dialog
- Lauren's tool does tract --> labelmap no slicer3 version of this yet
- MAKE MODEL button in editor (calls regular modelmaker, but only exposes a couple simple options, smooth/not, has a button to go to full model-maker). makes model in background
- rectangle draw may also be useful (particularly with threshold or paint-over modes). rubber-bandy rectangle.
- volume rendering, sort of an alternative to making a model, better for things like FA maps or CT data. equivalent of making a model, but differently.
- ability to change size of control panel vs. vis window - already doable, (e.g. F5 hides control panel, can swap from left to right, is resizable now, but there is a minimum)
FEATURE REQUESTS (overlaps with other sections)
- shortcut for fade in/out. might work as hold button and scroll? CTRL+H sets home.
- ANNO - more options for crosshairs and SHIFT, particularly ability to not pan entire image with shift, plus crosshairs follow mouse. (possibly fixed with fiducials tools?)
- ability to turn off little floating "mode" tag on pointer (partic. on draw).
- un-applied points to stay when change slices, also when select "don't delete after apply," also ability to copy and move.
- polygon, line, and point drawing? (right now only polygon exists) can currently do line by applying after clicking down two points
- some notification of "working..." . currently no explicit log of activity, e.g. difficult to know what's going on when loading an xml scene. need to know, e.g. when loading large DWI, if it's crashed or if it's just working. (red button on lower right gives additional info).
- delete last, shortcut also, also undelete? smaller scale undo? (ctrl+z, ctrl+y; delete, insert?) - level set tracing, tell you gray level, parameters to set?
- problem of moving slicer across windows (CTRL+ALT+SHIFT+arrow) still exists
- more info on scalar vis, level set tracing..?
- periodic auto-save? into tmp directory of some kind?
- paint-in as well as paint-over?
- model --> labelmap (vtk cutter?) geometry draw in slicer 2 similar?
- make all models invisible menu, LINK for model visualizations?
- shift mode over models
- hotkeys window?
ADDITIONAL NOTES, CONCLUSION
- the build of Slicer 3 that we are currently using is compiled weekly using a cronjob from Katharina. Instructions are here
hopefully this will be useful to figure out which version we're using. - For now, our highest priority requests are probably for stability in editor (particularly draw) module, as well as other commonly-used modules, and within this version of Fedora. We'll also need to figure out how we can be sure we're running the most current, stable version (with Katharina gone). - Hopefully later we can re-visit and see if we can figure out DTI, level-set drawing, models, etc.
Please let me know if we can help in any way, or if you could use any particular feedback. I've written down a few of my personal questions below that weren't covered in the meeting.
- will there be a unit of spin in 3D view (e.g. the unit rotate arrows in Slicer2, or the incremental rotations in tksurfer). yes, this is already available in the view manipulation control in the lower left - what is ROI module for? it's used by some command line modules to select a subvolume, but isn't used in the Editor
- DT estimation and scalar modules very different from Slicer2. I think we may need help eventually understanding the changes.
- LINKED slice controls should be default.
- create new labelmap snaps FOV back to automatic fit, losing specific views.
- what is editor-ERASE for if can draw w/ 0?