0000318: Slices skipped or ??? by slider when editing - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000318	Slicer3	Usability	public	2008-09-12 15:50	2009-10-05 13:34

Reporter	inorton	Assigned To	pieper
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed

Summary	0000318: Slices skipped or ??? by slider when editing
Description	In the Editor module, the interpolation of hand-drawn labelmaps is inconsistent - possibly due to skipping of slices. Problem: [load some image - in this case: BaselineNode for DWI image volume] 1) In Editor module, create a labelmap select the draw tool. 2) draw outline of some feature on the Axial slice 3) click "Apply" [note: after clicking Apply the labelmap should appear as a 1-slice blip on the Cor/Sag views] 4) click within the slice selection slider to move up/down one slicer 4a) repeat drawing of outline and Apply on several slices. The resulting labelmap shows gaps on the Cor/Sag views - corresponding roughly to 1 slice (maybe 1/2?). When ModelMaker is used to create a model from the hand-drawn labelmap, the model shows similar gaps (ie: a stack of 1-slice thick "slabs" with "air" in between). I'm not sure that there is a good way to interpolate between hand-drawn labelmaps on individual (axial) slices -- But am used to the slicer2 behavior of interpolating the labelmap to the entire thickness of the slice. This is imperfect because of the resulting blockiness. But it is at least consistent, in approximating the way that Cor/Sag planes are reconstructed from an image with Axial primary slices. Part of the problem may be with the functioning of the slice selection slider. When I click to the left or right of the slider, the number (mm?) will often change, but it takes two clicks to change the slice actually displayed. My impression is that clicking within the slider causes the slide selection to change change by .5 (left side) or 2 (right side) of whatever units the slider measures... The expected behavior is to move to the next slice - if the units are mm then the thing should adjust by the value of "Slice Thickness", at least for axial. NOTE: I can't find the "missing" slices, even if I use the slider itself rather than clicking to the left or right within the slider bar.
Tags	No tags attached.

pieper 2008-12-04 02:43 administrator ~0000497	Do the arrow keys have the same problem?

inorton 2009-05-27 14:00 developer ~0000994	The addition of the Manual Spacing option provides a fix for the slice skipping problem, but there is still the problem of odd behavior when clicking in the slice position trough. the problem seems to be due to Center'ed volume (for example, load the dicoms in SlicerSampleVisualization.tar.gz on the training page, then Center Volume). Perhaps the reason that I am (?) the only one complaining about this is that I use Center Volume a lot due to the persistence of Analyze here (which loads way out in space otherwise). One thing I noticed is that the OffsetScale slider value is being changed for clicks in the left side of the trough.. but that change is too small. set slicesGUI [$::slicer3::ApplicationGUI GetSlicesGUI] set redSlice [$slices GUI GetSliceGUI "Yellow"] (Yellow == Red .. ??) set redCtrl [$redSlice GetSliceController] set offs [$redCtrl GetOffsetScale] check value: % $offs GetValue 5.25 click in left side of trough (slice is stationary): % $offs GetValue 4.5 click again (now slice moves): % $offs GetValue 3.75 the resolution (as expected) is: % $offs GetResolution 1.5 The volume is 512x512x92, (0.5, 0.5, 1.5) dimensions. Center Volume sets Origin to: (127.75, -127.75, -68.25). If I change the z-origin to -69 then the slice slider works perfectly in increments of 1.5 as expected... This is sort of a solution, I guess. One other note: the slider will not move all the way to the left. The lowest possible value should be -68.25 (and indeed, if I SetValue to -70 then OffsetScale clamps to -68.25 as Range dictates). But as it is, the Slider will not go below -66.75. On the other side, it will go all the way up to +68.25. It seems like there may be a weird interaction between the observer and the KWScale widget -- ie the guicallback for the OffsetScale does it's own internal clamping... I haven't followd the observers/logic around yet.

rausch 2009-06-29 07:17 reporter ~0001023	I'm also having trouble with this, PNL RAs are still using Slicer 2 to draw seeding labelmaps, etc. hence the lack of more complaints here. Also (maybe I should bug report this?) arrow keys only seem to work correctly (moving the right number of slices) before I open a label map, after that they fail to work at all.

inorton 2009-07-01 11:23 developer ~0001025	I second the arrow key problem. Arrow keys haven't worked in quite a while and I kind of forgot about them. The Editor limitation "background and labelmaps .. cannot be inside transforms" is problematic too. That one is by design, but would be great to find a way around it eventually.

pieper 2009-07-17 08:32 administrator ~0001073	Arrow keys should be fixed now - they were actually broken only in "linked slice" mode.

pieper 2009-07-20 12:08 administrator ~0001076	Okay - I think I got this one (once and for all!). http://viewvc.slicer.org/viewcvs.cgi?rev=9975&view=rev I was definitely able to reproduce this using the SlicerSampleVisualization data and with this fix it works for me now. I'm going to mark this as resolved - Isaiah, if you have a chance to test that would be great!

Date Modified	Username	Field	Change
2008-09-12 15:50	inorton	New Issue
2008-12-04 02:43	pieper	Note Added: 0000497
2008-12-04 02:43	pieper	Assigned To	=> pieper
2008-12-04 02:43	pieper	Status	new => assigned
2009-05-27 14:00	inorton	Note Added: 0000994
2009-06-29 07:17	rausch	Note Added: 0001023
2009-07-01 11:23	inorton	Note Added: 0001025
2009-07-17 08:32	pieper	Note Added: 0001073
2009-07-20 12:08	pieper	Note Added: 0001076
2009-07-20 12:08	pieper	Status	assigned => resolved
2009-07-20 12:08	pieper	Resolution	open => fixed
2009-10-05 13:34	pieper	Status	resolved => closed