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 <jsmit...@central.uh.edu> Date: Tuesday, November 12, 2024 at 8:55 AM To: Gwyddion use discussion <gwyddion-users@lists.sourceforge.net> 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) <y...@gwyddion.net> Date: Tuesday, November 12, 2024 at 6:22 AM To: Gwyddion use discussion <gwyddion-users@lists.sourceforge.net> 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 Gwyddion-users@lists.sourceforge.net 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$>
_______________________________________________ Gwyddion-users mailing list Gwyddion-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gwyddion-users
