gwyddion-users Mailing List for Gwyddion (Page 3)

On Fri, May 19, 2023 at 02:20:11PM +0200, luis vazquez wrote:
> I am working with the surface reconstruction tool of Gwyddion. From one
> image, I set a model tip (a cone with 70 degrees in slope and 8 nm of
> radius) and then I apply the reconstruction tool. What I do not understand
> is that the reconstructed image has a lower roughness than the measured one.
> In my case, this is more evident when I use 25 nm as the radius of the tip).
> In principle, the convolution of the real surface with the tip geometry
> should lead to a smoother or less rough image. Accordingly, the
> reconstructed one should be rougher than the measured one. Perhaps, I am not
> applying properly the tool.
> 
> I note that when I do the opposite, using the dilation tool, I do get an
> image with less roughness than the measured one as expected.

First, always be at least a bit distrustful about the reconstruction. It
needs to make up information which often just is not present in the
data.

Tip convolution decreases roughness (σ) only sometimes.

For a Gaussian-like rough surface the first effect of tip convolution is
in fact an increase of measured correlation length T, whereas the effect
on σ is second order. So you cannot really see any change until the tip
radius becomes large.

For a spiky surface (positive skewness γ₃) tip convolution *increases*
measured σ, usually not much but for quite a large range of tip radii.
Dilation, unreliable as it is, still kind of reverses the effect.

So, it depends.

Yeti

Hi,

I am working with the surface reconstruction tool of Gwyddion. From one 
image, I set a model tip (a cone with 70 degrees in slope and 8 nm of 
radius) and then I apply the reconstruction tool. What I do not 
understand is that the reconstructed image has a lower roughness than 
the measured one. In my case, this is more evident when I use 25 nm as 
the radius of the tip). In principle, the convolution of the real 
surface with the tip geometry should lead to a smoother or less rough 
image. Accordingly, the reconstructed one should be rougher than the 
measured one. Perhaps, I am not applying properly the tool.

I note that when I do the opposite, using the dilation tool, I do get an 
image with less roughness than the measured one as expected.

Thanks in advance,

Luis Vázquez

On Sun, May 14, 2023 at 10:28:52AM +0000, Natnael K Kahssay wrote:
> > Please try tomorrow's or later development snapshot of Gwyddion.
> Is there a location where I can download the patched software now?

Right now you can compile it from subversion.

Yeti

Thanks for the quick response David.

> I modified the OPD import module to deal with it better (r25324) and the file loads fine for me now
I was able to open the files by hex editing the files and setting the hex value after cycleNumber entry from 00 00 00 00 00 06 00 04 00 00 00 10 00 to 00 00 00 00 00 00 00 04 00 00 00 10 00.

> Please try tomorrow's or later development snapshot of Gwyddion.
Is there a location where I can download the patched software now?

Thanks,

_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

On Sat, May 13, 2023 at 08:18:03PM +0000, Natnael K Kahssay wrote:
>  I am having an issue opening opd files.  I am getting error: Parameter
> `CycleNumber' is missing or invalid. Is there a way to get around this error?

Thanks for the report and the example of problematic file.

It seems CycleNumber in the file has inconsistent type and size (16bit
vs. 32bit integer). But this does not have to completely prevent the
file from loading. I modified the OPD import module to deal with it
better (r25324) and the file loads fine for me now. Please try
tomorrow's or later development snapshot of Gwyddion.

Regards,

Yeti

Hello gwyddion users,
  I am having an issue opening opd files.  I am getting error: Parameter `CycleNumber' is missing or invalid. Is there a way to get around this error?
[cid:image001.png@01D985B6.16639F70]
I have tried using the following gwyddion versions on different operating systems,
 - 2.62 32 bit windows version
 - 2.60 linux version (wsl2)

I have uploaded a sample file to https://www.dropbox.com/scl/fo/ubnczgic8lckx1dlt2unz/h?dl=0&rlkey=e343hwyy52jz5odwizr626l2s.

Thanks,

Dear Matthias,

thank you so much for your quick answer. This works perfectly.

Best regards and a nice day,
Lukas Grossmann

On 25.04.23 13:31, Matthias Krinninger wrote:
> Hi Lukas,
>
> you can simply right-click in the image and choose "Metadata Browser" or press shift+control+b when the window of the image is focused.
> In the Metadata Browser you can search (case sensitive) by simply starting to type, for SM4 files e.g. "Bias".
> As long as you see the small pop-up window with your query, you can jump to the next/previous search result with arrow-up/arrow-down keys.
>
> Best,
> Matthias
>
>
> -----Original Message-----
> From: Lukas Grossmann <luk...@tu...>
> Sent: Dienstag, 25. April 2023 12:06
> To: gwy...@li...
> Subject: [Gwyddion-users] Reading tunneling voltage from sm4 file.
>
> Dear Gwyddion users,
>
> i am using a STM system with an RHK electronic (Model SPM 100). This produces SM4-files. For each image, one can look up the tunneling parameters and PID parameters in the RHK software, so these information have to be also in the file. However, i prefer using Gwyddion for data evaluation. Is there a way to display these parameters in Gwyddion? I appreciate any help i can get. Thank you. I necessary i can provide data files.
>
> With best regards,
> Lukas Grossmann
>
>
>
> _______________________________________________
> Gwyddion-users mailing list
> Gwy...@li...
> https://lists.sourceforge.net/lists/listinfo/gwyddion-users

Hi Lukas,

you can simply right-click in the image and choose "Metadata Browser" or press shift+control+b when the window of the image is focused.
In the Metadata Browser you can search (case sensitive) by simply starting to type, for SM4 files e.g. "Bias".
As long as you see the small pop-up window with your query, you can jump to the next/previous search result with arrow-up/arrow-down keys.

Best,
Matthias


-----Original Message-----
From: Lukas Grossmann <luk...@tu...> 
Sent: Dienstag, 25. April 2023 12:06
To: gwy...@li...
Subject: [Gwyddion-users] Reading tunneling voltage from sm4 file.

Dear Gwyddion users,

i am using a STM system with an RHK electronic (Model SPM 100). This produces SM4-files. For each image, one can look up the tunneling parameters and PID parameters in the RHK software, so these information have to be also in the file. However, i prefer using Gwyddion for data evaluation. Is there a way to display these parameters in Gwyddion? I appreciate any help i can get. Thank you. I necessary i can provide data files.

With best regards,
Lukas Grossmann



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

Dear Gwyddion users,

i am using a STM system with an RHK electronic (Model SPM 100). This 
produces SM4-files. For each image, one can look up the tunneling 
parameters and PID parameters in the RHK software, so these information 
have to be also in the file. However, i prefer using Gwyddion for data 
evaluation. Is there a way to display these parameters in Gwyddion? I 
appreciate any help i can get. Thank you. I necessary i can provide data 
files.

With best regards,
Lukas Grossmann

On Sun, Apr 02, 2023 at 06:43:48AM +0000, Sidney Cohen wrote:
> As we continue to enjoy this great software, we have recently made use of
> python scripts and noted that this is only supported in the 32 bit version. Is
> there any plan to make it possible for 64 bit Gwyddion?

Hello, our only current plans concernnig the Python 2 era stuff are
preventing it from falling apart completely before we are finally able
to move to Python 3. Which is coming – very slowly.

There should not be any fundamental obstacle preventing the 64bit MS
Windows version from working. But it would require a chunk of someone's
time and effort…

Regards,

Yeti

Hi
  As we continue to enjoy this great software, we have recently made use of python scripts and noted that this is only supported in the 32 bit version. Is there any plan to make it possible for 64 bit Gwyddion?

Thanks
Sidney Cohen
Weizmann Institute of Science
Rehovot ISRAEL 76100

Gwyddion 2.62 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.62/
  (all released files)

  http://gwyddion.net/download/2.62/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>", id 62A07732
  fingerprint = 263F 9B1E C1E0 5261 C689  D83B 00FD D1D0 62A0 7732

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Czech, French, Russian.

Libraries:
- libgwyddion: GwyResource functions helping with saving them to files.
- libgwyddion: UTF-8 friendly alternative to g_strescape() was added.
- libgwyprocess: Functions for windowing of GwyDataLine and GwyDataField.
- libgwyprocess: A Zoom FFT function was added for GwyDataField.
- libgwyprocess: Use after free in GwyPeaks was fixed.
- libgwyprocess: Crashing deserialisation of GwyLawn with unset array-like
  attributes was fixed.
- libgwyprocess: gwy_data_field_get_local_maxima_list() sometimes returning
  strange maxima lists was fixed.
- libgwydgets: Function for emitting "row-changed" for a range of GwyNullStore
  rows was added.
- libgwyapp: GwyParamDef parameter name and label can be queried.
- libgwyapp: File open dialogue no longer shows ‘???’ as the file type for
  ‘Automatically detected’ when first used.
- libgwyapp: GwyParamTable supports enablers for entries and can fill itself
  from a GwyParams object. Several setup functions for slider alternative
  values were added.
- libgwyapp: GwyPlainTool has a rudimentary GwyParamTable support.
- libgwyapp: GwyResultsExport can handle Copy and Save buttons using user
  provided formatting function.
- libgwyapp: GwyParams values can be assigned to another GwyParams object.
- libgwyapp: Fixed graph functions sometimes being runnable (and crashing)
  even if there was no active graph window.
- libgwyapp: Module utility functions for running subdialogs and expander
  handling.
- libgwyapp: Module utility functions for creation and handling of filtered
  inventory treeviews.
- libgwyapp: Possible crash when the gradient or GL material editor was active
  upon program exit was fixed.

Modules:
- Curve Map Find Position (new): Searches for the first or last occurence of
  a threshold value.
- Curve Map Lock-in (new): Detects oscillations in curves.
- 2D PSDF and Measure Lattice: Off-centre PSDF images (visible at larger zooms)
  were fixed.
- Measure Lattice: Single-vector mode was added for simple frequency space
  measurements.
- Tip blind estimate: Tip reset button works correctly again.
- Statistical functions: Windowing option was added for FFT-based functions.
- Pattern synthesis: Shape option for Pillars was restored.
- Keyence: Support for VK3 and VK7 files was added.
- Color range tool: Full range labels are updated when image data change.
- Three point level tool: Fixed ‘Apply’ button sometimes being clickable with
  no active data (and crashing).
- Roughness tool: Swedish height parameter was added.
- Raw file import: Parsing of some numbers with comma decimal separator was
  corrected.
- NanoObserver: Detection of v1.33 files, which was not correctly recognising
  some files, was improved.
- NRRD: Parsing of quoted sampleunits was corrected.
- Pixmap: HEIF support was added (if the corresponding gdk-pixbuf loader is
  found at run time).
- Volume summarize planes: The z-level can be selected numerically in both
  pixel and real units. Module preview can either show the selected level or
  the original preview.

Other:
- MS Windows: HDF5 was updated to version 1.10.8, fixing import of Ergo files
  which did not work with HDF 1.8.22.
- Compilation: Modules are always explicitly linked with libm to ensure the
  silent implied linking with libmvec occurs when needed.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

On Fri, Sep 30, 2022 at 11:11:45AM +0000, Andreu Mor Maldonado wrote:
> I am relatively new to Gwyddion, but I have tried to open a .dat file from a
> publication (https://www.nature.com/articles/s41467-020-17562-1#Sec10) and
> every time I do that, gwyddion gives an error:
>   "Opening of 'name_of_file' failed. No module can load this file type.
> I have tried to open it as raw data, but a black screen is shown in preview
> making me understand that the data is not being recognized.

If the file format was recognised, the file would be just loaded. When
you have to go through manual import it means you need to specify the
file format and properties manually.

The preview will be blank until you press Update to attempt to load the
file – and commonly also afterwards if the attempt fails. Or it will
show rubbish if you specify the format wrong.

I am not sure which files you mean because the link leads to section
‘Protein purification and mutagenesis’. But I found a link to some
related AFM files elsewhere in the paper. They seem to be 481×481 raw
text dump of values.

Dimensions and type are sufficient to physically read the file, i.e. for
the preview to show something reasonable. But not enough to get correct
data! The file does not contain any information about physical
dimensions, units of the values, etc. You have to find them, wherever
they are noted, and set them yourself in the raw file import dialogue.

Raw file import remembers the settings from the last time and you can
also name a set of parameters and save it as a preset if you expect to
use it frequently.

> My Gwyddion version is 2.60-2, I believe it is the last version since when I
> try to do apt-get install gwyddion, I get the message that it is the last
> version to install.

The latest version is 2.61, but it is probably not in the repo (yet),
and it should not matter anyway.

Yeti

Hi everyone,

I am relatively new to Gwyddion, but I have tried to open a .dat file from a publication (https://www.nature.com/articles/s41467-020-17562-1#Sec10) and every time I do that, gwyddion gives an error:
  "Opening of 'name_of_file' failed. No module can load this file type.
I have tried to open it as raw data, but a black screen is shown in preview making me understand that the data is not being recognized.

My Gwyddion version is 2.60-2, I believe it is the last version since when I try to do apt-get install gwyddion, I get the message that it is the last version to install.

Do you have any idea how I could open such files? If you need to see them, they can be found in the paper under code availability.

Thank you very much for your help,

Andreu

Hello David,

Thanks for your explanations which confirm what I have seen in the 
sources of pySPM.

My reference is the actual text output of gwyddion.

In fact I am coding a Scilab (www.scilab.org) script for a student of 
our lab who want to read a SPM file therein, and my first source of 
inspiration is the "Bruker.py" file of pySPM. I hate python (I hate also 
RE (regular exepressions) when the person who has coded does not explain 
what does the RE) , but I managed to understand what they do but pySPM 
does not yield the correct scale. Actually they use method 1 and (almost 
by accident, i.e. I multiplied all the numbers I could get) I concluded 
that method 2 leads to the actual gwyddion results.

Thanks for your insights !

Best,

S.


Le 13/09/2022 à 16:36, David Nečas (Yeti) a écrit :
> On Mon, Sep 12, 2022 at 05:34:48PM +0200, Stéphane Mottelet wrote:
>> I have great difficulties for understand how is computed the final factor by
>> which is multiplied the raw data (e.g. 32 bits signed integer) to obtain the
>> correct unit
> Welcome to the club. We've been having the same difficulties for almost
> 20 years now (nanoscope.c is pure madness). There seem to be two basic
> ways to get the conversion factor. I will refer to the parts of the
> header fields as follows (only HardValue is non-optional):
>
>      \@Key: V [SoftScale] (HardScale) HardValue
>
> 1) The method which I think corresponds to what Veeco user guide used to
>     say.
>
>     Look for key ‘2:Z scale’ or ‘4:Z scale’ in the corresponding data
>     section.
>
>     Read the hardvalue (not hardscale). This gives you factor 1.
>
>     Read also the softscale.  This gives you another key (like ‘Sens. ZsensSens’).
>     Look for that key and read the hardvalue. This gives you factor 2.
>
>     Look for key Bytes/pixel. Read the hardvalue as bpp, or use 2 if not
>     present.
>
>     Multiply factors 1 and 2. Divide by 256^bpp. Multiply all the raw
>     values by this.
>
> 2) The method which I do not think you can find in the guide but is
>     apparently the new and correct one.
>
>     Look for key ‘2:Z scale’ or ‘4:Z scale’ in the corresponding data
>     section.
>
>     Read the hardscale (not hardvalue). This gives you factor 1.
>
>     Read also the softscale.  This gives you another key (like ‘Sens. ZsensSens’).
>     Look for that key and read the hardvalue. This gives you factor 2.
>
>     Multiply factors 1 and 2. Multiply all the raw values by this.
>
> In either you need to keep track of powers of 10 in units, i.e. nm means
> 10⁻⁹ m.
>
> Often both methods give you the same correct result, which is nice.
>
> Sometimes one of them give you the right result, but for whatever reason
> not the other. Method 2 seems to work with force mapping, force curves,
> peakforce QNM and these types of things. Method 1 seems to well with
> more traditional modes like tapping.
>
> Sometimes neither of them gives you the right result. When, why and
> how this happens is anyone's guess.
>
> Then there are also very old files for which you need to know some
> semi-hardcoded conversion factors which depend on the data type (height,
> phase, …). Pray you do not encounter any of those.
>
> Hope it helps at least a bit. If someone could explain Icon raw data
> conversion to me in a way which makes sense *and* works for all files, I
> would be grateful…
>
> Regards,
>
> Yeti
>
>
>
> _______________________________________________
> Gwyddion-users mailing list
> Gwy...@li...
> https://lists.sourceforge.net/lists/listinfo/gwyddion-users

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

On Mon, Sep 12, 2022 at 05:34:48PM +0200, Stéphane Mottelet wrote:
> I have great difficulties for understand how is computed the final factor by
> which is multiplied the raw data (e.g. 32 bits signed integer) to obtain the
> correct unit

Welcome to the club. We've been having the same difficulties for almost
20 years now (nanoscope.c is pure madness). There seem to be two basic
ways to get the conversion factor. I will refer to the parts of the
header fields as follows (only HardValue is non-optional):

    \@Key: V [SoftScale] (HardScale) HardValue

1) The method which I think corresponds to what Veeco user guide used to
   say.

   Look for key ‘2:Z scale’ or ‘4:Z scale’ in the corresponding data
   section.

   Read the hardvalue (not hardscale). This gives you factor 1.

   Read also the softscale.  This gives you another key (like ‘Sens. ZsensSens’).
   Look for that key and read the hardvalue. This gives you factor 2.

   Look for key Bytes/pixel. Read the hardvalue as bpp, or use 2 if not
   present.

   Multiply factors 1 and 2. Divide by 256^bpp. Multiply all the raw
   values by this.

2) The method which I do not think you can find in the guide but is
   apparently the new and correct one.

   Look for key ‘2:Z scale’ or ‘4:Z scale’ in the corresponding data
   section.

   Read the hardscale (not hardvalue). This gives you factor 1.

   Read also the softscale.  This gives you another key (like ‘Sens. ZsensSens’).
   Look for that key and read the hardvalue. This gives you factor 2.

   Multiply factors 1 and 2. Multiply all the raw values by this.

In either you need to keep track of powers of 10 in units, i.e. nm means
10⁻⁹ m.

Often both methods give you the same correct result, which is nice.

Sometimes one of them give you the right result, but for whatever reason
not the other. Method 2 seems to work with force mapping, force curves,
peakforce QNM and these types of things. Method 1 seems to well with
more traditional modes like tapping.

Sometimes neither of them gives you the right result. When, why and
how this happens is anyone's guess.

Then there are also very old files for which you need to know some
semi-hardcoded conversion factors which depend on the data type (height,
phase, …). Pray you do not encounter any of those.

Hope it helps at least a bit. If someone could explain Icon raw data
conversion to me in a way which makes sense *and* works for all files, I
would be grateful…

Regards,

Yeti

Hello,
I have great difficulties for understand how is computed the final 
factor by which is multiplied the raw data (e.g. 32 bits signed integer) 
to obtain the correct unit (meter in the below example) For example in 
my actual spm file I have

|\*Ciao image list \Data offset: 80960 \Data length: 1048576 
\Bytes/pixel: 4 \Start context: OL \Data type: AFM \Data Type 
Description: \Note: \Plane fit: 0 0 0 5 \Frame direction: Down \Capture 
start line: 0 \Color Table Index: 12 \Relative frame time: 5091.9 
\Invalid Data Flag: None \Invalid Data Fill: None \Samps/line: 512 
\Number of lines: 512 \Aspect Ratio: 1:1 \Scan Size: 10 10 ~m \Scan 
Line: Main \Line Direction: Retrace \Highpass: 0 \Lowpass: 0 \Realtime 
Planefit: Line \Offline Planefit: None \Valid data start X: 0 \Valid 
data start Y: 0 \Valid data len X: 512 \Valid data len Y: 512 \Tip x 
width correction factor: 1 \Tip y width correction factor: 1 \Tip x 
width correction factor sigma: 1 \Tip y width correction factor sigma: 1 
\@2:Image Data: S [ZSensor] "Height Sensor" \@Z magnify: C [2:Z scale] 
4.14356 \@2:Z scale: V [Sens. ZsensSens] (0.0000000000370204 V/LSB) 
0.159002 V \@2:Z offset: V [Sens. ZsensSens] (0.0000000000370204 V/LSB) 
0.000000 V |

I don't manage to recover the actual factor from numbers in the lines

|\@Z magnify: C [2:Z scale] 4.14356 \@2:Z scale: V [Sens. ZsensSens] 
(0.0000000000370204 V/LSB) 0.159002 V \@2:Z offset: V [Sens. ZsensSens] 
(0.0000000000370204 V/LSB) 0.000000 V |

Thanks for help.

S.

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

OK, got it thanks for quick reply!

------------------
Viorel


On Thu, May 5, 2022 at 4:43 PM David Nečas (Yeti) <ye...@gw...> wrote:

> On Thu, May 05, 2022 at 03:55:06PM +0200, Viorel Balan wrote:
> > CUrrently i am working  on windows station w/ 32 bits version of
> gwyddion. The
> > python 2.7 script  crash on some large images because of memory issue.
> > Now, switching on Linux, would it allow to work with Python3  with 64
> bits
> > version? Or, i will be still forced to use 32 bits version ?
>
> There is currently no Python 3 pygwy.  It is still some years away…  The
> 64bit architecture is not a problem in Linux – it is just a MS Windows
> build and packaging issue.  However, in any OS you need Python 2.7.
>
> Gwyddion generally prefers simplicity and efficiency to resource
> conservation so it can be sometimes memory hungry.  But if you suspect a
> memory leak please report it as a bug.
>
> Regards,
>
> Yeti
>
>
>
> _______________________________________________
> Gwyddion-users mailing list
> Gwy...@li...
> https://lists.sourceforge.net/lists/listinfo/gwyddion-users
>

On Thu, May 05, 2022 at 03:55:06PM +0200, Viorel Balan wrote:
> CUrrently i am working  on windows station w/ 32 bits version of gwyddion. The
> python 2.7 script  crash on some large images because of memory issue.
> Now, switching on Linux, would it allow to work with Python3  with 64 bits
> version? Or, i will be still forced to use 32 bits version ?

There is currently no Python 3 pygwy.  It is still some years away…  The
64bit architecture is not a problem in Linux – it is just a MS Windows
build and packaging issue.  However, in any OS you need Python 2.7.

Gwyddion generally prefers simplicity and efficiency to resource
conservation so it can be sometimes memory hungry.  But if you suspect a
memory leak please report it as a bug.

Regards,

Yeti

Dear all,

I have to batch treat large topographical images.
CUrrently i am working  on windows station w/ 32 bits version of gwyddion.
The python 2.7 script  crash on some large images because of memory issue.
Now, switching on Linux, would it allow to work with Python3  with 64 bits
version? Or, i will be still forced to use 32 bits version ?
Thank you. Best regards

------------------
Viorel

On Mon, May 02, 2022 at 11:17:27AM +0200, David Nečas (Yeti) wrote:
> Gwyddion 2.61 is now available for download…

…and the actual list of changes in 2.61 follows. Sorry about posting the
2.60 news instead.

Application:
- Translations updated: Czech, French, Russian.
- Command line: New option --convert-to-gwy merges and converts SPM files to
  the Gwyddion file format.
- Command line: Non-GUI operations --identify, --check and --convert-to-gwy
  avoid more carefully GUI initialisation code, fixing some warnings.

Libraries:
- libgwyddion: gwy_check_regular_2d_grid() gives better offsets and steps.
- libgwyddion: GwySIUnit parser handles better Unicode powers like 10³ or m².
- libgwyddion: New gwy_math_curvature_at_origin() curvature function.
- libgwyprocess: GwyLawn deserialisation segment data size check was fixed.
- libgwyprocess: Elliptic area extraction and unextraction, broken in 2.59,
  work correctly again.  This fixes intersection with an elliptic area in Mask
  Editor tool.
- libgwyprocess: Rectangular pyramid shape fitting preset was added.
- libgwyprocess: Shape fitting preset parameters can have descriptions.
- libgwyprocess: gwy_data_field_row_gaussian() no longer limits kernel size
  using the vertical resolution.
- libgwyprocess: Function for changing the number of GwySurface points without
  immediately filling it with new data.
- libgwyprocess: A Zoom FFT function was added for GwyDataLine.
- libgwyprocess: New function for a linear combination of two GwyDataLines.
- libgwyprocess: GwyPeaks should no longer produce NaN peak widths for odd
  peak shapes.
- libgwydgets: Gwy3DView draws correctly the false colour axis for inverted
  gradients and follows better mapping changes made in the false colour tool.
- libgwydgets: gwy_color_axis_set_unit() invokes a redraw even if the same
  object is set again.
- libgwydgets, libgwyapp: GtkTooltips functions were deprecated (use the simple
  GtkWidget functions instead).
- libgwyapp: Incorrect warning about the default value in
  gwy_param_def_add_string() was fixed.
- libgwyapp: Crash in GwyParamTable radio button row construction was fixed.
- libgwyapp: gwy_param_table_reset() no longer tries to reset foreign controls.
- libgwyapp: New predefined parameter type for a set of grain value groups.
- libgwyapp: A helper function for adding a vector layer to a preview.

Modules:
- Nova ASCII (new): Imports NT-MDT Nova exported ASCII data.
- Indentor analyze: Completely rewritten, with useless quantities removed,
  useful added and region marking improved.
- Dimensions and Units: Bug sometimes causing it to forget the dimensions mode
  was fixed.  For Set range and Correct by factor the unit is remembered in
  settings.
- Graph Flip, Graph FZ to FD: Output data order which was causing problems in
  subsequent processing was fixed.
- Corning: Import of Corning Tropel UltraSort TTF files works now too.
- Nanonics: Raw data conversion factors were improved; some data may still be
  imported wrong.
- Nanoscope: Single force curve rebasing was made more robust.
- Curve Map Nanomechanical Fit, Fit FD Curve: Miscellaneous model improvements.
- GwyTIFF: Byte counts and offsets are read correctly when of type short.
- WRUST: Support for Liczba Kolumn parameter was added. Extra empty lines in
  header are ignored.
- 3D formats: Fixed import of STL files which was reading only some points and
  some multiple times.
- Anfatec: Also imports FV matrix data (as curve maps).  Metadata are created
  from the header file.
- Pixmap, HDR image: Option to simply use the pixel dimensions as the lateral
  dimensions was added.
- Wrap value: Option to keep the current data range unchanged was added.
- Grain correlations: Quantities available for abscissa are updated correctly
  when it is calculated from a different image.
- Measure lattice: Masking support was added.  Vector numbers can be displayed.
  The FFT image is refined.
- Tip model: Can enforce square tip image.
- Fit Shape: Pressing OK again consistently produces output images, whether
  they originate from fitting or just setting parameters manually.  Most
  parameters have toolips with descriptions.
- Perspective correction: Correction can be applied to all compatible images
  and it can modify the current image (instead of creating a new one).
- Projective selection: Supports crop and move and can be distributed by the
  selection manager tool.

Yeti

Gwyddion 2.61 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.61/
  (all released files)

  http://gwyddion.net/download/2.61/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>", id 62A07732
  fingerprint = 263F 9B1E C1E0 5261 C689  D83B 00FD D1D0 62A0 7732

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Brazilian Portugese, Czech, French, Russian.
- Toolbox editor: Possible crash when adding a new group was fixed.

Libraries:
- libgwyddion: New functions available in GwyExpr: step, spow (signed pow),
  exp2, log2, sinc.  If the system math library provides them, the following
  are also available: erf, erfc, lGamma, Gamma, J0, J1, Y0, Y1.
- libgwyddion: gwy_sinc function was added for the cardinal sine function.
- libgwyddion: New GwyResource methods for resource deleting and renaming,
  including corresponding on-disk operations.
- libgwyddion: Function for decomposing GwySIUnit to base units was added.
  More degree variants and a few other odd units are recognised.
- libgwyddion: One-dimensional minimum search function was added.
- libgwyprocess: Functions for magnetic force microscopy data modelling and
  handling were added.
- libgwyprocess: New tip model, ball at the end of cylinder, was added.
- libgwyprocess: New GwyBrick functions: copy, transposition, compatibility
  checking, setting a plane.
- libgwyprocess: Speed of various GwyBrick summary operations such as
  gwy_brick_mean_plane() was considerably improved.
- libgwyprocess: Function for bounding boxes of periodic grains was added.
- libgwyprocess: RMS grain quantity was added.
- libgwyprocess: Simple regularised deconvolution function was added.
- libgwyprocess: New k-th rank filter with arbitrarily shaped kernel function.
- libgwyprocess: New function for calculation of 2D PSDF from masked data.
- libgwydgets: Helper functions for managing a group of check boxes which
  correspond to a set of bit flags (gwycheckboxes) were added.
- libgwydgets: GwyGraphModel has new functions for deriving units from a
  GwyDataField and replacing a curve model at given index.
- libgwyapp: Helper functions for managing module data in the user directory.
- libgwyapp: Failed assertion message when restoring file open dialogue file
  name filter from settings was corrected.
- libgwyapp: Critical warning when deleting XYZ data channel was fixed.

Modules:
- Ambios profile (new): Imports 1D profilometry data (both XML and DAT).
- Volume ASCII export (new): Export of volume data to various text formats.
- Volume Arithmetic (new): Arithmetic operations with volume data.
- Volume summarize planes (new): Plots graphs of dependencies of volume data
  plane statistics over z.
- Volume stray field (new): Checks consistency of volume MFM data.
- Volume and image MFM recalculation (new): Converts MFM data to force
  gradient.
- Volume transfer function (new): Plane-by-plane estimation of point spread
  functions in volume data planes corresponding to different levels.
- Area function (new): Calculates the tip area function.
- Hertz (new): Calculates the apparent Young's modulus of a rough surface
  according to Hertzian contact theory.
- Phoenix (new): Imports AFM data files from NASA Phoenix Mars mission.
- Disc synthesis (new): Generates surface randomly covered by discs or tiles.
- XYZ Channels (new): Create XYZ data from three images (values and precise
  X and Y coordinates).
- DM3: Raw data are no longer scaled by inverse maximum representable value.
- Coerce: Skew-normal distribution was added.
- Volume Show and Extract: Cleanup; functions superseded by Cut'n'Slice were
  removed, visualisation and stability improved.
- MFM modules: Cleanup; a few wrong numerical factors were corrected.
- Volume Z calibration: Calibration can be also taken from another volume data.
- Volume Swap Axes: Preview image units correspond to the transformed data.
- NMM file: Sometimes incorrect import when a only subset of channels is
  selected was fixed.
- NRRD file: Import from text-encoded files was corrected.  Endian is no longer
  required for text data.
- PNI file: Support for v2.0 files was added, at least for a subset of data
  types.
- Volume slice: Mislabelled axes on output graphs were corrected.
- Transfer function (PSF) guess and fit: The set of output images can be
  controlled
- Transfer function fit: Frequency-space exponential model was added.
- Transfer function guess: The sigma estimation algorithm was improved.
- Nanoscope: Force volume file reading was standardised to follow format
  specification.
- WSxM: File headers with ‘UAM’ copyright are recognised.
- Nanonis DAT spectra: All files matching the same fooNNN.dat pattern are
  merged, not just with names starting from 1.  When files do not seem
  numbered at all, the single selected file is loaded instead of failing.
- Basic operations: Function for flipping around the diagonal was added.
- Pattern synthesis: Holes are placed with respect to image centre instead
  of some defined but unhelpful origin of coordinates.  This means generated
  images also changed and match previous versions only statistically.
- Graph logscale: Logarithm base mishandling was fixed.  Base-2 logarithm and
  negative abscissa handling options were added.
- Statistics Quantities: Volume was added as a new quantity.
- FFT profile: Renamed to 2D PSDF.  It can now both extract profiles and create
  the entire 2D PSDF image.
- Image export: Font selection having sometimes no effect on the exported
  image was, hopefully, fixed.  It no longer crashes when there is no image
  to export.
- Filters tool: The median filter now uses circular kernel.
- 2D ACF: Creation of the output image is optional.  The image can be limited
  to the zoomed part.
- Volume summarize profiles: The value for the currently selected profile is
  displayed in the dialogue.
- Dimensions and Units: Crash when reinvoked after selecting Match pixel size
  was fixed.
- Pygwy: Function gwy_app_data_browser_get_containers() no longer leaks
  references to all the returned Containers.  GraphModel supports the sequence
  protocol.

Other:
- Compilation: pygobject2 codegen is no longer required to build pygwy; an
  embedded implementation is used when it is not available.
- Compilation: autogen.sh no longer gets stuck without gettextize; it prints
  an error message.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

Gwyddion 2.60 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.60/
  (all released files)

  http://gwyddion.net/download/2.60/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>", id 62A07732
  fingerprint = 263F 9B1E C1E0 5261 C689  D83B 00FD D1D0 62A0 7732

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:

Application:
- Translations updated: Czech, Russian.
- Menus: Graph function menu was reorganised to hierarchical.
- Command line: Program exit status is now correctly 0/1 when --check finds no
  problems/some problems, instead of the opposite.
- Command line: New option --identify identifies and prints the detected type
  of SPM files.

Libraries:
- libgwyddion: gwy_container_transfer() handles empty prefixes correctly
  (instead of crashing).
- libgwyddion: SI unit decomposition producing wrong decomposed units was
  corrected; it also corrects comparisons with decomposable units like N.
- libgwyddion: GwySIUnit parses correctly units with numbers in denominators
  like ‘nm/100V’.
- libgwyddion: Helper function for UTF-16 to UTF-8 conversions.
- libgwyprocess: New GwyLawn data object representing regular map of irregular
  curve tuples.
- libgwyprocess: Holes fit shape derived quantity R calculation was corrected.
- libgwyprocess: Cross-correlation iteration ranges were corrected for
  odd-sized windows, in particular 1 pixel wide or high.  It was also sped up.
- libgwyprocess: Snednon conical, DMT spherical and Hertz spherical with film
  models were added to FD curve fitting presets.
- libgwydgets: Convenience combo constructor for GwyLawn curve selection.
- libgwydgets: Fixed odd behaviour and possible crashes in graph window measure
  dialog when curves are deleted from the graph.
- libgwymodule: New functions for handling curve map modules and functions.
- libgwyapp: Missing data item sync function for XYZ data was added.
- libgwyapp: Support for GwyLawn curve map data was added to data browser,
  menus, toolbox, file previews, and other data management.
- libgwyapp: Fix of various GwyDialog and GwyParamTable labels showing always
  in English despite being translated.
- libgwyapp: Graph and lawn curve number parameters were added to GwyParams.
- libgwyapp: GwyParamTable supports plain text entries for numbers and strings.
- libgwyapp: Possible division by zero in gwy_synth_sanitise_params() was
  fixed.
- libgwyapp: New menu sensitivity flag indicating that a graph is non-empty.

Modules:
- Curve Map Basic operations (new): Basic operations with curve map data.
- Curve Map Crop (new): Cropping of curve map data.
- Curve Map Extract Curves (new): Extract curves from curve map data.
- Curve Map Summarise Curves (new): Statistics on curves in curve map data.
- Curve Map Cut to Segments (new): Cuts curves in curve map data to approach/
  contact/rectract segments.
- Curve Map Align (new): Aligns curves in curve map data to match key points
  (maximum, minimum or zero crossing).
- Curve Map Sine Background (new): Sine background removal from curve maps.
- Curve Map Polynomial Background (new): Polynomial background removal from
  curve maps.
- Curve Map FZ to FD (new): Force-Z to Force-distance curve recalculation for
  curve maps.
- Curve Map Nanomechanical Fit (new): Simple evaluation of Force-distance
  curves for curve maps.
- Curve Map Fit FD Curve (new): Force-distance curve fitting for curve maps.
  curve maps.
- Graph Sine Background (new): Sine background removal from curves.
- Graph Flip (new): Graph curve flipping.
- Graph Invert (new): Graph curve inversion.
- Graph FZ to FD (new): Force-Z to Force-distance curve recalculation.
- Quazar NPIC (new): Import Quarzar STM NPIC data files (experimental).
- WRUST (new): Imports AFM data files from Department of Nanometrology, WRUST.
- Wetting (new): Simple wetting front synthetic data generator.
- Dimensions and Units: Reworked to make clear the intent of the changes and
  reapply them without confusion.  Also now provides a similar curve map
  function.
- Fix zero, Zero maximum value: Masking support was added.
- Keyence: Support for VK6 files was added (by reading the embedded VK4 file).
- DM3: Detection was made a bit less strict, helping with some files being
  misdetected as AIST.
- PS-PPT: Rewritten to import data as curve maps.
- Nanoscope: Volume data import was rewritten to import them as curve maps.
  Support for Deep Trench unevenly sampled profile data was added.
- Igor: Units of ‘NapSomething’ images should be correct now.
- Rawfile: Reading files to the very end works even with non-zero skips.
- Omicron MATRIX: Incorrect subgrid calculation, affecting some volume data,
  was fixed.
- Image export: Incorrect coordinates or even crash when drawing a cross
  selection was fixed.
- Particle synthesis: Simulation speed was greatly improved.  A random number
  generation bug was fixed; the same random seed will not generate identical
  image as in previous versions.
- Straighten path: Output orientation can now be chosen.
- Graph modules: No longer executable for empty graphs with no curves,
  meaning they also do not crash in such case.
- Graph statistical functions: Windowing used for PSDF computation is now
  user-controllable.
- Graph export bitmap: Saves also to JPEG/TIFF/BMP according to image file
  extension.  An error is shown if file saving fails.

Other:
- Compilation: Minizip header inclusion should work also with version 3.x.
- Compilation: Failure to compile with OpenEXR 3.x was fixed.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

There is horizontal shift between each forward and backward line due to the stick-slip effect at each turning point of a scan. In an ideal case this would mean that the forward image and backward image everywhere the dame shift. This could be only if at the turning points the material, i.e. the adhesion due to stick-slip, is constant. If this is not the case the thing is hopeless. One chance would be to reduce or eliminate the stick at the turning points what is possible if a horizontal high frequency vibration is superimposed to the x-drive. All that for polymers (which have a high adhesion). We published this method, feel free to ask for a copy.
Regards
Heinz

-----Ursprüngliche Nachricht-----
Von: David Nečas (Yeti) <ye...@gw...> 
Gesendet: Sonntag, 24. Oktober 2021 09:36
An: Gwyddion use discussion <gwy...@li...>
Betreff: Re: [Gwyddion-users] request about friction

On Sat, Oct 23, 2021 at 07:38:31AM -0400, Philippe Bilas wrote:
> I want to calculate the friction from the left and right side images. 
> When we do the difference we need to shift a few pixels to align the images.

I know little about friction evaluation, so I will just comment on finding shifts between images.  The general tool is Multidata → Cross-Correlation.  In this case you probably want both the window and the search region wide but vertically narrow.  The case of height = 1 px does not seem to be handled correctly, so currently you need to make the search region at least 2 pixels high.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

On Sat, Oct 23, 2021 at 07:38:31AM -0400, Philippe Bilas wrote:
> I want to calculate the friction from the left and right side images. When
> we do the difference we need to shift a few pixels to align the images.

I know little about friction evaluation, so I will just comment on
finding shifts between images.  The general tool is Multidata →
Cross-Correlation.  In this case you probably want both the window and
the search region wide but vertically narrow.  The case of height = 1 px
does not seem to be handled correctly, so currently you need to make the
search region at least 2 pixels high.

Regards,

Yeti