Home Download News Features Screenshots Documentation Communicate Participate Resources Applications Site Map
General:
Why Gwyddion?
I found a bug, what should I do?
When it will be finished?
How to cite/refer to Gwyddion?
When a new version will be released?
How can I get notified of new releases?
What systems and architectures Gwyddion runs on?
Can we use proprietary plug-ins?
How do I send large data files to you, do you have a FTP upload area?
Data processing:
Why I cannot load my microscope files?
What the strange PSDF values mean?
How can I export an image of the data?
What is the best method to automatically load my raw data?
Extending and developing:
Why C programming language?
Why to use Gtk+ library?
Can I use my own routines with this software?
Can I use other graphical library (Qt, MFC) with the program
Will my plug-ins work with future versions of Gwyddion?
Will my modules work with future versions of Gwyddion?
I linked Gwyddion with --as-needed and it broke. How to fix it?
How do I write a module in C++?
See the explanation.
Please, report it to Petr.
Also please check it is still present in the latest stable version. You will be likely asked to upgrade if you report a bug in an old version.
For file loading-related bugs please provide the file that causes problems to make reproducing the bug possible. If you experience crashes on a Unix-based system a gdb trace or valgrind output will also be helpful for locating the bug.
As the system should be a framework for developement and sharing of new analytical methods, everlasting continuous developement is expected.
A paper about Gwyddion has been published recently in Central European Journal of Physics. It can be cited as follows:
David Nečas, Petr Klapetek, Gwyddion: an open-source software for SPM data analysis, Cent. Eur. J. Phys. 10(1) (2012) 181-188
BibTeX record:
@Article{Necas2012,
author = {Nečas, David and Klapetek, Petr},
affiliation = {CEITEC — Central European Institute of Technology, Masaryk University Kamenice 753/5, 625 00 Brno, Czech Republic},
title = {Gwyddion: an open-source software for {SPM} data analysis},
journal = {Central European Journal of Physics},
publisher = {Versita, co-published with Springer-Verlag GmbH},
issn = {1895-1082},
keyword = {Physics and Astronomy},
pages = {181-188},
volume = {10},
issue = {1},
year = {2012},
doi = {10.2478/s11534-011-0096-2},
}
If you refer to Gwyddion in software context it is also useful to give the
URL http://gwyddion.net/.
When the amount of changes will warrant a new release.
Assuming a reasonable development pace this policy means a new version is released once a month or two on average. Sometimes the development is slower so it takes longer.
As many other projects have realized, waiting until features are finished leads to excessive delays. Hence features that are not ready yet are simply omitted from the release. Do not take it personally if you have a personal interest in something left out – since we do not wait another release, meaning another chance, will occur soon.
If you are subscribed to either gwyddion-users or gwyddion-devel mailing list you will receive notifications by e-mail.
If you are a Freecode user, you can subscribe to project Gwyddion (the Follow link is in the right side-box).
If you are a SourceForge.net user, you can monitor project Gwyddion, see the top right corner Develop tab. Unfortunately, this does not seem to be configurable to file releases only so it is not very useful if you are not interested in every subversion commit. SourceForge also offers a RSS feed for file releases, see the top right corner of the Files tab.
OS-wise, Gwyddion is known to work on GNU/Linux, Microsoft Windows, Mac OS X, and FreeBSD. Architecture-wise, it has been tested on i386, AMD64, and PowerPC. It should work on any Unix-like system where Gtk+ and other dependencies work.
Yes you can. You can use a plug-in with other than open source license. However, such a plug-in can't be a part of the program, but can be distributed separately. Also note the difference between plug-ins, i.e. standalone programs reading/writing/processing some data, that can be independent works and modules that are always derived works of Gwyddion.
Unfortunately, we do not have any public FTP upload space.
The preferred method of sending large files is to upload them to a file hosting service/file deposit and send the link.
Not preferred, but also possible is to send files by e-mail. In such case compress the files with 7zip, bzip2 or zip because:
Please do not send large files directly to the mailing lists; messages exceeding certain size are rejected.
If your microscope native files are not supported yet, you can write a IO plugin by yourself or you can contact us and send us your format specifications and some data.
If your format is supported but you have problems with file loading, report it as a bug (we will need the problematic file to fix it).
There is page describing the file format situation in details.
Most probably you are looking at the PSDF method of fractal dimension estimation. It uses a log-log plot with arbitrary shifts and scale. Use the statistical functions tool to obtain PSDF in absolute units.
The x axis units are then lateral_unit-1 and y axis units lateral_unit × value_unit2. The normalization corresponds to the PSDF expressions for various surfaces that can be used to fit rms and autocorrelation length of rough surfaces in graph fitting.
Many different PSDF normalizations can be found in the literature, together with reasons why they are better than others. PSDF in Gwyddion is based on the concept of an infinite (rough) surface. The measured data is a finite-resolution measurement on a finite area which is assumed to have the same statistical properties as the entire surface.
The total energy of an infinite surface is infinite so, a meaningful quantity is the energy per unit interval. The PSDF displayed in Gwyddion can be then imagined as this function. It is sampled in certain points given by the discrete nature of the calculation, nevertheless, the values should be approximations of W1(k) that results from contiguous FT of the entire infinite surface.
This has the following nice consequences:
Also, for contiguous distributions, the square of a density of some quantity is not the density of the same quantity squared. Hence normalizations of PSDF and Fourier coefficients generally need to be considered separately.
Using File → Save As and choosing an image format such as PNG or TIFF (or just giving the file the corresponding extension).
For a plain export without rulers, false colour bars, etc. you can also press Ctrl-C in an image window to copy it to the clipboard and then paste it to another program.
If you want to represent the data in an image format but not to lose too much information then save it as PNG, TIFF or PPM and select 16bit grayscale for a larger bit depth. Gwyddion also can save and load OpenEXR HDR images that offer even higher bit depths and dynamic ranges.
Complement the data file with a standalone
NRRD header
refering to the raw file using data file: and specifying the
dimensions and other properties. Loading this header into Gwyddion will then
load the raw data.
The biggest advantage of this method is that no modification of the raw file is necessary.
NRRD is supported since version 2.25.
The core and modules is written in C language.
This language was chosen as it is well known and widely spread, there are many important libraries that could be used (Gtk+), and it's relatively easy to bind C function to other languages. At present Python bindings are available.
Plugins can be written in C, C++, Perl, Python and maybe more. The simplest ones can be written in almost any language.
The Gtk+ graphical library is used because of its licensing, portability and capabilities.
Yes, you can make a plug-in very easily from your software. This is one of the main goals.
Roughly said, you just need to use the specified data recieveing and sending back to the program. Then you can use your software routines as a plug-in inside the program. If you want, you can take more time programming it as a module so that everybody will be able to use your functions.
Yes you can do it in a form of simple plug-ins. But note, that with using some libraries (MFC) you may produce code that is not portable. This is not problem if you use code for you own, but you might be in a problem when you want to share your plug-in with someone.
Yes, virtually forever.
Even if a decision was made the current plug-in system is so bad that a new one must be designed, Gwyddion architecture would allow the old and new plug-in system to coexist, and the current would be kept for compatibility with existing plug-ins.
Note: The current plug-in system is actually considered ill-designed. While this does not mean the plug-in support will disappear soo, certainly it will not disappear before Gwyddion 3.0, it is not the preferred method to add routines in other programming languages any more and it cannot be expected to be further developed. Better alternatives can be language bindings, such as pygwy, or writing a small specialized C wrapper module specific for your language and problem domain, i.e. a kind of small specialized plug-in proxy that interfaces your routines the way you prefer.
Yes, under normal circumstances.
Modules are bound to Gwyddion more tightly than plug-ins, so a substantial change in it may break compatibility. Normally, all new versions are both source and binary level compatible with previous ones and modules linked against old versions work even with the newest one.
Gwyddion 2.0 is neither binary compatible (so modules have to be recompiled) not source compatible (so beside recompilation, some changes in module code are necessary) with 1.x versions. But all 2.x version will be backward compatible with other 2.x versions again.
Actually, there already was a one unplanned incompatible change, in version 1.3, where a serious bug present in previous versions could not be fixed while retaining compatibility. This should not happen again.
--as-needed and it broke. How to fix it?Contrary to the popular belief linking with --as-needed would
make Gwyddion slow and bloated, not more efficient. So the short answer is:
you fix it by not linking with --as-needed.
On platforms that support it, and that means at least all modern Unix
systems, the main application is linked with some “redundant” libraries
and modules are not linked with anything (unless they need a specific extra
library). Symbols in modules are resolved from the libraries the main
application was linked with. Obviously, --as-needed makes this
optimization impossible and every module then has to be linked with all
libraries it requires – this is less than the full set of libraries
but still much more than none. It takes more time to build (even 2×)
and install (almost 10×) and it makes the program start more slowly (module
loading time increases 2×).
But if you insist then pass --enable-library-bloat option
to configure and all the bloat will be linked in.
Easily. You only need to ensure two elementary things:
libstdc++. This should be obvious but since most C modules do not
need to link explicitly with anything it is easy to forget.In fact, Gwyddion contains a C++ module hdrimage although it is written in quite C-like C++ because it also interacts with lots of C libraries.