[Insight-developers] PathToImageFilter issues

[Zachary Pincus]

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

One route would be to create new base could be called  
PathToImageFilterBase, and the PathToImageFilter deprecated and  
replaced with a "SimplePathToImageFilter" class that does the same  
thing.

The ITK conventions would be a bit tweaked by this -- e.g. the base  
class for image to image filters is ImageToImageFilter, not  
ImageToImageFilterBase, but that's not the worst thing in the world.

The other possibility would be to deprecate the nasty stuff in  
PathToImageFilter, but leave it there (for a couple of releases) so  
the class still works as it did. At the same time the proper  
mechanism for PathToImageFilter to be a good base class could be added.

This latter seems like an OK idea; I'll see what I can do with it and  
report back. Maybe the class isn't as broken as I thought yesterday  
when it seemed that I couldn't get anything to work properly with it.

Zach

PS. Sorry if my last email came across as sour; certainly that's not  
my intention. I'm happy for what there is in ITK and happy to help  
make that better.


On Feb 8, 2006, at 4:09 AM, Lorensen, William E (GE, Research) wrote:

> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers