gwyddion-users Mailing List for Gwyddion

Gwyddion 2.70 is now available for download at

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

  https://gwyddion.net/download/2.70/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

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

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

More information about Gwyddion is available at

  https://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.
- Image stack import: Better handling of multiple channels with same name.

Libraries:
- libgwprocess: A bug in GwyLawn serialisation with some curve units set and
  some unset was fixed.
- libgwyprocess: Added brick thresholding and brick XY plane multiplication.
- libgwyapp: Critical message when trying to drag a selection from Selection
  Manager to a non-image window was fixed.
- libgwyapp: Metadata editing, broken by filtering added in 2.68, works again.
- libgwyapp: Right-click menu item ‘Zoom 1:1’ works again for image data.

Modules:
- Qnami (new): Qnami ProteusQ text DAT file import (somewhat experimental).
- Reorder (new): Simple image data reordering: meander or (de)interlace.
- XYZ Volumize (new): Splitting XYZ data stream from HS-AFM and rasterize it
  creating Volume data.
- XYZ Step detect (new): Removing steps from XYZ data treated as time series.
- LAFM density map (new): Export of LAFM density map data in .afm format.
- Count Peaks (new): Count peaks in curve map.
- HDF5: NaNs are masked in generic HDF5 import, fixing a possible crash.
  Incorrect reading of fixed-sized string attributes was fixed.
- HDF5: Support for Ergo 9 files (ARVersion 2) was added.
- HDF5: Reading of curve maps from NHF v15+ files was corrected.
- HDF5: Support for GXSM4 HDF5-based netCDF-4 files was added.
- HDF5: Support for FusionScope .fsexp files was added.
- JPK scan: Broken segmentation of imported force curve maps was corrected.
- Talos: Incorrect real dimensions of some imported images were fixed.
- Raw file import: New text data import style was added, one value from each
  file line. Broken creation of a mask over bad/missing value was corrected.
- Localization Merge: Can create probability density volume.
- Volume clustering: Simple supervised learning methods were added.

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

Thanks all who contributed,

Yeti

Gwyddion 2.69 is now available for download at

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

  https://gwyddion.net/download/2.69/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

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

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

More information about Gwyddion is available at

  https://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.
- File menu: Image stack import was added.

Libraries:
- libgwyapp: Workaround for data browser drag'n'drop dropping wrong data in KDE
  Plasma in Wayland was improved to catch non-image data types.
- libgwyapp: Default curve map and volume data previews attemp to filter out
  outliers and a filtering option was also added to the explicit preview
  creation.
- libgwyapp: Curve length was added as a possible curve map preview.
- libgwyapp: New high-level function for loading an image stack.

Modules:
- Talos (new): Imports ThemoFisher Talos TEM images.
- RMI TMD (new): Imports RMI TrueMap Data v2.0 files.
- Curve map ASCII export (new): Simple export of curve maps to text with one
  curve per line.
- Curve map ASCII import (new): Read back the curve map text export format.
- Curve Map Cut to Segments: Invert option was added for Approach-Retract
  splitting using curves where the split point is at the maximum, not minimum.
- Igor: Mismatched channel titles in exported IBW files were corrected.
- HDF5: Invalid/missing values in DATX are handled correctly now (by masking
  and interpolating).
- Nanoscope: Files with explicit Slow Axis Size do not have the vertical size
  corrected twice any more, which resulted in wrong physical dimensions.
- DME file: Possible crash in MS Windows upon file import was fixed.
- JPK scan: Force curve map import attempts to avoid placeholder pause
  segments, which previously caused a non-uniform channels error.
- MFM Current Line and Parallel Field: Memory handling bugs were fixed.

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

Thanks all who contributes,

Yeti

Yes, Gwyddion supports silent/unattended installation on Windows using command-line parameters with its installer. Here's how you can do it:   Silent Installation 


Steps: 1. Download the Gwyddion installer (e.g., `gwyddion-2.x.x-win64.exe`). 


2. Run the installer silently using the `/S` flag (for NSIS-based installers):    ```cmd     gwyddion-2.x.x-win64.exe /S     ```    This will install Gwyddion with default settings without user interaction.   Additional Options: - Specify Installation Directory (optional):   ```cmd    gwyddion-2.x.x-win64.exe /S /D=C:\Path\To\Install    ``` 
 Replace `C:\Path\To\Install` with your desired directory. 


 Verification: After installation, check if Gwyddion was installed correctly by: - Looking in the specified directory (or default `C:\Program Files\Gwyddion`). - Running `gwyddion` from the command line to verify execution. 


 Notes: - The Gwyddion installer is built with NSIS (Nullsoft Scriptable Install System), which supports `/S` for silent installation. - If you need further customization (e.g., disabling shortcuts), you may need to modify the installer script or check for additional flags. 


 Let me know if you need help with more advanced silent installation options!


         原始邮件
         
       
发件人：Oliver Brandel // Leibniz-IPHT via Gwyddion-users <gwy...@li...&gt;
发件时间：2025年4月9日 16:59
收件人：gwy...@li... <gwy...@li...&gt;
抄送：Oliver Brandel // Leibniz-IPHT <oli...@le...&gt;
主题：[Gwyddion-users] Silent installation



 Hi,

 
 I was wondering if there is a possibility for a silent/unattended installation of Gwyddion on Windows?

 
 Best regards
 Oliver

Hi,

I was wondering if there is a possibility for a silent/unattended installation of Gwyddion on Windows?

Best regards
Oliver

Gwyddion 2.68 was released, sort of. We seem to be affected by a
SourceForge bug. So we hope Gwyddion 2.68 will soon be also available
for download at

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

but at present only the following works

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

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

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

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.

Libraries:
- libgwyprocess: Functions for angularly averaged 2D PSDF were added.
- libgwyprocess: Fixed brick transposition not updating the real dimensions
  correctly.
- libgwyapp: Row levelling in file open preview was changed to median, avoiding
  the global tilt sometimes added by median difference.
- libgwyapp: GwyParamTable reset is actually handled for range-from and range-to
  type controls.
- libgwyapp: Items in metadata browser can be filtered by name.

Modules:
- Volume clustering (new): Volume data clustering, replacing volume k-means
  and k-medians and adding new methods, such as DBSCAN.
- Zyvex (new): Imports ZyVector Scanz data files.
- Accurion ellipsometry (new): Imports ASCII data maps exported from Accurion
  ellipsometers.
- K-means, K-medians: Removed (replaced with Volume clustering).
- HDF5 and a dozen other file modules: Import is now corectly recorded in the
  log.
- 2D ACF, 2D PSDF: Wrong sensitivity of target graph selector was fixed.
- 2D PSDF: The output curves are just sections of the 2D PSDF and have the same
  units as 2D PSDF.
- Statistical functions: Angularly averaged PSDF was added.
- Wave synthesis: Incorrect phase and amplitude outputs for cosh waves were
  corrected. Complementary displacement wave output was added. Underflow is
  handled better, allowing farther sources with decay.
- Coerce: Skew parameter of skew-normal distribution can be negative.
- Curve Map Find Position: Fixed possible crash when working with individual
  curve segments.
- Frequency split: Spectral density plot not displaying with wide and flat
  images was corrected.

Others:
- Compilation: Python detection on python3-only systems was fixed, making
  build scripts actually work there.

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

Thanks all who contributed,

Yeti

Thank you sincerely for your help—it means a lot.
 
Best regards

On Sat, Mar 22, 2025 at 07:35:31AM +0800, 自由如风 via Gwyddion-users wrote:
> I'm really sorry that my previous description of the problem wasn't accurate
> enough. It's not that wrong data was exported, but rather that the
> corresponding data couldn't be exported. The corresponding image can be opened,
> but the corresponding operations to export the data cannot be carried out. I
> speculate that these data might be in the same file, so only the height data
> can be exported. As for the subsequent data, there are situations where it
> cannot be selected, processed, or exported.

So you probably acquired some force volme data and opened it in
Gwyddion. (Still just guessing based on your mention of ‘.pfc’ file
extension in the previous e-mail.)

That would mean you have a curve map, not an image. You can tell because
the data are listed under Curve Maps in the data browser (and the window
looks different – there is curve map information in the upper part).
Functions for curve maps are in the Curve Maps menu.

There is currently no export function for curve maps in Gwyddion (it has
been requested a couple of times). Mainly because they have non-trivial
structure – multiple curves with lenghts varying bewteen pixels – and
there just isn't any common format to export to. If the data are regular
you can use Volumise Curves and export the resulting volume data which
have simpler structure.

I still do not think you can do anything meaningful with half a gigabyte
(typically) of such data in MS Excel though.

Regards,

Yeti

I'm really sorry that my previous description of the problem wasn't accurate enough. It's not that wrong data was exported, but rather that the corresponding data couldn't be exported. The corresponding image can be opened, but the corresponding operations to export the data cannot be carried out. I speculate that these data might be in the same file, so only the height data can be exported. As for the subsequent data, there are situations where it cannot be selected, processed, or exported.


Regards,


Yan

On Sat, Mar 22, 2025 at 01:50:56AM +0800, 自由如风 via Gwyddion-users wrote:
> I have obtained .spm and .pfc files from an atomic force microscope,

An atomic force microscope a bit vague, considering that Gwyddion
supports 150+ SPM file formats. Pleas see

https://sourceforge.net/p/gwyddion/discussion/fileformats/thread/ee82b3156c/

The extension .pfc suggests Bruker Dimension Icon & Nanoscope. So that's
what I assume below.

> which contain valuable data on modulus, adhesion force, and dissipated
> energy. However, I am facing difficulties exporting these specific datasets
> (modulus, adhesion force, dissipated energy) to Excel. Notably, I can
> successfully export height data, but the mechanical properties
> mentioned above do not appear to export correctly.

Exporting one channel correctly and another wrong should be pretty much
impossible.

What is, unfortunately, quite possible is that some data are *imported*
wrong to Gwyddion. Meaning the values you see in Gwdddion do match the
instrument software. The Nanoscope file format is complicated and has
evolved over time. We read many files correctly, but not all.

So, do the data really become wrong only after the export?

Or are they already wrong in Gwyddion?

There is no export to Excel. So I assume you exported the data to plain
text files. But really, I have no idea.

Regards,

Yeti

Dear Technical Support Team,


I hope this message finds you well. I am a university student, and I am writing to seek assistance with an issue I encountered while using your


 software.   I have obtained .spm and .pfc files from an atomic force microscope, which contain valuable data on modulus, adhesion force, and dissipated


 energy. However, I am facing difficulties exporting these specific datasets (modulus, adhesion force, dissipated energy) to Excel. Notably, I can successfully


 export height data, but the mechanical properties mentioned above do not appear to export correctly.   I have carefully reviewed the software’s export


 options and followed the standard procedures, yet I have not been able to resolve this issue. Could you kindly advise if there are specific steps or settings I


 need to adjust? Alternatively, might there be an additional plugin or software update required to enable the export of these data formats?   To aid in


 troubleshooting, I am happy to provide further details, including: 


 - Software version: [Gywdiion 2.67]


 - Operating system: [Windows]
 
- Sample files: [Indicate willingness to share, if applicable] 


 I would greatly appreciate your guidance in resolving this matter. Thank you for your time and support, and I look forward to your prompt response. 


 Best regards

Thank you so much for taking the time to help me with this!

From: David Nečas (Yeti) <ye...@gw...>
Date: Thursday, November 14, 2024 at 9:36 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Some Pygwy-extracted grain values (mean, surface area, ...) do not match interactive mode results
On Mon, Nov 11, 2024 at 06:37:41PM +0000, Smith, Justin wrote:
> I wrote a simple standalone Pygwy script which applies align_rows, fix_zero,
> and grain_wshed in the same order and with the same settings (per the log
> window) as in interactive mode. However, some (but not all—26 of the 47
> GrainQuantity value sets do match) of the value columns obtained from the
> script do not match the values obtained from interactive mode.

There is a simple mistake in the script. You need to do

    height_field.grains_get_values(...)

not

    mask_field.grains_get_values(...)

The mask defines where the grains are (which is then captured by the
numbering – grains_arr in your case). But their properties are
calculated using the actual topography.

If you pass the mask field instead, area-related quantities will be OK
because they are defined entirely by the xy coordinates and the heights
do not matter. But any quantities related to heights will be wrong
because you are now processing the 0s and 1s in the mask field.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!BI-MxEJ86-ZFmlTBVYfl_u2H2dDglLd25Ml32X7-TSQTZlmmAN4L3SN8ev2_YIhimFF7duy4HzXkAus3Qj4xtw$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!BI-MxEJ86-ZFmlTBVYfl_u2H2dDglLd25Ml32X7-TSQTZlmmAN4L3SN8ev2_YIhimFF7duy4HzXkAus3Qj4xtw$>

On Mon, Nov 11, 2024 at 06:37:41PM +0000, Smith, Justin wrote:
> I wrote a simple standalone Pygwy script which applies align_rows, fix_zero,
> and grain_wshed in the same order and with the same settings (per the log
> window) as in interactive mode. However, some (but not all—26 of the 47
> GrainQuantity value sets do match) of the value columns obtained from the
> script do not match the values obtained from interactive mode.

There is a simple mistake in the script. You need to do

    height_field.grains_get_values(...)

not

    mask_field.grains_get_values(...)

The mask defines where the grains are (which is then captured by the
numbering – grains_arr in your case). But their properties are
calculated using the actual topography.

If you pass the mask field instead, area-related quantities will be OK
because they are defined entirely by the xy coordinates and the heights
do not matter. But any quantities related to heights will be wrong
because you are now processing the 0s and 1s in the mask field.

Regards,

Yeti

The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.zip,troubleshooting.zip

======================================================================
The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.zip

======================================================================
Hmmm… apparently there was an issue sending that attachment; I should be able to send it as a zip (attached).

From: Smith, Justin <jsm...@Ce...>
Date: Tuesday, November 12, 2024 at 8:55 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Some Pygwy-extracted grain values (mean, surface area, ...) do not match interactive mode results
The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.tar.gz,troubleshooting.tar.gz
________________________________
The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.tar.gz
________________________________
Thanks for the swift response! I have attached an example script that reproduces the issue, along with an example spm file and a pregenerated csv that I get as output from the script.


From: David Nečas (Yeti) <ye...@gw...>
Date: Tuesday, November 12, 2024 at 6:22 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Some Pygwy-extracted grain values (mean, surface area, ...) do not match interactive mode results
On Mon, Nov 11, 2024 at 06:37:41PM +0000, Smith, Justin wrote:
> I wrote a simple standalone Pygwy script which applies align_rows, fix_zero,
> and grain_wshed in the same order and with the same settings (per the log
> window) as in interactive mode. However, some (but not all—26 of the 47
> GrainQuantity value sets do match) of the value columns obtained from the
> script do not match the values obtained from interactive mode.
>
> ...
>
> In some cases (e.g., GRAIN_VALUE_MINIMUM, GRAIN_VALUE_MAXIMUM,
> GRAIN_VALUE_MEAN, …), the value I get from the Pygwy script is “1” for every
> grain. In other cases (e.g., GRAIN_VALUE_SURFACE_AREA), each grain does have a
> unique value from the Pygwy script, but it does not match (in the specific case
> of GRAIN_VALUE_SURFACE_AREA, the Pygwy script value is on the order of
> magnitude of one dimension (i.e., it is as though it was not multiplied by
> another value to give something on the order of magnitude to be expected for
> area)).

This is very strange. Can you provide an executable script which I can
use to reproduce the problem?

My first guess would be grain numbering was not done [correctly] first.
But it does not really explain the results.

> Side Note 1: When doing “Export raw data” with “Add informational commend
> header” from the [Data Process > Grains > Distributions…] window, the exported
> tab-separated file contains one more header than the number of data columns;
> the “#” column is not prepended to match the data with the headers).

This is intentional. ‘#’ is the standard comment mark. Programs like
gnuplot then automatically skip the line (as does numpy.loadtxt). I can
see nowadays everyone expects everything to be formatted for
pandas.read_csv. But the Gwyddion grain data export function predates
the existence of Pandas by a few of years and simply follows a different
convention.

> Side Note 2: This may be intended behavior (and it is easy for me to work
> around if so), but the first entry in all arrays of GrainQuantity values does
> not correspond to a grain (the size of the array is 1 larger than the number of
> grains); most of the values here are ~0, and CENTER_X and CENTER_Y correspond
> to the center of the image.

This is very intentional. The values are indexed by grain numbers, which
are positive integers. So the zeroth element does not correspond to any
grain.

The zeroth element corresponds to the empty space outside grains (that
is what the grain number image looks like). A few functions can actually
do something meaningful based on this interpretation; most do not and
the zeroth element should be ignored. In this case just skip the zeroth
value.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!AzTVsO5qwrJoHAEF6pJRw11gCQWtwd7JTVUi-jQlM_LttZiNMpgbb484zq3jnNOH0X46h4WeHzbrg7DEIjaYIQ$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!AzTVsO5qwrJoHAEF6pJRw11gCQWtwd7JTVUi-jQlM_LttZiNMpgbb484zq3jnNOH0X46h4WeHzbrg7DEIjaYIQ$>

The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.tar.gz,troubleshooting.tar.gz

======================================================================
The following attachments were removed by the UH email system as they are not allowed to be transferred by email:

troubleshooting.tar.gz

======================================================================
Thanks for the swift response! I have attached an example script that reproduces the issue, along with an example spm file and a pregenerated csv that I get as output from the script.


From: David Nečas (Yeti) <ye...@gw...>
Date: Tuesday, November 12, 2024 at 6:22 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Some Pygwy-extracted grain values (mean, surface area, ...) do not match interactive mode results
On Mon, Nov 11, 2024 at 06:37:41PM +0000, Smith, Justin wrote:
> I wrote a simple standalone Pygwy script which applies align_rows, fix_zero,
> and grain_wshed in the same order and with the same settings (per the log
> window) as in interactive mode. However, some (but not all—26 of the 47
> GrainQuantity value sets do match) of the value columns obtained from the
> script do not match the values obtained from interactive mode.
>
> ...
>
> In some cases (e.g., GRAIN_VALUE_MINIMUM, GRAIN_VALUE_MAXIMUM,
> GRAIN_VALUE_MEAN, …), the value I get from the Pygwy script is “1” for every
> grain. In other cases (e.g., GRAIN_VALUE_SURFACE_AREA), each grain does have a
> unique value from the Pygwy script, but it does not match (in the specific case
> of GRAIN_VALUE_SURFACE_AREA, the Pygwy script value is on the order of
> magnitude of one dimension (i.e., it is as though it was not multiplied by
> another value to give something on the order of magnitude to be expected for
> area)).

This is very strange. Can you provide an executable script which I can
use to reproduce the problem?

My first guess would be grain numbering was not done [correctly] first.
But it does not really explain the results.

> Side Note 1: When doing “Export raw data” with “Add informational commend
> header” from the [Data Process > Grains > Distributions…] window, the exported
> tab-separated file contains one more header than the number of data columns;
> the “#” column is not prepended to match the data with the headers).

This is intentional. ‘#’ is the standard comment mark. Programs like
gnuplot then automatically skip the line (as does numpy.loadtxt). I can
see nowadays everyone expects everything to be formatted for
pandas.read_csv. But the Gwyddion grain data export function predates
the existence of Pandas by a few of years and simply follows a different
convention.

> Side Note 2: This may be intended behavior (and it is easy for me to work
> around if so), but the first entry in all arrays of GrainQuantity values does
> not correspond to a grain (the size of the array is 1 larger than the number of
> grains); most of the values here are ~0, and CENTER_X and CENTER_Y correspond
> to the center of the image.

This is very intentional. The values are indexed by grain numbers, which
are positive integers. So the zeroth element does not correspond to any
grain.

The zeroth element corresponds to the empty space outside grains (that
is what the grain number image looks like). A few functions can actually
do something meaningful based on this interpretation; most do not and
the zeroth element should be ignored. In this case just skip the zeroth
value.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!AzTVsO5qwrJoHAEF6pJRw11gCQWtwd7JTVUi-jQlM_LttZiNMpgbb484zq3jnNOH0X46h4WeHzbrg7DEIjaYIQ$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!AzTVsO5qwrJoHAEF6pJRw11gCQWtwd7JTVUi-jQlM_LttZiNMpgbb484zq3jnNOH0X46h4WeHzbrg7DEIjaYIQ$>

On Mon, Nov 11, 2024 at 06:37:41PM +0000, Smith, Justin wrote:
> I wrote a simple standalone Pygwy script which applies align_rows, fix_zero,
> and grain_wshed in the same order and with the same settings (per the log
> window) as in interactive mode. However, some (but not all—26 of the 47
> GrainQuantity value sets do match) of the value columns obtained from the
> script do not match the values obtained from interactive mode.
>
> ... 
> 
> In some cases (e.g., GRAIN_VALUE_MINIMUM, GRAIN_VALUE_MAXIMUM,
> GRAIN_VALUE_MEAN, …), the value I get from the Pygwy script is “1” for every
> grain. In other cases (e.g., GRAIN_VALUE_SURFACE_AREA), each grain does have a
> unique value from the Pygwy script, but it does not match (in the specific case
> of GRAIN_VALUE_SURFACE_AREA, the Pygwy script value is on the order of
> magnitude of one dimension (i.e., it is as though it was not multiplied by
> another value to give something on the order of magnitude to be expected for
> area)).

This is very strange. Can you provide an executable script which I can
use to reproduce the problem?

My first guess would be grain numbering was not done [correctly] first.
But it does not really explain the results.

> Side Note 1: When doing “Export raw data” with “Add informational commend
> header” from the [Data Process > Grains > Distributions…] window, the exported
> tab-separated file contains one more header than the number of data columns;
> the “#” column is not prepended to match the data with the headers).

This is intentional. ‘#’ is the standard comment mark. Programs like
gnuplot then automatically skip the line (as does numpy.loadtxt). I can
see nowadays everyone expects everything to be formatted for
pandas.read_csv. But the Gwyddion grain data export function predates
the existence of Pandas by a few of years and simply follows a different
convention.

> Side Note 2: This may be intended behavior (and it is easy for me to work
> around if so), but the first entry in all arrays of GrainQuantity values does
> not correspond to a grain (the size of the array is 1 larger than the number of
> grains); most of the values here are ~0, and CENTER_X and CENTER_Y correspond
> to the center of the image.

This is very intentional. The values are indexed by grain numbers, which
are positive integers. So the zeroth element does not correspond to any
grain.

The zeroth element corresponds to the empty space outside grains (that
is what the grain number image looks like). A few functions can actually
do something meaningful based on this interpretation; most do not and
the zeroth element should be ignored. In this case just skip the zeroth
value.

Regards,

Yeti

I wrote a simple standalone Pygwy script which applies align_rows, fix_zero, and grain_wshed in the same order and with the same settings (per the log window) as in interactive mode. However, some (but not all—26 of the 47 GrainQuantity value sets do match) of the value columns obtained from the script do not match the values obtained from interactive mode.

GrainQuantity value sets which DO NOT match between the two approaches:
GRAIN_VALUE_MINIMUM, GRAIN_VALUE_MAXIMUM, GRAIN_VALUE_MEAN, GRAIN_VALUE_MEDIAN, GRAIN_VALUE_RMS, GRAIN_VALUE_BOUNDARY_MINIMUM, GRAIN_VALUE_BOUNDARY_MAXIMUM, GRAIN_VALUE_SURFACE_AREA, GRAIN_VALUE_HALF_HEIGHT_AREA, GRAIN_VALUE_VOLUME_0, GRAIN_VALUE_VOLUME_MIN, GRAIN_VALUE_VOLUME_LAPLACE, GRAIN_VALUE_SLOPE_THETA, GRAIN_VALUE_SLOPE_PHI, GRAIN_VALUE_CURVATURE_CENTER_X, GRAIN_VALUE_CURVATURE_CENTER_Y, GRAIN_VALUE_CURVATURE_CENTER_Z, GRAIN_VALUE_CURVATURE1, GRAIN_VALUE_CURVATURE2, GRAIN_VALUE_CURVATURE_ANGLE1, GRAIN_VALUE_CURVATURE_ANGLE2

In some cases (e.g., GRAIN_VALUE_MINIMUM, GRAIN_VALUE_MAXIMUM, GRAIN_VALUE_MEAN, …), the value I get from the Pygwy script is “1” for every grain. In other cases (e.g., GRAIN_VALUE_SURFACE_AREA), each grain does have a unique value from the Pygwy script, but it does not match (in the specific case of GRAIN_VALUE_SURFACE_AREA, the Pygwy script value is on the order of magnitude of one dimension (i.e., it is as though it was not multiplied by another value to give something on the order of magnitude to be expected for area)).

Let me know if there is anything that I can provide you to help with this. This was encountered with Gwyddion 2.66, just in case it is something that has been addressed in the latest version.

Side Note 1: When doing “Export raw data” with “Add informational commend header” from the [Data Process > Grains > Distributions…] window, the exported tab-separated file contains one more header than the number of data columns; the “#” column is not prepended to match the data with the headers).

Side Note 2: This may be intended behavior (and it is easy for me to work around if so), but the first entry in all arrays of GrainQuantity values does not correspond to a grain (the size of the array is 1 larger than the number of grains); most of the values here are ~0, and CENTER_X and CENTER_Y correspond to the center of the image.

Gwyddion 2.67 is now available for download at

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

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

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

Note that the key has changed and for this release the files are signed
by both the old and new keys (separately).

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

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.

Libraries:
- libgwyddion: ACF and PSDF fitting preset initial guesses were improved.
- libgwyddion: Function for checking for a regular lattice was added, able to
  handle rotation and some moderate defects.
- libgwyddion: gwy_raw_data_size() was updated for the new types added since
  2.65 and gwy_raw_data_size_bits() was added, useful for fractional sizes.
- libgwyddion: gwy_convert_raw_data() can handle 10byte x86 ‘extended’ floating
  point numbers.
- libgwyddion: Functions for filling an array with arithmetic progression and
  accumulation/rewind of array of counts were added.
- libgwyprocess: Function for the entire facet levelling procedure was added.
- libgwyprocess: Function for facet distribution computation was added.
- libgwyprocess: Function for polynomial scan line levelling was added.
- libgwyapp: Workaround was added for data browser drag'n'drop dropping wrong
  data in KDE Plasma in Wayland (and possibly other environments).
- libgwyapp: Log message handling can be modified using a new function.

Modules:
- Curve map fit (new): Fits general functions to curve map curves.
- Curve map volumize (new): Converts regular curve map data to volume data.
- XYZ Reduce (new): Reduces number of points in a XYZ data array. 
- XYZ 1D FFT filter (new): Performs FFT filtering in the XYZ data array,
  treating it as time series of equidistant values.
- PFM (new): Performs processing of vector Piezoresponse Force Microscopy
  data consisting of measurements in two perpendicular directions.
- Periodic translate (new): Translate image in the XY plane, treating it as
  periodic.
- Residue synthesis (new): Simulates surfaces resembling film residue after
  partial dissolution.
- HDF5: Support for Nanosurf NHF file format was added. Missing data units
  in EPFL files were corrected.
- Keyence: Wrong physical data scales and metadata in imported VK3 files were
  corrected.
- Nanoscope: Uses FV Lines for the number of scan lines in force volume data.
- Image export: Fonts with attributes like ‘Bold’ or ‘Italics’ are correctly
  loaded back from settings (instead of the font being reset to default).
  Round interpolation should make images in exported SVGs pixelated and masks
  should always be pixelated in SVG (as they are in PDF).
- Correlation length tool: Rewritten using the new self-consistent ACF paper.
  It also displays ACF and PSDF plots and lots of other improvements.
- Volume equiplane, Z-pos level: Crash for data with Z-calibration was fixed.
- Volume Crop: Missing coordinate units were corrected.
- Mutual Crop: Has a preview, can create new images and allows method
  selection.
- Statistical functions tool: Radial ACF subtracts the mean value
  automatically. Result not being always updated upon masking mode changes was
  fixed.
- Volume slice: Clear selection button was added. Fixed previews not
  correctly updating according to changing selection in some cases.
- Volume plane level: Zero mean value function was added.
- Lattice synthesis: Incorrect lattice scaling was fixed.
- Volume facet level: The progress bar actually works and the computation
  is cancellable.
- Fit terraces (image and graph) and volume and graph ASCII export: Output
  files are written with native EOLs, not always Unix.
- Facet analysis: Manual rotation of points works correctly again.
- Frequency split: A PSDF and filter shape plot was added.
- Grain filter: It now actually reads the ranges file with remembered ranges
  the for various quantities when run non-interactively.

Others:
- Compilation: configure now aborts when basic C99 maths functions like cbrt(),
  hypot() or erf() are not available. Gwyddion code has been using erf()
  unconditionally for many years so the change just makes it manifest.
- Compilation: Various auxiliary Python build scripts, generally used in builds
  from subversion, work with any Python version (2.7 or 3.x). Python checks
  were split into pygwy and interpreter for the scripts. Pygwy compiler and
  linker variables are now prefixed PYTHON2_ instead of PYTHON_.
- Plug-in proxy: Configuring with --disable-plugin-proxy now also prevents the
  installation of all plug-in support files.
- Python: Standalone Python module gwy initialises GTK+ more carefully, making
  it work at least to some degree without a display.

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

Thanks all who contributed,

Yeti

You are amazing! Thank you so much!!

[University of Houston logo]
Justin Smith
Postdoctoral Fellow
William A. Brookshire Department of Chemical and Biomolecular Engineering
University of Houston
Mobile (913) 449-3220
jsm...@ce...<mailto:jsm...@ce...>
https://uh.edu<https://uh.edu/>

CONFIDENTIALITY NOTICE: The information in this email may be confidential and/or privileged. If you are not the intended recipient, then any review, dissemination, or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, then please immediately notify the sender by return email and delete this email from your devices.


From: David Nečas (Yeti) <ye...@gw...>
Date: Tuesday, November 5, 2024 at 9:00 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Standalone Pygwy script execution of grain_filter process
On Tue, Nov 05, 2024 at 11:38:11AM +0100, David Nečas (Yeti) wrote:
> On Mon, Nov 04, 2024 at 03:58:37PM +0000, Smith, Justin wrote:
> > The problem is not the string that I write to the file because it
> > successfully sets the default that shows up in manual Gwyddion usage
> > (i.e., the [Data Process > Grains > Filter…] dialog box has the values
> > I set for the ranges), and because using a file simply generated from
> > manual Gwyddion usage also fails.
>
> The module seems to not work correctly non-interactively (which is
> probably something done rarely in this case). Since simply running it
> again using Ctrl-F does not work, any other non-interactive use is
> unlikely to work either.
>
> In other words, it is a bug. I will have to look into it.

I fixed the bug (r26796). It was not reading the ranges file when used
non-interactively. So Ctrl-F works now.

The module is still kind of interactive-only because of the file where
it remembers all the ranges. But in principle you can rewrite the file
in Python and run the function.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!BuQozEI-RCg3Uyt4JRX_qJCgVTAbS0lvPPbg2uenoYoAPjRynxwKrWbNSG6biSkhaw_ItMH1yqF8RKbh9AzCuw$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!BuQozEI-RCg3Uyt4JRX_qJCgVTAbS0lvPPbg2uenoYoAPjRynxwKrWbNSG6biSkhaw_ItMH1yqF8RKbh9AzCuw$>

On Tue, Nov 05, 2024 at 11:38:11AM +0100, David Nečas (Yeti) wrote:
> On Mon, Nov 04, 2024 at 03:58:37PM +0000, Smith, Justin wrote:
> > The problem is not the string that I write to the file because it
> > successfully sets the default that shows up in manual Gwyddion usage
> > (i.e., the [Data Process > Grains > Filter…] dialog box has the values
> > I set for the ranges), and because using a file simply generated from
> > manual Gwyddion usage also fails.
> 
> The module seems to not work correctly non-interactively (which is
> probably something done rarely in this case). Since simply running it
> again using Ctrl-F does not work, any other non-interactive use is
> unlikely to work either.
> 
> In other words, it is a bug. I will have to look into it.

I fixed the bug (r26796). It was not reading the ranges file when used
non-interactively. So Ctrl-F works now.

The module is still kind of interactive-only because of the file where
it remembers all the ranges. But in principle you can rewrite the file
in Python and run the function.

Regards,

Yeti

On Mon, Nov 04, 2024 at 03:58:37PM +0000, Smith, Justin wrote:
> The problem is not the string that I write to the file because it
> successfully sets the default that shows up in manual Gwyddion usage
> (i.e., the [Data Process > Grains > Filter…] dialog box has the values
> I set for the ranges), and because using a file simply generated from
> manual Gwyddion usage also fails.

The module seems to not work correctly non-interactively (which is
probably something done rarely in this case). Since simply running it
again using Ctrl-F does not work, any other non-interactive use is
unlikely to work either.

In other words, it is a bug. I will have to look into it.

Regards,

Yeti

I am able to use some modules like linematch per the instructions in the Python Scripting section of the documentation, but I am struggling to properly set some of the parameters when using the grain_filter module because there does not appear to be a way to set the ranges of the filter quantities within the Settings Container object. Use of the log while using gwyddion manually only reveals settings values for, e.g., `settings['/module/grain_filter/quantity1'] = "Center x position"`.  I can see from the source code that these parameters are written to/read from the file ~/.gwyddion/ranges, and I see that a python method is provided to write to such user data files (gwy. gwy_module_data_save()), but I am unable to get the values of this file to control the behavior of grain_filter when executed from a standalone Pygwy script. The problem is not the string that I write to the file because it successfully sets the default that shows up in manual Gwyddion usage (i.e., the [Data Process > Grains > Filter…] dialog box has the values I set for the ranges), and because using a file simply generated from manual Gwyddion usage also fails.

Now, when I say that it “fails”, what I mean is that I am getting different results between manual Gwyddion usage and the standalone Pygwy script. When I simply use grain_wshd from the Pygwy script alone, I get the correct outcome (i.e., export of an image shows the grains correctly masked, and operations like `len(container[mask_field_key].grains_get_values(grains_arr,gwy.GRAIN_VALUE_SURFACE_AREA))` give the expected value (400 in my specific case)); this part matches what I see with manual Gwyddion usage. However, if I apply grain_filter with the settings below and a ~/.gwyddion/ranges file generated from manual Gwyddion usage…

# Set up parameters for the 'grain_filter' function.
settings['/module/grain_filter/update'] = False
settings['/module/grain_filter/expanded'] = 190
settings['/module/grain_filter/logical'] = 3
settings['/module/grain_filter/quantity1'] = "Center x position"
settings['/module/grain_filter/quantity2'] = "Center y position"
settings['/module/grain_filter/quantity3'] = "Pixel area"

# Run grain_filter and export image
gwy.gwy_process_func_run('grain_filter', container, gwy.RUN_IMMEDIATE)
mask_field_key = int(gwy.gwy_app_data_browser_get_current(gwy.APP_MASK_FIELD_KEY))
grains_arr = container[mask_field_key].number_grains()
print(len(container[mask_field_key].grains_get_values(grains_arr,gwy.GRAIN_VALUE_SURFACE_AREA)))
gwyutils.save_dfield_to_png(gu.get_current_container(),'/0/data','./out_data.png',gwy.RUN_NONINTERACTIVE)

…now the image shows no mask on the grains and the output from the print command is 1 instead of 400.

What should I do differently? Let me know if you need additional information. Any help is much appreciated!

[University of Houston logo]
Justin Smith
Postdoctoral Fellow
William A. Brookshire Department of Chemical and Biomolecular Engineering
University of Houston
Mobile (913) 449-3220
jsm...@ce...<mailto:jsm...@ce...>
https://uh.edu<https://uh.edu/>

CONFIDENTIALITY NOTICE: The information in this email may be confidential and/or privileged. If you are not the intended recipient, then any review, dissemination, or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, then please immediately notify the sender by return email and delete this email from your devices.

OK, I think it’s working now! I assumed that pygtk2 was installed since I was able to access the Pygwy Console, but I looked and saw that neither `sudo dnf install gwyddion.x86_64` nor `sudo dnf install gwyddion-devel.x86_64`installed it. Following `sudo dnf install pygtk2.x86_64`, the Pygwy Console appears to be working (no errors from `import gwyutils` or `d = gwy.gwy_app_data_browser_get_current(gwy.APP_DATA_FIELD)`). A standalone Pygwy script consisting only of…

#!/usr/bin/python2
import gwy
print(gwy.__file__)

…also seems to work, although I do get a message from gtk; the output is…

Gtk-Message: 16:54:06.966: Failed to load module "pk-gtk-module"
/usr/lib64/python2.7/site-packages/gwy.so

…but if the pk-gtk-module thing isn’t important, then I think we are up and running. Thank you so much!

From: David Nečas (Yeti) <ye...@gw...>
Date: Friday, October 25, 2024 at 12:39 PM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Python error when trying to build from source with pygwy support
On Fri, Oct 25, 2024 at 04:42:21PM +0000, Smith, Justin wrote:
> OK, so I have installed VirtualBox on an Intel Mac (if you think this is a
> problem I can alternatively make the virtual machine on my Ubuntu computer) and
> installed Fedora 40 as a virtual machine. Within the virtual machine, I then
> downloaded and installed the F40 repository configuration. From the command
> line I then did `sudo dnf install gwyddion.x86_64`, which successfully
> installed Gwyddion. However, within the Pygwy Console I am still encountering
> the same problem with the gwy module not being found.

You do not need to do ‘import gwy’ in the console because it's
automatically there. However, if you run it, it should still work. I
have just tested the F40 packages and it works fine for me.

> A simple script consisting of `import gwyutils` when executed first
> gives the output…

For standalone scripts you also need to install gwyddion-devel which
installs the standalone gwy module (the one in the console is just
created on the fly there).

> Traceback (most recent call last):
>
>   File "<string>", line 7, in <module>
>
> ImportError: No module named gwy
>
> Traceback (most recent call last):
>
>   File "<string>", line 1, in <module>
>
>   File "/usr/share/gwyddion/pygwy/gwyutils.py", line 1, in <module>
>
>     import gwy
>
> ImportError: No module named gwy
>
> …and executing it a second time gives only the second traceback/error message.
> What am I doing wrong here?

You may be running it under Python 3 (because that is the default) and
you do not have gwyddion-devel.

However, I do not understand the console problem.

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!CbAfJ-q-cZHUqGAZ7mzgo5LmsE1HLG5pWQMvtv88Z6Nd5saCidnFmGCmgKLy7JYhklZPDKCfES5tuxioc8NGeQ$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!CbAfJ-q-cZHUqGAZ7mzgo5LmsE1HLG5pWQMvtv88Z6Nd5saCidnFmGCmgKLy7JYhklZPDKCfES5tuxioc8NGeQ$>

On Fri, Oct 25, 2024 at 04:42:21PM +0000, Smith, Justin wrote:
> OK, so I have installed VirtualBox on an Intel Mac (if you think this is a
> problem I can alternatively make the virtual machine on my Ubuntu computer) and
> installed Fedora 40 as a virtual machine. Within the virtual machine, I then
> downloaded and installed the F40 repository configuration. From the command
> line I then did `sudo dnf install gwyddion.x86_64`, which successfully
> installed Gwyddion. However, within the Pygwy Console I am still encountering
> the same problem with the gwy module not being found.

You do not need to do ‘import gwy’ in the console because it's
automatically there. However, if you run it, it should still work. I
have just tested the F40 packages and it works fine for me.

> A simple script consisting of `import gwyutils` when executed first
> gives the output…

For standalone scripts you also need to install gwyddion-devel which
installs the standalone gwy module (the one in the console is just
created on the fly there).

> Traceback (most recent call last):
> 
>   File "<string>", line 7, in <module>
> 
> ImportError: No module named gwy
> 
> Traceback (most recent call last):
> 
>   File "<string>", line 1, in <module>
> 
>   File "/usr/share/gwyddion/pygwy/gwyutils.py", line 1, in <module>
> 
>     import gwy
> 
> ImportError: No module named gwy
> 
> …and executing it a second time gives only the second traceback/error message.
> What am I doing wrong here?

You may be running it under Python 3 (because that is the default) and
you do not have gwyddion-devel.

However, I do not understand the console problem.

Regards,

Yeti

OK, so I have installed VirtualBox on an Intel Mac (if you think this is a problem I can alternatively make the virtual machine on my Ubuntu computer) and installed Fedora 40 as a virtual machine. Within the virtual machine, I then downloaded and installed the F40 repository configuration. From the command line I then did `sudo dnf install gwyddion.x86_64`, which successfully installed Gwyddion. However, within the Pygwy Console I am still encountering the same problem with the gwy module not being found. A simple script consisting of `import gwyutils` when executed first gives the output…

Traceback (most recent call last):
  File "<string>", line 7, in <module>
ImportError: No module named gwy
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/share/gwyddion/pygwy/gwyutils.py", line 1, in <module>
    import gwy
ImportError: No module named gwy

…and executing it a second time gives only the second traceback/error message. What am I doing wrong here?

From: Smith, Justin <jsm...@Ce...>
Date: Wednesday, October 23, 2024 at 7:11 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Python error when trying to build from source with pygwy support
Ah, that's exactly what I'll do then (virtual machine approach). I agree; the way you've been helping has been extremely generous, but if there is an easier way that you don't have to troubleshoot, then it's much better that I go with that.

My objective is to use pygwy standalone scripts to systematically process large numbers of AFM images for statistical analysis. Thank you so much for your help and all your work!
________________________________
From: David Nečas (Yeti) <ye...@gw...>
Sent: Wednesday, October 23, 2024 3:15:55 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Python error when trying to build from source with pygwy support

On Mon, Oct 21, 2024 at 05:18:04PM +0000, Smith, Justin wrote:
> When I used `ldd /lib/x86_64-linux-gnu/libgtkglext-x11-1.0.so.0`,  all
> but two lines of the output were analogous/seemingly correct

Yes, it looks OK. There are no unresolved libraries.

> When I run `LD_PRELOAD=/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ./runscript.py
> I get the following output:
>
> …
> ImportError: could not import gtk

So, somehow pygtk2 got lost and we are back at the beginning?

I am sorry; I do not have a good mental model of the environment you are
trying to run the scripts in. I can see what is going wrong, but am not
able to give effective advice what to change – all I write is based on
more conventional setups.

I am not sure what are you ultimately trying to achieve. You could have
probably set up Fedora 40 in a virtual machine and have everything
working there under 15 minutes. Yes, we should have Python 3 support,
but it will still take us a couple of years to get there because it
involves rewriting basically everything…

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!H-52uKiozwY-4OaZaOmw_tA3qo73l5vc6baFrkptRfl-dy1fiY_A4cBkC3V1hF0UN84gbc3XtFA759BiyQUYVQ$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!H-52uKiozwY-4OaZaOmw_tA3qo73l5vc6baFrkptRfl-dy1fiY_A4cBkC3V1hF0UN84gbc3XtFA759BiyQUYVQ$>

Ah, that's exactly what I'll do then (virtual machine approach). I agree; the way you've been helping has been extremely generous, but if there is an easier way that you don't have to troubleshoot, then it's much better that I go with that.

My objective is to use pygwy standalone scripts to systematically process large numbers of AFM images for statistical analysis. Thank you so much for your help and all your work!
________________________________
From: David Nečas (Yeti) <ye...@gw...>
Sent: Wednesday, October 23, 2024 3:15:55 AM
To: Gwyddion use discussion <gwy...@li...>
Subject: Re: [Gwyddion-users] Python error when trying to build from source with pygwy support

On Mon, Oct 21, 2024 at 05:18:04PM +0000, Smith, Justin wrote:
> When I used `ldd /lib/x86_64-linux-gnu/libgtkglext-x11-1.0.so.0`,  all
> but two lines of the output were analogous/seemingly correct

Yes, it looks OK. There are no unresolved libraries.

> When I run `LD_PRELOAD=/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ./runscript.py
> I get the following output:
>
> …
> ImportError: could not import gtk

So, somehow pygtk2 got lost and we are back at the beginning?

I am sorry; I do not have a good mental model of the environment you are
trying to run the scripts in. I can see what is going wrong, but am not
able to give effective advice what to change – all I write is based on
more conventional setups.

I am not sure what are you ultimately trying to achieve. You could have
probably set up Fedora 40 in a virtual machine and have everything
working there under 15 minutes. Yes, we should have Python 3 support,
but it will still take us a couple of years to get there because it
involves rewriting basically everything…

Regards,

Yeti



_______________________________________________
Gwyddion-users mailing list
Gwy...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gwyddion-users__;!!LkSTlj0I!H-52uKiozwY-4OaZaOmw_tA3qo73l5vc6baFrkptRfl-dy1fiY_A4cBkC3V1hF0UN84gbc3XtFA759BiyQUYVQ$