[Insight-developers] FFT implementations handle spacing differently

[Cartik Sharma]

In addition to previous post and compiler statements from your message, we
might need to introduce
filters to "cleanse" the data, reduce noise and then perform the actual
FFTw transform.

This in combination with computing for the coefficients with *standard* FFT
techniques should help
remove the bug. As mentioned earlier, we also need to check for precision
in computing coefficient
values.

-Cartik

On Thu, Sep 27, 2012 at 10:15 AM, Cartik Sharma <cartik.sharma at gmail.com>wrote:

> Dear Kent,
>
> From previous knowledge of Fourier transforms, this seems like it might
> have to do with computing
> coefficients with extreme precision.
> Depending on the nature of data, there might also be the added problem
> with dimensionality reduction, so you might have to have a dimensionality
> reduction technique to filter out correlations in data components.
>
> Please post the code and we'll correct the pos/space and orientation
> computation based on above suggestions and then have domain transformation
> with FFT as well as with reverse transformations
> with the iFFTs.
>
> Best regards,
> Cartik
>
> On Thu, Sep 27, 2012 at 10:00 AM, Williams, Norman K <
> norman-k-williams at uiowa.edu> wrote:
>
>> This is code I wrote years ago, so I'd have stop what I'm doing and spend
>> a couple hours reading the code to know what was really going on.  But it
>> sounds like the pos/orientation/spacing isn't being propogated from the
>> input to the FFT and by the IFFT to the output.
>>
>> I would argue that this should always happen -- an image converted to the
>> frequency domain doesn't transform it spatially; no matter what you do in
>> the frequency domain, when you transform back to the spatial domain, it
>> should be oriented and positioned the same.
>>
>> --
>> Kent Williams norman-k-williams at uiowa.edu
>>
>>
>>
>>
>>
>>
>> On 9/27/12 7:13 AM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>>
>> >Hello,
>> >
>> >I have compiled SimpleITK with FFTW and I am getting the following
>> >regression test failue:
>> >
>> >81: [ RUN      ] BasicFilters.ForwardFFT_defaults
>> >81: Starting image compare on BasicFilters_ForwardFFT_defaults_
>> >81: Loading baseline
>>
>> >/Users/blowekamp/src/SimpleITK/Testing/Data/Baseline/BasicFilters_ForwardF
>> >FT_defaults.nrrd
>> >81:
>>
>> >/scratch/blowekamp/build/SimpleITK/SimpleITK-build/Testing/Unit/sitkForwar
>> >dFFTImageFilterTest.cxx:128: Failure
>> >81: Value of: imageCompare.compare( output, "", "" )
>> >81:   Actual: false
>> >81: Expected: true
>> >81: ImageCompare: Failed to subtract image
>>
>> >/Users/blowekamp/src/SimpleITK/Testing/Data/Baseline/BasicFilters_ForwardF
>> >FT_defaults.nrrd because:
>>
>> >/scratch/blowekamp/build/SimpleITK/ITK-prefix/include/ITK-4.2/itkImageToIm
>> >ageFilter.hxx:243:
>> >81: itk::ERROR: SubtractImageFilter(0x7ffe943009e0): Inputs do not occupy
>> >the same physical space!
>> >81: InputImage Origin: [0.0000000e+00, 0.0000000e+00, 0.0000000e+00],
>> >InputImageIndexedDataObject1 Origin: [2.8345293e-01, 2.8345293e-01,
>> >2.8345293e-01]
>> >81:    Tolerance: 1.0000000e-06
>> >81: InputImage Spacing: [1.0000000e+00, 1.0000000e+00, 1.0000000e+00],
>> >InputImageIndexedDataObject1 Spacing: [7.5587445e-01, 7.5587445e-01,
>> >7.5587445e-01]
>> >81:    Tolerance: 1.0000000e-06
>> >
>> >
>> >This is telling me that the vnl and the FFTW implementation of the
>> >ForwardFFT image filter are handling the spacing different. The second
>> >input is the baseline originating from the Vnl FFT implementation, while
>> >the one from FFTW still has the default origin and spacing. However, I am
>> >uncertain that this actually make sense, as the FFTForward filter does
>> >converts from the spacial domain to the frequency this physical
>> >information may not be very logical.
>> >
>> >What should the correct behavior be?
>> >
>> >Thanks,
>> >Brad
>> >
>> >ps
>> >Please note that this exception is coming from the cumbersome standard
>> >check in the ImageToImageFilter during comparison to the baseline. And
>> >it's revealing a true bug.
>> >_______________________________________________
>> >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.php
>> >
>> >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
>>
>>
>>
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by
>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>> confidential and may be legally privileged.  If you are not the intended
>> recipient, you are hereby notified that any retention, dissemination,
>> distribution, or copying of this communication is strictly prohibited.
>>  Please reply to the sender that you have received the message in error,
>> then delete it.  Thank you.
>> ________________________________
>> _______________________________________________
>> 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.php
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120927/e1dff71f/attachment.htm>