[Insight-developers] PathToImageFilter issues

[Lorensen, William E (GE, Research)]

Zach,

Perhaps a new class hierarchy is called for with new names for the base and derived classes. This would retain backward compatability and give us freedoom do develop a better set of algorithms.

Bill

-----Original Message-----
From: insight-developers-bounces+lorensen=crd.ge.com at itk.org
[mailto:insight-developers-bounces+lorensen=crd.ge.com at itk.org]On Behalf
Of Zachary Pincus
Sent: Tuesday, February 07, 2006 7:48 PM
To: insight-developers at itk.org
Subject: Re: [Insight-developers] PathToImageFilter issues


On closer inspection, there are some real problems with the  
itk::PathToImageFilter class that will require API changes.

(1) The class claims to be a "Base class for filters that take a Path  
as input and produce an image as output" but it is in fact a filter  
that takes a path as input and draws that path on an image. This  
class can't serve as a base class since a lot of the important  
machinery of generating the output image is stuffed into the  
GenerateData method, instead of packaged as an AllocateOutputs()  
method that subclasses could call to make use of.

(2) The Origin and Spacing of the output image is specified as float*  
or double* arrays, instead of ImageType::PointType and  
ImageType::SpacingType.

(3) Consequently, the setters and getters for the above do not use  
the proper ITK macros.

This class is a mess. If there were no backward-compatibility issues,  
PathToImageFilter should really be split into a real base class and a  
derived filter called "ScanConvertPathToImageFilter" or something.

Does anyone have any suggestions? Now that I'm trying to use it, it  
seems that a lot of the Path stuff is still pretty broken, but  
already locked into place by backwards-compatibility concerns. I  
might just give up on using paths to do anything and use  
PolygonSpatialObject and the properly-constructed SpatialObject class  
and filter hierarchy. Except that there's no SpatialObjectSource or  
ImageToSpatialObject base classes, so I'd have to write those too, I  
think.

Zach



On Feb 7, 2006, at 3:57 PM, Zachary Pincus wrote:

> Hi folks -
>
> Just a heads-up: I'm going to make some changes to  
> itk::PathToImageFilter to make it actually useful. There are no API  
> changes implicated.
>
> - Right now the class documentation states that the output image  
> will be automatically sized according to the bounding box of the  
> path. This is not actually the case in the code, so I will update  
> the docs accordingly. (The methods to do this computation  
> generically for any path type don't exist in the itk::Path  
> hierarchy, so adding this functionality is not trivial.)
>
> - There is a way to set the size and the origin of the output  
> image, but not the index at which the image starts. However,  
> PolyLineParametricPath objects are specified as a series of  
> ContinuousIndex values, not Points. (I personally think that this  
> was a mistake, but I could be convinced otherwise, and it's kind of  
> moot since that's the API now.) Anyhow, this means that  
> PathToImageFilter needs to allow the user to specify the starting  
> index of the produced image.
>
> Zach
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers