[Insight-developers] Neighborhoods and filter output types

[Luis Ibanez]

Jim,


------------
> "Miller, James V (CRD)" wrote:
> Output type for a GradientFilter
> ...
>    * RecursiveGaussianGradientImageFilter is templated over the input
>      image type, the output image type, and a computation value type
>      (used for intermediate results).  This filter requires the user
>      to instantiate the filter with the proper output type (namely a
>      CovariantVector pixel type). Strictly speaking, this filter
>      allows the output type to be any pixel type that support
>      operator[]. But if we are going to use CovariantVectors for
>      gradients, we should probably restrict this filter to produce
>      CovariantVector images.
> 

I agree with you about using CovariantVectors for gradients. Maybe we
just have to vote for a trade-off between freedom of coding and 
mathematical correctness.  Changing the
RecursiveGaussianGradientImageFilter
for specifying an image of CovariantVectors shouldn't be too hard,
and I'll be happy to do it if we agree on that convention.


> 
> However, now we have an inconsistency for the template arguments for
> the various gradient image filters.  Can we decide on a consistent set
> of template parameters for these filters. Furthermore, some of the
> filters are not templated over the output image type.  Does the latter
> prevent ImageAdaptors? Do we allow "output adaptors" anymore?
> 

Adaptors have an internal face and an external face. Whatever is 
connected to the internal face can be resolve at run-time, but the
filters that connect to the external face have to be resolved at
compile time, that is, the filter should know that it is having 
an adaptor as parameter. 

In order to use output adaptors, the filter have to be templated
over the output. In that way when the filter type is instantiated,
it is possible to put an adaptor type as the type parameter.

It is worth to double-check that output adaptors are still doing
the rigth thing as far as memory allocation and streaming go.
Specially after the recent revision on the pipeline mechanisms.

Summarizing:  
    yes, we may want to encourage templating 
    filters over the output type.

BTW, that invalidates the previous comment about enforcing the 
output of the derivative filters to be Images of CovariantVectors,
because that will preclude the use of Image adaptors at the output.


> 
> Should the derivative operator take into account the spacing of the
> data?  Or should the derivative just be in parametric space and
> whomever uses the derivative operator (like the DerivativeImageFilter)
> must decide to convert the values to physical space.  I can go either
> way on this one.
> 

I vote for using the spacing. There will be a price in performace
for sure, but having fast filters that compute the wrong thing 
can be more costly.

That being said, once we are done with the spreadsheet assesment,
we may probably need another round for verifying the passage of 
pixel spacing through the pipeline.





Luis