Discussion:
[Gwyddion-users] false aspect ratio with 2D-FFT
Mathias Müller
2014-01-17 10:03:10 UTC
Permalink
Hi yeti,

it seems I found an issue regarding the 2D-FFT transformation in the current Gwyddion release (v2.34).

I have (again) data with a physical dimension of 1 x 1 q-microns with a pixel aspect ratio of 2:1.

Performing standard operations like leveling etc everything works fine. But when continuing with FFT transformation
the output relates to the aspect ratio of the pixel size. Not only in the aspect ratio of the displayed image is falsified but also
its physical dimension. Here, the xrange goes from [-256:256] invers microns, but the yrange is [-126:126] invers microns.
This should be equal.

Fruther, the toggle menu in the left corner (change between physically square and pixelwise square) does not respond.

Is there a chance to fix this?

Cheers,

/M
David Nečas (Yeti)
2014-01-17 12:27:07 UTC
Permalink
Post by Mathias Müller
it seems I found an issue regarding the 2D-FFT transformation in the
current Gwyddion release (v2.34).
I have (again) data with a physical dimension of 1 x 1 q-microns with
a pixel aspect ratio of 2:1.
Performing standard operations like leveling etc everything works
fine. But when continuing with FFT transformation the output relates
to the aspect ratio of the pixel size. Not only in the aspect ratio of
the displayed image is falsified but also its physical dimension.
Here, the xrange goes from [-256:256] invers microns, but the yrange
is [-126:126] invers microns.
This should be equal.
There might be some subtle bug, but basically the output seems correct.
How things correspond between the direct and requency space?

Direct space Frequency space
───────────────────────────────────────────────────────────
Pixel size Δx Image size 2π/Δx
Pixel size Δy Image size 2π/Δy
Image size Lx Pixel size 2π/Lx
Image size Ly Pixel size 2π/Ly

Your direct-space image has equal dimensions (1µm), so your FFT image
should have *square pixels*.

Your direct-space image has non-square pixels, so your FFT image should
have *non-equal dimensions*.

And this is indeed what you observe.
Post by Mathias Müller
Fruther, the toggle menu in the left corner (change between physically
square and pixelwise square) does not respond.
So, of course the toggle works because the pixels are square.

Regards,

Yeti
David Nečas (Yeti)
2014-01-17 12:32:17 UTC
Permalink
Post by David Nečas (Yeti)
There might be some subtle bug, but basically the output seems correct.
How things correspond between the direct and requency space?
Direct space Frequency space
───────────────────────────────────────────────────────────
Pixel size Δx Image size 2π/Δx
Pixel size Δy Image size 2π/Δy
Image size Lx Pixel size 2π/Lx
Image size Ly Pixel size 2π/Ly
I should have complemented the table with the numbers of pixels in each
dimension:

Direct space Frequency space
───────────────────────────────────────────────────────────
Resolution Nx Resolution Nx
Resolution Mx Resolution Mx

They are the same in direct and fequency. But one needs to take this
into account explicitly to
Mathias Müller
2014-01-17 13:13:28 UTC
Permalink
Oh great, I see. I just ignored the conversion to the freqency space. Of cause this makes totally sense.
I was totally fixed on the must-have-square-dimensions of my images. This was way too much data analysis
for today.

Sorry to bother you, I would like to take back the bug report :-)
Post by David Nečas (Yeti)
Post by David Nečas (Yeti)
There might be some subtle bug, but basically the output seems correct.
How things correspond between the direct and requency space?
Direct space Frequency space
───────────────────────────────────────────────────────────
Pixel size Δx Image size 2π/Δx
Pixel size Δy Image size 2π/Δy
Image size Lx Pixel size 2π/Lx
Image size Ly Pixel size 2π/Ly
I should have complemented the table with the numbers of pixels in each
Direct space Frequency space
───────────────────────────────────────────────────────────
Resolution Nx Resolution Nx
Resolution Mx Resolution Mx
They are the same in direct and fequency. But one needs to take this
into account explicitly to make sense of things...
Loading...