[Insight-users] Performance issues for single slices

Ross Whitaker whitaker at cs . utah . edu
Thu, 19 Jun 2003 10:49:06 -0700



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.  

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.  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.

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.

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.

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