Re: [GRASS-user] Question to the input seed grid of i.segment
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:mlenn...@club.worldonline.be]
Gesendet: Freitag, 10. Februar 2017 18:41
An: Raphael Knevels; grass-user@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
Re: [GRASS-user] Question to the input seed grid of i.segment
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:mlenn...@club.worldonline.be] Gesendet: Mittwoch, 25. Januar 2017 12:11 An: Raphael Knevels; grass-user@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 > pix
Re: [GRASS-user] Question to the input seed grid of i.segment
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.
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."
-> alright. That means, I definitely must convert the no data values in the
SAGA Seed Output to zero or any other integer number.
Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing
as Seeds for GRASS - this works...
" 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.
Raphael
-Ursprüngliche Nachricht-
Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Gesendet: Dienstag, 24. Januar 2017 19:11
An: grass-user@lists.osgeo.org; Raphael Knevels
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment
Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels
<raphael.knev...@uni-jena.de> a écrit :
>Dear GRASS-community,
>
>
>
>I have to perform a multi-scale, object-oriented analysis on an image
>with about 93'535'000 pixels^^
>
>
>
>I'm doing the process on a server, so I need for one simple
>segmentation process approximately 700-800 minutes depending on the
>threshold.
This does seem rather long. Is your computational region set to the extent and
resolution of your raster ?
Also try setting the memory parameter of I.segment to a higher value (depending
on your server's resources).
Which thresholds have you tried ?
>The
>same
>process in SAGA takes around 60 minutes with the use of seed points (as
>grid pixels).
Which segmentation algorithm do you use in SAGA ?
>But in SAGA there is no possibility for hierarchical segmentation.
>Therefore, I would like to use the seed points of SAGA as Input for
>GRASS
>7.2.0 to speed up i.segment.
>
>
>
>However, I am not capable to transform the seeds of SAGA to a
>meaningful i.segment input. How has to look an optimal input seeds grid
>for GRASS?
>
>
>
>- I've already found out is that it must be an integer grid with
>positive seed numbers. The float-grid output of SAGA seed contains
>single pixels surrounded by no-data values. When I transform the SAGA
>seed to an integer grid and into GRASS (by (r)gdal), I have to give no
>data values a positive number. Negative values in the seed-grid-input
>lead to an error in i.segment.
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.
I don't really understand what your seed points represent, but unless they have
a semantic meaning related to the objects you are trying to identify, I'm not
sure they are really relevant.
You could try using the brand new i.superpixels.slic add-on to create
superpixels which you can then use as seeds.
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Question to the input seed grid of i.segment
Dear GRASS-community, I have to perform a multi-scale, object-oriented analysis on an image with about 93'535'000 pixels^^ I'm doing the process on a server, so I need for one simple segmentation process approximately 700-800 minutes depending on the threshold. The same process in SAGA takes around 60 minutes with the use of seed points (as grid pixels). But in SAGA there is no possibility for hierarchical segmentation. Therefore, I would like to use the seed points of SAGA as Input for GRASS 7.2.0 to speed up i.segment. However, I am not capable to transform the seeds of SAGA to a meaningful i.segment input. How has to look an optimal input seeds grid for GRASS? - I've already found out is that it must be an integer grid with positive seed numbers. The float-grid output of SAGA seed contains single pixels surrounded by no-data values. When I transform the SAGA seed to an integer grid and into GRASS (by (r)gdal), I have to give no data values a positive number. Negative values in the seed-grid-input lead to an error in i.segment. I would be glad for any hint and reply. Best regards ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
