[GRASS-user] i.segment.stats memory usage error

GRASS GRASS user
1

Hello,

I’m trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive 32bit operating system.

Prior to using this tool I have successfully created my segmented map using i.segment.

When I try to execute the following command:

i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1
rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
raster_statistics=min,max,mean,stddev,variance,sum
csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats
separator=comma

I get this error:

Calculating geometry statistics
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
/tmp/tmpgzUtnA/r.object.geometry/main.c:129

Having read into this error, it seems to be an issue with having a 32bit operating system. I’m not in a position to use a 64bit machine, and given that i.segment can work with small memory limits, I wondered if i.segment.stats could as well. I’m not requesting the vector map be created to also save on processing strain.

Any help would be much appreciated.

Thanks

James

2

Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <james.philip.duffy@gmail.com> a écrit :

Hello,

I'm trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive
32bit
operating system.

Prior to using this tool I have successfully created my segmented map
using
i.segment.

When I try to execute the following command:

i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1 \
raster_statistics=min,max,mean,stddev,variance,sum \
csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
separator=comma

I get this error:

Calculating geometry statistics
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
      /tmp/tmpgzUtnA/r.object.geometry/main.c:129

This is coming from r.object.geometry.

What are your region settings (g.region -p) ? How many segments do you have ?

Try running I.segment.stats without requesting form statistics. And try running r.object.geometry directly.

Moritz

3

On 27 October 2016 at 11:08, Moritz Lennert <mlennert@club.worldonline.be> wrote:

Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <james.philip.duffy@gmail.com> a écrit :

Hello,

I’m trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive
32bit
operating system.

Prior to using this tool I have successfully created my segmented map
using
i.segment.

When I try to execute the following command:

i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1
rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
raster_statistics=min,max,mean,stddev,variance,sum
csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats
separator=comma

I get this error:

Calculating geometry statistics
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
/tmp/tmpgzUtnA/r.object.geometry/main.c:129

This is coming from r.object.geometry.

What are your region settings (g.region -p) ? How many segments do you have ?

GRASS 7.0.4 (GarronPill):~ > g.region -p
projection: 99 (OSGB 1936 / British National Grid)
zone: 0
datum: osgb36
ellipsoid: airy
north: 208007.00931776
south: 207952.59780698
west: 200993.90853302
east: 201097.28911076
nsres: 0.00430914
ewres: 0.00430914
rows: 12627
cols: 23991
cells: 302934357

Try running I.segment.stats without requesting form statistics.

Running:

i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1
csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats
separator=comma

Gives:

Calculating geometry statistics
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
/tmp/tmpgzUtnA/r.object.geometry/main.c:129

And try running r.object.geometry directly.

Running:

r.object.geometry --overwrite --verbose input=gp_seg_optimum@gp1
output=/home/jpd205/Wales_GRASS/GarronPill/gp_test separator=comma

Gives:

Current region rows: 12627, cols: 23991
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
/tmp/tmpgzUtnA/r.object.geometry/main.c:129

Moritz

Thanks for your reply.

James

4

Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 11:08, Moritz Lennert
<mlennert@club.worldonline.be>
wrote:

Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
james.philip.duffy@gmail.com> a écrit :
>Hello,
>
>I'm trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive
>32bit
>operating system.
>
>Prior to using this tool I have successfully created my segmented

map

>using
>i.segment.
>
>When I try to execute the following command:
>
>i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
>rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1

\

>raster_statistics=min,max,mean,stddev,variance,sum \
>csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
>separator=comma
>
>I get this error:
>
>Calculating geometry statistics
>ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
> /tmp/tmpgzUtnA/r.object.geometry/main.c:129

This is coming from r.object.geometry.

What are your region settings (g.region -p) ? How many segments do

you

have ?

GRASS 7.0.4 (GarronPill):~ > g.region -p
projection: 99 (OSGB 1936 / British National Grid)
zone: 0
datum: osgb36
ellipsoid: airy
north: 208007.00931776
south: 207952.59780698
west: 200993.90853302
east: 201097.28911076
nsres: 0.00430914
ewres: 0.00430914
rows: 12627
cols: 23991
cells: 302934357

Are you sure 4mm is correct for the resolution ?

What does r.info on

Try running I.segment.stats without requesting form statistics.

Running:

i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
separator=comma

Default is to do form statistics, so the above line also does. I have to admit that I don't know what happens when you give an empty parameter such as

area_measures= or area_measures=""

What does r.info gp_seg_optimum give you ?

Moritz

Gives:

Calculating geometry statistics
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
      /tmp/tmpgzUtnA/r.object.geometry/main.c:129

And try running r.object.geometry directly.

Running:

r.object.geometry --overwrite --verbose input=gp_seg_optimum@gp1 \
output=/home/jpd205/Wales_GRASS/GarronPill/gp_test separator=comma

Gives:

Current region rows: 12627, cols: 23991
ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
      /tmp/tmpgzUtnA/r.object.geometry/main.c:129

Moritz

Thanks for your reply.

James

5

On 27 October 2016 at 11:45, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy <
james.philip.duffy@gmail.com> a écrit :
>On 27 October 2016 at 11:08, Moritz Lennert
><mlennert@club.worldonline.be>
>wrote:
>
>>
>>
>> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
>> james.philip.duffy@gmail.com> a écrit :
>> >Hello,
>> >
>> >I'm trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive
>> >32bit
>> >operating system.
>> >
>> >Prior to using this tool I have successfully created my segmented
>map
>> >using
>> >i.segment.
>> >
>> >When I try to execute the following command:
>> >
>> >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
>> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
>\
>> >raster_statistics=min,max,mean,stddev,variance,sum \
>> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
>> >separator=comma
>> >
>> >I get this error:
>> >
>> >Calculating geometry statistics
>> >ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
>> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
>>
>> This is coming from r.object.geometry.
>>
>> What are your region settings (g.region -p) ? How many segments do
>you
>> have ?
>>
>
>GRASS 7.0.4 (GarronPill):~ > g.region -p
>projection: 99 (OSGB 1936 / British National Grid)
>zone: 0
>datum: osgb36
>ellipsoid: airy
>north: 208007.00931776
>south: 207952.59780698
>west: 200993.90853302
>east: 201097.28911076
>nsres: 0.00430914
>ewres: 0.00430914
>rows: 12627
>cols: 23991
>cells: 302934357

Are you sure 4mm is correct for the resolution ?

Yes. It's high resolution imagery from a drone.

What does r.info on

>
>
>>
>> Try running I.segment.stats without requesting form statistics.
>
>
>Running:
>
>i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
>csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
>separator=comma

Default is to do form statistics, so the above line also does. I have to
admit that I don't know what happens when you give an empty parameter such
as

area_measures= or area_measures=""

What does r.info gp_seg_optimum give you ?

+----------------------------------------------------------------------------+
| Map: gp_seg_optimum Date: Thu Oct 27 06:45:57
2016 |
| Mapset: gp1 Login of Creator:
jpd205 |
| Location:
GarronPill |
| DataBase:
/home/jpd205/Wales_GRASS |
| Title: ( gp_seg_optimum
) |
| Timestamp:
none |
|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories:
0 |
| Data Type:
CELL |
| Rows:
12627 |
| Columns:
23991 |
| Total Cells:
302934357 |
| Projection: OSGB 1936 / British National
Grid |
| N: 208007.00931776 S: 207952.59780698 Res:
0.00430914 |
| E: 201097.28911076 W: 200993.90853302 Res:
0.00430914 |
| Range of data: min = 35 max =
133556294 |
|
|
| Data
Description: |
| generated by
i.segment |
|
|
|
Comments: |
| i.segment --overwrite --verbose -d group="gp_combo@gp1"
output="gp_s\ |
| eg_optimum" threshold=0.1 method="region_growing"
similarity="euclid\ |
| ean" minsize=10 memory=3000
iterations=20 |
|
|
+----------------------------------------------------------------------------+

Moritz

>
>Gives:
>
>Calculating geometry statistics
>ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
> /tmp/tmpgzUtnA/r.object.geometry/main.c:129
>
>And try running r.object.geometry directly.
>>
>
>Running:
>
>r.object.geometry --overwrite --verbose input=gp_seg_optimum@gp1 \
>output=/home/jpd205/Wales_GRASS/GarronPill/gp_test separator=comma
>
>Gives:
>
>Current region rows: 12627, cols: 23991
>ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
> /tmp/tmpgzUtnA/r.object.geometry/main.c:129
>
>
>>
>> Moritz
>>
>>
>Thanks for your reply.
>
>James

6

On 27/10/16 12:51, James Duffy wrote:

On 27 October 2016 at 11:45, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
    <james.philip.duffy@gmail.com <mailto:james.philip.duffy@gmail.com>>
    a écrit :
    >On 27 October 2016 at 11:08, Moritz Lennert
    ><mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
    >wrote:
    >
    >>
    >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
    >> james.philip.duffy@gmail.com
    <mailto:james.philip.duffy@gmail.com>> a écrit :
    >> >Hello,
    >> >
    >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in the osgeolive
    >> >32bit
    >> >operating system.
    >> >
    >> >Prior to using this tool I have successfully created my segmented
    >map
    >> >using
    >> >i.segment.
    >> >
    >> >When I try to execute the following command:
    >> >
    >> >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
    >> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
    >\
    >> >raster_statistics=min,max,mean,stddev,variance,sum \
    >> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
    >> >separator=comma
    >> >
    >> >I get this error:
    >> >
    >> >Calculating geometry statistics
    >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
    >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
    >>
    >> This is coming from r.object.geometry.
    >>
    >> What are your region settings (g.region -p) ? How many segments do
    >you
    >> have ?
    >>
    >
    >GRASS 7.0.4 (GarronPill):~ > g.region -p
    >projection: 99 (OSGB 1936 / British National Grid)
    >zone: 0
    >datum: osgb36
    >ellipsoid: airy
    >north: 208007.00931776
    >south: 207952.59780698
    >west: 200993.90853302
    >east: 201097.28911076
    >nsres: 0.00430914
    >ewres: 0.00430914
    >rows: 12627
    >cols: 23991
    >cells: 302934357

    Are you sure 4mm is correct for the resolution ?

Yes. It's high resolution imagery from a drone.

    What does r.info <http://r.info> on

    >
    >>
    >> Try running I.segment.stats without requesting form statistics.
    >
    >Running:
    >
    >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
    >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
    >separator=comma

    Default is to do form statistics, so the above line also does. I
    have to admit that I don't know what happens when you give an empty
    parameter such as

    area_measures= or area_measures=""

    What does r.info <http://r.info> gp_seg_optimum give you ?

+----------------------------------------------------------------------------+
| Map: gp_seg_optimum Date: Thu Oct 27 06:45:57
2016 |
| Mapset: gp1 Login of Creator:
jpd205 |
| Location:
GarronPill |
| DataBase:
/home/jpd205/Wales_GRASS |
| Title: ( gp_seg_optimum
) |
| Timestamp:
none |
|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories:
0 |
| Data Type:
CELL |
| Rows:
12627 |
| Columns:
23991 |
| Total Cells:
302934357 |
| Projection: OSGB 1936 / British National
Grid |
| N: 208007.00931776 S: 207952.59780698 Res:
0.00430914 |
| E: 201097.28911076 W: 200993.90853302 Res:
0.00430914 |
| Range of data: min = 35 max =
133556294 |
|

Ok, I think I see at least part of the problem: in GRASS 7.0 i.segment numbers segments non sequentially, i.e. whenever a new segment is created out of the merger of two existing segments, a new id is assigned. In GRASS trunk (the development version) i.segment is rewritten to, at the end, number all segments sequentially from 1 to the number of segments.

r.object.geometry allocates memory according to the new system. As it says in the code:

     /* REMARK: The following is only true if object ids are continuously numbered */
     n_objects = max - min + 1;
     obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));

So, one solution would be to use the development version of GRASS. Another would be to run r.clump on the result of the segmentation in order to renumber the segments before running it through i.segment.stats.

A third option, potentially a bit faster than the second, would be to write a little script which gets all category values from the segment map (using r.category), and reassigns sequential category values to those using r.reclass. I.e. something like this:

r.category segment_map | awk 'BEGIN{cat=1} {printf"%d=%d\n", $1, cat; cat++}' | r.reclass segment_map out=sequential_segment_map rules=-

Moritz

7

On 27 October 2016 at 13:53, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

On 27/10/16 12:51, James Duffy wrote:

On 27 October 2016 at 11:45, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
    <james.philip.duffy@gmail.com <mailto:james.philip.duffy@gmail.com>>
    a écrit :
    >On 27 October 2016 at 11:08, Moritz Lennert
    ><mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
    >wrote:
    >
    >>
    >>
    >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
    >> james.philip.duffy@gmail.com
    <mailto:james.philip.duffy@gmail.com>> a écrit :

    >> >Hello,
    >> >
    >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in the
osgeolive
    >> >32bit
    >> >operating system.
    >> >
    >> >Prior to using this tool I have successfully created my segmented
    >map
    >> >using
    >> >i.segment.
    >> >
    >> >When I try to execute the following command:
    >> >
    >> >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
    >> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ort
ho.4@gp1
    >\
    >> >raster_statistics=min,max,mean,stddev,variance,sum \
    >> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
    >> >separator=comma
    >> >
    >> >I get this error:
    >> >
    >> >Calculating geometry statistics
    >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at
    >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
    >>
    >> This is coming from r.object.geometry.
    >>
    >> What are your region settings (g.region -p) ? How many segments do
    >you
    >> have ?
    >>
    >
    >GRASS 7.0.4 (GarronPill):~ > g.region -p
    >projection: 99 (OSGB 1936 / British National Grid)
    >zone: 0
    >datum: osgb36
    >ellipsoid: airy
    >north: 208007.00931776
    >south: 207952.59780698
    >west: 200993.90853302
    >east: 201097.28911076
    >nsres: 0.00430914
    >ewres: 0.00430914
    >rows: 12627
    >cols: 23991
    >cells: 302934357

    Are you sure 4mm is correct for the resolution ?

Yes. It's high resolution imagery from a drone.

    What does r.info <http://r.info> on

    >
    >
    >>
    >> Try running I.segment.stats without requesting form statistics.
    >
    >
    >Running:
    >
    >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
    >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
    >separator=comma

    Default is to do form statistics, so the above line also does. I
    have to admit that I don't know what happens when you give an empty
    parameter such as

    area_measures= or area_measures=""

    What does r.info <http://r.info> gp_seg_optimum give you ?

+-----------------------------------------------------------
-----------------+
| Map: gp_seg_optimum Date: Thu Oct 27 06:45:57
2016 |
| Mapset: gp1 Login of Creator:
jpd205 |
| Location:
GarronPill |
| DataBase:
/home/jpd205/Wales_GRASS |
| Title: ( gp_seg_optimum
) |
| Timestamp:
none |
|----------------------------------------------------------
------------------|
|
|
| Type of Map: raster Number of Categories:
0 |
| Data Type:
CELL |
| Rows:
12627 |
| Columns:
23991 |
| Total Cells:
302934357 |
| Projection: OSGB 1936 / British National
Grid |
| N: 208007.00931776 S: 207952.59780698 Res:
0.00430914 |
| E: 201097.28911076 W: 200993.90853302 Res:
0.00430914 |
| Range of data: min = 35 max =
133556294 |
|

Ok, I think I see at least part of the problem: in GRASS 7.0 i.segment
numbers segments non sequentially, i.e. whenever a new segment is created
out of the merger of two existing segments, a new id is assigned. In GRASS
trunk (the development version) i.segment is rewritten to, at the end,
number all segments sequentially from 1 to the number of segments.

r.object.geometry allocates memory according to the new system. As it says
in the code:

    /* REMARK: The following is only true if object ids are continuously
numbered */
    n_objects = max - min + 1;
    obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));

So, one solution would be to use the development version of GRASS.

Another would be to run r.clump on the result of the segmentation in order
to renumber the segments before running it through i.segment.stats.

This option seemed the most straightforward given my current setup. I ran
r.clump with diagnoal enabled, and the output looked good. It only took
2mins to run.

I then proceeded with the original i.segment.stats command and got the
following:

Calculating geometry statistics
Calculating statistics for raster gp_ortho.1@gp1
ERROR: G_realloc: unable to allocate 572000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

It looks like the tool got further, but is still getting stuck on
something...

A third option, potentially a bit faster than the second, would be to
write a little script which gets all category values from the segment map
(using r.category), and reassigns sequential category values to those using
r.reclass. I.e. something like this:

r.category segment_map | awk 'BEGIN{cat=1} {printf"%d=%d\n", $1, cat;
cat++}' | r.reclass segment_map out=sequential_segment_map rules=-

Moritz

James

8

On 27/10/16 15:38, James Duffy wrote:

On 27 October 2016 at 13:53, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    On 27/10/16 12:51, James Duffy wrote:

        On 27 October 2016 at 11:45, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

            Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
            <james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
        <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>>
            a écrit :
            >On 27 October 2016 at 11:08, Moritz Lennert
            ><mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>>
            >wrote:
            >
            >>
            >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
            >> james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
            <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>> a écrit :

            >> >Hello,
            >> >
            >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in
        the osgeolive
            >> >32bit
            >> >operating system.
            >> >
            >> >Prior to using this tool I have successfully created my
        segmented
            >map
            >> >using
            >> >i.segment.
            >> >
            >> >When I try to execute the following command:
            >> >
            >> >i.segment.stats --overwrite --verbose
        map=gp_seg_optimum@gp1 \
            >>
        >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
            >\
            >> >raster_statistics=min,max,mean,stddev,variance,sum \
            >> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >> >separator=comma
            >> >
            >> >I get this error:
            >> >
            >> >Calculating geometry statistics
            >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of
        memory at
            >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
            >>
            >> This is coming from r.object.geometry.
            >>
            >> What are your region settings (g.region -p) ? How many
        segments do
            >you
            >> have ?
            >>
            >
            >GRASS 7.0.4 (GarronPill):~ > g.region -p
            >projection: 99 (OSGB 1936 / British National Grid)
            >zone: 0
            >datum: osgb36
            >ellipsoid: airy
            >north: 208007.00931776
            >south: 207952.59780698
            >west: 200993.90853302
            >east: 201097.28911076
            >nsres: 0.00430914
            >ewres: 0.00430914
            >rows: 12627
            >cols: 23991
            >cells: 302934357

            Are you sure 4mm is correct for the resolution ?

        Yes. It's high resolution imagery from a drone.

            What does r.info <http://r.info> <http://r.info> on

            >
            >>
            >> Try running I.segment.stats without requesting form
        statistics.
            >
            >Running:
            >
            >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \
            >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >separator=comma

            Default is to do form statistics, so the above line also does. I
            have to admit that I don't know what happens when you give
        an empty
            parameter such as

            area_measures= or area_measures=""

            What does r.info <http://r.info> <http://r.info>
        gp_seg_optimum give you ?

        +----------------------------------------------------------------------------+
         | Map: gp_seg_optimum Date: Thu Oct 27
        06:45:57
        2016 |
         | Mapset: gp1 Login of Creator:
        jpd205 |
         | Location:
        GarronPill |
         | DataBase:
        /home/jpd205/Wales_GRASS |
         | Title: ( gp_seg_optimum
        ) |
         | Timestamp:
        none |
         |----------------------------------------------------------------------------|
         |
        |
         | Type of Map: raster Number of Categories:
        0 |
         | Data Type:
        CELL |
         | Rows:
        12627 |
         | Columns:
        23991 |
         | Total Cells:
        302934357 |
         | Projection: OSGB 1936 / British National
        Grid |
         | N: 208007.00931776 S: 207952.59780698 Res:
        0.00430914 |
         | E: 201097.28911076 W: 200993.90853302 Res:
        0.00430914 |
         | Range of data: min = 35 max =
        133556294 |
         |

    Ok, I think I see at least part of the problem: in GRASS 7.0
    i.segment numbers segments non sequentially, i.e. whenever a new
    segment is created out of the merger of two existing segments, a new
    id is assigned. In GRASS trunk (the development version) i.segment
    is rewritten to, at the end, number all segments sequentially from 1
    to the number of segments.

    r.object.geometry allocates memory according to the new system. As
    it says in the code:

        /* REMARK: The following is only true if object ids are
    continuously numbered */
        n_objects = max - min + 1;
        obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));

    So, one solution would be to use the development version of GRASS.

    Another would be to run r.clump on the result of the segmentation in
    order to renumber the segments before running it through
    i.segment.stats.

This option seemed the most straightforward given my current setup. I
ran r.clump with diagnoal enabled, and the output looked good. It only
took 2mins to run.

I then proceeded with the original i.segment.stats command and got the
following:

Calculating geometry statistics
Calculating statistics for raster gp_ortho.1@gp1
ERROR: G_realloc: unable to allocate 572000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

It looks like the tool got further, but is still getting stuck on
something...

Yes, now there a memory issue in the part where it uses r.univar to calculate statistics per segment on one of the spectral bands.

What does r.info on the clumped map give you ?

Moritz

9

On 27/10/16 16:15, Moritz Lennert wrote:

On 27/10/16 15:38, James Duffy wrote:

On 27 October 2016 at 13:53, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 27/10/16 12:51, James Duffy wrote:

        On 27 October 2016 at 11:45, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

            Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
            <james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
        <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>>
            a écrit :
            >On 27 October 2016 at 11:08, Moritz Lennert
            ><mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>>
            >wrote:
            >
            >>
            >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
            >> james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
            <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>> a écrit :

            >> >Hello,
            >> >
            >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in
        the osgeolive
            >> >32bit
            >> >operating system.
            >> >
            >> >Prior to using this tool I have successfully created my
        segmented
            >map
            >> >using
            >> >i.segment.
            >> >
            >> >When I try to execute the following command:
            >> >
            >> >i.segment.stats --overwrite --verbose
        map=gp_seg_optimum@gp1 \
            >>

>rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
            >\
            >> >raster_statistics=min,max,mean,stddev,variance,sum \
            >>
>csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >> >separator=comma
            >> >
            >> >I get this error:
            >> >
            >> >Calculating geometry statistics
            >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of
        memory at
            >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
            >>
            >> This is coming from r.object.geometry.
            >>
            >> What are your region settings (g.region -p) ? How many
        segments do
            >you
            >> have ?
            >>
            >
            >GRASS 7.0.4 (GarronPill):~ > g.region -p
            >projection: 99 (OSGB 1936 / British National Grid)
            >zone: 0
            >datum: osgb36
            >ellipsoid: airy
            >north: 208007.00931776
            >south: 207952.59780698
            >west: 200993.90853302
            >east: 201097.28911076
            >nsres: 0.00430914
            >ewres: 0.00430914
            >rows: 12627
            >cols: 23991
            >cells: 302934357

            Are you sure 4mm is correct for the resolution ?

        Yes. It's high resolution imagery from a drone.

            What does r.info <http://r.info> <http://r.info> on

            >
            >>
            >> Try running I.segment.stats without requesting form
        statistics.
            >
            >Running:
            >
            >i.segment.stats --overwrite --verbose
map=gp_seg_optimum@gp1 \
            >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >separator=comma

            Default is to do form statistics, so the above line also
does. I
            have to admit that I don't know what happens when you give
        an empty
            parameter such as

            area_measures= or area_measures=""

            What does r.info <http://r.info> <http://r.info>
        gp_seg_optimum give you ?

+----------------------------------------------------------------------------+

         | Map: gp_seg_optimum Date: Thu Oct 27
        06:45:57
        2016 |
         | Mapset: gp1 Login of Creator:
        jpd205 |
         | Location:

GarronPill |
         | DataBase:

/home/jpd205/Wales_GRASS |
         | Title: ( gp_seg_optimum
        ) |
         | Timestamp:
        none |

|----------------------------------------------------------------------------|

         |
        |
         | Type of Map: raster Number of Categories:
        0 |
         | Data Type:
        CELL |
         | Rows:
        12627 |
         | Columns:
        23991 |
         | Total Cells:
        302934357 |
         | Projection: OSGB 1936 / British National
        Grid |
         | N: 208007.00931776 S: 207952.59780698 Res:
        0.00430914 |
         | E: 201097.28911076 W: 200993.90853302 Res:
        0.00430914 |
         | Range of data: min = 35 max =
        133556294 |
         |

    Ok, I think I see at least part of the problem: in GRASS 7.0
    i.segment numbers segments non sequentially, i.e. whenever a new
    segment is created out of the merger of two existing segments, a new
    id is assigned. In GRASS trunk (the development version) i.segment
    is rewritten to, at the end, number all segments sequentially from 1
    to the number of segments.

    r.object.geometry allocates memory according to the new system. As
    it says in the code:

        /* REMARK: The following is only true if object ids are
    continuously numbered */
        n_objects = max - min + 1;
        obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));

    So, one solution would be to use the development version of GRASS.

    Another would be to run r.clump on the result of the segmentation in
    order to renumber the segments before running it through
    i.segment.stats.

This option seemed the most straightforward given my current setup. I
ran r.clump with diagnoal enabled, and the output looked good. It only
took 2mins to run.

I then proceeded with the original i.segment.stats command and got the
following:

Calculating geometry statistics
Calculating statistics for raster gp_ortho.1@gp1
ERROR: G_realloc: unable to allocate 572000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

It looks like the tool got further, but is still getting stuck on
something...

Yes, now there a memory issue in the part where it uses r.univar to
calculate statistics per segment on one of the spectral bands.

Could you run

r.univar -et gp_ortho.1 zones=ClumpedSegmentMap output=testoutput.csv

to if r.univar by itself handles this (which would mean I could try to change the data handling in i.segment.stats to make it more memory efficient), or not ?

Thanks !

Moritz

10

On 27 October 2016 at 16:33, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

On 27/10/16 16:15, Moritz Lennert wrote:

On 27/10/16 15:38, James Duffy wrote:

On 27 October 2016 at 13:53, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 27/10/16 12:51, James Duffy wrote:

        On 27 October 2016 at 11:45, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

            Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
            <james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
        <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>>
            a écrit :
            >On 27 October 2016 at 11:08, Moritz Lennert
            ><mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
        <mailto:mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>>>
            >wrote:
            >
            >>
            >>
            >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <
            >> james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>
            <mailto:james.philip.duffy@gmail.com
        <mailto:james.philip.duffy@gmail.com>>> a écrit :

            >> >Hello,
            >> >
            >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in
        the osgeolive
            >> >32bit
            >> >operating system.
            >> >
            >> >Prior to using this tool I have successfully created my
        segmented
            >map
            >> >using
            >> >i.segment.
            >> >
            >> >When I try to execute the following command:
            >> >
            >> >i.segment.stats --overwrite --verbose
        map=gp_seg_optimum@gp1 \
            >>

>rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
            >\
            >> >raster_statistics=min,max,mean,stddev,variance,sum \
            >>
>csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >> >separator=comma
            >> >
            >> >I get this error:
            >> >
            >> >Calculating geometry statistics
            >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of
        memory at
            >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
            >>
            >> This is coming from r.object.geometry.
            >>
            >> What are your region settings (g.region -p) ? How many
        segments do
            >you
            >> have ?
            >>
            >
            >GRASS 7.0.4 (GarronPill):~ > g.region -p
            >projection: 99 (OSGB 1936 / British National Grid)
            >zone: 0
            >datum: osgb36
            >ellipsoid: airy
            >north: 208007.00931776
            >south: 207952.59780698
            >west: 200993.90853302
            >east: 201097.28911076
            >nsres: 0.00430914
            >ewres: 0.00430914
            >rows: 12627
            >cols: 23991
            >cells: 302934357

            Are you sure 4mm is correct for the resolution ?

        Yes. It's high resolution imagery from a drone.

            What does r.info <http://r.info> <http://r.info> on

            >
            >
            >>
            >> Try running I.segment.stats without requesting form
        statistics.
            >
            >
            >Running:
            >
            >i.segment.stats --overwrite --verbose
map=gp_seg_optimum@gp1 \
            >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
            >separator=comma

            Default is to do form statistics, so the above line also
does. I
            have to admit that I don't know what happens when you give
        an empty
            parameter such as

            area_measures= or area_measures=""

            What does r.info <http://r.info> <http://r.info>
        gp_seg_optimum give you ?

+-----------------------------------------------------------
-----------------+

         | Map: gp_seg_optimum Date: Thu Oct 27
        06:45:57
        2016 |
         | Mapset: gp1 Login of Creator:
        jpd205 |
         | Location:

GarronPill |
         | DataBase:

/home/jpd205/Wales_GRASS |
         | Title: ( gp_seg_optimum
        ) |
         | Timestamp:
        none |

|-----------------------------------------------------------
-----------------|

         |
        |
         | Type of Map: raster Number of Categories:
        0 |
         | Data Type:
        CELL |
         | Rows:
        12627 |
         | Columns:
        23991 |
         | Total Cells:
        302934357 |
         | Projection: OSGB 1936 / British National
        Grid |
         | N: 208007.00931776 S: 207952.59780698 Res:
        0.00430914 |
         | E: 201097.28911076 W: 200993.90853302 Res:
        0.00430914 |
         | Range of data: min = 35 max =
        133556294 |
         |

    Ok, I think I see at least part of the problem: in GRASS 7.0
    i.segment numbers segments non sequentially, i.e. whenever a new
    segment is created out of the merger of two existing segments, a new
    id is assigned. In GRASS trunk (the development version) i.segment
    is rewritten to, at the end, number all segments sequentially from 1
    to the number of segments.

    r.object.geometry allocates memory according to the new system. As
    it says in the code:

        /* REMARK: The following is only true if object ids are
    continuously numbered */
        n_objects = max - min + 1;
        obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));

    So, one solution would be to use the development version of GRASS.

    Another would be to run r.clump on the result of the segmentation in
    order to renumber the segments before running it through
    i.segment.stats.

This option seemed the most straightforward given my current setup. I
ran r.clump with diagnoal enabled, and the output looked good. It only
took 2mins to run.

I then proceeded with the original i.segment.stats command and got the
following:

Calculating geometry statistics
Calculating statistics for raster gp_ortho.1@gp1
ERROR: G_realloc: unable to allocate 572000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

It looks like the tool got further, but is still getting stuck on
something...

Yes, now there a memory issue in the part where it uses r.univar to
calculate statistics per segment on one of the spectral bands.

Could you run

r.univar -et gp_ortho.1 zones=ClumpedSegmentMap output=testoutput.csv

to if r.univar by itself handles this (which would mean I could try to
change the data handling in i.segment.stats to make it more memory
efficient), or not ?

Thanks !

Moritz

r.info on the clumped map gives:

+----------------------------------------------------------------------------+
| Map: gp_seg_optimum_clump Date: Thu Oct 27 14:28:30
2016 |
| Mapset: gp1 Login of Creator:
jpd205 |
| Location:
GarronPill |
| DataBase:
/home/jpd205/Wales_GRASS |
| Title: gp_seg_optimum_clump ( gp_seg_optimum_clump
) |
| Timestamp:
none |
|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories:
0 |
| Data Type:
CELL |
| Rows:
12627 |
| Columns:
23991 |
| Total Cells:
302934357 |
| Projection: OSGB 1936 / British National
Grid |
| N: 208007.00931776 S: 207952.59780698 Res:
0.00430914 |
| E: 201097.28911076 W: 200993.90853302 Res:
0.00430914 |
| Range of data: min = 1 max =
1264957 |
|
|
| Data
Source: |
| gp_seg_optimum@gp1
|
|
|
|
|
| Data
Description: |
| generated by
r.clump |
|
|
|
Comments: |
| r.clump --overwrite --verbose -d input="gp_seg_optimum@gp1"
output="\ |
| gp_seg_optimum_clump"
title="gp_seg_optimum_clump" |
|
|
+----------------------------------------------------------------------------+

Running:

r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump output=testoutput2.csv

Returns:

Current region rows: 12627, cols: 23991
ERROR: G_realloc: unable to allocate 224000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

James

11

Le Thu, 27 Oct 2016 16:45:47 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 16:33, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

> On 27/10/16 16:15, Moritz Lennert wrote:
>
>> On 27/10/16 15:38, James Duffy wrote:
>>
>>>
>>>
>>> On 27 October 2016 at 13:53, Moritz Lennert
>>> <mlennert@club.worldonline.be
>>> <mailto:mlennert@club.worldonline.be>> wrote:
>>>
>>> On 27/10/16 12:51, James Duffy wrote:
>>>
>>>
>>>
>>> On 27 October 2016 at 11:45, Moritz Lennert
>>> <mlennert@club.worldonline.be
>>> <mailto:mlennert@club.worldonline.be>
>>> <mailto:mlennert@club.worldonline.be
>>> <mailto:mlennert@club.worldonline.be>>> wrote:
>>>
>>>
>>>
>>> Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
>>> <james.philip.duffy@gmail.com
>>> <mailto:james.philip.duffy@gmail.com>
>>> <mailto:james.philip.duffy@gmail.com
>>> <mailto:james.philip.duffy@gmail.com>>>
>>> a écrit :
>>> >On 27 October 2016 at 11:08, Moritz Lennert
>>> ><mlennert@club.worldonline.be
>>> <mailto:mlennert@club.worldonline.be>
>>> <mailto:mlennert@club.worldonline.be
>>> <mailto:mlennert@club.worldonline.be>>>
>>> >wrote:
>>> >
>>> >>
>>> >>
>>> >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy
>>> >> < james.philip.duffy@gmail.com
>>> <mailto:james.philip.duffy@gmail.com>
>>> <mailto:james.philip.duffy@gmail.com
>>> <mailto:james.philip.duffy@gmail.com>>> a écrit :
>>>
>>> >> >Hello,
>>> >> >
>>> >> >I'm trying to use i.segment.stats with GRASS
>>> >> >7.0.4 in
>>> the osgeolive
>>> >> >32bit
>>> >> >operating system.
>>> >> >
>>> >> >Prior to using this tool I have successfully
>>> >> >created my
>>> segmented
>>> >map
>>> >> >using
>>> >> >i.segment.
>>> >> >
>>> >> >When I try to execute the following command:
>>> >> >
>>> >> >i.segment.stats --overwrite --verbose
>>> map=gp_seg_optimum@gp1 \
>>> >>
>>>
>>> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
>>> >\
>>> >> >raster_statistics=min,max,mean,stddev,variance,sum
>>> >> >\
>>> >>
>>> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
>>> >> >separator=comma
>>> >> >
>>> >> >I get this error:
>>> >> >
>>> >> >Calculating geometry statistics
>>> >> >ERROR: G_malloc: unable to allocate 4273800320
>>> >> >bytes of
>>> memory at
>>> >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
>>> >>
>>> >> This is coming from r.object.geometry.
>>> >>
>>> >> What are your region settings (g.region -p) ? How
>>> >> many
>>> segments do
>>> >you
>>> >> have ?
>>> >>
>>> >
>>> >GRASS 7.0.4 (GarronPill):~ > g.region -p
>>> >projection: 99 (OSGB 1936 / British National Grid)
>>> >zone: 0
>>> >datum: osgb36
>>> >ellipsoid: airy
>>> >north: 208007.00931776
>>> >south: 207952.59780698
>>> >west: 200993.90853302
>>> >east: 201097.28911076
>>> >nsres: 0.00430914
>>> >ewres: 0.00430914
>>> >rows: 12627
>>> >cols: 23991
>>> >cells: 302934357
>>>
>>> Are you sure 4mm is correct for the resolution ?
>>>
>>>
>>> Yes. It's high resolution imagery from a drone.
>>>
>>>
>>>
>>> What does r.info <http://r.info> <http://r.info> on
>>>
>>>
>>> >
>>> >
>>> >>
>>> >> Try running I.segment.stats without requesting
>>> >> form
>>> statistics.
>>> >
>>> >
>>> >Running:
>>> >
>>> >i.segment.stats --overwrite --verbose
>>> map=gp_seg_optimum@gp1 \
>>> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats
>>> >\ separator=comma
>>>
>>> Default is to do form statistics, so the above line
>>> also does. I
>>> have to admit that I don't know what happens when you
>>> give an empty
>>> parameter such as
>>>
>>> area_measures= or area_measures=""
>>>
>>> What does r.info <http://r.info> <http://r.info>
>>> gp_seg_optimum give you ?
>>>
>>>
>>>
>>>
>>> +-----------------------------------------------------------
>>> -----------------+
>>>
>>> | Map: gp_seg_optimum Date: Thu Oct
>>> 27 06:45:57
>>> 2016 |
>>> | Mapset: gp1 Login of
>>> Creator: jpd205 |
>>> | Location:
>>>
>>> GarronPill |
>>> | DataBase:
>>>
>>> /home/jpd205/Wales_GRASS |
>>> | Title: ( gp_seg_optimum
>>> ) |
>>> | Timestamp:
>>> none
>>> |
>>>
>>> |-----------------------------------------------------------
>>> -----------------|
>>>
>>> |
>>> |
>>> | Type of Map: raster Number of
>>> Categories: 0 |
>>> | Data Type:
>>> CELL
>>> | | Rows:
>>> 12627
>>> | | Columns:
>>> 23991
>>> | | Total Cells:
>>> 302934357
>>> | | Projection: OSGB 1936 / British National
>>> Grid |
>>> | N: 208007.00931776 S: 207952.59780698
>>> Res: 0.00430914 |
>>> | E: 201097.28911076 W: 200993.90853302
>>> Res: 0.00430914 |
>>> | Range of data: min = 35 max =
>>> 133556294 |
>>> |
>>>
>>>
>>> Ok, I think I see at least part of the problem: in GRASS 7.0
>>> i.segment numbers segments non sequentially, i.e. whenever a
>>> new segment is created out of the merger of two existing
>>> segments, a new id is assigned. In GRASS trunk (the development
>>> version) i.segment is rewritten to, at the end, number all
>>> segments sequentially from 1 to the number of segments.
>>>
>>> r.object.geometry allocates memory according to the new
>>> system. As it says in the code:
>>>
>>> /* REMARK: The following is only true if object ids are
>>> continuously numbered */
>>> n_objects = max - min + 1;
>>> obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));
>>>
>>> So, one solution would be to use the development version of
>>> GRASS.
>>>
>>>
>>>
>>> Another would be to run r.clump on the result of the
>>> segmentation in order to renumber the segments before running it
>>> through i.segment.stats.
>>>
>>>
>>> This option seemed the most straightforward given my current
>>> setup. I ran r.clump with diagnoal enabled, and the output looked
>>> good. It only took 2mins to run.
>>>
>>> I then proceeded with the original i.segment.stats command and
>>> got the following:
>>>
>>> Calculating geometry statistics
>>> Calculating statistics for raster gp_ortho.1@gp1
>>> ERROR: G_realloc: unable to allocate 572000 bytes of memory at
>>> raster/r.univar/r.univar_main.c:324
>>>
>>> It looks like the tool got further, but is still getting stuck on
>>> something...
>>>
>>
>> Yes, now there a memory issue in the part where it uses r.univar to
>> calculate statistics per segment on one of the spectral bands.
>>
>
> Could you run
>
> r.univar -et gp_ortho.1 zones=ClumpedSegmentMap
> output=testoutput.csv
>
> to if r.univar by itself handles this (which would mean I could try
> to change the data handling in i.segment.stats to make it more
> memory efficient), or not ?
>
> Thanks !
>
> Moritz
>

r.info on the clumped map gives:

+----------------------------------------------------------------------------+
| Map: gp_seg_optimum_clump Date: Thu Oct 27 14:28:30
2016 |
| Mapset: gp1 Login of Creator:
jpd205 |
| Location:
GarronPill |
| DataBase:
/home/jpd205/Wales_GRASS |
| Title: gp_seg_optimum_clump ( gp_seg_optimum_clump
) |
| Timestamp:
none |
|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories:
0 |
| Data Type:
CELL |
| Rows:
12627 |
| Columns:
23991 |
| Total Cells:
302934357 |
| Projection: OSGB 1936 / British National
Grid |
| N: 208007.00931776 S: 207952.59780698 Res:
0.00430914 |
| E: 201097.28911076 W: 200993.90853302 Res:
0.00430914 |
| Range of data: min = 1 max =
1264957 |
|
|
| Data
Source: |
| gp_seg_optimum@gp1
|
|
|
|
|
| Data
Description: |
| generated by
r.clump |
|
|
|
Comments:
| | r.clump --overwrite --verbose -d input="gp_seg_optimum@gp1"
output="\ |
| gp_seg_optimum_clump"
title="gp_seg_optimum_clump" |
|
|
+----------------------------------------------------------------------------+

Running:

r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
output=testoutput2.csv

Returns:

Current region rows: 12627, cols: 23991
ERROR: G_realloc: unable to allocate 224000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

Ok, so the issue is with r.univar (although the issue has made me
aware that i.segment.stats could be made way more memory efficient
as well).

How much RAM do you have on your machine ?

This warrants a bug report. Would you be willing to file one on
http://trac.osgeo.org/grass ?

Moritz

12

On 27 October 2016 at 17:48, Moritz Lennert <mlennert@club.worldonline.be>
wrote:

Le Thu, 27 Oct 2016 16:45:47 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

> On 27 October 2016 at 16:33, Moritz Lennert
> <mlennert@club.worldonline.be> wrote:
>
> > On 27/10/16 16:15, Moritz Lennert wrote:
> >
> >> On 27/10/16 15:38, James Duffy wrote:
> >>
> >>>
> >>>
> >>> On 27 October 2016 at 13:53, Moritz Lennert
> >>> <mlennert@club.worldonline.be
> >>> <mailto:mlennert@club.worldonline.be>> wrote:
> >>>
> >>> On 27/10/16 12:51, James Duffy wrote:
> >>>
> >>>
> >>>
> >>> On 27 October 2016 at 11:45, Moritz Lennert
> >>> <mlennert@club.worldonline.be
> >>> <mailto:mlennert@club.worldonline.be>
> >>> <mailto:mlennert@club.worldonline.be
> >>> <mailto:mlennert@club.worldonline.be>>> wrote:
> >>>
> >>>
> >>>
> >>> Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy
> >>> <james.philip.duffy@gmail.com
> >>> <mailto:james.philip.duffy@gmail.com>
> >>> <mailto:james.philip.duffy@gmail.com
> >>> <mailto:james.philip.duffy@gmail.com>>>
> >>> a écrit :
> >>> >On 27 October 2016 at 11:08, Moritz Lennert
> >>> ><mlennert@club.worldonline.be
> >>> <mailto:mlennert@club.worldonline.be>
> >>> <mailto:mlennert@club.worldonline.be
> >>> <mailto:mlennert@club.worldonline.be>>>
> >>> >wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy
> >>> >> < james.philip.duffy@gmail.com
> >>> <mailto:james.philip.duffy@gmail.com>
> >>> <mailto:james.philip.duffy@gmail.com
> >>> <mailto:james.philip.duffy@gmail.com>>> a écrit :
> >>>
> >>> >> >Hello,
> >>> >> >
> >>> >> >I'm trying to use i.segment.stats with GRASS
> >>> >> >7.0.4 in
> >>> the osgeolive
> >>> >> >32bit
> >>> >> >operating system.
> >>> >> >
> >>> >> >Prior to using this tool I have successfully
> >>> >> >created my
> >>> segmented
> >>> >map
> >>> >> >using
> >>> >> >i.segment.
> >>> >> >
> >>> >> >When I try to execute the following command:
> >>> >> >
> >>> >> >i.segment.stats --overwrite --verbose
> >>> map=gp_seg_optimum@gp1 \
> >>> >>
> >>>
> >>> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ortho.4@gp1
> >>> >\
> >>> >> >raster_statistics=min,max,mean,stddev,variance,sum
> >>> >> >\
> >>> >>
> >>> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \
> >>> >> >separator=comma
> >>> >> >
> >>> >> >I get this error:
> >>> >> >
> >>> >> >Calculating geometry statistics
> >>> >> >ERROR: G_malloc: unable to allocate 4273800320
> >>> >> >bytes of
> >>> memory at
> >>> >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129
> >>> >>
> >>> >> This is coming from r.object.geometry.
> >>> >>
> >>> >> What are your region settings (g.region -p) ? How
> >>> >> many
> >>> segments do
> >>> >you
> >>> >> have ?
> >>> >>
> >>> >
> >>> >GRASS 7.0.4 (GarronPill):~ > g.region -p
> >>> >projection: 99 (OSGB 1936 / British National Grid)
> >>> >zone: 0
> >>> >datum: osgb36
> >>> >ellipsoid: airy
> >>> >north: 208007.00931776
> >>> >south: 207952.59780698
> >>> >west: 200993.90853302
> >>> >east: 201097.28911076
> >>> >nsres: 0.00430914
> >>> >ewres: 0.00430914
> >>> >rows: 12627
> >>> >cols: 23991
> >>> >cells: 302934357
> >>>
> >>> Are you sure 4mm is correct for the resolution ?
> >>>
> >>>
> >>> Yes. It's high resolution imagery from a drone.
> >>>
> >>>
> >>>
> >>> What does r.info <http://r.info> <http://r.info> on
> >>>
> >>>
> >>> >
> >>> >
> >>> >>
> >>> >> Try running I.segment.stats without requesting
> >>> >> form
> >>> statistics.
> >>> >
> >>> >
> >>> >Running:
> >>> >
> >>> >i.segment.stats --overwrite --verbose
> >>> map=gp_seg_optimum@gp1 \
> >>> >csvfile=/home/jpd205/Wales_
GRASS/GarronPill/gp_seg_stats
> >>> >\ separator=comma
> >>>
> >>> Default is to do form statistics, so the above line
> >>> also does. I
> >>> have to admit that I don't know what happens when you
> >>> give an empty
> >>> parameter such as
> >>>
> >>> area_measures= or area_measures=""
> >>>
> >>> What does r.info <http://r.info> <http://r.info>
> >>> gp_seg_optimum give you ?
> >>>
> >>>
> >>>
> >>>
> >>> +-----------------------------------------------------------
> >>> -----------------+
> >>>
> >>> | Map: gp_seg_optimum Date: Thu Oct
> >>> 27 06:45:57
> >>> 2016 |
> >>> | Mapset: gp1 Login of
> >>> Creator: jpd205 |
> >>> | Location:
> >>>
> >>> GarronPill |
> >>> | DataBase:
> >>>
> >>> /home/jpd205/Wales_GRASS |
> >>> | Title: ( gp_seg_optimum
> >>> ) |
> >>> | Timestamp:
> >>> none
> >>> |
> >>>
> >>> |-----------------------------------------------------------
> >>> -----------------|
> >>>
> >>> |
> >>> |
> >>> | Type of Map: raster Number of
> >>> Categories: 0 |
> >>> | Data Type:
> >>> CELL
> >>> | | Rows:
> >>> 12627
> >>> | | Columns:
> >>> 23991
> >>> | | Total Cells:
> >>> 302934357
> >>> | | Projection: OSGB 1936 / British National
> >>> Grid |
> >>> | N: 208007.00931776 S: 207952.59780698
> >>> Res: 0.00430914 |
> >>> | E: 201097.28911076 W: 200993.90853302
> >>> Res: 0.00430914 |
> >>> | Range of data: min = 35 max =
> >>> 133556294 |
> >>> |
> >>>
> >>>
> >>> Ok, I think I see at least part of the problem: in GRASS 7.0
> >>> i.segment numbers segments non sequentially, i.e. whenever a
> >>> new segment is created out of the merger of two existing
> >>> segments, a new id is assigned. In GRASS trunk (the development
> >>> version) i.segment is rewritten to, at the end, number all
> >>> segments sequentially from 1 to the number of segments.
> >>>
> >>> r.object.geometry allocates memory according to the new
> >>> system. As it says in the code:
> >>>
> >>> /* REMARK: The following is only true if object ids are
> >>> continuously numbered */
> >>> n_objects = max - min + 1;
> >>> obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));
> >>>
> >>> So, one solution would be to use the development version of
> >>> GRASS.
> >>>
> >>>
> >>>
> >>> Another would be to run r.clump on the result of the
> >>> segmentation in order to renumber the segments before running it
> >>> through i.segment.stats.
> >>>
> >>>
> >>> This option seemed the most straightforward given my current
> >>> setup. I ran r.clump with diagnoal enabled, and the output looked
> >>> good. It only took 2mins to run.
> >>>
> >>> I then proceeded with the original i.segment.stats command and
> >>> got the following:
> >>>
> >>> Calculating geometry statistics
> >>> Calculating statistics for raster gp_ortho.1@gp1
> >>> ERROR: G_realloc: unable to allocate 572000 bytes of memory at
> >>> raster/r.univar/r.univar_main.c:324
> >>>
> >>> It looks like the tool got further, but is still getting stuck on
> >>> something...
> >>>
> >>
> >> Yes, now there a memory issue in the part where it uses r.univar to
> >> calculate statistics per segment on one of the spectral bands.
> >>
> >
> > Could you run
> >
> > r.univar -et gp_ortho.1 zones=ClumpedSegmentMap
> > output=testoutput.csv
> >
> > to if r.univar by itself handles this (which would mean I could try
> > to change the data handling in i.segment.stats to make it more
> > memory efficient), or not ?
> >
> > Thanks !
> >
> > Moritz
> >
>
> r.info on the clumped map gives:
>
> +-----------------------------------------------------------
-----------------+
> | Map: gp_seg_optimum_clump Date: Thu Oct 27 14:28:30
> 2016 |
> | Mapset: gp1 Login of Creator:
> jpd205 |
> | Location:
> GarronPill |
> | DataBase:
> /home/jpd205/Wales_GRASS |
> | Title: gp_seg_optimum_clump ( gp_seg_optimum_clump
> ) |
> | Timestamp:
> none |
> |-----------------------------------------------------------
-----------------|
> |
> |
> | Type of Map: raster Number of Categories:
> 0 |
> | Data Type:
> CELL |
> | Rows:
> 12627 |
> | Columns:
> 23991 |
> | Total Cells:
> 302934357 |
> | Projection: OSGB 1936 / British National
> Grid |
> | N: 208007.00931776 S: 207952.59780698 Res:
> 0.00430914 |
> | E: 201097.28911076 W: 200993.90853302 Res:
> 0.00430914 |
> | Range of data: min = 1 max =
> 1264957 |
> |
> |
> | Data
> Source: |
> | gp_seg_optimum@gp1
> |
> |
> |
> |
> |
> | Data
> Description: |
> | generated by
> r.clump |
> |
> |
> |
> Comments:
> | | r.clump --overwrite --verbose -d input="gp_seg_optimum@gp1"
> output="\ |
> | gp_seg_optimum_clump"
> title="gp_seg_optimum_clump" |
> |
> |
> +-----------------------------------------------------------
-----------------+
>
> Running:
>
> r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
> output=testoutput2.csv
>
> Returns:
>
> Current region rows: 12627, cols: 23991
> ERROR: G_realloc: unable to allocate 224000 bytes of memory at
> raster/r.univar/r.univar_main.c:324

Ok, so the issue is with r.univar (although the issue has made me
aware that i.segment.stats could be made way more memory efficient
as well).

How much RAM do you have on your machine ?

It's a virtual machine which I have dedicated about 10GB.

This warrants a bug report. Would you be willing to file one on
http://trac.osgeo.org/grass ?

I'm happy to submit it if you can guide me as to what exactly should go
into it please?

Moritz

James

13

Le Thu, 27 Oct 2016 20:33:23 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 17:48, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

> > Running:
> >
> > r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
> > output=testoutput2.csv
> >
> > Returns:
> >
> > Current region rows: 12627, cols: 23991
> > ERROR: G_realloc: unable to allocate 224000 bytes of memory at
> > raster/r.univar/r.univar_main.c:324
>
>
> Ok, so the issue is with r.univar (although the issue has made me
> aware that i.segment.stats could be made way more memory efficient
> as well).
>
> How much RAM do you have on your machine ?
>

It's a virtual machine which I have dedicated about 10GB.

>
> This warrants a bug report. Would you be willing to file one on
> http://trac.osgeo.org/grass ?
>

I'm happy to submit it if you can guide me as to what exactly should
go into it please?

The bug report should concentrate on r.univar

You should provide:

- region settings (output of g.region -p)
- info about the two maps going into the command, i.e. r.info, plus the
  info that the segment map is an output of r.clump and thus
  sequentially numbered
- the error message

I don't know how difficult it will be to allow for lower memory usage
in r.univar, so we'll have to see if an improvement is possible.

Moritz

14

On Thu, Oct 27, 2016 at 3:47 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Le Thu, 27 Oct 2016 20:33:23 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 17:48, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

> > Running:
> >
> > r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
> > output=testoutput2.csv
> >
> > Returns:
> >
> > Current region rows: 12627, cols: 23991
> > ERROR: G_realloc: unable to allocate 224000 bytes of memory at
> > raster/r.univar/r.univar_main.c:324
>
>
> Ok, so the issue is with r.univar (although the issue has made me
> aware that i.segment.stats could be made way more memory efficient
> as well).
>
> How much RAM do you have on your machine ?
>

It's a virtual machine which I have dedicated about 10GB.

>
> This warrants a bug report. Would you be willing to file one on
> http://trac.osgeo.org/grass ?
>

I'm happy to submit it if you can guide me as to what exactly should
go into it please?

The bug report should concentrate on r.univar

You should provide:

- region settings (output of g.region -p)
- info about the two maps going into the command, i.e. r.info, plus the
  info that the segment map is an output of r.clump and thus
  sequentially numbered
- the error message

I don't know how difficult it will be to allow for lower memory usage
in r.univar, so we'll have to see if an improvement is possible.

I haven't read this thread carefully, so sorry if this is unrelated,
but I think the -e flag might require a lot of memory. Also, is this
64bit?

Anna

Moritz

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

15

On 27/10/16 23:47, Anna Petrášová wrote:

On Thu, Oct 27, 2016 at 3:47 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Le Thu, 27 Oct 2016 20:33:23 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 17:48, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Running:

r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
output=testoutput2.csv

Returns:

Current region rows: 12627, cols: 23991
ERROR: G_realloc: unable to allocate 224000 bytes of memory at
       raster/r.univar/r.univar_main.c:324

Ok, so the issue is with r.univar (although the issue has made me
aware that i.segment.stats could be made way more memory efficient
as well).

How much RAM do you have on your machine ?

It's a virtual machine which I have dedicated about 10GB.

This warrants a bug report. Would you be willing to file one on
http://trac.osgeo.org/grass ?

I'm happy to submit it if you can guide me as to what exactly should
go into it please?

The bug report should concentrate on r.univar

You should provide:

- region settings (output of g.region -p)
- info about the two maps going into the command, i.e. r.info, plus the
  info that the segment map is an output of r.clump and thus
  sequentially numbered
- the error message

I don't know how difficult it will be to allow for lower memory usage
in r.univar, so we'll have to see if an improvement is possible.

I haven't read this thread carefully, so sorry if this is unrelated,
but I think the -e flag might require a lot of memory. Also, is this
64bit?

No, James is working on "GRASS 7.0.4 in the osgeolive 32bit
operating system."

So, yes, memory limits are expected. The question is whether it would be possible to reduce r.univar's memory usage.

Moritz

16

I can’t register with osgeo to submit a bug as no-one has replied with a ‘mantra’ for me to do so… what a convoluted bug reporting system!

And in your opinion Moritz, does it look like my workflow will not be possible unless I find a 64bit machine with a decent amount of RAM?

Thanks for your support on this.

James

···

On 27 October 2016 at 20:47, Moritz Lennert <mlennert@club.worldonline.be> wrote:

Le Thu, 27 Oct 2016 20:33:23 +0100,
James Duffy <james.philip.duffy@gmail.com> a écrit :

On 27 October 2016 at 17:48, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Running:

r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
output=testoutput2.csv

Returns:

Current region rows: 12627, cols: 23991
ERROR: G_realloc: unable to allocate 224000 bytes of memory at
raster/r.univar/r.univar_main.c:324

Ok, so the issue is with r.univar (although the issue has made me
aware that i.segment.stats could be made way more memory efficient
as well).

How much RAM do you have on your machine ?

It’s a virtual machine which I have dedicated about 10GB.

This warrants a bug report. Would you be willing to file one on
http://trac.osgeo.org/grass ?

I’m happy to submit it if you can guide me as to what exactly should
go into it please?

The bug report should concentrate on r.univar

You should provide:

  • region settings (output of g.region -p)
  • info about the two maps going into the command, i.e. r.info, plus the
    info that the segment map is an output of r.clump and thus
    sequentially numbered
  • the error message

I don’t know how difficult it will be to allow for lower memory usage
in r.univar, so we’ll have to see if an improvement is possible.

Moritz

–

James Duffy
PhD Researcher
Environment and Sustainability Institute
Penryn Campus
University of Exeter
Penryn
Cornwall
TR10 9FE

17

James,

On Wed, Nov 2, 2016 at 11:05 AM, James Duffy
<james.philip.duffy@gmail.com> wrote:

I can't register with osgeo to submit a bug as no-one has replied with a
'mantra' for me to do so... what a convoluted bug reporting system!

We got > 20000 fakje registrations :frowning: That's why these measures had to
be implemented.
I'll send the mantra to you separately.

And in your opinion Moritz, does it look like my workflow will not be
possible unless I find a 64bit machine with a decent amount of RAM?

Thanks for your support on this.

James

Markus

18

On 02/11/16 11:05, James Duffy wrote:

I can't register with osgeo to submit a bug as no-one has replied with a
'mantra' for me to do so... what a convoluted bug reporting system!

And in your opinion Moritz, does it look like my workflow will not be
possible unless I find a 64bit machine with a decent amount of RAM?

I'm not sure about the necessity of 64bit, but more RAM probably.

IIUC, all the stats of all the zones are put into memory during the run of the module. Maybe a file-based store of the information might be possible which would avoid this memory usage, but I'm not sure.

@MarkusM: could you have a look at this ? See https://lists.osgeo.org/pipermail/grass-user/2016-October/075493.html for the beginning of the thread. In short: James seems to be hitting memory limits of r.univar and I'm wondering out loud whether there is something that could be done about this...

Moritz

19

On Wed, Nov 2, 2016 at 3:47 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 02/11/16 11:05, James Duffy wrote:

I can't register with osgeo to submit a bug as no-one has replied with a
'mantra' for me to do so... what a convoluted bug reporting system!

And in your opinion Moritz, does it look like my workflow will not be
possible unless I find a 64bit machine with a decent amount of RAM?

I'm not sure about the necessity of 64bit, but more RAM probably.

IIUC, all the stats of all the zones are put into memory during the run of
the module. Maybe a file-based store of the information might be possible
which would avoid this memory usage, but I'm not sure.

@MarkusM: could you have a look at this ? See
https://lists.osgeo.org/pipermail/grass-user/2016-October/075493.html for
the beginning of the thread. In short: James seems to be hitting memory
limits of r.univar and I'm wondering out loud whether there is something
that could be done about this...

As Anna wrote, the -e flag increases memory consumption of r.univar
considerably. A file based approach for extended stats of r.univar is
difficult because the number of values per segment is initially
unknown to r.univar, thus the amount of disk space needed for extended
stats for each segment is unknown.

I would rather use r.univar for standard stats and r.stats.quantile
for extended stats. The options for raster_statistics of
i.segment.stats would then reduce to "min, max, range, mean,
mean_of_abs, stddev, variance, coeff_var, sum, sum_abs", and a new
option, e.g. raster_percentiles could be added, accepting a list of
percentiles which can be directly fed by i.segment.stats to
r.stats.quantile percentiles=<list of percentiles>.

Markus M

20

On 02/11/16 17:15, Markus Metz wrote:

On Wed, Nov 2, 2016 at 3:47 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 02/11/16 11:05, James Duffy wrote:

I can't register with osgeo to submit a bug as no-one has replied with a
'mantra' for me to do so... what a convoluted bug reporting system!

And in your opinion Moritz, does it look like my workflow will not be
possible unless I find a 64bit machine with a decent amount of RAM?

I'm not sure about the necessity of 64bit, but more RAM probably.

IIUC, all the stats of all the zones are put into memory during the run of
the module. Maybe a file-based store of the information might be possible
which would avoid this memory usage, but I'm not sure.

@MarkusM: could you have a look at this ? See
https://lists.osgeo.org/pipermail/grass-user/2016-October/075493.html for
the beginning of the thread. In short: James seems to be hitting memory
limits of r.univar and I'm wondering out loud whether there is something
that could be done about this...

As Anna wrote, the -e flag increases memory consumption of r.univar
considerably. A file based approach for extended stats of r.univar is
difficult because the number of values per segment is initially
unknown to r.univar, thus the amount of disk space needed for extended
stats for each segment is unknown.

I would rather use r.univar for standard stats and r.stats.quantile
for extended stats. The options for raster_statistics of
i.segment.stats would then reduce to "min, max, range, mean,
mean_of_abs, stddev, variance, coeff_var, sum, sum_abs", and a new
option, e.g. raster_percentiles could be added, accepting a list of
percentiles which can be directly fed by i.segment.stats to
r.stats.quantile percentiles=<list of percentiles>.

Ok, I'll look into this. The only disadvantage is that r.stats.quantile creates a new raster map for each percentile, which then have to be treated to extract the statistics, instead of allowing to print the results directly to a file. But I guess the overhead of that is worth the fact that it reduces memory usage.

Moritz