Add `itkFFTDiscreteGaussianImageFilter`

[tbirdso]

Description

As we expand object factory methods for overriding FFT backends we can leverage accelerated FFTs for image processing. Image convolution with a Gaussian kernel can be accelerated for large images as multiplication in the frequency domain.

API details: Same as itkDiscreteGaussianImageFilter

Class hierarchy: Extends itkFFTConvolutionImageFilter

Internal implementation:

1. Construct Gaussian kernel from user parameters
2. Perform forward FFT to transform input image and Gaussian kernel into Fourier domain
3. Multiply in frequency space (== convolution in physical space)
4. Perform inverse FFT to transform resulting image back into physical space

Assign to @tbirdso

[tbirdso]

@thewtex

[thewtex]

@tbirdso excellent!

In addition, we can:

• Name the filter itk::FFTDiscreteGaussianImageFilter
• Generate the kernel with the itk::GaussianImageSource
• Generate the kernel directly in FFT-space

[tbirdso]

@thewtex I've started working on this but I'm having misgivings about the class hierarchy.

We want to extend itk::FFTConvolutionImageFilter to implement the interface described by itk::DiscreteGaussianImageFilter. It would be nice if we could make itk::FFTDiscreteGaussianImageFilter a subclass of itk::DiscreteGaussianImageFilter to allow the potential for overriding internal calls with object factory methods similar to how we do with FFT image filters. However, with multiple inheritance we run into the issue of both interfaces inheriting itk::ImageToImageFilter.

Could you share your thoughts on the design to be implemented here? What would be the downsides of relying on virtual inheritance, i.e. making one or both parents inherit from virtual ImageToImageFilter, to resolve the issue?

[dzenanz]

If I remember correctly, ITK style prevents diamond inheritance. See the case of ScanlineFilterCommon as added in d9e6b51 and then used again in 432bd97. Its Python wrapping was added in b803885. It is hard to get it right when you are fighting against the usual patterns.

[tbirdso]

Thanks @dzenanz, from those commits the demands of multiple inheritance definitely seem a bit intimidating in this context.

Perhaps a better design would be to implement FFTDiscreteGaussianImageFilter as a subclass of DiscreteGaussianImageFilter which redefines the GenerateData method to rely on a minipipeline making use of an FFTConvolutionImageFilter? This would avoid multiple inheritance altogether.

[thewtex]

@tbirdso I think I see what you are saying, and the factory is strong 🧑‍🚀 👽 , but, yes, jus simple single inheritance, no factory, provides a good trade-off of complexity, code re-use, and how the code is used. @dzenanz is right -- we should avoid multiple inheritance.

Perhaps a better design would be to implement FFTDiscreteGaussianImageFilter as a subclass of DiscreteGaussianImageFilter which redefines the GenerateData method to rely on a minipipeline making use of an FFTConvolutionImageFilter? This would avoid multiple inheritance altogether.

@tbirdso 👍 yes that's it!

[tbirdso]

Closed with #3121