[Insight-developers] Origin information for slices.

[Miller, James V (Research)]

ITK doesn't handle a MxNx1 3D image terribly well.  For any neighborhood
based filter, every pixel ends up being a boundary condition. Other filters
assume that there will be more than one slice in order to calculate derivatives
in Z.

It probably makes sense to be able to record where a sub-image is relative to 
a higher dimensional space: for a volume you may want to know what volume it is
in a time series?,  for a 1D image you may want to know that row it corresponded to, ...

This is tricky because a 1D image may be a row or a column of a 2D image, etc.

To date, we have been working on the premise that these issues are best handled
at the application level.  We could keep a "higher dimensional" origin and spacing
to supplement the current origin and spacing to indicate where this subimage is 
in a larger image. I don't think we can use increase the size of the origin and 
spacing because you need to know what dimensions are used by the current image

For instance, a 1D image that is a column from a 2D image would need different parts
of the origin and spacing as a 1D image that is a row of a 2D image.

Jim




> -----Original Message-----
> From: Mark Foskey [mailto:mark_foskey@unc.edu]
> Sent: Thursday, October 24, 2002 10:39 AM
> To: insight-developers
> Subject: [Insight-developers] Origin information for slices.
> 
> 
> In an ITK image, the origin has the same dimensionality as the image. 
> If, as is often the case, the image is a 2D slice of a 3D 
> volume, then 
> that really doesn't make sense.  We especially need the third 
> coordinate 
> if we intend to reconstruct 3D image from a collection of slices.
> 
> One possibility is to insist that slices be loaded as M x N x 1 3D 
> images.  Are there any appreciable disadvantages to that?  
> Will we ever 
> want to run a 2D filter on a slice, but simultaneously have 
> information 
> about where that slice lies in a volume?
> 
> Otherwise, we need a sensible way for m_Origin to have a different 
> number of entries than the dimensionality of the image.  And 
> we need to 
> include the possibility of higher dimensional images too.  We 
> might have 
> a 3D or 2D slice of a movie.  Perhaps the easiest approach is 
> to store 
> the origin as a std::vector<double>  and let there be a 
> GetOriginDimensions() method that returns m_Origin.size().
> 
> What do people think?
> 
> -- 
> Mark Foskey    (919) 843-5436   Computer-Aided Diagnosis and 
> Display Lab
> mark_foskey@unc.edu             Department of Radiology, CB 7515, UNC
> http://www.cs.unc.edu/~foskey   Chapel Hill, NC  27599-7515
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>