[Insight-users] Performance issues for single slices

[Simon Warfield]

Ross Whitaker wrote:

>
>Simon Warfield writes:
> > 
> > I don't agree that it is reasonable to have an expectation that a 3D 
> > filter will run poorly on a single slice of a 3D volume. 
> > 
> >   Often it is valuable to be able to present to a user a single coronal, 
> > sagittal or axial slice, or perhaps all three, and illustrate rapidly a 
> > processing operation on these slices, and then ask the user if it should 
> > be carried out in 3D.  For example, this UI strategy is used in our 
> > 3Dslicer environment.
> > 
> > I don't see what magic a 2D instantiation of template coded filter can 
> > work that a 3D filter running on a 2D slice could not also do.  Why 
> > could the 3D filter not determine it is running on an Xx1xZ data set, 
> > and know the boundary conditions as well as a 2D filter running on an 
> > XxZ data set ?
> > 
>
>When doing neighborhood operations there is a *big difference* between
>2D and 3D, regardless of the dimensions of the final output.  
>
>In the example you give, do you want to show the user one slice of the
>result of running the filter on the volume, or do want to you show a
>2D result (which is different from 3D)?  If it's the former, then you
>should let the ITK pipeline do it's thing, and take a one-slice
>requested region and pull throught the pipeline all of the data needed
>to implement the 3D neighborhoods.  This is what the Analyze people
>are doing (I think).
>
>If you want to see the result of a 2D process running on that slice
>(i.e. using 2D neigbhorhoods) then you need to use 2D filters.  
>

I am giving an example of the latter - running a 2D filtering process on 
2D data extracted from a 3D volume --- the motivation being that e.g. a 
user may interactively tune parameters on the 2D slices and then run the 
presumably longer but same filtering on the 3D with the adjusted 
parameters.  An example might be a noise smoothing filter.

>
>It is true that if the boundary conditions are set up correctly then
>running a 3D filter on a NxMx1 volume *should* be the same as running
>a 2D filter on a NxM image. 
>
Or on a 1xNxM or a Nx1xM image.

>However, this probably depends on the
>filter and precisely how the boundary conditions are defined.
>
>Furthermore, it's computationally expensive, as pointed out by Luis
>and others.
>

  What makes it more computationally expensive to process a 1xNxM set of 
voxels than to process an NxM set of voxels ?

>
>One of the reasons, as I recall, we templated the ITK code by
>dimension was to avoid all of the case statements assocated with
>checking on the dimensionality of the data.
>
So it is basically a design choice to simplify implementation with some 
performance implications ?

>
>If you want an application to handle an NxMx1 volume as a 2D image,
>why not put the logic in at the application level?  It's certainly
>easy enough to do, and it avoids filling the toolkit with specific
>assumptions about he way to handle degenerate cases.
>
I just have a feeling that a filter should work on a NxMxO data set, 
irrespective of the magnitude of N, or M or O.  A filter that doesn't 
work or goes slow for any of N,M,O = 1 is broken.

>
>Cheers, 
>
>Ross
>
>
>--------------------------
>Ross T. Whitaker, Assistant Professor
>50 S. Central Campus Drive, Rm. 3190 
>University of Utah
>Salt Lake City, UT  84112-9205
>voice: 801/587-9549, fax: 801/581-5843
>web: www.cs.utah.edu/~whitaker
>
>  
>


-- 
Simon K. Warfield, Ph.D. warfield at bwh . harvard . edu Phone:617-732-7090
http://www . spl . harvard . edu/~warfield           FAX:  617-582-6033
Assistant Professor of Radiology,          Harvard Medical School
Director, Computational Radiology Laboratory
Thorn 329, Dept Radiology,  Brigham and Women's Hospital 
75 Francis St, Boston, MA, 02115