[Insight-developers] Proposed requirements for convolution filters in ITK

[Cory Quammen]

>> Here is what I would like to see in the convolution filters in ITK.
>>
>> - Convolution filters should have the same interface to make it easy
>> to switch between the spatial domain and Fourier domain methods. This
>> suggests a class hierarchy for image convolution filters, perhaps
>> organized as follows:
>>
>> --ConvolutionImageFilter
>> ---SpatialDomainConvolutionImageFilter
>> ---FourierDomainConvolutionImageFilter
>>
>
> Looks like a good idea, even if I would prefer some shorter names

Any suggestions for shorter names?

>
>> - Each algorithm should take two inputs. The first is treated as the
>> image to convolve and the second as the convolution kernel.
>>
>
> sounds good
>
>> - The output image should be the same size as the first input image.
>>
>
> In FFTConvolutionImageFilter I've added an option to get the padded image
> instead of the cropped one, at the request of Richard Beare, to do some auto
> correlation IIRC

That sounds like a reasonable option to add. In Matlab, the conv2
function also enables you to get only the valid portion of the output,
that is, only the pixels where the kernel image is contained entirely
within the input image boundary.

>> - Both the image to convolve and the kernel can have an arbitrary
>> size. There should be no assumption that requires the kernel to be
>> smaller than the input image in any dimension or to have an even or
>> odd size.
>
> agree
>
>>
>> - Results from the spatial domain implementation and Fourier domain
>> implementation should differ only by a tolerance when the same
>> settings are used for each filter and the pixel type of the images is
>> compatible with the underlying FFT routines used in the Fourier domain
>> implementation.
>
> agree
>
>>
>> - The spacing of the two input images should be required to be the
>> same (other specialized convolution algorithms may handle other
>> cases). *Or* the image with coarser spacing should be resampled to the
>> same spacing as the image with finer spacing.
>>
>
> I'm not so sure about this one. It would force the developer who is working
> with pixels rather than physical space to also set the origin, direction and
> spacing on the kernel image. I would prefer to have it as an option, as Kent
> just did for BinaryFunctorImageFilter

Good point.

>
>> - The user must have the ability to specify which index is treated as
>> the center of the second input. This should default to
>> floor((2*index+size-1)/2) where index and size are from the largest
>> possible region of the kernel image input.
>
> Can you give a use case for that feature?

Say I'm synthesizing some images to test deconvolution algorithms, and
the center of my microscope point-spread function does not correspond
to the central image index. I'd like to specify the index that should
be treated as the center of the PSF image rather than crop or resample
the PSF image.

This was initially motivated by the question of what to do when the
kernel size is even. Where do you center it? I think the filters
should automatically determine a center for convenience, but if the
user disagrees with the choice of the center made by the filter, s/he
should be able to specify the desired index that is treated as the
center. Without this feature, a user might need to change the size of
the kernel image by padding or cropping to accomodate the filter's
definition of the kernel center.

Alternatively, we could say that the center of the kernel is defined
to be index (0, 0, ... 0) and force the user to change the image
information to achieve the desired centering, but that seems like a
lot of work. It is simpler to specify which image index to treat as
the kernel center in the convolution filter directly.

>> - The treatment of regions beyond the boundaries of the input images
>> should be controllable by the user. Typical choices include constant
>> padding, periodic, mirror, and zero-flux Neumann boundary conditions.
>> Default should be constant padding with a constant of zero.
>>
>
> sounds good to me
>
>> - Normalization of the kernel image should be an option. Default is off.
>
> I'd prefer to have it on by default, especially if the kernel image has
> integer pixel types.

I'm not opposed to having it on by default.

>
>>
>> Outstanding question:
>>
>> - VNL operates only on images whose sizes are powers of two. For best
>> performance, FFTW requires that the largest prime factor in an image
>> size should be 13 or less. Input images should be padded to meet those
>> size constraints in the Fourier domain filter, but no such restriction
>> exists for padding in the spatial domain filter. Nevertheless, to
>> compare outputs of the spatial and Fourier domain filters, users
>> should be able to set the padding size in the spatial domain filter to
>> be the same as the padding in the Fourier domain filter. Does exposing
>> a class method to control this justified if it is used only for
>> testing? Or should testing for agreement between the spatial and
>> Fourier domain filters be restricted to cases where no special padding
>> for VNL or FFTW is required?
>
> I don't understand why this would be needed for testing. Can you elaborate?

On second thought, this shouldn't be a problem. I had an incorrect
understanding of how the padding should work until I drew out the
scenarios I was concerned about on paper.

Thanks,
Cory

>
>
>
>>
>> Please let me know what you think.
>>
>> Thanks,
>> Cory
>>
>> --
>> Cory Quammen
>> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
>> Department of Computer Science
>> University of North Carolina at Chapel Hill
>> http://www.cs.unc.edu/~cquammen
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.itk.org
> http://www.mandriva.org  http://www.bepo.fr
>
>



-- 
Cory Quammen
Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen