Detailed Description

SpecialCoordinatesImages are templated over a pixel type (modeling the dependent variables), and a dimension (number of independent variables). The container for the pixel data is the ImportImageContainer.

Within the pixel container, images are modelled as arrays, defined by a start index and a size.

Almost arbitrary mappings between index space & Cartesian physical space are possible, and so m_Origin and m_Spacing should be ignored. They exist only to allow the possibility of running a "spatially-aware" filter in raw index space, as if the SpecialCoordinatesImage data was laid out on a regular grid. Note that this may or may not produce useful results, and it is up the the user to determine the appropriateness of running a filter designed for normal images on special-coordinates images.

The only correct generic method for operating on a SpecialCoordinatesImage in physical space is to use the virtual functions TransformPhysicalPointToIndex, TransformPhysicalPointToContinuousIndex, TransformIndexToPhysicalPoint, and TransformContinuousIndexToPhysicalPoint. All of these methods transform points in Cartesian physical space to and from indices in the special (typically non-Cartesian) index space. It is also possible to check the type of coordinate representation being used by a SpecialCoordinatesImage, and then use representation-specific code to speed up the filter for certain coordinate representations, falling back to the generic method for unrecognized and/or unoptimized coordinate representations.

There are three sets of meta-data describing portions of a SpecialCoordinatesImages. These are "Region" objects that define a portion of an image via a starting index for the image array and a size. The ivar LargestPossibleRegion defines the size and starting index of the image dataset. The entire image dataset, however, need not be resident in memory. The region of the image that is resident in memory is defined by the "BufferedRegion". The Buffer is a contiguous block of memory. The third set of meta-data defines a region of interest, called the "RequestedRegion". The RequestedRegion is used by the pipeline execution model to define what a filter is requested to produce.

Pixels can be accessed direcly using the SetPixel() and GetPixel() methods or can be accessed via iterators. Begin() creates an iterator that can walk a specified region of a buffer.

The pixel type may be one of the native types; a Insight-defined class type such as Vector; or a user-defined type. Note that depending on the type of pixel that you use, the process objects (i.e., those filters processing data objects) may not operate on the image and/or pixel type. This becomes apparent at compile-time because operator overloading (for the pixel type) is not supported.

The data in an image is arranged in a 1D array as [][][][slice][row][col] with the column index varying most rapidly. The Index type reverses the order so that with Index[0] = col, Index[1] = row, Index[2] = slice, ...

Spacing typedef support. Spacing holds the "fake" size of a pixel, making each pixel look like a 1 unit hyper-cube to filters that were designed for normal images and that therefore use m_Spacing. The spacing is the geometric distance between image samples.

Create an object from an instance, potentially deferring to a factory. This method allows you to create an instance of an object that is exactly the same type as the referring object. This is useful in cases where an object has been cast back to a base class.

Methods invoked by Print() to print information about the object including superclasses. Typically not called by the user (use Print() instead) but used in the hierarchical print process to combine the output of several classes.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

These functions do NOTHING! They exist only to not break the pipeline. It is vital that the user specify any and all physical-spacing parameters to the output of a normal filter which is being used to output a special-coordinates image. Filters designed to produce a particular kind of special-coordinates image should do this automatically.

Member Data Documentation

Dimension of the image. This constant is used by functions that are templated over image type (as opposed to being templated over pixel type and dimension) when they need compile time access to the dimension of the image.