Slicer3:VisualBlog Extension - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:07:25Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Unprotected "Slicer3:VisualBlog Extension"

2008-05-20T19:10:55Z

Unprotected "Slicer3:VisualBlog Extension"

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:VisualBlog_...'

2008-05-20T19:10:47Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:VisualBlog_...'

Marianna at 14:57, 26 October 2007

2007-10-26T14:57:25Z

Marianna at 14:43, 26 October 2007

2007-10-26T14:43:58Z

Marianna: New page: === Image from pieper on Tuesday, August 08, 2006 at 4:26PM === A number of things have come together to allow the new prototype editor module: * the label map layers are enabled * lookup...

2007-10-26T14:30:27Z

New page: === Image from pieper on Tuesday, August 08, 2006 at 4:26PM === A number of things have come together to allow the new prototype editor module: * the label map layers are enabled * lookup...

New page

=== Image from pieper on Tuesday, August 08, 2006 at 4:26PM ===

A number of things have come together to allow the new prototype editor module:
* the label map layers are enabled
* lookup table support in the layer logic
* a new set of 2D UI widgets
* generalized painting infrastructure, which is based on requests and feedback from NA-MIC Core 3 users and other users of Slicer2
** paint brush has a 'threshold' option in which the label map only gets painted if the background intensity is in a specified range
** paint brush optionally won't overpaint existing voxels
** 'eye dropper' mode allows you to start painting with the label value where you first clicked (so you don't need to go to the UI to change the label color as often).
** all painting operations can happen on arbitrarily transformed volumes. This allows the painting plane to be aligned with the major axis of a structure like the hippocampus
** background layers are interpolated to current screen resolution (not limited to nearest neighbor sampling as in slicer2's draw mode)
** painting is performed using a circular brush with a diameter selected by the user. this makes it easier to follow the contours of curved biological structures.
** the cursor is turned off on mouse down and reappears on mouse up so you can see the exact pixels you are drawing (a circle around the cursor location indicates the mouse location)

A few limitations make this still a 'prototype' including:

* there's no convenient way to save your label maps volumes (except as dicom)
* the color map is currently random
* only label numbers 0-255 will show as distinct colors
* no hot keys for frequently used operations
* brush radius is in screen space units rather than RAS (means that the brush is effectively getting bigger and smaller as you zoom in and out)
* the paint algorithm is implemented inefficiently and can be slow when painting large numbers of pixels
* much of the code is written in tcl - new vtk classes are needed to implement the functionality more efficiently.

← Older revision		Revision as of 18:07, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3:VisualBlog_Extension here]</font></big>	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:VisualBlog_Extension here]</font></big>

← Older revision		Revision as of 19:10, 20 May 2008
Line 1:		Line 1:
−	~~=== Image from pieper on Tuesday, August 08, 2006 at 4:26PM ===~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:VisualBlog_Extension here]</font></big>
−
−	~~A number of things have come together to allow the new prototype editor module:~~
−	* the label map layers are enabled
−	* lookup table support in the layer logic
−	* a new set of 2D UI widgets
−	* generalized painting infrastructure, which is based on requests and feedback from NA-MIC Core 3 users and other users of Slicer2
−	** paint brush has a '~~threshold~~' ~~option in which the label map only gets painted if the background intensity is in a specified range~~
−	** paint brush optionally won'~~t overpaint existing voxels~~
−	** '~~eye dropper~~' ~~mode allows you to start painting with the label value where you first clicked (so you don~~'~~t need to go to the UI to change the label color as often).~~
−	** all painting operations can happen on arbitrarily transformed volumes. This allows the painting plane to be aligned with the major axis of a structure like the hippocampus
−	** background layers are ~~interpolated to current screen resolution (not limited to nearest neighbor sampling as in slicer2's draw mode)~~
−	** painting is performed using a circular brush with a diameter selected by the user. this ~~makes it easier~~ to ~~follow~~ the ~~contours of curved biological structures~~.
−	** the cursor is turned off on mouse down and reappears on mouse up so you can see the exact pixels you are drawing (a circle around the cursor location indicates the mouse location)
−
−	~~A few limitations make this still a 'prototype' including:~~
−
−	* there's no convenient way to save your label maps volumes (except as dicom)
−	* the color ~~map~~ is ~~currently random~~
−	* only label numbers 0-255 will show as distinct colors
−	* no hot keys for frequently used operations
−	* brush radius is in screen space units rather than RAS (means that the brush is effectively getting bigger and smaller as you zoom in and out)
−	* the paint algorithm is implemented inefficiently and can be slow when painting large numbers of pixels
−	* much of the code is written in tcl - new vtk classes are needed to implement the functionality more efficiently.
−
−	~~----~~
−
−	~~=== Image from pieper on Thursday, July 13, 2006 at 4~~:~~49PM ===~~
−
−	~~Type Control-T to bring up interactor, then~~
−
−	~~source Base~~/~~GUI~~/~~Testing/TestSliceModels~~.~~tcl~~
−	~~SliceModelsAdd~~
−
−	~~This test does things the right way in that it creates model nodes for the slices and the updates of the planes is triggered by observers on the Slice Logic~~. But it does things the wrong way in that it creates the texture in an ''ad hoc'' way for now since we don't yet have a clean way to specify textures in the model display nodes. Also, the Viewer renders on every changes to the slice view, so as you pan/~~zoom~~/~~scroll the slices the redraws are jerky~~. ~~Next step is to figure out how best to get this functionality integrated into the C++. Probably there should be a vtkSlicerSliceModelsLogic class that's managed by the vtkSlicerSliceGUI.~~
−
−	~~----~~
−
−	~~=== Image from blezek on Tuesday, April, 10, 2007 at 8~~:~~00AM ===~~
−
−	~~[[Image:PythonConsole.png \| thumb \| left\| 280px\|Bringing up the Python console]~~]<br><~~br><br><br><br><br><br><br><br>~~
−
−
−	~~Now, do something interesting with it!~~
−
−	~~>>> # import MatPlotLib via pylab functions so we can refer to them directly~~
−	>>> from pylab import *
−	>>~~> imshow ( data[128,:,:] )~~
−	~~>>> # Instruct pylab to show our plots... hit return to continue entering commands.~~
−	~~>>> show()~~
−
−	~~[[Image:Pythonimshow.png \| thumb \| left\| 200px\|Voila!]]~~

@@ Line 23: / Line 23: @@
 * the paint algorithm is implemented inefficiently and can be slow when painting large numbers of pixels
 * much of the code is written in tcl - new vtk classes are needed to implement the functionality more efficiently.
 === Image from pieper on Thursday, July 13, 2006 at 4:49PM ===
@@ Line 32: / Line 34: @@
 This test does things the right way in that it creates model nodes for the slices and the updates of the planes is triggered by observers on the Slice Logic. But it does things the wrong way in that it creates the texture in an ''ad hoc'' way for now since we don't yet have a clean way to specify textures in the model display nodes. Also, the Viewer renders on every changes to the slice view, so as you pan/zoom/scroll the slices the redraws are jerky. Next step is to figure out how best to get this functionality integrated into the C++. Probably there should be a vtkSlicerSliceModelsLogic class that's managed by the vtkSlicerSliceGUI.

← Older revision		Revision as of 14:43, 26 October 2007
Line 23:		Line 23:
	* the paint algorithm is implemented inefficiently and can be slow when painting large numbers of pixels		* the paint algorithm is implemented inefficiently and can be slow when painting large numbers of pixels
	* much of the code is written in tcl - new vtk classes are needed to implement the functionality more efficiently.		* much of the code is written in tcl - new vtk classes are needed to implement the functionality more efficiently.
		+
		+	=== Image from pieper on Thursday, July 13, 2006 at 4:49PM ===
		+
		+	Type Control-T to bring up interactor, then
		+
		+	source Base/GUI/Testing/TestSliceModels.tcl
		+	SliceModelsAdd
		+
		+	This test does things the right way in that it creates model nodes for the slices and the updates of the planes is triggered by observers on the Slice Logic. But it does things the wrong way in that it creates the texture in an ''ad hoc'' way for now since we don't yet have a clean way to specify textures in the model display nodes. Also, the Viewer renders on every changes to the slice view, so as you pan/zoom/scroll the slices the redraws are jerky. Next step is to figure out how best to get this functionality integrated into the C++. Probably there should be a vtkSlicerSliceModelsLogic class that's managed by the vtkSlicerSliceGUI.

← Older revision	Revision as of 19:10, 20 May 2008
(No difference)