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

[Moritz Lennert]

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
>