[GRASS-user] how to tweak the parameters to speed up i.segment

GRASS GRASS user
1

Hi,

I have not clear understanding how the parameters meansize, iterations, memory, etc. in i.segment could be tweaked to speed up the running time. In which direction should they be tuned and what are the drawbacks? Is there some trick? :wink:

Thank you in advance

ā€“

Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.

2

On 26/09/14 11:56, Margherita Di Leo wrote:

Hi,

I have not clear understanding how the parameters

[...]

in i.segment could be tweaked to speed up the running time.

meansize

I suppose you mean minsize ?

This does not speed up running time. It just adds a last iteration that
ignores the threshold parameter and merges segments that are smaller
than minsize to their closest (in variable space) neighbor.

iterations,

If you set this very low, this can "speed up" the running time, but it
will then merge less segments, even though some might still have
neighbors at a distance less than threshold. So, I wouldn't use it by
default for speeding up the process. I don't think I've actually ever
reached the max iterations...

memory,

This is probably the parameter you most want to play with. If you have
lots of memory on the machine you can seriously increase this and this
should normally speed up the process.

In which direction should they be tuned and what are the drawbacks?
Is there some trick? :wink:

You can try following the suggestion on the man page and go though some iteration with increasing threshold parameters, using the output of the preceding run as seeds for the next run.

More generally, segmentation is a time-consuming process. i.segment is already much faster than the proprietary market leader....

You could possible speed up things if you have several CPUs by cutting up your image in several regions and processing them in parallel. Then you would probably want to patch the results and run i.segment again with this result as seed map. Haven't tried this, yet, though, and so I don't know what effect this will have on segmentation results. You might have to do some r.mapcalc'ing before patching to ensure that all segments have unique ids...

Moritz

Thank you in advance

-- Best regards,

Dr. Margherita DI LEO Scientific / technical project officer

European Commission - DG JRC Institute for Environment and
Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP
261 Tel. +39 0332 78 3600 margherita.di-leo@jrc.ec.europa.eu
<mailto:margherita.di-leo@jrc.ec.europa.eu>

Disclaimer: The views expressed are purely those of the writer and
may not in any circumstance be regarded as stating an official
position of the European Commission.

_______________________________________________ grass-user mailing
list grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

Moritz,

Ā·Ā·Ā·

On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 26/09/14 11:56, Margherita Di Leo wrote:

meansize

I suppose you mean minsize ?

Oopsā€¦ yep

[ā€¦]

You could possible speed up things if you have several CPUs by cutting up your image in several regions and processing them in parallel. Then you would probably want to patch the results and run i.segment again with this result as seed map. Havenā€™t tried this, yet, though, and so I donā€™t know what effect this will have on segmentation results. You might have to do some r.mapcalcā€™ing before patching to ensure that all segments have unique idsā€¦

Thank you very much for your precious hints. Iā€™ll go this direction.

cheers,
madi

ā€“

Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.

4

Hi,

at the moment I guess the only way to speed up it is exactly what
suggested by Moritz:

On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

You could possible speed up things if you have several CPUs by cutting up
your image in several regions and processing them in parallel. Then you
would probably want to patch the results and run i.segment again with this
result as seed map. Haven't tried this, yet, though, and so I don't know
what effect this will have on segmentation results.

Following this approach I've implement: i.segment.hierarchical
(grass-addons). I've used this module to segment an image (RGB) of 24
x 48 kpixels on my laptop in less than 12 hours (if I remeber
correctly). Still I think we can reach greater improvement working at
C level but I didn't have time to work on it I have just some ideas,
no code.

All the best

Pietro

5

Ciao Pietro!

Ā·Ā·Ā·

On Fri, Sep 26, 2014 at 2:49 PM, Pietro <peter.zamb@gmail.com> wrote:

Following this approach Iā€™ve implement: i.segment.hierarchical
(grass-addons). Iā€™ve used this module to segment an image (RGB) of 24
x 48 kpixels on my laptop in less than 12 hours (if I remeber
correctly). Still I think we can reach greater improvement working at
C level but I didnā€™t have time to work on it I have just some ideas,
no code.

kudos! :smiley:
I have some troubles installing it though:

g.extension i.segment.hierarchical
Fetching <i.segment.hierarchical> from GRASS-Addons SVN repository (be
patient)ā€¦
Compilingā€¦
Makefile:17: warning: overriding commands for target /tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical' /space/gis/grass_trunk/grass-7.1.svn/include/Make/ScriptRules.make:19: warning: ignoring old commands for target /tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchicalā€™
Traceback (most recent call last):
File ā€œ/tmp/tmpc7e9Oc/i.segment.hierarchical/scripts/i.segment.hierarchicalā€, line 158, in
from isegpatch import rpatch_map
ImportError: No module named isegpatch
make: *** [i.segment.hierarchical.tmp.html] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

?

Thanks!
madi

ā€“

Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.

6

On Fri, Sep 26, 2014 at 3:18 PM, Margherita Di Leo <diregola@gmail.com> wrote:

I have some troubles installing it though:

g.extension i.segment.hierarchical

Fetching <i.segment.hierarchical> from GRASS-Addons SVN repository (be
patient)...
Compiling...
Makefile:17: warning: overriding commands for target
`/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical'
/space/gis/grass_trunk/grass-7.1.svn/include/Make/ScriptRules.make:19:
warning: ignoring old commands for target
`/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical'
Traceback (most recent call last):
  File
"/tmp/tmpc7e9Oc/i.segment.hierarchical/scripts/i.segment.hierarchical", line
158, in <module>
    from isegpatch import rpatch_map
ImportError: No module named isegpatch
make: *** [i.segment.hierarchical.tmp.html] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

It Is not coping the file isegpatch in the right directory, please try
to copy the directory in grass71/script and run make, in this way it
is working without problems on my computer.

I guess that g.external doesn't like python module libraries or the
makefile is not written correctly to work with g.external.

Let me know.

Pietro

7

On Fri, Sep 26, 2014 at 7:36 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

More generally, segmentation is a time-consuming process. i.segment is
already much faster than the proprietary market leader....

Oh, this is interesting. I'm not sure if you already did something like it
but if not, can you please try to do some benchmarks and post them
somewhere? It think it would be really good to actually see the numbers.

8

On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 26/09/14 11:56, Margherita Di Leo wrote:

Hi,

I have not clear understanding how the parameters

[...]

in i.segment could be tweaked to speed up the running time.

memory,

This is probably the parameter you most want to play with. If you have
lots of memory on the machine you can seriously increase this and this
should normally speed up the process.

threshold is probably even more important than memory, because a
larger threshold value means longer running time. If you are not sure
which threshold value gives you the desired results (depends on your
data and your objective), you should start with a low value, e.g.
0.01, and then perform hierarchical segmentation by using the output
of the last run as seeds for the next run. Suggested steps are 0.01,
0.05, 0.1, 0.2. You could also test one or several small regions
within your study area before performing the real segmentation on the
full study area.

More generally, segmentation is a time-consuming process. i.segment is
already much faster than the proprietary market leader....

To be fair, this market leader offers some time consuming features
that are not implemented in i.segment.

Markus M