[Insight-developers] Dashboard woes

[Luis Ibanez]

On Thu, Jun 2, 2011 at 12:23 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Hans,
>
> It make since to me to require that images line up in physical space before
> performing index base operations. In fact I would be in favor of moving this
> check way up in the pipeline for all filters, and when this behavior is not
> desired having to overload a method. I have suggested adding a new method in
> the pipeline, called something like, VerifyAllInputs(), which is called
> before the UpdateOutputInformation() methods are called. This method could
> verify that the required inputs are set and that they match is size, and
> physical location. Currently, many filters don't check that any of this
> information matches.


This sounds reasonable.


-------------------------------------------
>>
>> Are you referring to ImageAdaptors as we already have them
>> implemented ? or are you using that term loosely ?
>
> I would think that only minor changes to the ImageAdaptor is needed to enable
> it to perform linear interpolation at each sample.
>

Then we are talking about a new class.
And that's fine.

Please design a new class for doing this.
Instead of inserting new features in the
ImageAdaptor one.

>>
>> ImageAdaptors, as currently implemented in ITK are only
>> suitable for Pixel-wise operations, and are unaware of
>> many of the transactions that filters have to deal with.
>
> The ImageAdaptor is a data object not a process object, so I am not sure
> about what you are referring to.

That's exactly what I'm referrig:

 ImageAdaptors do not deal with regions, or image grids.

Image adaptors were designed for replacing trivial
pixel-wise filters.

>
> I was thinking of being able to define a filter as:
>
> itk::AddIImageFilter< InputImageType, ColocatedImageAdaptor<InputImageType>, OutputImageType>.
>
> Where the adaptor object would need some information from the first input object, to ensure they are on the same grid.


Let's just not call it ImageAdaptor.

The actual image adaptors work by providing
alternative PixelAccessors that are used by
ImageIterators.

I agree that an "adaptor"-like class could
be used here. It just that is is a new
creature, and it should use a new name.


       Luis