Discussion:
[Gwyddion-users] grain photo segmentation
Václav Šmilauer
2016-03-27 18:29:05 UTC
Permalink
Hi everybody,

I am new to Gwyddion and would like to try using it for grain size
analysis from industrial camera images. A typical image is like this:
Loading Image... (the diagonal separates two types of
material which has different reflectivity), and I would like to run (at
some point) unattended analysis of grain size distribution under
constant conditions (same lighting, similar material).

I was able to use some of the tools provided to improve the picture
(like Polynomial Background to make the lighting artefacts less visible)
but I am at loss with segmentation. The simple techniques (e.g.
watershed) are not suitable, since grains have different luminosity
(especially the glossy ones).

I will be grateful for hints, pointers or solutions. At this moment, the
analysis does not have to be unattended, setting parameters or light
hand-tuning is fine.

Cheers, Václav
David Nečas (Yeti)
2016-03-27 20:45:04 UTC
Permalink
Post by Václav Šmilauer
I am new to Gwyddion and would like to try using it for grain size
http://i.imgur.com/lwuOBeh.jpg (the diagonal separates two types of
material which has different reflectivity), and I would like to run (at
some point) unattended analysis of grain size distribution under
constant conditions (same lighting, similar material).
I was able to use some of the tools provided to improve the picture
(like Polynomial Background to make the lighting artefacts less visible)
but I am at loss with segmentation. The simple techniques (e.g.
watershed) are not suitable, since grains have different luminosity
(especially the glossy ones).
The image is a photograph, i.e. intensity does not correspond to height,
which is somewhat outside Gwyddion's focus.

Anyway, the first step would be a strong local equalisation filter. I
would use something like Presentation → Rank with a reasonable radius (25
or so). Then Extract Presentation and use the result as your data.

Then it depends... I do not even know what exactly I would mark there
as a human. Since the image is grainy you can use a smoothing filter
(in Filters tool), either linear Gaussian or morphological such as ACF
Closing.

In this moment threshold marking will give a more or less reasonable
result that can be improved by Fill Voids in the Mask Editor tool or
again some morphological operations with the mask (Grow with grain
merging prevention, ...).

You can get rid of too small and too large grains using Grains → Filter.
Grains → Distributions can export selected properties of all grains as a
table to some file.

Regards,

Yeti
Daniil Bratashov
2016-03-28 04:20:15 UTC
Permalink
On Sun, 27 Mar 2016 20:29:05 +0200
Post by Václav Šmilauer
Hi everybody,
I will be grateful for hints, pointers or solutions. At this moment,
the analysis does not have to be unattended, setting parameters or
light hand-tuning is fine.
Unfortunately Gwyddion still lacks working advanced segmentation
filters. This kind of images should be first filtered (equalizing
intensity over image, maybe stretch color scale to improve contrast,
apply smoothing filter to remove small single pixel local noise), than
right watershed or maxflow/mincut algorithm should work and probably
right combination of local height more than threshold intersection with
curvature less than threshold can also give decent result with smoothed
enough surface. The current watershed implementations do something
strange, watershed algorithm as it is described in documentation should
work after some tuning of parameters, but it has some problems in
implementation.

WBR, Daniil Bratashov.
Mark S. Bentley
2016-04-21 10:32:34 UTC
Permalink
Dear all,

I was playing with some data in the OME-TIFF format and tried to test
the sample data here:

http://www.openmicroscopy.org/site/support/ome-model/ome-tiff/data.html

in Gwyddion. The artificial dataset examples work fine, but if I try,
for example, to load either of the files contained in:

tubhiswt-2D.zip

I get an error:

"TIFF directory 0 is assigned to multiple conflicting ZTC coordinates"

The image loads fine into Fiji/ImageJ.

Does anyone know if this problem is in the Gwyddion OME-TIFF reader, or
elsewhere? Or are these data simply incompatible with Gwyddion?

Regards,

Mark
David Nečas (Yeti)
2016-04-21 12:10:18 UTC
Permalink
...but if I try,
tubhiswt-2D.zip
"TIFF directory 0 is assigned to multiple conflicting ZTC coordinates"
The error is a bit cryptic... It occurs in consequence of data being
split into two files.

The OME XMLs in the file (any of the two) specifies two images. So
Gwyddion tries to load one TIFF file with two images. But in fact there
are two separate files. This is probably valid; the multi-file stuff in
OME TIFF is complicated and not really supported in Gwyddion.
The image loads fine into Fiji/ImageJ.
AFAICT ImageJ does not load the two TIFFs as one two-channel image (or
image set), which is what a proper implementation should do. However,
it loads the single images which is certainly better than nothing. I
can probably fix Gwyddion to do the same.

Regards,

Yeti
Mark S. Bentley
2016-04-21 12:57:55 UTC
Permalink
Post by David Nečas (Yeti)
The error is a bit cryptic... It occurs in consequence of data being
split into two files.
Ahh, OK! Thanks for the explanation.
Post by David Nečas (Yeti)
AFAICT ImageJ does not load the two TIFFs as one two-channel image
(or image set), which is what a proper implementation should do.
However, it loads the single images which is certainly better than
nothing.
Yes, you're right.

If I end of generating OME-TIFF files it will as single files (with
multiple channels), which should load fine in any case. I was just
trying to understand the limitations.
Post by David Nečas (Yeti)
I can probably fix Gwyddion to do the same.
From my side it's not critical now that I understand what's going on,
though perhaps fixing it in that way, or providing a different error
message, would be useful.

Regards,

Mark
David Nečas (Yeti)
2016-04-21 15:47:59 UTC
Permalink
Post by Mark S. Bentley
Post by David Nečas (Yeti)
I can probably fix Gwyddion to do the same.
From my side it's not critical now that I understand what's going on,
though perhaps fixing it in that way, or providing a different error
message, would be useful.
I did a simple fix: The loader still cannot load data from mutliple
files, but it checks if the data UUID matches the file being loaded.
Non-matching data are ignored. So it no longer tries to find the second
channel in the same file and you can load the two images separately.

Regards,

Yeti

Loading...