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

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Jun 1 15:22:12 EDT 2011


Hi Cory,

Le 1 juin 11 à 17:17, Cory Quammen a écrit :

> 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

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

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

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

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

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

Gaëtan



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110601/e6c76ba0/attachment.pgp>


More information about the Insight-developers mailing list