[Insight-developers] Origin information for slices.

[Mark Foskey]

I see what you mean.  Algorithms that process a 2D image expect the 0 
and 1 components of the pixel spacing to be the relevant (and currently 
the only existing) components.  We don't want to change that.  It hadn't 
occurred to me that we would really like the pixel spacing in all n 
dimensions too, but you're right.

It looks like the two reasonable possibilities are:

1. Make users handle the information themselves, in which case we need 
to make it possible to query the ImageFileReader for it.  (Users have to 
get their hands on the info somehow.)

2. As Jim suggested, have additional higher-dimensional origin and 
spacing members.  We might also need an array indicating which higher 
dimension each lower-dimensional axis corresponded to.

It may not even be as simple as that.  DICOM has fields for image 
orientation, too.

Miller, James V (Research) wrote:
> 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
>>
> 

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