[Gwyddion-users] force curve analysis-Oliver Pharr Method

[Collin Becker]

I searched through the modules and did not see anything, but I thought I
would ask anyway: does Gwyddion offer any force curve analysis, in
particular I would like analyze my data using the Oliver Pharr method.

Thanks,

Collin

[Petr Klapetek]

Dear Collin,

Oliver Pharr method is a bit far from conventional SPM data processing,
but our colleague
made a standalone Gwyddion module for that, so you should be able to
download it soon.
Now it is in testing phase, as far as I know.

Best regards,

Petr

Post by Collin Becker
I searched through the modules and did not see anything, but I thought
I would ask anyway: does Gwyddion offer any force curve analysis, in
particular I would like analyze my data using the Oliver Pharr method.
Thanks,
Collin
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

[Collin Becker]

Thanks for the info Petr. Do you know when it will be available?

Post by Petr Klapetek
Dear Collin,
Oliver Pharr method is a bit far from conventional SPM data processing,
but our colleague
made a standalone Gwyddion module for that, so you should be able to
download it soon.
Now it is in testing phase, as far as I know.
Best regards,
Petr
I searched through the modules and did not see anything, but I thought I
would ask anyway: does Gwyddion offer any force curve analysis, in
particular I would like analyze my data using the Oliver Pharr method.
Thanks,
Collin
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.http://p.sf.net/sfu/bds
_______________________________________________

[Petr Klapetek]

Anna is now on holidays, so we will let you know when she is back.

Regards,
Petr

Post by Collin Becker
Thanks for the info Petr. Do you know when it will be available?
Dear Collin,
Oliver Pharr method is a bit far from conventional SPM data
processing, but our colleague
made a standalone Gwyddion module for that, so you should be able
to download it soon.
Now it is in testing phase, as far as I know.
Best regards,
Petr

Post by Collin Becker
I searched through the modules and did not see anything, but I
thought I would ask anyway: does Gwyddion offer any force curve
analysis, in particular I would like analyze my data using the
Oliver Pharr method.
Thanks,
Collin
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

--
Collin Becker
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

[Mark S. Bentley]

Dear all,

I have a minor feature request - when using the 3D view I often want to
visualise 1:1:1 or with a given vertical exaggeration, for presentation
purposes. It would be great if the "Value scale" spinner had a linked
"Vertical exaggeration" spinner such that one could easily show the 3D
topography with a factor 1:1:n. Right now I click "Make 1:1" and get the
calculator out to multiply the given value scale - perhaps there's
already another way?

Regards,

Mark

[Collin Becker]

I agree that would be an excellent addition. It would also be good to be
able to set the maximum value on the scale bar so that when making multiple
images it is obvious that same scale is being used. Right now I do things
the way Mark does. Then when comparing images I often have to make my own
scale bars and photoshop them in so it is clear that the images all use the
same scale since the maximum values are not always the same.

--Collin

Post by Mark S. Bentley
Dear all,
I have a minor feature request - when using the 3D view I often want to
visualise 1:1:1 or with a given vertical exaggeration, for presentation
purposes. It would be great if the "Value scale" spinner had a linked
"Vertical exaggeration" spinner such that one could easily show the 3D
topography with a factor 1:1:n. Right now I click "Make 1:1" and get the
calculator out to multiply the given value scale - perhaps there's
already another way?
Regards,
Mark
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

[David Nečas (Yeti)]

Post by Collin Becker
I agree that would be an excellent addition. It would also be good to be
able to set the maximum value on the scale bar so that when making multiple
images it is obvious that same scale is being used. Right now I do things
the way Mark does. Then when comparing images I often have to make my own
scale bars and photoshop them in so it is clear that the images all use the
same scale since the maximum values are not always the same.

On this I have to say that 3D renderings are useful when you can change
the view interactively. As static images, they can't convey so much
information in the same space as false colour and contour maps. In
fact, a considerable part of the information is always lost completely
due to screening, the presentation of information with high spatial
frequency is poor and humans' perception of shape based on light and
shadows does not play well together with the usual colouring. Hence
such presentations of SPM data may look ‘cool’ but that is about their
only advantage. I'd like to discourage everyone from publishing SPM
data as 3D renderings. Some more enlightened journals recommend
presenting SPM data as 2D views and I hope more will join.

Regards,

Yeti

[David Nečas (Yeti)]

Post by Mark S. Bentley
I have a minor feature request - when using the 3D view I often want to
visualise 1:1:1 or with a given vertical exaggeration, for presentation
purposes. It would be great if the "Value scale" spinner had a linked
"Vertical exaggeration" spinner such that one could easily show the 3D
topography with a factor 1:1:n. Right now I click "Make 1:1" and get the
calculator out to multiply the given value scale - perhaps there's
already another way?

I will try to make it easier to set a specific real z scale. There will
be some limitations (as they are for 1:1 now) since the z value can
actually be something that differs from the lateral coordinates by many
orders of magnitude. But something like ‘Make this ratio’ button
instead of ‘Make 1:1’ could work...

Yeti

[David Nečas (Yeti)]

Post by Mark S. Bentley
I have a minor feature request - when using the 3D view I often want to
visualise 1:1:1 or with a given vertical exaggeration, for presentation
purposes. It would be great if the "Value scale" spinner had a linked
"Vertical exaggeration" spinner such that one could easily show the 3D
topography with a factor 1:1:n.

I implemented the possibility to set other physical scales than 1:1.
Please try tomorrow's or later development snapshot.

Regards,

Yeti

[Mark S. Bentley]

Hi Yeti,

Great - I just tried the latest snapshot, and it works perfectly - just
what I need! The only slightly odd thing, that may or may not be
related, is that now when I open the 3D view the default view is "upside
down".

Regards,

Mark

Post by David Nečas (Yeti)

Post by Mark S. Bentley
I have a minor feature request - when using the 3D view I often want to
visualise 1:1:1 or with a given vertical exaggeration, for presentation
purposes. It would be great if the "Value scale" spinner had a linked
"Vertical exaggeration" spinner such that one could easily show the 3D
topography with a factor 1:1:n.

I implemented the possibility to set other physical scales than 1:1.
Please try tomorrow's or later development snapshot.
Regards,
Yeti

[David Nečas (Yeti)]

Post by Mark S. Bentley
The only slightly odd thing, that may or may not be
related, is that now when I open the 3D view the default view is "upside
down".

Could you by coincidence press ‘Set as Default’ when the view was upside
down? Please try removing all lines starting "/app/3d/" from the
settings file (they should be all at the begining). If the problem
persists then there is really something wrong with the default view.

Regards,

Yeti

[Mark S. Bentley]

I zapped those lines and everything's fine - I guess I did click "Set as
Default" - sorry for the noise!

Cheers, Mark

Post by David Nečas (Yeti)

Post by Mark S. Bentley
The only slightly odd thing, that may or may not be
related, is that now when I open the 3D view the default view is "upside
down".

Could you by coincidence press ‘Set as Default’ when the view was upside
down? Please try removing all lines starting "/app/3d/" from the
settings file (they should be all at the begining). If the problem
persists then there is really something wrong with the default view.
Regards,
Yeti

[s***@bo.ismn.cnr.it]

Hi everybody,

I'm currently facing the following problem:

I'm used to obtain AFM images from MATRIX program. Files are .mtrx.

Sometimes, I don't know why not always, when I open them with Gwyddion,
the original size of the images is not kept the same. I do 6x6 um^2 images
and when I open them with Gwyddion I get x-y sizes in meters and z-scale
bar in Km.

I know I can use the option: Data Process --> Basic Operations -->
Dimensions and Units to change these measures but, after doing, I always
get 6 nm height islands (of my organic semiconductor) while I'm expecting
2.4 nm as always (this is a very well known information).

Do you think I forgot to change some internal settings of Gwyddion or the
6 nm height information is a true one?

When I changed the Dimensions and Units I put 6um in x and y axis and
change the unit in the z axis from km to nm. It should be right, shouldn't
it?


Thank you a lot for the help


Stefano

[David Nečas (Yeti)]

Post by s***@bo.ismn.cnr.it
I'm used to obtain AFM images from MATRIX program. Files are .mtrx.
Sometimes, I don't know why not always, when I open them with Gwyddion,
the original size of the images is not kept the same. I do 6x6 um^2 images
and when I open them with Gwyddion I get x-y sizes in meters and z-scale
bar in Km.

The file is misimported. Which is possible since the file format is
complicated...

Does ‘sometimes’ mean that the same file can be imported both correctly
and incorrectly? If it can this means an odd bug in Gwyddion. If not
please send some problematic file(s) to the omicronmatrix module author
(see Module Browser). Cc me, but I have only a couple of MATRIX files
for reference and little experience with them. So I could easily end up
breaking the import of other MATRIX files while fixing yours.

Post by s***@bo.ismn.cnr.it
Do you think I forgot to change some internal settings of Gwyddion or the
6 nm height information is a true one?

There are no internal settings. The MATRIX file support is just not
100%.

Post by s***@bo.ismn.cnr.it
When I changed the Dimensions and Units I put 6um in x and y axis and
change the unit in the z axis from km to nm. It should be right, shouldn't
it?

Yes, if you know the correct scales this is the way to fix them.

Regards,

Yeti

[Philipp Rahe]

Hi,

just to make sure: The Omicron MATRIX stores the image data in a .mtrx
file, but for opening them correctly, the _0001.mtrx session file has
also to be present in the same directory. The omicronmatrix plugin
automatically searches for this file and parses it, it contains all
dimensions.

If it is not found, a comment will be included in the Data Browser next
to each image as a warning, please check this.

If the _0001 file is not found, the module falls back to map the raw
data along the z axis - this might easily end up in km as the raw data
is the int ADC value or such.

If the _0001 file is present, no comment is in the Data Browser and the
problem persists, please send the file in question (and also the
corresponding _0001 file) to me, I'll have a look at it.

Cheers,
Philipp

Post by David Nečas (Yeti)

Post by s***@bo.ismn.cnr.it
I'm used to obtain AFM images from MATRIX program. Files are .mtrx.
Sometimes, I don't know why not always, when I open them with Gwyddion,
the original size of the images is not kept the same. I do 6x6 um^2 images
and when I open them with Gwyddion I get x-y sizes in meters and z-scale
bar in Km.

The file is misimported. Which is possible since the file format is
complicated...
Does ‘sometimes’ mean that the same file can be imported both correctly
and incorrectly? If it can this means an odd bug in Gwyddion. If not
please send some problematic file(s) to the omicronmatrix module author
(see Module Browser). Cc me, but I have only a couple of MATRIX files
for reference and little experience with them. So I could easily end up
breaking the import of other MATRIX files while fixing yours.

Post by s***@bo.ismn.cnr.it
Do you think I forgot to change some internal settings of Gwyddion or the
6 nm height information is a true one?

There are no internal settings. The MATRIX file support is just not
100%.

Post by s***@bo.ismn.cnr.it
When I changed the Dimensions and Units I put 6um in x and y axis and
change the unit in the z axis from km to nm. It should be right, shouldn't
it?

Yes, if you know the correct scales this is the way to fix them.
Regards,
Yeti
------------------------------------------------------------------------------
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

--
Dr. Philipp Rahe
Marie Curie Research Fellow
Group Prof. Philip Moriarty
School of Physics & Astronomy
The University of Nottingham

Physics, Room A7
University Park
Nottingham
NG7 2RD
UK

Phone: [phone]
E-Mail: ***@nottingham.ac.uk
Web: http://www.nottingham.ac.uk/physics

[s***@bo.ismn.cnr.it]

The problem was exactly the _0001.mtrx file!

As soon as I tried to open .mtrx file copying in my foder also the
_0001.mtrx file all the dimensions got back to the proper ones in
Gwyddion.


Thank you a lot for the reply!

Have a nice day


Stefano




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

Post by Philipp Rahe
Hi,
just to make sure: The Omicron MATRIX stores the image data in a .mtrx
file, but for opening them correctly, the _0001.mtrx session file has
also to be present in the same directory. The omicronmatrix plugin
automatically searches for this file and parses it, it contains all
dimensions.
If it is not found, a comment will be included in the Data Browser next
to each image as a warning, please check this.
If the _0001 file is not found, the module falls back to map the raw
data along the z axis - this might easily end up in km as the raw data
is the int ADC value or such.
If the _0001 file is present, no comment is in the Data Browser and the
problem persists, please send the file in question (and also the
corresponding _0001 file) to me, I'll have a look at it.
Cheers,
Philipp

Post by David Nečas (Yeti)

Post by s***@bo.ismn.cnr.it
I'm used to obtain AFM images from MATRIX program. Files are .mtrx.
Sometimes, I don't know why not always, when I open them with Gwyddion,
the original size of the images is not kept the same. I do 6x6 um^2 images
and when I open them with Gwyddion I get x-y sizes in meters and z-scale
bar in Km.

The file is misimported. Which is possible since the file format is
complicated...
Does ‘sometimes’ mean that the same file can be imported both correctly
and incorrectly? If it can this means an odd bug in Gwyddion. If not
please send some problematic file(s) to the omicronmatrix module author
(see Module Browser). Cc me, but I have only a couple of MATRIX files
for reference and little experience with them. So I could easily end up
breaking the import of other MATRIX files while fixing yours.

Post by s***@bo.ismn.cnr.it
Do you think I forgot to change some internal settings of Gwyddion or the
6 nm height information is a true one?

There are no internal settings. The MATRIX file support is just not
100%.

Post by s***@bo.ismn.cnr.it
When I changed the Dimensions and Units I put 6um in x and y axis and
change the unit in the z axis from km to nm. It should be right, shouldn't
it?

Yes, if you know the correct scales this is the way to fix them.
Regards,
Yeti
------------------------------------------------------------------------------
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

--
Dr. Philipp Rahe
Marie Curie Research Fellow
Group Prof. Philip Moriarty
School of Physics & Astronomy
The University of Nottingham
Physics, Room A7
University Park
Nottingham
NG7 2RD
UK
Phone: [phone]
Web: http://www.nottingham.ac.uk/physics
------------------------------------------------------------------------------
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

--
Stefano Chiodini, PhD Student
Istituto per lo Studio dei Materiali Nanostrutturati (ISMN)
Consiglio Nazionale delle Ricerche (CNR)
Via Piero Gobetti 101
I-40129 Bologna
I T A L Y
Phone:++39-051-639-9188
Cell: ++39-3393142341
***@bo.ismn.cnr.it
www.bo.ismn.cnr.it

[Philipp Rahe]

Post by s***@bo.ismn.cnr.it
The problem was exactly the _0001.mtrx file!
As soon as I tried to open .mtrx file copying in my foder also the
_0001.mtrx file all the dimensions got back to the proper ones in
Gwyddion.

Great, thanks for your response.

Can I ask you to just doublecheck if there is a warning on your system
in the Data Browser that the _0001.mtrx file is missing when it's
missing? Otherwise I have to check where this message has gone.

@Yeti: Any suggestions to show the warning more prominent? On
alternative would be to not load the file at all, but I was trying to
avoid this - in exactly the case the _0001 file was deleted, is
unreadable or such.

Thanks, have a great day,
Philipp

[s***@bo.ismn.cnr.it]

When the _0001.mtrx is missing, in the Gwyddion Data Browser, I don't have
any warning. Nor elsewhere.

Stefano

Post by Philipp Rahe
Great, thanks for your response.
Can I ask you to just doublecheck if there is a warning on your system
in the Data Browser that the _0001.mtrx file is missing when it's
missing? Otherwise I have to check where this message has gone.
@Yeti: Any suggestions to show the warning more prominent? On
alternative would be to not load the file at all, but I was trying to
avoid this - in exactly the case the _0001 file was deleted, is
unreadable or such.
Thanks, have a great day,
Philipp
------------------------------------------------------------------------------
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

--
Stefano Chiodini, PhD Student
Istituto per lo Studio dei Materiali Nanostrutturati (ISMN)
Consiglio Nazionale delle Ricerche (CNR)
Via Piero Gobetti 101
I-40129 Bologna
I T A L Y
Phone:++39-051-639-9188
Cell: ++39-3393142341
***@bo.ismn.cnr.it
www.bo.ismn.cnr.it

[David Nečas (Yeti)]

Post by Philipp Rahe
@Yeti: Any suggestions to show the warning more prominent? On
alternative would be to not load the file at all, but I was trying to
avoid this - in exactly the case the _0001 file was deleted, is
unreadable or such.

I'm not sure if I understand the situation completely. But Gwyddion has
no mechanism (and is unlikely to have in 2.x) for reporting partial
data loading failures. So we go with one of three options:

- Consider the problems ignorable and just emit a g_warning() that
ends up in gwyddion.log.

BTW did you really mean errors should be visible in Data Browser? I
cannot see any code doing that.

- Consider the problem serious and fail.

- Ask the user for input. This is normally done for raw-data-like
import where the required information is unavailable in principle, but
the situation of standalone data file with lost ‘header’ is not so
different. For instance in the case of pixmap images we know some
information (pixel dimensions) and only need to complement it. So if
you want to go into this direction, I'm not against.

Note I did some rather extensive cleanup (i.e. many lines of code
touched) of omicronmatrix.c this spring, namely r15846 and r15865 when I
noticed some prevasive memory leaks and was adding support for logging.
I hope I didn't break anything.

Regards,

Yeti

[Philipp Rahe]

Post by David Nečas (Yeti)
BTW did you really mean errors should be visible in Data Browser? I
cannot see any code doing that.

What I meant is the string " (unscaled)" added to the data label in the
Data Browser. I just checked, this is still present (but propably easily
overlooked)

Post by David Nečas (Yeti)
- Ask the user for input. This is normally done for raw-data-like
import where the required information is unavailable in principle, but
the situation of standalone data file with lost ‘header’ is not so
different. For instance in the case of pixmap images we know some
information (pixel dimensions) and only need to complement it. So if
you want to go into this direction, I'm not against.

The situation is pretty much identical to a lost 'header'. The module
guesses the pixel dimensions from the data size, but that's pretty much
it without the session file. I'll look into the pixmap module and see if
I can implement something similiar.
The case of the missing session file is, hopefully, rare.

Post by David Nečas (Yeti)
Note I did some rather extensive cleanup (i.e. many lines of code
touched) of omicronmatrix.c this spring, namely r15846 and r15865 when I
noticed some prevasive memory leaks and was adding support for logging.
I hope I didn't break anything.

That's definetely appreciated.
I'll look into it as soon as I've sorted out why my toolchain is not
working.


Regards,

Philipp

[Mark S. Bentley]

Dear all,

I make extensive use of meta-data in producing .GWY files, and add the
data in a specific order. However the meta-data browser shows data
ordered alphabetically by name. This can be frustrating since related
data that I have added in sequence (e.g. x_orig, y_orig) are then spread
throughout the list and hard to read.

For me it would be more useful if the data would be displayed ordered as
in the GWY file, perhaps with the option to sort by name/value by
clicking the header, for example. If I check the files with gwydump, the
metadata are indeed ordered there so I assume it's purely a display issue.

Thanks for your time!

Regards,

Mark

[David Nečas (Yeti)]

Post by Mark S. Bentley
I make extensive use of meta-data in producing .GWY files, and add the
data in a specific order.

Metadata are represented by a dictionary/hash table/unordered map/...,
whatever you call it. The entries are not ordered. So the order in
which you store the items to a .GWY file does not matter and is already
lost during the loading of the file when the unordered dictionary is
constructed.

The same applies for instance to the contents of main GwyContainer.
Generally, the order in which named components of anything are stored in
a .GWY file is arbitrary (as stated in the specs).

Post by Mark S. Bentley
However the meta-data browser shows data
ordered alphabetically by name.

Yes, this is to present them in a stable order (as opposed to completely
randomly which would people hardly appreciate). If the metadata have a
hierarchical structure, import modules often flatten this hierarchy
using prefixes and "::" separators, leading to names such as "General
Info::Z Amplitude"...

Post by Mark S. Bentley
This can be frustrating since related
data that I have added in sequence (e.g. x_orig, y_orig) are then spread
throughout the list and hard to read.

...which may be a reasonable option also in your case if you have lots
of metadata to get the related bits closer in an alphabetical listing.

Post by Mark S. Bentley
For me it would be more useful if the data would be displayed ordered as
in the GWY file, perhaps with the option to sort by name/value by
clicking the header, for example.

So, unfortunately, this is not possible.

Regards,

Yeti

[Mark S. Bentley]

Thanks for your response and explanation Yeti - I'll either live with
the order, or rename my properties with prefixes or similar to control
the order.

[Mark S. Bentley]

Dear all,

I have some pygwy scripts for that work very well on my desktop (mainly
creating gwy files). I want to move this operation to a headless linux
server, but python crashes on import with the error:

Gtk-WARNING **: cannot open display:

Does anyone know if I can force Gwyddion to work in this environment? At
the moment I'm only creating files, but later I would also like to
perform some batch operations on the images (plane level etc.). Can I
use off-screen rendering?

Any hints gratefully accepted!

Thanks, Mark

[Sameer Grover]

You can create a virtual X server using Xvfb to stop python complaining. I
haven't tried it out myself but it should work. Maybe someone else can
suggest a better solution.

http://en.wikipedia.org/wiki/Xvfb

Sameer

Post by Mark S. Bentley
Dear all,
I have some pygwy scripts for that work very well on my desktop (mainly
creating gwy files). I want to move this operation to a headless linux
Does anyone know if I can force Gwyddion to work in this environment? At
the moment I'm only creating files, but later I would also like to
perform some batch operations on the images (plane level etc.). Can I
use off-screen rendering?
Any hints gratefully accepted!
Thanks, Mark
------------------------------------------------------------------------------
_______________________________________________
Gwyddion-users mailing list
https://lists.sourceforge.net/lists/listinfo/gwyddion-users

[Mark S. Bentley]

<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
OK, I solved it using
<meta http-equiv="content-type" content="text/html; charset=utf-8">
xvfb to run a virtual X server - seems to work for now at least!<br>
<br>
Thanks, Mark<br>
<br>
<div class="moz-cite-prefix">On 18/08/14 19:13, Mark S. Bentley
wrote:<br>
</div>
<blockquote cite="mid:***@lunartech.org" type="cite">Dear
all,
<br>
<br>
I have some pygwy scripts for that work very well on my desktop
(mainly creating gwy files). I want to move this operation to a
headless linux server, but python crashes on import with the
error:
<br>
<br>
Gtk-WARNING **: cannot open display:
<br>
<br>
Does anyone know if I can force Gwyddion to work in this
environment? At the moment I'm only creating files, but later I
would also like to perform some batch operations on the images
(plane level etc.). Can I use off-screen rendering?
<br>
<br>
Any hints gratefully accepted!
<br>
<br>
Thanks, Mark
<br>
<br>
</blockquote>
<br>
</body>
</html>