Activity for Gwyddion
-
David Nečas posted a comment on discussion File formats
Now I've got it, thanks. I hope to look into it soon.
-
Frederic Schell posted a comment on discussion File formats
My bad, hope it reached you now.
-
Please send it to the normal Gwyddion address yeti@gwyddion.net. I have not received anything at any of my university e-mails so far. When people try to send e-mails to my institutional address they invariably send it to one of my many namesakes (and vice versa). We regularly get review requests, project documents, student questions, etc. intended for some other David Nečas, sometimes even for some working at a different university.
-
I have sent you an email to your institutional email address with all the necessary info.
-
Please send the specs and files to me personally. The description of the changes is a bit convoluted.
-
Dear David, I want to make you aware of the new SURF file standard, that is currently not supported by Gwyddion, as well as an issue for files containing image data, such as intensity and rgb data. In the source code file surffile.c, you check if the file is longer than expected based on the contents of the header. If it is longer, you simply move the filepointer by the "unpexpected" size difference and then read the data at that location. if (expected_size != size) { gwy_debug("Size mismatch!");...
-
- added HHCF method (called structure function as this is the usual name in this context)
-
- added HHCF fractal dimension method
-
Yes, partitioning in the combo and variance in the user guide are the same method. I will clarify the documentation. Be careful with fractal dimension evaluation because the methods are prone to all kinds of systematic errors.
-
- clarification
-
- documentation clarification
-
David Casas posted a comment on discussion General Discussion
Hi! I'm using Gwyddion to calculate fractal dimension of AFM images with 512x512 pixels and 10 micrometers of lateral scan size. First of all, I'm wondering, if the Variance method that appears in Gwyddion Help (http://gwyddion.net/documentation/user-guide-en/fractal-analysis.html) is the same as the Partitioning method that appears in the dialogo box for calculating fractal dimension in Gwyddion or not. In the last case, which could be Partitioning method and how is implemented? Second, if I've...
-
Francois RIGUET committed [r26279] on Code
Update of French translation
-
This looks OK. I still do not know what is the data format (there are literally thousands different file types with the extension .dat), but phase seems recalculated to height so it should be good for roughness evaluation. Intensity is light intensity. It is shown with the correct units, i.e. no units. Please understand that Statistical Quantities simply calculates various statistical quantities from whatever data you use it on. If you use it on a voltage image, it will calculate mean, minimum, maximum,...
-
Mrudul Velhal posted a comment on discussion General Discussion
Thanks for the reply, David. The file format is .dat, but it does contain information about the surface topography. I have attached images of the phase and intensity plots and their accompanying 3D plots. The phase plot shows the scale in microns. one thing I forgot to mention is that the Statistical Quantities for the phase plot gives all the roughness values with units, but not for the intensity plot. In the data browser, I can only see phase and intensity plots. Maybe in this case the phase plot...
-
Petr Klapetek committed [r26278] on Code
added report and rss
-
Ad 1. Regions masked upon import were marked as invalid/missing/undefined/NaN/… in the original file. In some file formats there is a separate image giving the mask. In some invalid data are simply stored as NaN or some dedicated special value. It depends. You generally want to keep the mask and use the Exclude masked region option. Gwyddion interpolates the missing values, making the data usable with operations which run on a full image (like FFT). However, in most cases you want to only use the...
-
Hello everyone, Thanks in advance for your support. I am new to using Gwyddion. I am analyzing roughness profiles of my samples done using a interferometer. I have been using the 'Statistical Quantities' option to calculate the roughness of the entire area, but I had a couple of questions. 1. When I open the image, there are some spots marked as 'masks' by default. I guess they are in the metadata for the image. I was wondering if I need to keep these masks or remove them before calculation. Also,...
-
Askhat Bakarov posted a comment on discussion General Discussion
Thanks, now I can compile the nightly sources.
-
Lucas Schlenger posted a comment on discussion File formats
Hi together, As a small follow up to ensure the code does not crash on Win 11.: I had to include the lines: "gwy.gwy_app_data_browser_set_gui_enabled(False)" to not open a new window for each file I am looping over, and "gwy.gwy_app_data_browser_remove(container) " to release the memory. import gwy, numpy, os import gwyutils import matplotlib.pyplot as plt import pandas as pd root = (r'C:\Users\schlenge\Desktop\Line6') os.chdir(root) gwy.gwy_app_data_browser_set_gui_enabled(False) for filename in...
-
increased max number of iterations
-
- removed JXL flags
-
- fixed missing space after dnl in disabling libjxl
-
fitting something
-
adjusted adjustment steps
-
added capacitance plot
-
added fitting option, results stil not ideal
-
Havar Junker posted a comment on discussion General Discussion
Thanks a lot, I figured out what the problem was!
-
- disabled libjxl check
-
- added a comment about disabling JPEG XL code
-
Running configure like JXL_CFLAGS=-DJXL_VERSION_IS_AT_LEAST_0_7_BUT_IT_DOES_NOT_HAVE_ANY_PREPROCESSOR_LEVEL_VERSION_CHECK ./configure might work as a workaround. But it might not. I have not checked in detail what they removed. In any case, I will be removing libjxl as a dependence. It took less than 18 months for code correct at the time it was written (for libjxl 0.6.x) to stop compiling at all (in 0.9.0). Meaning the library does not preserve backward compatibility and we just cannot use it. JPEG...
-
For the near future it would be enough to add an option like ./configure --disable-jxl
-
Could you please post some build log? Update: Maybe not necessary. According to the logs they removed a bunch of functions in 0,9.
-
Could you please post some build log?
-
Compilation always fails if the system has a libjxl library version greater than 0.9. If this library is not there, then everything is fine. Unfortunately, I can't find any configuration options to disable libjxl. Arch linux, gwyddion 2.65
-
Compilation always fails if the system has a libjxl library version greater than 0.9. If this library is not there, then everything is fine. Unfortunately, I can't find any configuration options to disable libjxl. Arch linux
-
Compilation always fails if the system has a libjxl library version greater than 0.9. If this library is not there, then everything is fine. Unfortunately, I can't find any configuration options to disable it.
-
Look for gwy_data_field_area_row_acf in https://sourceforge.net/p/gwyddion/code/HEAD/tree/trunk/gwyddion/libprocess/stats-acfpsdf.c. The function is not trivial and does not work as you might expect if you know elementary ACF computation using FFT because it can calculate ACF with masking (most statistical function in Gwyddion support masking). You probably need to read http://dx.doi.org/10.1016/j.ultramic.2012.08.002 to understand how it works (the main ideas are summarised also in the user guide)....
-
Dear All, I am struggling a lot to reproduce the 1D ACF curves generated in Gwyddion elsewhere using the formulas provided in the documentation. I read on this forum that a line levelling is applied to each row under the hood in Gwyddion before the summation, but I cannot seem to find the source code for this. My own implementation agrees with standard FFT methods in Python, meaning that the problem most likely lies in the preprocessing/line levelling of the raw data in Gwyddion. Could someone point...
-
Vojtěch Klapetek committed [r26268] on Code
allow arbitrary length IDAT
-
Chrysor posted a comment on discussion File formats
After some testing everything seems to be working perfectly. Thanks a lot for the support!
-
Since some SPM files can contain hundreds of images, Gwyddion does not show all when you open a file, but only the first one. Usually the first image in the file is useful. For a few specific file formats we know that the physically first image is not useful so the import module tries to select a better one. However, there is no user-controlled rule which image to show. If your file format is one of those where the first image is not useful we might modify the import module – but currently I don't...
-
kim Kyeongnam posted a comment on discussion General Discussion
When I first open an AFM data file, the amplitude is displayed. So, i always have to go to Information -> Data Process and change it to Z-axis. I would appreciate it if i could know how to set the Z-axis to appear when opening AFM data for the first time.
-
- do not pass hash to get_scan_size() in hash_to_lawn(); pass scansize twice
-
- grammar fix
-
- added a note about MS Windows trying to discourage users from installation
-
Yes, this kind of things is difficult to spot with random noise… Thanks for the testing files. It should be fixed in r26264.
-
- don't apply bufferRange to multicolumn ASCII data which are already in physical units
-
I really thank you for the quick implementation in the current snapshot! I can read the .txt files, but I think there are some bugs regarding the read in. The image appears to be mirrored along the horizontal. Somehow the values don't match and are too large. In the attachment you will find one AFM measurement, saved in .mi format and in .txt format. There you should be able to compare the images and check for the differences. Thanks a lot for your support!
-
Multicolumn ASCII images should be working as of r26263. Please try tomorrow's or later development snapshot.
-
- added support for multicolumn ASCII image files
-
Joe Smerdon posted a comment on discussion General Discussion
Hi, Thanks again for Gwyddion. I've been using it 15 years now or thereabouts. In STM, there is always some distortion due to piezo creep. There are a few things that come from piezo creep, but the specific distortion I refer to is as follows: The centre of an image is pushed slightly towards the side. Which side, depends on the scan direction. This makes it difficult to average forward and backward images (which I want to do, as I have noise. Good resolution, but plenty of random noise). The left...
-
Thank you for the report. I do not have that many files with AmpitudeErrors in volts (as opposed to metres), but you are right the voltage value scale is wrong. At this moment we do not know why or how to correct it to match Nanoscope. The conversion from raw data to physical values has to be done differently than for other channels (or even differently to when it is in nm)? On the other hand, these voltages are not something you would normally try to interpret quantitatively – do you actually need...
-
In the attachement you can find such an example file. Thanks a lot for your support!
-
If the files come from PicoView please provide some example (directly here using Add attachments if the data are not secret) and I will add support for the MI file import module.
-
Thanks for the reply. Yes the AFM files are generated by PicoView. I can save the data there as a .mi file, where I have no problems to read them in into gwyddion. In addition, the files can also be saved in the described .txt format but then are not readable by gwyddion. I want to use a python script for detailed analysis of the measurements but I can't seem to find a way to read in .mi with python 3 as easy as .txt files. Therefore I'm looking for a filestructure of .txt files which gwyddion can...
-
Are you trying to write the files in some existing file format, or is this an ad hoc format? Fields xPixels and yPixels look like from a Molecular Imaging/PicoView text format. The data look a bit like it. I have never seen xUnit, yUnit and Channels in MI files though. Gwyddion has a bunch of file import modules for various text exports (SPIP, Attocube, Accurex II, SDF/BCR, PLT, WSF), but they are generally single-channel. It seems we might read multiple channels from MI files. The data are, however,...
-
Are you trying to write the files in some existing file format, or is this an ad hoc format? Fields xPixels and yPixels look like from a Molecular Imaging/PicoView text format. The data look a bit like it. I have never seen xUnit, yUnit and Channels in MI files though. Gwyddion has a bunch of file import modules for various text exports (SPIP, Attocube, Accurex II, SDF/BCR, PLT, WSF), but they are generally single-channel. It seems we might read multiple channels from MI files. The data are, however,...
-
Hello, I have a really general problem with importing .txt files. I want to import .txt files into Gwyddion from some AFM measurements but I cannot seem to find a proper example how the file should be structure so I can read it in. To be more detailed, the file from AFM measurements look something like this: (Header with some basic info like:) xPixels 512 yPixels 512 xUnit µm yUnit µm Channels 4 .... (Measurement data of multiple channels:) TopographyTrace(µm) TopographyRetrace(µm) Amplitude(V) Phase(deg)...
-
- added magic comments
-
- added a couple more tiny grain special cases to the Laplace solver
-
- added a function special-casing tiny grains, currently 1×1
-
- updated 2.66 news a bit
-
- try to read binary wave records from PXP files and merge them to a file
-
- refactored igor_read_single() to read into a caller-supplied container from a caller-supplied
-
- removed debugging timer
-
- worked around slow laplace solver when running on a huge number of small-ish grains
-
- started adding support for Igor packed experiment (PXP) files
-
- a feeble attempt to add some conversion to physical values
-
Alice Li modified a comment on discussion General Discussion
Dear all, recently, when I open a spm file in Gwyddion, I find the unit of the Amplitude Error is wrong (see attached snaped image ). I am sure that during the measurement, the unit is in the mV, but not the V. Can someone help how to fix this? I am really appreciate that if someone could help me. Thank you a lot in advance
-
Dear all, recently, when I open a spm file in Gwyddion, I find the unit of the Amplitude Error is wrong (see attached snaped image ). I am sure that during the measurement, the unit is in the mV, but not the V. Can someone help how to fix this. I an really appreciate that if someone could help me. Thank you a lot in advance
-
- read both channels, if present
-
- moved header reading out of the main load function
-
- added a NO_REBASE filetype flag for files which look like volume/curve data, but are not
-
- improved file format detection, especially for version 0
-
- started adding support also for version 2
-
- read v0 frames from the correct positions in the file
-
- started adding support for version 0 of the file format
-
- do not include pyroscopy version attributes in metadata because they are fake anyway
-
If the points are in a regular grid and you use Create Image Directly in Rasterise then it has no effect. If you actually have to rasterise then some interpolation is done, but I do not think it can have an effect here.
-
If the points are in a regular grid and you use Create Image Directly in Rasterise then it has no effect. If you actually has to rasterise some interpolation is done, but I do not think it can have an effect here.
-
L.G posted a comment on discussion General Discussion
Just checked, and the curves look practically identical. I should probably add that I'm working with .obj files (coming from a 3D scanner). So after importing them, I use the tool "Rasterize XYZ data" for obtaining a processable image. But I don't think that procedure adds any error (as long as it is kept consistent, at least).
-
What shall I do with the row statistics tool? See the row averages as the 2D data might be quite noisy.
-
Selecting a same rectangle in the most flat region of the reference part could help with the odd features in the corners But it uses even less data. Yes, then data would be reduced. Also, I tried with other samples (having more even surfaces) and I didn't get any improvements. Since the upper part is larger, you can also alternatively try to level the surface using the upper part. The difference works either way, just the sign changes. The issue here is that the treatment might not cause a uniform...
-
The change seems pretty minor, so it will be very sensitive to the levelling/z-alignment – and the reference part is rather uneven. I might try to suggest a couple of things, but you are in danger of trying to get the results you want to see – as opposed to what the data say (which might not be much, at least not reliably) Selecting a same rectangle in the most flat region of the reference part could help with the odd features in the corners But it uses even less data. Since the upper part is larger,...
-
The change seems pretty minor, so it will be very sensitive to the levelling/z-alignment – and the reference part is rather uneven. I might try ti suggest a couple of things, but you are in danger of trying to get the results you want to see – as opposed to what the data say (which might not be much, at least not reliably) Selecting a same rectangle in the most flat region of the reference part could help with the odd features in the corners But it uses even less data. Since the upper part is larger,...
-
Thanks for your feedback. I'm attaching a pic, left map before the treatment and right map after. In both, the reference (always untreated) surface is in the bottom part, below that groove (which I always exclude from any calculation, because very noisy and because I don't need it). So yes, the reference is on one side only. I get credible results only if I do plane leveling from the entire map - which probably is incorrect.
-
What you write sounds reasonable (although I have some difficulties imaging it exactly without a picture). So the problem may be that the reference part is small/on one side/…, making the procedure ill-conditioned (i.e. numerically not stable)?
-
Hi all, I need to process 3D models of tiles at different stages of surface treatment. The part of the surface treated erodes (recedes), the untreated part is no affected in any way instead. I would like to keep the untreated surface as reference and to calculate the increasing height differences with the treated surface during a sequence of following treatments. All in all, the surfaces mapped approximate a simple plain. What is the correct way of leveling the maps, before any calculation? I assumed...
-
updated graph axes and other GUI aspects
-
- try to read physical dimensions from scanlist if we find a separate Slow Axis Size field
-
added parameters
-
most of the GUI working, no calculation yet
-
- fixed Match voxel size modes to actually match voxel sizes, not brick sizes
-
- fixed Match pixel size to actually match pixel size, not image size
-
- fixed inverted meaning of inverted for rank-based marking
-
- fixed swapped arguments of err_SIZE_MISMATCH()
-
- updated 2.66 news a bit
-
- added mark by rank option which marks given fraction of the pixels (as opposed to
-
- formatted to 120 columns