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

Mon Feb 13 05:11:09 PST 2017

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 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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_ortho_seed_creation.sprm
Type: text/xml
Size: 1405 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170213/8d397aaf/attachment.xml>