<br><br>Hi, <br><br>i have investigated a little about the Vnl FFT implementation. My conclusion is that it works quite fine, but:<br><br>1) is limited only to images with some specific sizes. I am not sure which&nbsp;sizes Vnl FFT supports (i supposed either powers or multiples of two), but function
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;VnlFFTRealToComplexConjugateImageFilter&lt;TPixel,Dimension&gt;::Legaldim(int n)<br><br>is a little bit strange - but it may reflect what VnlFFT needs.&nbsp;Finally&nbsp;the&nbsp;padding&nbsp;code&nbsp;in&nbsp;FFTDirectInverse.cxx&nbsp;is&nbsp;does&nbsp;not&nbsp;reflect&nbsp;what&nbsp;Legaldim()&nbsp;checks. 
<br><br>For general usage, ITK wrapper should be able to padd the input image if neccessary (and probably store the original size as metadata, may be in the same way as FFTW wrapper does.)<br><br>2) Forward FFT is producing output, that is conjugate of what FFTW (consequently Matlab) produces. Inverse FFT is counting with that so the forward-inverse result by VnlFFT is fine. But if you do forward by VnlFFT and inverse by FFTW (Matlab), you get flipped result. It also very probably causes problems when there is some processing in the fourier domain.
<br><br>The solution would be&nbsp;to&nbsp;process&nbsp;the&nbsp;result&nbsp;of&nbsp;forward&nbsp;and&nbsp;input&nbsp;to&nbsp;inverse&nbsp;transform. <br><br><br>Note that these conclusions does not correspond with FFTDirectInvers.cxx example,&nbsp;so&nbsp;if&nbsp;i&nbsp;am&nbsp;wrong&nbsp;or&nbsp;i&nbsp;missed&nbsp;something,&nbsp;please,&nbsp;let&nbsp;me&nbsp;know.
<br> <br>Regards,<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jakub<br><br><br>PS: does someone have function for reading MHD files into Matlab? I have written something now, but it is not very &quot;complete&quot;.<br>