[GRASS-dev] i.segment: Invalid region id -1

Nikos_Alexandris · December 2, 2013, 3:48pm

Hi,

I am trying to (re-)segment a group of high resolution multi-spectral bands
(QuickBird2). I work with

version=7.0.svn
date=2013
revision=58327M
build_date=2013-11-29

and use a seed map (result from the Panchromatic band) and, unfortunately, I
got twice the same error message

--%<---
i.segment msx out=segments_msx_t0.02 threshold=0.02 minsize=4
seed=segments_pan_t0.02 memory=10000 iterations=1000

0..5..10..15..20..25..30..35..40..45..50..55..60..65..70..75..80..85..90..95..0..5..10..15..20..25..ERROR:
Invalid region id -1
--->%--

The region I am working in is indeed large,

nsres: 0.6
ewres: 0.6
rows: 12384
cols: 12303
cells: 152360352

but (almost) the same extents didn't cause any errors in another, very
similar, segmentation attempt (again with QuickBird2 data). What should I look
after?

Thanks, N

Nikos_Alexandris · December 2, 2013, 6:24pm

Nikos Alexandris wrote:

I am trying to (re-)segment a group of high resolution multi-spectral bands
(QuickBird2). I work with

version=7.0.svn
date=2013
revision=58327M
build_date=2013-11-29

and use a seed map (result from the Panchromatic band) and, unfortunately, I
got twice the same error message

--%<---
i.segment msx out=segments_msx_t0.02 threshold=0.02 minsize=4
seed=segments_pan_t0.02 memory=10000 iterations=1000

0..5..10..15..20..25..30..35..40..45..50..55..60..65..70..75..80..85..90..95
..0..5..10..15..20..25..ERROR: Invalid region id -1
--->%--

The region I am working in is indeed large,

nsres: 0.6
ewres: 0.6
rows: 12384
cols: 12303
cells: 152360352

but (almost) the same extents didn't cause any errors in another, very
similar, segmentation attempt (again with QuickBird2 data). What should I
look after?

I've tested this with at least three different similar cases. All work fine
without the seed map! All fail with a seed map supplied. I guess, the only
real difference is time for the processes to complete, right?

Thanks, Nikos

Nikos_Alexandris · December 3, 2013, 12:05am

Nikos Alexandris wrote:
..

I've tested this with at least three different similar cases. All work fine
without the seed map! All fail with a seed map supplied. I guess, the only
real difference is time for the processes to complete, right?

OK, I've just discovered that I mixed 8-bit (the Pan images) for the seed map
and 16-bit (the Multi-Spectral images). So, seed -> 8-bit, group to be
segmented -> 16-bit. Does this play a role?

Thank you, Nikos

Nikos_Alexandris · December 3, 2013, 12:24am

Nikos Alexandris wrote:

> I've tested this with at least three different similar cases. All work
> fine without the seed map! All fail with a seed map supplied. I guess, the
> only real difference is time for the processes to complete, right?

OK, I've just discovered that I mixed 8-bit (the Pan images) for the seed
map and 16-bit (the Multi-Spectral images). So, seed -> 8-bit, group to be
segmented -> 16-bit. Does this play a role?

Silly question. It does. The 8-bit seeds are not "compatible" to 16-bit data
then... :-p

N

Markus_Metz · December 3, 2013, 7:20am

On Tue, Dec 3, 2013 at 1:05 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris wrote:
..

I've tested this with at least three different similar cases. All work fine
without the seed map! All fail with a seed map supplied. I guess, the only
real difference is time for the processes to complete, right?

OK, I've just discovered that I mixed 8-bit (the Pan images) for the seed map
and 16-bit (the Multi-Spectral images). So, seed -> 8-bit, group to be
segmented -> 16-bit. Does this play a role?

No, the seed map must be integer (not more than 32 bit int), that's
the only limitation. The data to be segmented can be anything, integer
and/or floating point.

But it does not make sense to use a pan band as seeds when segmenting
the other bands. Seeds are typically the result of a previous run of
i.segment or the result of a previous classification of the same data.

Markus M

Nikos_Alexandris · December 3, 2013, 10:22am

Nikos Alexandris wrote:

>> I've tested this with at least three different similar cases. All work
>> fine without the seed map! All fail with a seed map supplied. I guess,
>> the only real difference is time for the processes to complete, right?

> OK, I've just discovered that I mixed 8-bit (the Pan images) for the seed
> map and 16-bit (the Multi-Spectral images). So, seed -> 8-bit, group to
> be segmented -> 16-bit. Does this play a role?

Markus Metz:

No, the seed map must be integer (not more than 32 bit int), that's
the only limitation. The data to be segmented can be anything, integer
and/or floating point.

Good to know.

But it does not make sense to use a pan band as seeds when segmenting
the other bands. Seeds are typically the result of a previous run of
i.segment or the result of a previous classification of the same data.

Then I have inserted a small mistake in my tests/workflow. Wanted to drive
"finer objects" (from Pan) in bigger ones (based on MS). Will adjust.

Maybe we can add 1-2 sentences what a seed map is actually. What kind of
numbers per object for example.

Thanks, N

Nikos_Alexandris · December 3, 2013, 7:50pm

Nikos Alexandris wrote:

> >> I've tested this with at least three different similar cases. All work
> >> fine without the seed map! All fail with a seed map supplied. I guess,
> >> the only real difference is time for the processes to complete, right?

> > OK, I've just discovered that I mixed 8-bit (the Pan images) for the
> > seed map and 16-bit (the Multi-Spectral images). So, seed -> 8-bit,
> > group to be segmented -> 16-bit. Does this play a role?

Markus Metz:

> No, the seed map must be integer (not more than 32 bit int), that's
> the only limitation. The data to be segmented can be anything, integer
> and/or floating point.

Good to know.

I guess this is because the segments are only "counted" then.

> But it does not make sense to use a pan band as seeds when segmenting
> the other bands. Seeds are typically the result of a previous run of
> i.segment or the result of a previous classification of the same data.

Then I have inserted a small mistake in my tests/workflow. Wanted to drive
"finer objects" (from Pan) in bigger ones (based on MS). Will adjust.

So, no problem here. All fixed. And, in most of the segmentations so far,
indeed, I used pan only (frist segmentation, then seeding a second) and fed
the derived objects with descriptive stats.

i.segment is a real working tool. It's awesome.

N

Markus_Metz · December 3, 2013, 8:18pm

Nikos Alexandris wrote:

Nikos Alexandris wrote:

> >> I've tested this with at least three different similar cases. All work
> >> fine without the seed map! All fail with a seed map supplied. I guess,
> >> the only real difference is time for the processes to complete, right?

> > OK, I've just discovered that I mixed 8-bit (the Pan images) for the
> > seed map and 16-bit (the Multi-Spectral images). So, seed -> 8-bit,
> > group to be segmented -> 16-bit. Does this play a role?

Markus Metz:

> No, the seed map must be integer (not more than 32 bit int), that's
> the only limitation. The data to be segmented can be anything, integer
> and/or floating point.

Good to know.

I guess this is because the segments are only "counted" then.

Not exactly. You grow stuff from seeds, in this case segments. A seeds
map defines initial segments (objects) which are then grown if
possible. Internally, a seeds map is processed just as in r.clump: all
contiguous cells with the same id will belong to the same initial
segment.

> But it does not make sense to use a pan band as seeds when segmenting
> the other bands. Seeds are typically the result of a previous run of
> i.segment or the result of a previous classification of the same data.

Then I have inserted a small mistake in my tests/workflow. Wanted to drive
"finer objects" (from Pan) in bigger ones (based on MS). Will adjust.

The seeds map does the opposite. You probably want to do pansharpening first.

Anyway, it does not explain why the invalid region id -1 has been
encountered, which should not happen.

Markus M

Nikos_Alexandris · December 3, 2013, 10:05pm

On Tuesday 03 of December 2013 21:18:36 Markus Metz wrote:

>> > But it does not make sense to use a pan band as seeds when segmenting
>> > the other bands. Seeds are typically the result of a previous run of
>> > i.segment or the result of a previous classification of the same data.

>> Then I have inserted a small mistake in my tests/workflow. Wanted to
>> drive "finer objects" (from Pan) in bigger ones (based on MS).
>> Will adjust.

The seeds map does the opposite. You probably want to do pansharpening
first.

Ha-Yey I did (in some cases). Actually, it worked in this cases! And, of
course not in the ones I did not perform pan-sharpening.

Nikos =)

ps- Ah, as for the "-1", I can reproduce it with the data I am working on.
Care for more details (during the weekend)?

Nikos_Alexandris · December 4, 2013, 6:21am

Markus M:

> >> > But it does not make sense to use a pan band as seeds when segmenting
> >> > the other bands. Seeds are typically the result of a previous run of
> >> > i.segment or the result of a previous classification of the same
> >> > data.

Nikos A:

> >> Then I have inserted a small mistake in my tests/workflow. Wanted to
> >> drive "finer objects" (from Pan) in bigger ones (based on MS).
> >> Will adjust.

MM:

> The seeds map does the opposite. You probably want to do pansharpening
> first.

NA:

Ha-Yey I did (in some cases).

Just for completeness, ehm... I was too fast. So, I did use sharpenned images
only in 2 trials, however, as I can actually see in the history. The exact
same process in two different Mapsets (same Location), QuickBird2 data:

--%<--
i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02 minsize=4
seed=segments_pan_t0.01 memory=3000 iterations=1000
-->%--

It worked in one case (repeated to be sure) and it failed in another! In the
failing case, before the ERROR message, there are multiple WARNINGS issued:

..
WARNING: Region consists of only one cell, nothing to update
..

The other 2 (out of 3) failures were simply using (wrongly) the Pan seeds to
segment the MSes. The region was set to 0.6m ns/we resolution (working in a
UTM projection).

[ Minsize set to 4 so as to be close in objects that can be tree crowns... Not
sure how much sense this makes, but it didn't hurt also as I can see in the
final classification results. I also repeated this at least once (as I can
remember) with the resolution set to 2.4 and minsize adjusted to 1 then. ]

Now, I have re-ran the "failed" one and I get this strange:

..
0..5..10..15..20..25..30..35..40..ERROR: Invalid region id -1489
..

I went after looking all of the details of the involved maps. The only
"strange" thing I can see (which I caused) is that the region is 0.6, the seed
(segments_pan_t0.01) is also 0.6 while the group of Pan-Sharpened images are
(each) of 0.60017817 (ns) x 0.60016801 (we) resolution. Is this my mistake?
The resolution(s) should be identical, right?

Thanks for shedding light, sorry for crunching time away, N

Markus_Metz · December 4, 2013, 7:14am

Nikos Alexandris wrote:

Markus M:

> >> > But it does not make sense to use a pan band as seeds when segmenting
> >> > the other bands. Seeds are typically the result of a previous run of
> >> > i.segment or the result of a previous classification of the same
> >> > data.

Nikos A:

> >> Then I have inserted a small mistake in my tests/workflow. Wanted to
> >> drive "finer objects" (from Pan) in bigger ones (based on MS).
> >> Will adjust.

MM:

> The seeds map does the opposite. You probably want to do pansharpening
> first.

NA:

Ha-Yey I did (in some cases).

Just for completeness, ehm... I was too fast. So, I did use sharpenned images
only in 2 trials, however, as I can actually see in the history. The exact
same process in two different Mapsets (same Location), QuickBird2 data:

--%<--
i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02 minsize=4
seed=segments_pan_t0.01 memory=3000 iterations=1000
-->%--

It worked in one case (repeated to be sure) and it failed in another!

Different computational regions?

In the
failing case, before the ERROR message, there are multiple WARNINGS issued:

..
WARNING: Region consists of only one cell, nothing to update

This should not happen, a bug in the region growing algorithm.

Now, I have re-ran the "failed" one and I get this strange:

..
0..5..10..15..20..25..30..35..40..ERROR: Invalid region id -1489

Essentially the same like "ERROR: Invalid region id -1". Again, this
should not happen.

..

I went after looking all of the details of the involved maps. The only
"strange" thing I can see (which I caused) is that the region is 0.6, the seed
(segments_pan_t0.01) is also 0.6 while the group of Pan-Sharpened images are
(each) of 0.60017817 (ns) x 0.60016801 (we) resolution. Is this my mistake?
The resolution(s) should be identical, right?

Yes. I guess in the process of pansharpening, the region was set to
0.6, then the resolution was adjusted to the extents (for g.region,
extents have precedence over resolution). The correct way of adjusting
the region would be to either set the region to the pan band or align
the region to the band band (g.region align=pan). Note that g.region
res=0.6 -a can introduce a pixel shift.

Can you reproduce that with sample data? Or give me chance to reproduce that?

Markus M

Nikos_Alexandris · December 4, 2013, 8:56am

Markus M:

>> > >> > But it does not make sense to use a pan band as seeds when
>> > >> > segmenting the other bands. Seeds are typically the result of a
>> > >> > previous run of i.segment or the result of a previous
>> > >> > classification of the same data.

Nikos A:

>> > >> Then I have inserted a small mistake in my tests/workflow. Wanted to
>> > >> drive "finer objects" (from Pan) in bigger ones (based on MS).
>> > >> Will adjust.

MM:

>> > The seeds map does the opposite. You probably want to do pansharpening
>> > first.

NA:

> Just for completeness, ehm... I was too fast. So, I did use sharpenned
> images only in 2 trials, however, as I can actually see in the history.
> The exact same process in two different Mapsets (same Location),
> QuickBird2 data:

> --%<--
> i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02
> minsize=4 seed=segments_pan_t0.01 memory=3000 iterations=1000
> -->%--

> It worked in one case (repeated to be sure) and it failed in another!

Different computational regions?

Absolutely. Two different, independent trials. Same Location, different
Mapsets, different regions ("physically", if I may say so, and
computationally).

> In the failing case, before the ERROR message, there are multiple WARNINGS
> issued:
>
> ..
> WARNING: Region consists of only one cell, nothing to update

This should not happen, a bug in the region growing algorithm.

> Now, I have re-ran the "failed" one and I get this strange:
>
> ..
> 0..5..10..15..20..25..30..35..40..ERROR: Invalid region id -1489

Essentially the same like "ERROR: Invalid region id -1". Again, this
should not happen.

> ..
>
> I went after looking all of the details of the involved maps. The only
> "strange" thing I can see (which I caused) is that the region is 0.6, the
> seed (segments_pan_t0.01) is also 0.6 while the group of Pan-Sharpened
> images are (each) of 0.60017817 (ns) x 0.60016801 (we) resolution. Is
> this my mistake? The resolution(s) should be identical, right?

Yes. I guess in the process of pansharpening, the region was set to
0.6, then the resolution was adjusted to the extents (for g.region,
extents have precedence over resolution). The correct way of adjusting
the region would be to either set the region to the pan band or align
the region to the band band (g.region align=pan). Note that g.region
res=0.6 -a can introduce a pixel shift.

Can you reproduce that with sample data?

I'll try.

Or give me chance to reproduce that?

If I can't make it with "common" data from the Spearish Location, I can try
with some publicly available High-Res images.

Nonetheless, I am convinced, for now, that the evil root was my bad choice of
setting the region using the "-a" flag. Usually, I try to keep the cell
resolutions intact, as imported. With many high resolution images I have
worked recently (IKONOS, QuickBird2, WorldView-1, WorldView-2), this is the
case. They are not exactly 0.6, 1 or 2.4 or whatever.

However, trying to make the computational region as minimal as possible, I use
very often something like "g.region zoom=Raster". This, however, has no
effect in the region's resolution. It affects only the extent. And then, I
easily fall in the trap to reset the resolution, e.g. it was set to match the
MSes and I need the Pan's, so I do "g.region res=0.6 -a".

What do you think, a short warning in the manual that "the resolution of the
computational region should be identical between subsequent segmentations that
make use of a seed map"?

Nikos

Nikos_Alexandris · December 4, 2013, 9:04am

On Wednesday 04 of December 2013 10:56:48 Nikos Alexandris wrote:
..

What do you think, a short warning in the manual that "the resolution of the
computational region should be identical between subsequent segmentations
that make use of a seed map"?

Or, maybe more "aggressively", a check if the resolution of the seed map is
identical to the region's resolution at the time of the segmentation process?

N

Nikos_Alexandris · December 5, 2013, 3:58pm

NA:

> > --%<--
> > i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02
> > minsize=4 seed=segments_pan_t0.01 memory=3000 iterations=1000
> > -->%--
> > It worked in one case (repeated to be sure) and it failed in another!

MM:

> Different computational regions?

NA:

Absolutely. Two different, independent trials. Same Location, different
Mapsets, different regions ("physically", if I may say so, and
computationally).

> > In the failing case, before the ERROR message, there are multiple
> > WARNINGS issued:
> > WARNING: Region consists of only one cell, nothing to update

> This should not happen, a bug in the region growing algorithm.

Is a Warning message always a bug (in the case of i.segment)?

> > I went after looking all of the details of the involved maps. The only
> > "strange" thing I can see (which I caused) is that the region is 0.6,
> > the seed (segments_pan_t0.01) is also 0.6 while the group of Pan-
> > Sharpened images are (each) of 0.60017817 (ns) x 0.60016801 (we)
> > resolution. Is this my mistake? The resolution(s) should be identical,
> > right?

> Yes. I guess in the process of pansharpening, the region was set to
> 0.6, then the resolution was adjusted to the extents (for g.region,
> extents have precedence over resolution).

-- useful --

> The correct way of adjusting the region would be to either set the region
> to the pan band or align the region to the band band (g.region align=pan).

-- useful --

> Note that g.region res=0.6 -a can introduce a pixel shift.
> Can you reproduce that with sample data?

I'll try.

I can't reproduce this anymore (with my working images) after being careful
with extent and resolution. Two examples, both worked fine:

1) Seed map (Pan), HPF-Sharpened MSes and Region: all of 0.59998996
2) Seed map (Pan), group of HPF-Sharpened MSes and Region: all of 0.60017817 x
0.60016801

However, in a completely different setup (Location, Mapsets), I can see
multiple Warnings, like above, no error though. The process completes fine and
I get to see the segments. Is this ok?

If not, could it be related with sub-sequent processing errors? For example,
like invalid classification signatures from i.cluster and failure of i.maxlik?
I use(d) fancy segments-stats (segments used as a cover, group of Multi-
Spectral images used as source for stats) like skewness, kurtosis, etc.

Nikos