[GRASS-dev] i.segment: Invalid region id -1
nik at nikosalexandris.net
Wed Dec 4 00:56:48 PST 2013
> >> > >> > 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.
> > 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
> > 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?
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"?
More information about the grass-dev