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

[Raphael Knevels]

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. 

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.

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". - sorry also for the misunderstanding between floating-point output and Float32. 

Meanwhile, I also tested the i.segment.uspo add-on. It works fine - just the green progress bar does not. 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...

Best regards


-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert at club.worldonline.be] 
Gesendet: Mittwoch, 25. Januar 2017 12:11
An: Raphael Knevels; grass-user at lists.osgeo.org
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment

Out of curiosity, I did some testing myself, using the ortho photo available in the GRASS North Carolina demo data set [1]. Several conclusions (based on default parameter settings in SAGA and GRASS):

- Actually the seed map coming out of SAGA is not floating point. The created tiff is Float32, but in fact pixel values are integer. So, in GRASS you can just run r.mapcalc "int_map = int(map)" and then use it as seed input to i.segment.

- The SAGA seeded region algorithm as AFAIU is more similar to the i.superpixels.SLIC algorithm than to our region-growing algorithm. That explains the different execution times. See [2] (grass segmentation with threshold 0.1), [3] (saga segmentation), [4] (grass superpixels).

- Providing the seeds coming from SAGA as input to i.segment does not change neither the execution time, nor the result.

So: I would suggest you try segmenting with a lower threshold. In order to not loose time by segmenting the whole image at each try, you can either create a few small named regions and use the i.segment.uspo addon to try to automagically determine the best threshold, or you just define a small computational region and test manually before applying the result to the entire image.

Moritz

[1] http://tomahawk.ulb.ac.be/moritz/ortho_photo.png
[2]
http://tomahawk.ulb.ac.be/moritz/segmentation_grass_noseeds_thresh_01.png
[3] http://tomahawk.ulb.ac.be/moritz/segmentation_saga.png
[4] http://tomahawk.ulb.ac.be/moritz/grass_superpixels.png


On 25/01/17 11:22, Moritz Lennert wrote:
> On 24/01/17 20:40, Raphael Knevels wrote:
>> Thanks for the quick response :-)
>>
>> The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.
>
> That's a pretty large threshold which generally leads to
> under-segmentation. You might want to start with a value closer to 0.01.
>
>>
>> In SAGA I used at first Seed Generation (Band Width of 18, but I
>> also
>> varied this parameter) for producing the Seed Output. The Seed Output is
>> a raster with floating point values. Moreover, the Seed Output contains
>> single pixels distributed over the hole area. The "space" between those
>> pixels is "no data". The segmentation is then computed by Seeded Region
>> Growing with the seed grid as input.
>>
>> "Seeds in i.segment have to be polygons not points. These polygons
>> are
>> represented by identical positive integer values (= IDs) in adjacent
>> pixels, and they have to cover the entire region. When used as seeds for
>> a segmentation, these polygons are the further merged."
>
> Sorry, but this was actually wrong information from my part: i.segment
> also supports seed pixels. From the man page:
>
> "The seeds map can be used to provide either seed pixels (random or
> selected points from which to start the segmentation process) or seed
> segments. If the seeds are the results of a previous segmentation with
> lower threshold, hierarchical segmentation can be performed. The
> different approaches are automatically detected by the program: any
> pixels that have identical seed values and are contiguous will be
> assigned a unique segment ID. "
>
>
> However, the seed map has to have integer values. To get that from you
> SAGA output (floating-point) seed map, just run r.clump.
>
>> -> alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.
>
> No, I actually don't think this would help in any way as this would
> create one big region out of all the no data pixels...
>
>> Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works...
>
> And how long did this take ?
>
>> " You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
>> -> I could successfully install and open it ("g.extension i.superpixels.slic", GRASS 7.2.0).
>> However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.
>
> Ok, this sounds like bug #3247 [1] for which the author hasn't applied
> the fix, yet. Rashad, will you have the opportunity to apply just the
> fix for the actual bug (not necessarily the other proposals in the
> patch), soon, or should I do it ?
>
> Moritz
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>