<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 10:41 PM, Pablo Hernández <span dir="ltr"><<a href="mailto:pablo.hernandez.cerdan@outlook.com" target="_blank">pablo.hernandez.cerdan@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div dir="ltr">
<div>
<div>
<div>Thanks Matt, I agree that the more appropriate thing to do would be to document better, but maybe only in the ForwardFFT filter instead of ImageBase?<br></div></div></div></div></div></blockquote><div><br></div><div>Yes, ForwardFFTImageFilter is a good location, too.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div><div><div>
I can imagine experiments where the input images are in the frequency domain: photo detectors in scattering ( from this search [1], these images [2] for example). In this case origin and spacing metadata make sense as they are, even though the experimenters
 know the physical units of the images are in hertz, not in meters.<br></div></div></div></div></div></blockquote><div><br></div><div>Clarification and a good interface is also important for a common application encountered in medical imaging: magnetic resonance imaging collects samples in k-space.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div><div>
<div>The problem with the metadata arises exclusively doing the FFT. If we modify it, we will lose the input image metadata. If we don't, the metadata of the output requires extra knowledge and read the documentation to be meaningful.<br>
<br>
</div>
<div>Also the Origin is tricky... the first bin, or index {0}, of the output of an FFT depends on the frequency layout of the algorithm, usually in the "standard" layout, it corresponds to zero frequency [3]. So the Origin(Frequency) will be 0.0 if we understand
 the origin with the value of the first index..., but if the FFT is shifted, the first index would be now a large, negative frequency.<br>
</div>
<div><br>
</div>
</div>
<div>In the ExternalModule, I am using a FrequencyIterator, derived from a regular ImageRegionIterator. It adds a GetFrequency() function, providing an abstraction to let the user stop worrying about the specifics of the frequency layout.<br>
There are 3 different layouts, Regular, FFTLayout, and ShiftedFFTLayout.<br>
- Regular is a normal iterator, with GetFrequency() calling Get(), for the case I commented when the image is taken in the frequency domain, but the user needs to use the IsotropicWavelet module on it (which requires frequency iterators).<br>
</div>
<div>- FFTLayout is the standard FFT layout, vnl, fftw, and I think python uses it as well. This is the default type.<br>
</div>
<div>- ShiftedFFTLayout, the layout after shifting the FFT.</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div><div>
<br>
</div>
<div>This allows to iterate an image from the frequency domain, and get the frequency value, the frequency bin, as well as actual value of the current pixel.<br>
And also they are a good place to store frequency 'metadata' information such as FrequencyOrigin, and FrequencySpacing, that depends on the frequency layout: See [4]
<br></div></div></div></div></blockquote><div><br></div><div>These iterators with the explicit methods are excellent! The naming makes their meaning clear, and they are also practically useful for processing FFT data. Great idea.</div><div>  </div><div><br></div><div>Cheers,</div><div>Matt</div></div></div></div>