[Gwyddion-users] 2D-FFT conversion

[Mathias Müller]

Hi,

in my C-code I want to apply the gwyddion fft-transformation to SPM data.

the code sniplet is:

data_field_fft_r = gwy_data_field_new_alike(data_field, TRUE);
data_field_fft_i = gwy_data_field_new_alike(data_field, TRUE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_2dfft_humanize(data_field_fft_r) ;

where data_field is obtained from real space data.

When displaying the artifical data, it looks pretty good, e.g. like a hexagonal structure. Comparing the coordinates within the differently obtained FFT images, it looks
like all the x and y values are way larger in the c-code 2d-FFT (no window) then the one from the gwyddion module. I.e. the very center of the gwyddion-performed fft-image
is nearly at (0.002,0.004) nm^-1. But the data reasulting from gwy_data_field_2dfft_humanize(data_field_fft_r) show a center at approx. (3.43886e-08,5.05459e-08)...I guess m^-1.


There seems to be a juge difference. Does gwyddion itself calculate the 2d-fft in another way?

Thanks for helping.

Cheers,

/M

[David Nečas (Yeti)]

Post by Mathias Müller
in my C-code I want to apply the gwyddion fft-transformation to SPM data.
data_field_fft_r = gwy_data_field_new_alike(data_field, TRUE);
data_field_fft_i = gwy_data_field_new_alike(data_field, TRUE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_2dfft_humanize(data_field_fft_r) ;
where data_field is obtained from real space data.
When displaying the artifical data, it looks pretty good, e.g. like a hexagonal structure. Comparing the coordinates within the differently obtained FFT images, it looks
like all the x and y values are way larger in the c-code 2d-FFT (no window) then the one from the gwyddion module. I.e. the very center of the gwyddion-performed fft-image
is nearly at (0.002,0.004) nm^-1. But the data reasulting from gwy_data_field_2dfft_humanize(data_field_fft_r) show a center at approx. (3.43886e-08,5.05459e-08)...I guess m^-1.

Functions such as gwy_data_field_2dfft() only perform the transforms.
They do not set units nor real fiels dimensions. This is somewhat
unfortunate, but backward compatible. See for instance
fft_prosptocess() in the FFT module:

https://sourceforge.net/p/gwyddion/code/HEAD/tree/trunk/gwyddion/modules/process/fft.c#l182

Regards,

Yeti

[Mathias Müller]

Oh thanks for the hint, Yeti.

I guess this fft_postprocess() can be applied without any modification. Could you add this function to the gwyddion API?
It might be useful for others as well.


Cheers,

/M

Post by David Nečas (Yeti)

Post by Mathias Müller
in my C-code I want to apply the gwyddion fft-transformation to SPM data.
data_field_fft_r = gwy_data_field_new_alike(data_field, TRUE);
data_field_fft_i = gwy_data_field_new_alike(data_field, TRUE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_2dfft_humanize(data_field_fft_r) ;
where data_field is obtained from real space data.
When displaying the artifical data, it looks pretty good, e.g. like a hexagonal structure. Comparing the coordinates within the differently obtained FFT images, it looks
like all the x and y values are way larger in the c-code 2d-FFT (no window) then the one from the gwyddion module. I.e. the very center of the gwyddion-performed fft-image
is nearly at (0.002,0.004) nm^-1. But the data reasulting from gwy_data_field_2dfft_humanize(data_field_fft_r) show a center at approx. (3.43886e-08,5.05459e-08)...I guess m^-1.

Functions such as gwy_data_field_2dfft() only perform the transforms.
They do not set units nor real fiels dimensions. This is somewhat
unfortunate, but backward compatible. See for instance
https://sourceforge.net/p/gwyddion/code/HEAD/tree/trunk/gwyddion/modules/process/fft.c#l182
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
I guess this fft_postprocess() can be applied without any
modification. Could you add this function to the gwyddion API?

Good idea. See revision 16525.

Regards,

Yeti

[Mathias Müller]

That was pretty fast. Thanks alot!

Cheers,

/M

Post by David Nečas (Yeti)

Post by Mathias Müller
I guess this fft_postprocess() can be applied without any
modification. Could you add this function to the gwyddion API?

Good idea. See revision 16525.
Regards,
Yeti

[Mathias Müller]

I implemented the postprocess function to my plugin code. It compiles without errors.
However, when loading my plugin gwyddion crashes.

(gwyddion:20392): GLib-GObject-CRITICAL **: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed
zsh: trace trap (core dumped) gwyddion

But this doesn't relate to this very new function. When commenting the postprocess() it still crashes.
Returning to the stable version (cleaning the system,recompiling,installing,etc...and the code without postprocess)
the plugin works pretty well - again. The same code recompiled with the nightly snapshot...nope.

Further, I cannot use the ctrl+{1,2,3..} to open recently opened data. Gwyddion crashes already when pressing <ctrl>

(gwyddion:19037): Gtk-CRITICAL **: IA__gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed


Did you change anything else that might collide with gobject/gtk2?

I am running an archlinux OS with gtk2 version 2.24.24-1.

I apologize sorry for the trouble,

/M

Post by David Nečas (Yeti)

Post by Mathias Müller
I guess this fft_postprocess() can be applied without any
modification. Could you add this function to the gwyddion API?

Good idea. See revision 16525.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
I implemented the postprocess function to my plugin code. It compiles without errors.
However, when loading my plugin gwyddion crashes.
(gwyddion:20392): GLib-GObject-CRITICAL **: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed
zsh: trace trap (core dumped) gwyddion
But this doesn't relate to this very new function. When commenting the postprocess() it still crashes.
Returning to the stable version (cleaning the system,recompiling,installing,etc...and the code without postprocess)
the plugin works pretty well - again. The same code recompiled with the nightly snapshot...nope.
Further, I cannot use the ctrl+{1,2,3..} to open recently opened data. Gwyddion crashes already when pressing <ctrl>
(gwyddion:19037): Gtk-CRITICAL **: IA__gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

Please get backtraces from the coredumps. These are generic errors
that can appear practically anywhere if a bad pointer is passed to some
function. If it does not dump core
a) set ulimit -c unlimited
b) run gwyddion with G_DEBUG=fatal-criticals

Regards,

Yeti

[Mathias Müller]

ok, here we go: I recompiled the snapshot with G_DEBUG=fatal-criticals....but still the symbols are missing somehow.

Core was generated by `gwyddion'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 0x00007f249d48ad00 in g_logv () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007f249d48ad00 in g_logv () from /usr/lib/libglib-2.0.so.0
#1 0x00007f249d48af1f in g_log () from /usr/lib/libglib-2.0.so.0
#2 0x00007f247e22e186 in test_plugin (current_data=0x0, run=GWY_RUN_NONE) at fft_plugin.c:222
#3 0x00007f249f4fce63 in gwy_process_func_run () from /usr/lib/libgwymodule2.so.0
#4 0x00007f249f73e4d0 in gwy_app_run_process_func_in_mode () from /usr/lib/libgwyapp2.so.0
#5 0x00007f249f73e7af in gwy_app_run_process_func () from /usr/lib/libgwyapp2.so.0
#6 0x00007f249d754435 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#7 0x00007f249d7669fc in ?? () from /usr/lib/libgobject-2.0.so.0
#8 0x00007f249d76f228 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#9 0x00007f249d76f48f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#10 0x00007f249e86c836 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x00007f249e7687bd in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00007f249e768b5b in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x00007f249e7568bf in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x00007f249d754435 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#15 0x00007f249d7668f2 in ?? () from /usr/lib/libgobject-2.0.so.0
#16 0x00007f249d76ed36 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#17 0x00007f249d76f48f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#18 0x00007f249e86daac in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#19 0x00007f249e755004 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#20 0x00007f249e75549b in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00007f249e3cae4c in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#22 0x00007f249d483c7d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#23 0x00007f249d483f68 in ?? () from /usr/lib/libglib-2.0.so.0
#24 0x00007f249d484292 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#25 0x00007f249e754417 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x0000000000408a8c in main ()

Do I need to recompile gwyddion width -g to get more reasonable information?

Post by David Nečas (Yeti)

Post by Mathias Müller
I implemented the postprocess function to my plugin code. It compiles without errors.
However, when loading my plugin gwyddion crashes.
(gwyddion:20392): GLib-GObject-CRITICAL **: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed
zsh: trace trap (core dumped) gwyddion
But this doesn't relate to this very new function. When commenting the postprocess() it still crashes.
Returning to the stable version (cleaning the system,recompiling,installing,etc...and the code without postprocess)
the plugin works pretty well - again. The same code recompiled with the nightly snapshot...nope.
Further, I cannot use the ctrl+{1,2,3..} to open recently opened data. Gwyddion crashes already when pressing <ctrl>
(gwyddion:19037): Gtk-CRITICAL **: IA__gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

Please get backtraces from the coredumps. These are generic errors
that can appear practically anywhere if a bad pointer is passed to some
function. If it does not dump core
a) set ulimit -c unlimited
b) run gwyddion with G_DEBUG=fatal-criticals
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
ok, here we go: I recompiled the snapshot with G_DEBUG=fatal-criticals....but still the symbols are missing somehow.

This is a run-time environment variable to make it dump core on critical
errors. It makes no difference on compilation.

https://developer.gnome.org/glib/stable/glib-running.html#G-DEBUG:CAPS

Post by Mathias Müller
#2 0x00007f247e22e186 in test_plugin (current_data=0x0, run=GWY_RUN_NONE) at fft_plugin.c:222

Well, here's where it fails. So look at line 222 in your module.

Compiling Gwyddion or the module with -Og -ggdb can help to make sense
of the backtrace but does not seem necessary right now.

Regards,

Yeti

[Mathias Müller]

Uff, ok t here is a bunch of documentation left to read.

However, here is the line:

g_object_set_data(G_OBJECT(args.detect.selection[0]), "vector-layer", vector_layer[0]);


where:

args.detect.selection is : GwySelection *selection[2];
vector_layer[0] is : GwyVectorLayer *vector_layer[3];

This line works fine in gwyddion-stable.

I let the plugin run with G_DEBUG=fatal-criticals environment, but the core dump doesn't get more information.

Post by David Nečas (Yeti)

Post by Mathias Müller
ok, here we go: I recompiled the snapshot with G_DEBUG=fatal-criticals....but still the symbols are missing somehow.

This is a run-time environment variable to make it dump core on critical
errors. It makes no difference on compilation.
https://developer.gnome.org/glib/stable/glib-running.html#G-DEBUG:CAPS

Post by Mathias Müller
#2 0x00007f247e22e186 in test_plugin (current_data=0x0, run=GWY_RUN_NONE) at fft_plugin.c:222

Well, here's where it fails. So look at line 222 in your module.
Compiling Gwyddion or the module with -Og -ggdb can help to make sense
of the backtrace but does not seem necessary right now.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
g_object_set_data(G_OBJECT(args.detect.selection[0]), "vector-layer", vector_layer[0]);
args.detect.selection is : GwySelection *selection[2];
vector_layer[0] is : GwyVectorLayer *vector_layer[3];
This line works fine in gwyddion-stable.

For some reason, args.detect.selection[0] does not contain a valid
GObject pointer. I can't tell anything more from the information I
have. Trying printing it (should look suspiscious), running under
valgrind...

I don't know where and how you get the selection object.

Post by Mathias Müller
I let the plugin run with G_DEBUG=fatal-criticals environment, but the
core dump doesn't get more information.

It just enforces the core dump. If a core dump is already produced in
your environment the variable will not change anything.

BTW there seems something strange with recent files. If you keep the
file name and just select a different directory, it remembers some
rubbish as the file name. Furthermore, it started producing duplicate
entries. I'm not sure what has changed. I have to look into it.

Yeti

[Mathias Müller]

Ok, I got it work. I do not know why, but compiling against gwyddion stable [0] works fine but for the nightly
snaptshot it doesn't. Moving to array position [1] works flawless with the desired image output. This is something I
+do not understand yet. Maybe we should forget about this. I guess this is a strongly to my code related issue.


But this leads to problem #2. I am applying the gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ; to my
fft data obtained via:

gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;

results in the same data display, but with way larger x and y values.

(0,0) is something like [2,57677e+09,2,56559e+09] (1/m I guess) and an example fft peak [1,7607e+09,2,57677e+09] which is in the gwyddion fft-module
(-0.82/nm,0)...However,correcting the coorcdinates with the zero position it fits quit well. But the corrected fft-output is not centered at (0,0).

Shouldn't this be done by the fft_postprocess() ?

Post by Mathias Müller
Uff, ok t here is a bunch of documentation left to read.
g_object_set_data(G_OBJECT(args.detect.selection[0]), "vector-layer", vector_layer[0]);
args.detect.selection is : GwySelection *selection[2];
vector_layer[0] is : GwyVectorLayer *vector_layer[3];
This line works fine in gwyddion-stable.
I let the plugin run with G_DEBUG=fatal-criticals environment, but the core dump doesn't get more information.

Post by David Nečas (Yeti)

Post by Mathias Müller
ok, here we go: I recompiled the snapshot with G_DEBUG=fatal-criticals....but still the symbols are missing somehow.

This is a run-time environment variable to make it dump core on critical
errors. It makes no difference on compilation.
https://developer.gnome.org/glib/stable/glib-running.html#G-DEBUG:CAPS

Post by Mathias Müller
#2 0x00007f247e22e186 in test_plugin (current_data=0x0, run=GWY_RUN_NONE) at fft_plugin.c:222

Well, here's where it fails. So look at line 222 in your module.
Compiling Gwyddion or the module with -Og -ggdb can help to make sense
of the backtrace but does not seem necessary right now.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
Ok, I got it work. I do not know why, but compiling against gwyddion
stable [0] works fine but for the nightly
snaptshot it doesn't. Moving to array position [1] works flawless with
the desired image output.

This looks like you are overwriting the stack somewhere. Running under
valgrind may not help in this case but still it is worth trying.

Post by Mathias Müller
But this leads to problem #2. I am applying the gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ; to my
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
results in the same data display, but with way larger x and y values.
(0,0) is something like [2,57677e+09,2,56559e+09] (1/m I guess)

It should not be ‘I guess’. It should actually invert the xy unit of
the field. Does your field have correct lateral units to begin with?

Post by Mathias Müller
and an example fft peak [1,7607e+09,2,57677e+09] which is in the
gwyddion fft-module (-0.82/nm,0)...

1/nm = 10⁹ 1/m

So you seem to be off but the overall magnitude is right.

Post by Mathias Müller
However,correcting the coorcdinates
with the zero position it fits quit well. But the corrected fft-output
is not centered at (0,0).
Shouldn't this be done by the fft_postprocess() ?

Yes, it should. The simplest use is probably in
modules/process/fft_profile.c. See prof_psdf(). If it didn't set the
origin right, the profile selection in the GUI would be wrong because
one endpoint of the line is at (0,0) by definition. But it works for
me.

Regards,

Yeti

[Mathias Müller]

I already use the function as it is meant to be used and the sample data is fine, since the gwyddion fft-module displays everything correctly.
But when getting data points via:

gwy_selection_get_object(selection, ID, pos)

the center of my fft output is non-zero even after applying gwy_data_field_fft_postprocess(data_field_fft_r,TRUE).
However, the peak coordinates are fine when subtracting the fft center.

This puzzles me. Somehow my (x,y) offsets are not corrected after having them postprocessed. I apply it right after gwy_data_field_2dfft
as you do in prof_psdf.

Post by David Nečas (Yeti)

Post by Mathias Müller
Ok, I got it work. I do not know why, but compiling against gwyddion
stable [0] works fine but for the nightly
snaptshot it doesn't. Moving to array position [1] works flawless with
the desired image output.

This looks like you are overwriting the stack somewhere. Running under
valgrind may not help in this case but still it is worth trying.

Post by Mathias Müller
But this leads to problem #2. I am applying the gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ; to my
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
results in the same data display, but with way larger x and y values.
(0,0) is something like [2,57677e+09,2,56559e+09] (1/m I guess)

It should not be ‘I guess’. It should actually invert the xy unit of
the field. Does your field have correct lateral units to begin with?

Post by Mathias Müller
and an example fft peak [1,7607e+09,2,57677e+09] which is in the
gwyddion fft-module (-0.82/nm,0)...

1/nm = 10⁹ 1/m
So you seem to be off but the overall magnitude is right.

Post by Mathias Müller
However,correcting the coorcdinates
with the zero position it fits quit well. But the corrected fft-output
is not centered at (0,0).
Shouldn't this be done by the fft_postprocess() ?

Yes, it should. The simplest use is probably in
modules/process/fft_profile.c. See prof_psdf(). If it didn't set the
origin right, the profile selection in the GUI would be wrong because
one endpoint of the line is at (0,0) by definition. But it works for
me.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
I already use the function as it is meant to be used and the sample data is fine, since the gwyddion fft-module displays everything correctly.
gwy_selection_get_object(selection, ID, pos)

I don't understand what you are trying to accomplish. The selection is
just a set of real (as opposed to pixel) coordinates. If you have a
selection point saying it has coordinates (0,0) it has these
coordinates. You can use this selection in connection with some data
field to do something. Only in this combination the coordinates mean
something in some data field. If you shift the data field origin, (0,0)
will still mean ‘wherever (0,0) is in this field now’.

Post by Mathias Müller
This puzzles me. Somehow my (x,y) offsets are not corrected after
having them postprocessed. I apply it right after gwy_data_field_2dfft
as you do in prof_psdf.

Which offsets? For data field offsets, try printing

gwy_data_field_get_xoffset(dfield)
and

gwy_data_field_get_xoffset(dfield) + gwy_data_field_get_xreal(dfield)

They should be approximately the same with opposite signs (it depends on
the pixel size parity).

For selections, they will contain the coordinates you stored to them.

Regards,

Yeti

[Mathias Müller]

I see we talk at cross purposes. Sorry for that confusion.

By offset I am talking about the offset at the image center.

What I wanted to say is, that my FFT image doesn't have a center at (0,0) after postprocessing the data field.
But this is somehow achieved in the gwyddion fft-module.

I just realize this when comparing the fft images of my test data obtained with the gwyddion module and with the
output of gwy_data_field_fft_postprocess(). The center in my plugin-generated fft image is simply not the center
of the coordinate system which I expect after applying gwy_data_field_fft_postprocess().

my offsets:

-2,565e+09 and 2,555e+09

They seem to be what you expect them to be.

in the image: left edge -> x = 5,58952e+06
right edge -> x = 5,11441e+09


So in between there is no 0...same for the y coordinate. I don't do much on these data but gwy_data_field_2dfft and gwy_data_field_fft_postprocess.

Post by David Nečas (Yeti)

Post by Mathias Müller
I already use the function as it is meant to be used and the sample data is fine, since the gwyddion fft-module displays everything correctly.
gwy_selection_get_object(selection, ID, pos)

I don't understand what you are trying to accomplish. The selection is
just a set of real (as opposed to pixel) coordinates. If you have a
selection point saying it has coordinates (0,0) it has these
coordinates. You can use this selection in connection with some data
field to do something. Only in this combination the coordinates mean
something in some data field. If you shift the data field origin, (0,0)
will still mean ‘wherever (0,0) is in this field now’.

Post by Mathias Müller
This puzzles me. Somehow my (x,y) offsets are not corrected after
having them postprocessed. I apply it right after gwy_data_field_2dfft
as you do in prof_psdf.

Which offsets? For data field offsets, try printing
gwy_data_field_get_xoffset(dfield)
and
gwy_data_field_get_xoffset(dfield) + gwy_data_field_get_xreal(dfield)
They should be approximately the same with opposite signs (it depends on
the pixel size parity).
For selections, they will contain the coordinates you stored to them.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
-2,565e+09 and 2,555e+09
They seem to be what you expect them to be.
in the image: left edge -> x = 5,58952e+06
right edge -> x = 5,11441e+09

OK, if you are already displaying the same field, you just need to call
gwy_data_field_data_changed() so that views take notice that it has
changed.

Regards,

Yeti

[Mathias Müller]

I tried so, but it still doesn't show up with an image center at (0,0). The same data shows a center at (0,0) in the fft module.

thats how I fetch real data and generate the fft data and display them:


[code]
gwy_app_data_browser_get_current(GWY_APP_DATA_FIELD, &data_field, 0);

data_field_fft_r = gwy_data_field_new_alike(data_field, FALSE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ;
gwy_data_field_data_changed(data_field_fft_r);

data[1] = gwy_container_new();
data_view[1] = GWY_DATA_VIEW(gwy_data_view_new(data[1]));
gwy_data_view_set_data_prefix(data_view[1], "/0/data");
gwy_container_set_boolean_by_name(data[1], "/0/data/realsquare", TRUE);
gwy_container_set_int32_by_name(data[1], "/0/base/range-type", GWY_LAYER_BASIC_RANGE_FIXED);
gdouble min, max ;
gwy_data_field_get_min_max (data_field_fft_r,&min,&max);
gwy_container_set_double_by_name(data[1], "/0/base/min", 0.1*max);
gwy_container_set_double_by_name(data[1], "/0/base/max", 0.2*max);


g_assert( widget = GTK_WIDGET(gtk_builder_get_object(builder, "viewport2")) );
gtk_container_add(GTK_CONTAINER(widget), GTK_WIDGET(data_view[1]));
[/code]

Post by David Nečas (Yeti)

Post by Mathias Müller
-2,565e+09 and 2,555e+09
They seem to be what you expect them to be.
in the image: left edge -> x = 5,58952e+06
right edge -> x = 5,11441e+09

OK, if you are already displaying the same field, you just need to call
gwy_data_field_data_changed() so that views take notice that it has
changed.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
I tried so, but it still doesn't show up with an image center at (0,0). The same data shows a center at (0,0) in the fft module.
[code]
gwy_app_data_browser_get_current(GWY_APP_DATA_FIELD, &data_field, 0);
data_field_fft_r = gwy_data_field_new_alike(data_field, FALSE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ;
gwy_data_field_data_changed(data_field_fft_r);
data[1] = gwy_container_new();
data_view[1] = GWY_DATA_VIEW(gwy_data_view_new(data[1]));
gwy_data_view_set_data_prefix(data_view[1], "/0/data");
gwy_container_set_boolean_by_name(data[1], "/0/data/realsquare", TRUE);
gwy_container_set_int32_by_name(data[1], "/0/base/range-type", GWY_LAYER_BASIC_RANGE_FIXED);
gdouble min, max ;
gwy_data_field_get_min_max (data_field_fft_r,&min,&max);
gwy_container_set_double_by_name(data[1], "/0/base/min", 0.1*max);
gwy_container_set_double_by_name(data[1], "/0/base/max", 0.2*max);
g_assert( widget = GTK_WIDGET(gtk_builder_get_object(builder, "viewport2")) );
gtk_container_add(GTK_CONTAINER(widget), GTK_WIDGET(data_view[1]));
[/code]

I attach compilable module that shows the 0,0 frequency origin in the
centre for me. I have no idea what you may be doing differently.

Regards,

Yeti

[Mathias Müller]

Thanks for the example.

Honestly, I am kind of distressed. I do exactly the same. The image is of cause centered, but when extracting coordinates of the image center or the edges
than it simple does not fit to what I get in the fft-module.

when reading the data point from selection, could there be some wrong usage?

after creating the fft image exactly as you did in the example code, I read the coordinates as follows:

void cb_selection_finished(GwySelection *selection, display_t *ctrls)
{
gdouble pos[2];
g_assert( gwy_selection_get_object(selection, ID, pos) );

printf("FFT corrd #%d.: [%g,%g]\n",ID,pos[0],pos[1]) ; // when clicking the image center it pos[0] and pos[1] != 0

}

void cb_selection_changed(GwySelection *selection, gint id, display_t *ctrls)
{
ID = id ;
}

ID is global

could it be that the GwySelection is not well-connected to the data field?


selection[1] = (GwySelection*) g_object_new(g_type_from_name("GwySelectionPoint"), NULL);
gwy_container_set_object_by_name(data[1], "/0/selection", selection[1]);
g_object_set(selection[1], "max-objects", 10, NULL);

vector_layer[1] = (GwyVectorLayer*) g_object_new(g_type_from_name("GwyLayerPoint"), NULL);
gwy_vector_layer_set_selection_key(vector_layer[1], "/0/selection");
gwy_data_view_set_top_layer(data_view[1], vector_layer[1]);

Thanks for helping me and thanks for spending that much time with my problem.


Best,

/M

Post by David Nečas (Yeti)

Post by Mathias Müller
I tried so, but it still doesn't show up with an image center at (0,0). The same data shows a center at (0,0) in the fft module.
[code]
gwy_app_data_browser_get_current(GWY_APP_DATA_FIELD, &data_field, 0);
data_field_fft_r = gwy_data_field_new_alike(data_field, FALSE);
gwy_data_field_2dfft(data_field,NULL,data_field_fft_r,data_field_fft_i,GWY_WINDOWING_NONE,GWY_TRANSFORM_DIRECTION_FORWARD,GWY_INTERPOLATION_ROUND,TRUE,1) ;
gwy_data_field_fft_postprocess(data_field_fft_r,TRUE) ;
gwy_data_field_data_changed(data_field_fft_r);
data[1] = gwy_container_new();
data_view[1] = GWY_DATA_VIEW(gwy_data_view_new(data[1]));
gwy_data_view_set_data_prefix(data_view[1], "/0/data");
gwy_container_set_boolean_by_name(data[1], "/0/data/realsquare", TRUE);
gwy_container_set_int32_by_name(data[1], "/0/base/range-type", GWY_LAYER_BASIC_RANGE_FIXED);
gdouble min, max ;
gwy_data_field_get_min_max (data_field_fft_r,&min,&max);
gwy_container_set_double_by_name(data[1], "/0/base/min", 0.1*max);
gwy_container_set_double_by_name(data[1], "/0/base/max", 0.2*max);
g_assert( widget = GTK_WIDGET(gtk_builder_get_object(builder, "viewport2")) );
gtk_container_add(GTK_CONTAINER(widget), GTK_WIDGET(data_view[1]));
[/code]

I attach compilable module that shows the 0,0 frequency origin in the
centre for me. I have no idea what you may be doing differently.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mathias Müller
Honestly, I am kind of distressed. I do exactly the same. The image is
of cause centered, but when extracting coordinates of the image center
or the edges than it simple does not fit to what I get in the
fft-module.
when reading the data point from selection, could there be some wrong usage?

I'm sorry, I didn't work with this part of Gwyddion code for some
time... Selections are *NOT* offset. They have origin in the top-left
corner, like pixel coordinates, just scaled to the physical scale. You
have to add the offsets yourself:

sel[0] += gwy_data_field_get_xoffset(data_field);
sel[1] += gwy_data_field_get_yoffset(data_field);

This is, again, for compatibility reasons because offsets were a kind of
afterthought.

Regards,

Yeti

[Mathias Müller]

!!! We got it !!!

That was exactly the root of all evil. The FFT was fine but the selection was spoofing the coordinates. I should have asked for that much earlier.
Adding the x and y offset to every coordinate readout finally leads to reasonable values.


Many many thanks for your patience, yeti. We can finally close this chapter...

Cheers,

/M

Post by David Nečas (Yeti)

Post by Mathias Müller
Honestly, I am kind of distressed. I do exactly the same. The image is
of cause centered, but when extracting coordinates of the image center
or the edges than it simple does not fit to what I get in the
fft-module.
when reading the data point from selection, could there be some wrong usage?

I'm sorry, I didn't work with this part of Gwyddion code for some
time... Selections are *NOT* offset. They have origin in the top-left
corner, like pixel coordinates, just scaled to the physical scale. You
sel[0] += gwy_data_field_get_xoffset(data_field);
sel[1] += gwy_data_field_get_yoffset(data_field);
This is, again, for compatibility reasons because offsets were a kind of
afterthought.
Regards,
Yeti
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users