Help with ImgLib2 algorithm.fft.FourierTransform

I am trying to develop a plugin for ImageJ2, and I need to perform the FFT on an image. Since I’m new to developing for ImageJ2, I looked at examples online, and I found one that uses net.imglib2.algorithm.fft.FourierTransform. However, when I try to compute the FFT of a 512 by 512 image, it seems that the output is 360 by 720. I am very confused, because I believe the FFT is supposed to have the same dimensions as the input image, but the output is very different. This is my code for computing the FFT:

final FourierTransform< FloatType, ComplexFloatType > fft = new FourierTransform< FloatType, ComplexFloatType >(image, new ComplexFloatType() );
fft.process();
final Img< ComplexFloatType > templateFFT = fft.getResult(); 

Thanks!

Good day!

Although I have very little insights to ImageJ-2, I know that it comprises a module that performs a certain kind of Fourier transformation. The implementation is said to be mostly faster than the classic FFT and is widely independent of the image format (no need for square-sized 2^x support). As you’ve observed already, the output format takes some getting used to …

I have no idea whether the ImageJ-1 FFT-implementation was conserved or re-programmed in ImageJ-2. At least the ImageJ-1 FFT-implementation should be accessible. It works as you would expect it to work but it is no classic FFT-implementation as well because it is based on the Fast Hartley Transformation which is slightly faster than the classic FFT-implementation. If you are looking for the classic implementation, then the ImageJ plugin “Parallel FFTJ” is what you should consider:
https://sites.google.com/site/piotrwendykier/software/parallelfftj

Regards

Herbie

4 Likes

Hi @egosti

There are a couple of similar questions here and here.

Basically the output size of an FFT can be different than what you expect because the input to the FFT is sometimes padded to a “fast” size. The fast sizes can be different between different implementations. As well the FFT output is complex, however the FFT of a real signal is symmetric, so the redundant part of the FFT is sometimes discarded. Finally there is sometimes an additional padding factor added to the signal to prevent edge artifacts (in addition to padding to a fast size).

The library you are using FourierTransform is an older library that has been replaced by FFTMethods

Imagej-ops, wraps FFTMethods. I just tested the following script using the bridge (512 by 512) sample image.

# @OpService ops
# @UIService ui
# @Dataset img

from net.imglib2.img.display.imagej import ImageJFunctions

print img.dimension(0)
print img.dimension(1)

fft=ops.filter().fft(img.getImgPlus())

print fft.dimension(0)
print fft.dimension(1)

# display fft (by default it is displayed as power spectrum)
ImageJFunctions.show(fft).setTitle("fft power spectrum")

The output size is 281 by 560. This is because it was padded to a fast size, and the redundant complex values were eliminated. Your output size was different because FourierTransform uses a slightly different padding strategy.

Note that imagej-ops is meant to be expandable such that many implementations of different algorithms can be implemented. Thus in the future other implementations (ImageJ1-Hartley, Parallel FFTJ, FFTW, cufft, etc.) may be wrapped.

2 Likes

To whom it may concern,

in the days (summer 2012) when @StephanPreibisch worked on the discussed implementation of the Fourier-transformation, I had an exchange of opinions with him and argued that at least two aspects should be changed:

  1. This transformation should not be called FFT.
  2. All kinds of automatic padding and windowing should be omitted and left to the user.

Neither suggestion was finally realized and I know why. The reasons were not transparency …

Just my 5 Euro-cents

Herbie

1 Like