[GRASS-user] Question to the input seed grid of i.segment

Raphael_Knevels · January 24, 2017, 5:42pm

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image with about 93’535’000 pixels^^

I’m doing the process on a server, so I need for one simple segmentation process approximately 700-800 minutes depending on the threshold. The same process in SAGA takes around 60 minutes with the use of seed points (as grid pixels). But in SAGA there is no possibility for hierarchical segmentation. Therefore, I would like to use the seed points of SAGA as Input for GRASS 7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a meaningful i.segment input. How has to look an optimal input seeds grid for GRASS?

I’ve already found out is that it must be an integer grid with positive seed numbers. The float-grid output of SAGA seed contains single pixels surrounded by no-data values. When I transform the SAGA seed to an integer grid and into GRASS (by (r)gdal), I have to give no data values a positive number. Negative values in the seed-grid-input lead to an error in i.segment.

I would be glad for any hint and reply.

Best regards

mlennert · January 24, 2017, 6:10pm

Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <raphael.knevels@uni-jena.de> a écrit :

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image
with
about 93'535'000 pixels^^

I'm doing the process on a server, so I need for one simple
segmentation
process approximately 700-800 minutes depending on the threshold.

This does seem rather long. Is your computational region set to the extent and resolution of your raster ?

Also try setting the memory parameter of I.segment to a higher value (depending on your server's resources).

Which thresholds have you tried ?

The
same
process in SAGA takes around 60 minutes with the use of seed points (as
grid
pixels).

Which segmentation algorithm do you use in SAGA ?

But in SAGA there is no possibility for hierarchical
segmentation.
Therefore, I would like to use the seed points of SAGA as Input for
GRASS
7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a
meaningful
i.segment input. How has to look an optimal input seeds grid for GRASS?

- I've already found out is that it must be an integer grid with
positive
seed numbers. The float-grid output of SAGA seed contains single pixels
surrounded by no-data values. When I transform the SAGA seed to an
integer
grid and into GRASS (by (r)gdal), I have to give no data values a
positive
number. Negative values in the seed-grid-input lead to an error in
i.segment.

Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.

I don't really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I'm not sure they are really relevant.

You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.

Moritz

Raphael_Knevels · January 24, 2017, 7:40pm

Thanks for the quick response

The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.

In SAGA I used at first Seed Generation (Band Width of 18, but I also varied this parameter) for producing the Seed Output. The Seed Output is a raster with floating point values. Moreover, the Seed Output contains single pixels distributed over the hole area. The "space" between those pixels is "no data". The segmentation is then computed by Seeded Region Growing with the seed grid as input.

"Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged."
-> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.
Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0). However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Raphael

-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Gesendet: Dienstag, 24. Januar 2017 19:11
An: grass-user@lists.osgeo.org; Raphael Knevels
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment

Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <raphael.knevels@uni-jena.de> a écrit :

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image
with about 93'535'000 pixels^^

I'm doing the process on a server, so I need for one simple
segmentation process approximately 700-800 minutes depending on the
threshold.

This does seem rather long. Is your computational region set to the extent and resolution of your raster ?

Also try setting the memory parameter of I.segment to a higher value (depending on your server's resources).

Which thresholds have you tried ?

The
same
process in SAGA takes around 60 minutes with the use of seed points (as
grid pixels).

Which segmentation algorithm do you use in SAGA ?

But in SAGA there is no possibility for hierarchical segmentation.
Therefore, I would like to use the seed points of SAGA as Input for
GRASS
7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a
meaningful i.segment input. How has to look an optimal input seeds grid
for GRASS?

- I've already found out is that it must be an integer grid with
positive seed numbers. The float-grid output of SAGA seed contains
single pixels surrounded by no-data values. When I transform the SAGA
seed to an integer grid and into GRASS (by (r)gdal), I have to give no
data values a positive number. Negative values in the seed-grid-input
lead to an error in i.segment.

Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.

I don't really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I'm not sure they are really relevant.

You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.

Moritz

mlennert · January 25, 2017, 10:22am

On 24/01/17 20:40, Raphael Knevels wrote:

Thanks for the quick response

The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.

That's a pretty large threshold which generally leads to under-segmentation. You might want to start with a value closer to 0.01.

In SAGA I used at first Seed Generation (Band Width of 18, but I
also
varied this parameter) for producing the Seed Output. The Seed Output is
a raster with floating point values. Moreover, the Seed Output contains
single pixels distributed over the hole area. The "space" between those
pixels is "no data". The segmentation is then computed by Seeded Region
Growing with the seed grid as input.

"Seeds in i.segment have to be polygons not points. These polygons
are
represented by identical positive integer values (= IDs) in adjacent
pixels, and they have to cover the entire region. When used as seeds for
a segmentation, these polygons are the further merged."

Sorry, but this was actually wrong information from my part: i.segment also supports seed pixels. From the man page:

"The seeds map can be used to provide either seed pixels (random or selected points from which to start the segmentation process) or seed segments. If the seeds are the results of a previous segmentation with lower threshold, hierarchical segmentation can be performed. The different approaches are automatically detected by the program: any pixels that have identical seed values and are contiguous will be assigned a unique segment ID. "

However, the seed map has to have integer values. To get that from you SAGA output (floating-point) seed map, just run r.clump.

-> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.

No, I actually don't think this would help in any way as this would create one big region out of all the no data pixels...

Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...

And how long did this take ?

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0).
However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Ok, this sounds like bug #3247 [1] for which the author hasn't applied the fix, yet. Rashad, will you have the opportunity to apply just the fix for the actual bug (not necessarily the other proposals in the patch), soon, or should I do it ?

Moritz

mlennert · January 25, 2017, 11:11am

Out of curiosity, I did some testing myself, using the ortho photo available in the GRASS North Carolina demo data set [1]. Several conclusions (based on default parameter settings in SAGA and GRASS):

- Actually the seed map coming out of SAGA is not floating point. The created tiff is Float32, but in fact pixel values are integer. So, in GRASS you can just run r.mapcalc "int_map = int(map)" and then use it as seed input to i.segment.

- The SAGA seeded region algorithm as AFAIU is more similar to the i.superpixels.SLIC algorithm than to our region-growing algorithm. That explains the different execution times. See [2] (grass segmentation with threshold 0.1), [3] (saga segmentation), [4] (grass superpixels).

- Providing the seeds coming from SAGA as input to i.segment does not change neither the execution time, nor the result.

So: I would suggest you try segmenting with a lower threshold. In order to not loose time by segmenting the whole image at each try, you can either create a few small named regions and use the i.segment.uspo addon to try to automagically determine the best threshold, or you just define a small computational region and test manually before applying the result to the entire image.

Moritz

[1] http://tomahawk.ulb.ac.be/moritz/ortho_photo.png
[2] http://tomahawk.ulb.ac.be/moritz/segmentation_grass_noseeds_thresh_01.png
[3] http://tomahawk.ulb.ac.be/moritz/segmentation_saga.png
[4] http://tomahawk.ulb.ac.be/moritz/grass_superpixels.png

On 25/01/17 11:22, Moritz Lennert wrote:

On 24/01/17 20:40, Raphael Knevels wrote:

Thanks for the quick response

The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.

That's a pretty large threshold which generally leads to
under-segmentation. You might want to start with a value closer to 0.01.

In SAGA I used at first Seed Generation (Band Width of 18, but I
also
varied this parameter) for producing the Seed Output. The Seed Output is
a raster with floating point values. Moreover, the Seed Output contains
single pixels distributed over the hole area. The "space" between those
pixels is "no data". The segmentation is then computed by Seeded Region
Growing with the seed grid as input.

"Seeds in i.segment have to be polygons not points. These polygons
are
represented by identical positive integer values (= IDs) in adjacent
pixels, and they have to cover the entire region. When used as seeds for
a segmentation, these polygons are the further merged."

Sorry, but this was actually wrong information from my part: i.segment
also supports seed pixels. From the man page:

"The seeds map can be used to provide either seed pixels (random or
selected points from which to start the segmentation process) or seed
segments. If the seeds are the results of a previous segmentation with
lower threshold, hierarchical segmentation can be performed. The
different approaches are automatically detected by the program: any
pixels that have identical seed values and are contiguous will be
assigned a unique segment ID. "

However, the seed map has to have integer values. To get that from you
SAGA output (floating-point) seed map, just run r.clump.

-> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.

No, I actually don't think this would help in any way as this would
create one big region out of all the no data pixels...

Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...

And how long did this take ?

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0).
However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Ok, this sounds like bug #3247 [1] for which the author hasn't applied
the fix, yet. Rashad, will you have the opportunity to apply just the
fix for the actual bug (not necessarily the other proposals in the
patch), soon, or should I do it ?

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

mlennert · January 26, 2017, 12:16pm

On 25/01/17 11:22, Moritz Lennert wrote:

On 24/01/17 20:40, Raphael Knevels wrote:

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0).
However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Ok, this sounds like bug #3247 [1] for which the author hasn't applied
the fix, yet. Rashad, will you have the opportunity to apply just the
fix for the actual bug (not necessarily the other proposals in the
patch), soon, or should I do it ?

FYI: I've taken the liberty to commit the proposed fix for this bug. It is available for self-compilation, but the windows binaries installed with g.extension will only be available tomorrow morning.

Moritz

Mohammed_Rashad · February 3, 2017, 1:06pm

On Wed, Jan 25, 2017 at 11:22 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 24/01/17 20:40, Raphael Knevels wrote:

Thanks for the quick response

The extent of my region is also the extent of my imagery-group. For
i.segment I used as memory 10240 MB with a threshold of 0.25.

That's a pretty large threshold which generally leads to
under-segmentation. You might want to start with a value closer to 0.01.

In SAGA I used at first Seed Generation (Band Width of 18, but I
also
varied this parameter) for producing the Seed Output. The Seed Output is
a raster with floating point values. Moreover, the Seed Output contains
single pixels distributed over the hole area. The "space" between those
pixels is "no data". The segmentation is then computed by Seeded Region
Growing with the seed grid as input.

"Seeds in i.segment have to be polygons not points. These polygons
are
represented by identical positive integer values (= IDs) in adjacent
pixels, and they have to cover the entire region. When used as seeds for
a segmentation, these polygons are the further merged."

Sorry, but this was actually wrong information from my part: i.segment
also supports seed pixels. From the man page:

"The seeds map can be used to provide either seed pixels (random or
selected points from which to start the segmentation process) or seed
segments. If the seeds are the results of a previous segmentation with
lower threshold, hierarchical segmentation can be performed. The different
approaches are automatically detected by the program: any pixels that have
identical seed values and are contiguous will be assigned a unique segment
ID. "

However, the seed map has to have integer values. To get that from you
SAGA output (floating-point) seed map, just run r.clump.

-> alright. That means, I definitely must convert the no data values in

the SAGA Seed Output to zero or any other integer number.

No, I actually don't think this would help in any way as this would create
one big region out of all the no data pixels...

Meanwhile, I also tried the segmentation result of SAGA Seeded Region

Growing as Seeds for GRASS - this works...

And how long did this take ?

" You could try using the brand new i.superpixels.slic add-on to create

superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension
i.superpixels.slic", GRASS 7.2.0).
However, when I run the tool with default settings, GRASS gives a problem
message and finishs the process.

Ok, this sounds like bug #3247 [1] for which the author hasn't applied the
fix, yet. Rashad, will you have the opportunity to apply just the fix for
the actual bug (not necessarily the other proposals in the patch), soon, or
should I do it ?

I had pushed fix for compile error ( min and max ). Is it the same error?

Moritz

--
Regards,
Rashad

mlennert · February 3, 2017, 2:07pm

On 03/02/17 14:06, Rashad Kanavath wrote:

On Wed, Jan 25, 2017 at 11:22 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    On 24/01/17 20:40, Raphael Knevels wrote:

        Thanks for the quick response

        The extent of my region is also the extent of my imagery-group.
        For i.segment I used as memory 10240 MB with a threshold of 0.25.

    That's a pretty large threshold which generally leads to
    under-segmentation. You might want to start with a value closer to 0.01.

        In SAGA I used at first Seed Generation (Band Width of 18, but I
        also
        varied this parameter) for producing the Seed Output. The Seed
        Output is
        a raster with floating point values. Moreover, the Seed Output
        contains
        single pixels distributed over the hole area. The "space"
        between those
        pixels is "no data". The segmentation is then computed by Seeded
        Region
        Growing with the seed grid as input.

        "Seeds in i.segment have to be polygons not points. These polygons
        are
        represented by identical positive integer values (= IDs) in adjacent
        pixels, and they have to cover the entire region. When used as
        seeds for
        a segmentation, these polygons are the further merged."

    Sorry, but this was actually wrong information from my part:
    i.segment also supports seed pixels. From the man page:

    "The seeds map can be used to provide either seed pixels (random or
    selected points from which to start the segmentation process) or
    seed segments. If the seeds are the results of a previous
    segmentation with lower threshold, hierarchical segmentation can be
    performed. The different approaches are automatically detected by
    the program: any pixels that have identical seed values and are
    contiguous will be assigned a unique segment ID. "

    However, the seed map has to have integer values. To get that from
    you SAGA output (floating-point) seed map, just run r.clump.

        -> alright. That means, I definitely must convert the no data
        values in the SAGA Seed Output to zero or any other integer number.

    No, I actually don't think this would help in any way as this would
    create one big region out of all the no data pixels...

        Meanwhile, I also tried the segmentation result of SAGA Seeded
        Region Growing as Seeds for GRASS - this works...

    And how long did this take ?

        " You could try using the brand new i.superpixels.slic add-on to
        create superpixels which you can then use as seeds."
        -> I could successfully install and open it ("g.extension
        i.superpixels.slic", GRASS 7.2.0).
        However, when I run the tool with default settings, GRASS gives
        a problem message and finishs the process.

    Ok, this sounds like bug #3247 [1] for which the author hasn't
    applied the fix, yet. Rashad, will you have the opportunity to apply
    just the fix for the actual bug (not necessarily the other proposals
    in the patch), soon, or should I do it ?

I had pushed fix for compile error ( min and max ). Is it the same error?

No, it was the error explained in #3247. But the issue was fixed and since then MarkusM has significantly build upon your work on i.superpixels.slic. We now have a nicely functioning module. Thank you for your great work on this !

Moritz

Mohammed_Rashad · February 5, 2017, 11:05am

On Fri, Feb 3, 2017 at 3:07 PM, Moritz Lennert <mlennert@club.worldonline.be

wrote:

On 03/02/17 14:06, Rashad Kanavath wrote:

On Wed, Jan 25, 2017 at 11:22 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 24/01/17 20:40, Raphael Knevels wrote:

        Thanks for the quick response

        The extent of my region is also the extent of my imagery-group.
        For i.segment I used as memory 10240 MB with a threshold of 0.25.

    That's a pretty large threshold which generally leads to
    under-segmentation. You might want to start with a value closer to
0.01.

        In SAGA I used at first Seed Generation (Band Width of 18, but I
        also
        varied this parameter) for producing the Seed Output. The Seed
        Output is
        a raster with floating point values. Moreover, the Seed Output
        contains
        single pixels distributed over the hole area. The "space"
        between those
        pixels is "no data". The segmentation is then computed by Seeded
        Region
        Growing with the seed grid as input.

        "Seeds in i.segment have to be polygons not points. These polygons
        are
        represented by identical positive integer values (= IDs) in
adjacent
        pixels, and they have to cover the entire region. When used as
        seeds for
        a segmentation, these polygons are the further merged."

    Sorry, but this was actually wrong information from my part:
    i.segment also supports seed pixels. From the man page:

    "The seeds map can be used to provide either seed pixels (random or
    selected points from which to start the segmentation process) or
    seed segments. If the seeds are the results of a previous
    segmentation with lower threshold, hierarchical segmentation can be
    performed. The different approaches are automatically detected by
    the program: any pixels that have identical seed values and are
    contiguous will be assigned a unique segment ID. "

    However, the seed map has to have integer values. To get that from
    you SAGA output (floating-point) seed map, just run r.clump.

        -> alright. That means, I definitely must convert the no data
        values in the SAGA Seed Output to zero or any other integer
number.

    No, I actually don't think this would help in any way as this would
    create one big region out of all the no data pixels...

        Meanwhile, I also tried the segmentation result of SAGA Seeded
        Region Growing as Seeds for GRASS - this works...

    And how long did this take ?

        " You could try using the brand new i.superpixels.slic add-on to
        create superpixels which you can then use as seeds."
        -> I could successfully install and open it ("g.extension
        i.superpixels.slic", GRASS 7.2.0).
        However, when I run the tool with default settings, GRASS gives
        a problem message and finishs the process.

    Ok, this sounds like bug #3247 [1] for which the author hasn't
    applied the fix, yet. Rashad, will you have the opportunity to apply
    just the fix for the actual bug (not necessarily the other proposals
    in the patch), soon, or should I do it ?

I had pushed fix for compile error ( min and max ). Is it the same error?

No, it was the error explained in #3247. But the issue was fixed and since
then MarkusM has significantly build upon your work on i.superpixels.slic.
We now have a nicely functioning module. Thank you for your great work on
this !

Sorry. I saw that later. l SLICO and other options needs to be added I
think.

Moritz

--
Regards,
Rashad

mlennert · February 5, 2017, 12:35pm

Le Sun, 5 Feb 2017 12:05:16 +0100,
Rashad Kanavath <mohammedrashadkm@gmail.com> a écrit :

On Fri, Feb 3, 2017 at 3:07 PM, Moritz Lennert
<mlennert@club.worldonline.be [...]

[...]
[...]
[...]
[...]
[...]
[...]
>
> No, it was the error explained in #3247. But the issue was fixed
> and since then MarkusM has significantly build upon your work on
> i.superpixels.slic. We now have a nicely functioning module. Thank
> you for your great work on this !
>

Sorry. I saw that later. l SLICO and other options needs to be added I
think.

No, all done by Markus, already. Just try it out

Moritz

Raphael_Knevels · February 10, 2017, 11:08am

Hello Moritz,

thank you for your help, and sorry for my late response to this topic.

The slic algorithm works really great
for my image (... which is a slope) it needs around 27 minutes (11 000 superpixels and 0.6 compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min.
To use SLIC as Seed in i.segment it reduced the processing time to ~ 250 min.

Is there any prospect to add the SLIC algorithm to i.segment as an option for "Segmentation method"?- It would be very cool to do multiscale/hierarchical segmentation with this algorithm.

For curiosity, I also tried out your suggestion to use the Saga Seeds output modified by r.mapcalc "int_map = int(map)". However, during i.segment I received following Error-message: " ERROR: Invalid region id -3573". - sorry also for the misunderstanding between floating-point output and Float32.

Meanwhile, I also tested the i.segment.uspo add-on. It works fine - just the green progress bar does not. Besides, manually, I calculated Moran's I and Intrasegment Variance by i.segment with 8 instead of 4 neighbors (default). Even if the object looks kind of " pixelated" at the border, I received smaller Moran's I and Intrasegment Variance values with i.segment 8 NB in comparison to 4 NB (same settings for minsize and threshold). Maybe the "-d" flag of i.segment could also be added to i.segment.uspo...

Best regards

-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Gesendet: Mittwoch, 25. Januar 2017 12:11
An: Raphael Knevels; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment

Out of curiosity, I did some testing myself, using the ortho photo available in the GRASS North Carolina demo data set [1]. Several conclusions (based on default parameter settings in SAGA and GRASS):

- Actually the seed map coming out of SAGA is not floating point. The created tiff is Float32, but in fact pixel values are integer. So, in GRASS you can just run r.mapcalc "int_map = int(map)" and then use it as seed input to i.segment.

- The SAGA seeded region algorithm as AFAIU is more similar to the i.superpixels.SLIC algorithm than to our region-growing algorithm. That explains the different execution times. See [2] (grass segmentation with threshold 0.1), [3] (saga segmentation), [4] (grass superpixels).

- Providing the seeds coming from SAGA as input to i.segment does not change neither the execution time, nor the result.

So: I would suggest you try segmenting with a lower threshold. In order to not loose time by segmenting the whole image at each try, you can either create a few small named regions and use the i.segment.uspo addon to try to automagically determine the best threshold, or you just define a small computational region and test manually before applying the result to the entire image.

Moritz

[1] http://tomahawk.ulb.ac.be/moritz/ortho_photo.png
[2]
http://tomahawk.ulb.ac.be/moritz/segmentation_grass_noseeds_thresh_01.png
[3] http://tomahawk.ulb.ac.be/moritz/segmentation_saga.png
[4] http://tomahawk.ulb.ac.be/moritz/grass_superpixels.png

On 25/01/17 11:22, Moritz Lennert wrote:

On 24/01/17 20:40, Raphael Knevels wrote:

Thanks for the quick response

The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.

That's a pretty large threshold which generally leads to
under-segmentation. You might want to start with a value closer to 0.01.

In SAGA I used at first Seed Generation (Band Width of 18, but I
also
varied this parameter) for producing the Seed Output. The Seed Output is
a raster with floating point values. Moreover, the Seed Output contains
single pixels distributed over the hole area. The "space" between those
pixels is "no data". The segmentation is then computed by Seeded Region
Growing with the seed grid as input.

"Seeds in i.segment have to be polygons not points. These polygons
are
represented by identical positive integer values (= IDs) in adjacent
pixels, and they have to cover the entire region. When used as seeds for
a segmentation, these polygons are the further merged."

Sorry, but this was actually wrong information from my part: i.segment
also supports seed pixels. From the man page:

"The seeds map can be used to provide either seed pixels (random or
selected points from which to start the segmentation process) or seed
segments. If the seeds are the results of a previous segmentation with
lower threshold, hierarchical segmentation can be performed. The
different approaches are automatically detected by the program: any
pixels that have identical seed values and are contiguous will be
assigned a unique segment ID. "

However, the seed map has to have integer values. To get that from you
SAGA output (floating-point) seed map, just run r.clump.

-> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.

No, I actually don't think this would help in any way as this would
create one big region out of all the no data pixels...

Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...

And how long did this take ?

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
-> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0).
However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Ok, this sounds like bug #3247 [1] for which the author hasn't applied
the fix, yet. Rashad, will you have the opportunity to apply just the
fix for the actual bug (not necessarily the other proposals in the
patch), soon, or should I do it ?

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

mlennert · February 10, 2017, 5:41pm

Hi Raphael,

On 10/02/17 12:08, Raphael Knevels wrote:

Hello Moritz,

thank you for your help, and sorry for my late response to this
topic.

The slic algorithm works really great for my image (... which is
a slope) it needs around 27 minutes (11 000 superpixels and 0.6
compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min. To
use SLIC as Seed in i.segment it reduced the processing time to ~ 250
min.

Both are good to hear. Thanks for the feedback !

Is there any prospect to add the SLIC algorithm to i.segment as an
option for "Segmentation method"?- It would be very cool to do
multiscale/hierarchical segmentation with this algorithm.

The choice was to make this into a separate module, amongst others to follow the general principle in GRASS that each module should do one thing and only that (I know that with this logic, we probably should have created i.segment.regiongrowing and i.segment.meanshift, but there was sufficiently common code between the two to put them into one module). We felt that the superpixel approach was different enough from the other segmentation methods to warrant a separate modue.

When you speak of multiscale/hierarchical segmentation, what exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in i.segment ?

For curiosity, I also tried out your suggestion to use the Saga Seeds
output modified by r.mapcalc "int_map = int(map)". However, during
i.segment I received following Error-message: " ERROR: Invalid region
id -3573".

That's weird. Does SAGA create negative segment ids ? Which outcome did you use from the SAGA seed module ? For me it worked.

Meanwhile, I also tested the i.segment.uspo add-on. It works fine -
just the green progress bar does not.

No, I never implemented a progress measure in the module. A ToDo...

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of 4
neighbors (default). Even if the object looks kind of " pixelated" at
the border, I received smaller Moran's I and Intrasegment Variance
values with i.segment 8 NB in comparison to 4 NB (same settings for
minsize and threshold). Maybe the "-d" flag of i.segment could also
be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses the addon r.neighborhoodmatrix which has a '-d' flag. I just really do not have the time to implement this right now. You could try yourself by opening the i.segment.uspo (or on Windows i.segment.uspo.py) file and adding "flags='d'" to the call to r.neighborhoodmatrix (lines 535 and following):

     res = gscript.read_command('r.neighborhoodmatrix',
                                input_=mapname,
                                output='-',
                                sep='comma',
             flags='d',
                                quiet=True)

This will always apply the flag. When I have time I can add this as a flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code for the calculation of the spatial autocorrelation and create a "r.spatialautocorrelation" module. But not now...

Moritz

ecodiv · February 10, 2017, 6:15pm

On 10-02-17 18:41, Moritz Lennert wrote:

Hi Raphael,

On 10/02/17 12:08, Raphael Knevels wrote:

Hello Moritz,

thank you for your help, and sorry for my late response to this
topic.

The slic algorithm works really great for my image (... which is
a slope) it needs around 27 minutes (11 000 superpixels and 0.6
compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min. To
use SLIC as Seed in i.segment it reduced the processing time to ~ 250
min.

Both are good to hear. Thanks for the feedback !

Is there any prospect to add the SLIC algorithm to i.segment as an
option for "Segmentation method"?- It would be very cool to do
multiscale/hierarchical segmentation with this algorithm.

The choice was to make this into a separate module, amongst others to follow the general principle in GRASS that each module should do one thing and only that (I know that with this logic, we probably should have created i.segment.regiongrowing and i.segment.meanshift, but there was sufficiently common code between the two to put them into one module). We felt that the superpixel approach was different enough from the other segmentation methods to warrant a separate modue.

When you speak of multiscale/hierarchical segmentation, what exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in i.segment ?

For curiosity, I also tried out your suggestion to use the Saga Seeds
output modified by r.mapcalc "int_map = int(map)". However, during
i.segment I received following Error-message: " ERROR: Invalid region
id -3573".

That's weird. Does SAGA create negative segment ids ? Which outcome did you use from the SAGA seed module ? For me it worked.

Meanwhile, I also tested the i.segment.uspo add-on. It works fine -
just the green progress bar does not.

No, I never implemented a progress measure in the module. A ToDo...

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of 4
neighbors (default). Even if the object looks kind of " pixelated" at
the border, I received smaller Moran's I and Intrasegment Variance
values with i.segment 8 NB in comparison to 4 NB (same settings for
minsize and threshold). Maybe the "-d" flag of i.segment could also
be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses the addon r.neighborhoodmatrix which has a '-d' flag. I just really do not have the time to implement this right now. You could try yourself by opening the i.segment.uspo (or on Windows i.segment.uspo.py) file and adding "flags='d'" to the call to r.neighborhoodmatrix (lines 535 and following):

    res = gscript.read_command('r.neighborhoodmatrix',
                               input_=mapname,
                               output='-',
                               sep='comma',
                   flags='d',
                               quiet=True)

This will always apply the flag. When I have time I can add this as a flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code for the calculation of the spatial autocorrelation and create a "r.spatialautocorrelation" module. But not now...

+1 (or make that a double plus) that would be really great!

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

Raphael_Knevels · February 12, 2017, 9:39pm

Hello Moritz,

When you speak of multiscale/hierarchical segmentation, what exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in i.segment ?

As far as I remember correctly hierarchical segmenation is done by using the i.segment bounds-option. Objects of a first segmentation that were classed/merged/put together (i.e. to forest and not forest), served then as boundary for a subsequent segmentation. I have not looked in the source code yet, but by getting the processing output inside the console, I assume it works like iterating through every object ID of the bounds-raster, build an imagery group for the actual ID-loop-extent and segment it, and at the end put the different segmentation results together.
By the hierarchical segmentation I am able to do some object analysis in different segmentation levels and kind of link them.

That's weird. Does SAGA create negative segment ids ? Which outcome did
you use from the SAGA seed module ? For me it worked.

In SAGA (2.2.2) I used Seed Generation and created a Seeds Grid. This, I saved as seeds.sgrd. In GRASS GIS for importing I used r.in.gdal and as source input seeds.sdat. Then, in GRASS I continued by r.mapcalc...

... "r.spatialautocorrelation" module ...

Sounds great. I am all the time excited to discover new modules in new GRASS releases.

Best regards

-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Gesendet: Freitag, 10. Februar 2017 18:41
An: Raphael Knevels; grass-user@lists.osgeo.org
Betreff: Re: AW: [GRASS-user] Question to the input seed grid of i.segment

Hi Raphael,

On 10/02/17 12:08, Raphael Knevels wrote:

Hello Moritz,

thank you for your help, and sorry for my late response to this topic.

The slic algorithm works really great for my image (... which is a
slope) it needs around 27 minutes (11 000 superpixels and 0.6
compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min. To
use SLIC as Seed in i.segment it reduced the processing time to ~ 250
min.

Both are good to hear. Thanks for the feedback !

Is there any prospect to add the SLIC algorithm to i.segment as an
option for "Segmentation method"?- It would be very cool to do
multiscale/hierarchical segmentation with this algorithm.

The choice was to make this into a separate module, amongst others to follow the general principle in GRASS that each module should do one thing and only that (I know that with this logic, we probably should have created i.segment.regiongrowing and i.segment.meanshift, but there was sufficiently common code between the two to put them into one module). We felt that the superpixel approach was different enough from the other segmentation methods to warrant a separate modue.

When you speak of multiscale/hierarchical segmentation, what exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in i.segment ?

For curiosity, I also tried out your suggestion to use the Saga Seeds
output modified by r.mapcalc "int_map = int(map)". However, during
i.segment I received following Error-message: " ERROR: Invalid region
id -3573".

That's weird. Does SAGA create negative segment ids ? Which outcome did
you use from the SAGA seed module ? For me it worked.

Meanwhile, I also tested the i.segment.uspo add-on. It works fine -
just the green progress bar does not.

No, I never implemented a progress measure in the module. A ToDo...

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of 4
neighbors (default). Even if the object looks kind of " pixelated" at
the border, I received smaller Moran's I and Intrasegment Variance
values with i.segment 8 NB in comparison to 4 NB (same settings for
minsize and threshold). Maybe the "-d" flag of i.segment could also
be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses the
addon r.neighborhoodmatrix which has a '-d' flag. I just really do not
have the time to implement this right now. You could try yourself by
opening the i.segment.uspo (or on Windows i.segment.uspo.py) file and
adding "flags='d'" to the call to r.neighborhoodmatrix (lines 535 and
following):

     res = gscript.read_command('r.neighborhoodmatrix',
                                input_=mapname,
                                output='-',
                                sep='comma',
             flags='d',
                                quiet=True)

This will always apply the flag. When I have time I can add this as a
flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code for the
calculation of the spatial autocorrelation and create a
"r.spatialautocorrelation" module. But not now...

Moritz

mlennert · February 13, 2017, 1:11pm

On 12/02/17 22:39, Raphael Knevels wrote:

Hello Moritz,

When you speak of multiscale/hierarchical segmentation, what
exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in
i.segment ?

As far as I remember correctly hierarchical segmenation is done by

using the i.segment bounds-option. Objects of a first segmentation that
were classed/merged/put together (i.e. to forest and not forest), served
then as boundary for a subsequent segmentation. I have not looked in the
source code yet, but by getting the processing output inside the
console, I assume it works like iterating through every object ID of the
bounds-raster, build an imagery group for the actual ID-loop-extent and
segment it, and at the end put the different segmentation results together.

By the hierarchical segmentation I am able to do some object
analysis

in different segmentation levels and kind of link them.

Hierarchical segmentation can be either bottom-up or top-down. Currently, if you only want to use i.segment, their is just bottom-up= you segment at a threshold that creates very many segments, then use the result of that segmentation as a seed to a second run with i.segment with a higher threshold, which will merge the existing segments from the first run into fewer higher-level, larger segments.

If you have existing boundaries, then you can use those with the 'bounds' parameter. This has the effect that no segment created by i.segment will cross the bounds you provided. In other words, this is a form of top-down hierarchical segmentation, but the input (the bounds) is not something you would get out of i.segment (unless you decide to run it once with a very large threshold and then subdivide the resulting segments - but that is probably not the most efficient way).

So, the question is: should i.superpixels.slic also get "bounds" and "seeds" parameters ? I'm not so sure this is in line with the superpixels approach, but I'm no export.

That's weird. Does SAGA create negative segment ids ? Which outcome
did you use from the SAGA seed module ? For me it worked.

In SAGA (2.2.2) I used Seed Generation and created a Seeds Grid.
This,
I saved as seeds.sgrd. In GRASS GIS for importing I used r.in.gdal and
as source input seeds.sdat. Then, in GRASS I continued by r.mapcalc...

You would need to provide the exact commands used in SAGA, the exact commands used in GRASS GIS, and ideally the data for us to be able to find out what went wrong.

As an example, attached you can find the .sprm file from SAGA with the exact command used for seed generation based on the NC demo data orthophoto. I then, just like you, saved the "Seeds Grid" to a .sgrd file, and used the following commands in GRASS GIS:

r.in.gdal BROL/SeedsGrid.sdat out=seeds
i.group seeds in=seeds
g.region rast=ortho_2001_t792_1m
i.segment ortho seeds=seeds out=ortho_seeded thresh=0.1

No problems here...

... "r.spatialautocorrelation" module ...

Sounds great. I am all the time excited to discover new modules in new GRASS releases.

Well, all this (except for i.segment) is not in any official release at this time. These are all addon modules. Addons make GRASS even richer than it already is, and I, too, am amazed at the many new modules that I discover every time I check the list of addons !

Moritz

Best regards

-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Gesendet: Freitag, 10. Februar 2017 18:41
An: Raphael Knevels; grass-user@lists.osgeo.org
Betreff: Re: AW: [GRASS-user] Question to the input seed grid of i.segment

Hi Raphael,

On 10/02/17 12:08, Raphael Knevels wrote:

Hello Moritz,

thank you for your help, and sorry for my late response to this topic.

The slic algorithm works really great for my image (... which is a
slope) it needs around 27 minutes (11 000 superpixels and 0.6
compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min. To
use SLIC as Seed in i.segment it reduced the processing time to ~ 250
min.

Both are good to hear. Thanks for the feedback !

Is there any prospect to add the SLIC algorithm to i.segment as an
option for "Segmentation method"?- It would be very cool to do
multiscale/hierarchical segmentation with this algorithm.

The choice was to make this into a separate module, amongst others to follow the general principle in GRASS that each module should do one thing and only that (I know that with this logic, we probably should have created i.segment.regiongrowing and i.segment.meanshift, but there was sufficiently common code between the two to put them into one module). We felt that the superpixel approach was different enough from the other segmentation methods to warrant a separate modue.

When you speak of multiscale/hierarchical segmentation, what exactly are you missing in i.superpixels.slic ? Some sort of "seeds" map as in i.segment ?

For curiosity, I also tried out your suggestion to use the Saga Seeds
output modified by r.mapcalc "int_map = int(map)". However, during
i.segment I received following Error-message: " ERROR: Invalid region
id -3573".

That's weird. Does SAGA create negative segment ids ? Which outcome did
you use from the SAGA seed module ? For me it worked.

Meanwhile, I also tested the i.segment.uspo add-on. It works fine -
just the green progress bar does not.

No, I never implemented a progress measure in the module. A ToDo...

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of 4
neighbors (default). Even if the object looks kind of " pixelated" at
the border, I received smaller Moran's I and Intrasegment Variance
values with i.segment 8 NB in comparison to 4 NB (same settings for
minsize and threshold). Maybe the "-d" flag of i.segment could also
be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses the
addon r.neighborhoodmatrix which has a '-d' flag. I just really do not
have the time to implement this right now. You could try yourself by
opening the i.segment.uspo (or on Windows i.segment.uspo.py) file and
adding "flags='d'" to the call to r.neighborhoodmatrix (lines 535 and
following):

     res = gscript.read_command('r.neighborhoodmatrix',
                                input_=mapname,
                                output='-',
                                sep='comma',
             flags='d',
                                quiet=True)

This will always apply the flag. When I have time I can add this as a
flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code for the
calculation of the spatial autocorrelation and create a
"r.spatialautocorrelation" module. But not now...

Moritz

(attachments)

saga_ortho_seed_creation.sprm (1.37 KB)

mlennert · February 28, 2017, 1:35pm

Le Fri, 10 Feb 2017 19:15:25 +0100,
Paulo van Breugel <p.vanbreugel@gmail.com> a écrit :

On 10-02-17 18:41, Moritz Lennert wrote:
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
>> Besides, manually, I calculated
>> Moran's I and Intrasegment Variance by i.segment with 8 instead of
>> 4 neighbors (default). Even if the object looks kind of "
>> pixelated" at the border, I received smaller Moran's I and
>> Intrasegment Variance values with i.segment 8 NB in comparison to
>> 4 NB (same settings for minsize and threshold). Maybe the "-d"
>> flag of i.segment could also be added to i.segment.uspo...
>
> That shouldn't be too difficult. Internally, i.segment.uspo uses
> the addon r.neighborhoodmatrix which has a '-d' flag. I just really
> do not have the time to implement this right now. You could try
> yourself by opening the i.segment.uspo (or on Windows
> i.segment.uspo.py) file and adding "flags='d'" to the call to
> r.neighborhoodmatrix (lines 535 and following):
>
> res = gscript.read_command('r.neighborhoodmatrix',
> input_=mapname,
> output='-',
> sep='comma',
> flags='d',
> quiet=True)
>
>
> This will always apply the flag. When I have time I can add this as
> a flag to i.segment.uspo.
>
> A slightly larger project I have is to actually extract the code
> for the calculation of the spatial autocorrelation and create a
> "r.spatialautocorrelation" module. But not now...

+1 (or make that a double plus) that would be really great!

r70696: r.object.spatialautocor: new addon to calculate global spatial
autocorrelation for raster objects

Moritz

ecodiv · February 28, 2017, 7:13pm

On 28-02-17 14:35, Moritz Lennert wrote:

Le Fri, 10 Feb 2017 19:15:25 +0100,
Paulo van Breugel <p.vanbreugel@gmail.com> a écrit :

On 10-02-17 18:41, Moritz Lennert wrote:
  [...]

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of
4 neighbors (default). Even if the object looks kind of "
pixelated" at the border, I received smaller Moran's I and
Intrasegment Variance values with i.segment 8 NB in comparison to
4 NB (same settings for minsize and threshold). Maybe the "-d"
flag of i.segment could also be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses
the addon r.neighborhoodmatrix which has a '-d' flag. I just really
do not have the time to implement this right now. You could try
yourself by opening the i.segment.uspo (or on Windows
i.segment.uspo.py) file and adding "flags='d'" to the call to
r.neighborhoodmatrix (lines 535 and following):

     res = gscript.read_command('r.neighborhoodmatrix',
                                input_=mapname,
                                output='-',
                                sep='comma',
                    flags='d',
                                quiet=True)

This will always apply the flag. When I have time I can add this as
a flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code
for the calculation of the spatial autocorrelation and create a
"r.spatialautocorrelation" module. But not now...

+1 (or make that a double plus) that would be really great!

r70696: r.object.spatialautocor: new addon to calculate global spatial
autocorrelation for raster objects

Brilliant, will try it out a.sa.p.

Moritz