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

[Raphael Knevels]

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 at club.worldonline.be] 
Gesendet: Freitag, 10. Februar 2017 18:41
An: Raphael Knevels; grass-user at 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