[GRASS-user] Grass 7.6 i.segment minsize working?

Jamille_Haarloo · June 18, 2019, 1:31pm

Dear Grass members,

I have been testing i.segment and i.segment.hierarchical on a small region with Sentinel bands. However, the results consistently include segments of just one pixel even-though minimal segment sizes of 10 and 20 were indicated. The final run with minsize 20 created 8247 segments.
There were no errors nor warnings, and I couldn’t find the i.segment script to review it.
I also tried with a minsize of one (1). The result looks similar with even less segments created - a total of 8160.
I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

Best,
Jamille

Markus_Metz · June 18, 2019, 8:03pm

On Tue, Jun 18, 2019 at 3:31 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Dear Grass members,

I have been testing i.segment and i.segment.hierarchical on a small region with Sentinel bands. However, the results consistently include segments of just one pixel even-though minimal segment sizes of 10 and 20 were indicated. The final run with minsize 20 created 8247 segments.

There were no errors nor warnings, and I couldn’t find the i.segment script to review it.

It is here:
https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment

I also tried with a minsize of one (1). The result looks similar with even less segments created - a total of 8160.
I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

I tested in the North Carolina sample dataset with
g.region -p rast=lsat7_2002_10

using default minsize 1

i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min1
→ i.segment complete. Number of segments created: 29399

r.info -r lsat7_2002_min1

min=1
max=29399 ← as expected

using minsize=20
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min20 minsize=20
→ i.segment complete. Number of segments created: 2114

r.info -r lsat7_2002_min20
min=1
max=2114 ← as expected

r.stats -c lsat7_2002_min20 | sort -k 2n | head
1025 20
1081 20
109 20
1117 20
1220 20
1305 20

The given minimum segment size is in this test respected.

Can you provide test data, region settings and parameters for i.segment to reproduce?

Markus M

Jamille_Haarloo · June 18, 2019, 8:40pm

Thank you Markus,

I used this data: https://drive.google.com/file/d/1xrLJY5aZLKE-ja51wKRX_CKKcUtIiy16/view?usp=sharing (excluding band 6. I used band 1-5 as group)

The parameters:
i.segment.hierarchical group=S2bands_VV@LUPS thresholds=0.1, 0.2 output=hier_segmS2 minsizes=20 memory=4000 iterations=30

i.segment --overwrite group=“S2bands_VV” output=“SegmS2_02_20” band_suffix=“Modified” threshold=0.2 radius=1.5 method=“region_growing” similarity=“euclidean” minsize=20 memory=4000 iterations=50 goodness= “goodn_of_fit_SegmS2_02_20”

g.region -p
projection: 1 (UTM)
zone: 21
datum: wgs84
ellipsoid: wgs84
north: 620222.920747
south: 617573.079721
west: 782605.544297
east: 785903.817009
nsres: 0.49997
ewres: 0.49996555
rows: 5300
cols: 6597
cells: 34964100

On Tue, Jun 18, 2019 at 5:04 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Jun 18, 2019 at 3:31 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Dear Grass members,

I have been testing i.segment and i.segment.hierarchical on a small region with Sentinel bands. However, the results consistently include segments of just one pixel even-though minimal segment sizes of 10 and 20 were indicated. The final run with minsize 20 created 8247 segments.

There were no errors nor warnings, and I couldn’t find the i.segment script to review it.

It is here:
https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment

I also tried with a minsize of one (1). The result looks similar with even less segments created - a total of 8160.
I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

I tested in the North Carolina sample dataset with
g.region -p rast=lsat7_2002_10

using default minsize 1

i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min1
→ i.segment complete. Number of segments created: 29399

r.info -r lsat7_2002_min1

min=1
max=29399 ← as expected

using minsize=20
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min20 minsize=20
→ i.segment complete. Number of segments created: 2114

r.info -r lsat7_2002_min20
min=1
max=2114 ← as expected

r.stats -c lsat7_2002_min20 | sort -k 2n | head
1025 20
1081 20
109 20
1117 20
1220 20
1305 20

The given minimum segment size is in this test respected.

Can you provide test data, region settings and parameters for i.segment to reproduce?

Markus M

Markus_Metz · June 19, 2019, 9:07pm

Hi Jamille,

On Tue, Jun 18, 2019 at 10:40 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Thank you Markus,

I used this data: https://drive.google.com/file/d/1xrLJY5aZLKE-ja51wKRX_CKKcUtIiy16/view?usp=sharing (excluding band 6. I used band 1-5 as group)

The parameters:
i.segment.hierarchical group=S2bands_VV@LUPS thresholds=0.1, 0.2 output=hier_segmS2 minsizes=20 memory=4000 iterations=30

i.segment --overwrite group=“S2bands_VV” output=“SegmS2_02_20” band_suffix=“Modified” threshold=0.2 radius=1.5 method=“region_growing” similarity=“euclidean” minsize=20 memory=4000 iterations=50 goodness= “goodn_of_fit_SegmS2_02_20”

g.region -p
projection: 1 (UTM)
zone: 21
datum: wgs84
ellipsoid: wgs84
north: 620222.920747
south: 617573.079721
west: 782605.544297
east: 785903.817009
nsres: 0.49997
ewres: 0.49996555
rows: 5300
cols: 6597
cells: 34964100

the region settings don’t make sense because the resolution if the input data is 10 meter, not 0.49997 or 0.49996555. That means one original cell is converted to appr. 400 cells in the current region. If you really want to work with a resolution of appr. 0.5, you need to find a reasonable way to resample the 10 meter input data to 0.5 meter. I don’t know a method to resample these input data to 0.5 meter resolution that is really enhancing the spatial detail not just multiplying existing spatial detail (more content, same amount of info).

With these region settings, I get a minimum size of 120 cells for resultant segments according to “r.stats -c”, with both i.segment.hierarchical and i.segment as used by you. Where do you see segments of just one pixel?

Markus M

On Tue, Jun 18, 2019 at 5:04 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Jun 18, 2019 at 3:31 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Dear Grass members,

I have been testing i.segment and i.segment.hierarchical on a small region with Sentinel bands. However, the results consistently include segments of just one pixel even-though minimal segment sizes of 10 and 20 were indicated. The final run with minsize 20 created 8247 segments.
There were no errors nor warnings, and I couldn’t find the i.segment script to review it.

It is here:
https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment

I also tried with a minsize of one (1). The result looks similar with even less segments created - a total of 8160.
I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

I tested in the North Carolina sample dataset with
g.region -p rast=lsat7_2002_10

using default minsize 1
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min1
→ i.segment complete. Number of segments created: 29399

r.info -r lsat7_2002_min1
min=1
max=29399 ← as expected

using minsize=20
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min20 minsize=20
→ i.segment complete. Number of segments created: 2114

r.info -r lsat7_2002_min20
min=1
max=2114 ← as expected

r.stats -c lsat7_2002_min20 | sort -k 2n | head
1025 20
1081 20
109 20
1117 20
1220 20
1305 20

The given minimum segment size is in this test respected.

Can you provide test data, region settings and parameters for i.segment to reproduce?

Markus M

Jamille_Haarloo · June 20, 2019, 2:46pm

Thank you Markus!

I meant that I was literally seeing in the map display how the smallest segments corresponded exactly with single (10 by 10) pixels of the input data. I realize now, the module was using the pixel/cell units as determined by the region settings. I overlooked this when starting the project. Now I am better aware of how fundamental and how easy it is to adjust/ reset the region settings. I changed the resolution to 10 and got better results. According to r.stats the smallest segments have the minsize of 10 I used this time!

Thanks a lot for your clear remarks and suggestions!

Best,

Jamille

On Wed, Jun 19, 2019 at 6:07 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

Hi Jamille,

On Tue, Jun 18, 2019 at 10:40 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Thank you Markus,

I used this data: https://drive.google.com/file/d/1xrLJY5aZLKE-ja51wKRX_CKKcUtIiy16/view?usp=sharing (excluding band 6. I used band 1-5 as group)

The parameters:
i.segment.hierarchical group=S2bands_VV@LUPS thresholds=0.1, 0.2 output=hier_segmS2 minsizes=20 memory=4000 iterations=30

i.segment --overwrite group=“S2bands_VV” output=“SegmS2_02_20” band_suffix=“Modified” threshold=0.2 radius=1.5 method=“region_growing” similarity=“euclidean” minsize=20 memory=4000 iterations=50 goodness= “goodn_of_fit_SegmS2_02_20”

g.region -p
projection: 1 (UTM)
zone: 21
datum: wgs84
ellipsoid: wgs84
north: 620222.920747
south: 617573.079721
west: 782605.544297
east: 785903.817009
nsres: 0.49997
ewres: 0.49996555
rows: 5300
cols: 6597
cells: 34964100

the region settings don’t make sense because the resolution if the input data is 10 meter, not 0.49997 or 0.49996555. That means one original cell is converted to appr. 400 cells in the current region. If you really want to work with a resolution of appr. 0.5, you need to find a reasonable way to resample the 10 meter input data to 0.5 meter. I don’t know a method to resample these input data to 0.5 meter resolution that is really enhancing the spatial detail not just multiplying existing spatial detail (more content, same amount of info).

With these region settings, I get a minimum size of 120 cells for resultant segments according to “r.stats -c”, with both i.segment.hierarchical and i.segment as used by you. Where do you see segments of just one pixel?

Markus M

On Tue, Jun 18, 2019 at 5:04 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Jun 18, 2019 at 3:31 PM Jamille Haarloo <j.r.haarloo@gmail.com> wrote:

Dear Grass members,

I have been testing i.segment and i.segment.hierarchical on a small region with Sentinel bands. However, the results consistently include segments of just one pixel even-though minimal segment sizes of 10 and 20 were indicated. The final run with minsize 20 created 8247 segments.
There were no errors nor warnings, and I couldn’t find the i.segment script to review it.

It is here:
https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment

I also tried with a minsize of one (1). The result looks similar with even less segments created - a total of 8160.
I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

I tested in the North Carolina sample dataset with
g.region -p rast=lsat7_2002_10

using default minsize 1
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min1
→ i.segment complete. Number of segments created: 29399

r.info -r lsat7_2002_min1
min=1
max=29399 ← as expected

using minsize=20
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40 thresh=0.05 out=lsat7_2002_min20 minsize=20
→ i.segment complete. Number of segments created: 2114

r.info -r lsat7_2002_min20
min=1
max=2114 ← as expected

r.stats -c lsat7_2002_min20 | sort -k 2n | head
1025 20
1081 20
109 20
1117 20
1220 20
1305 20

The given minimum segment size is in this test respected.

Can you provide test data, region settings and parameters for i.segment to reproduce?

Markus M