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: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.spatialautocorrelation" module. But not now... ;-)
Moritz
<?xml version="1.0" encoding="UTF-8"?>
<PARAMETERS name="Seed Generation">
<OPTION type="grid_system" id="PARAMETERS_GRID_SYSTEM" name="Grid system">
<CELLSIZE>1</CELLSIZE>
<XMIN>637033.5</XMIN>
<XMAX>640080.5</XMAX>
<YMIN>219456.5</YMIN>
<YMAX>222503.5</YMAX>
</OPTION>
<DATA_LIST type="grid_list" id="FEATURES" name="Features">
<DATA>/data/GEODATA/ncimg/ortho_2001_t792_1m.tif</DATA>
</DATA_LIST>
<DATA type="grid" id="VARIANCE" name="Variance">CREATE</DATA>
<DATA type="grid" id="SEED_GRID" name="Seeds Grid">CREATE</DATA>
<DATA type="shapes" id="SEED_POINTS" name="Seed Points">NOT SET</DATA>
<OPTION type="choice" id="SEED_TYPE" name="Seed Type" index="0">minima of variance</OPTION>
<OPTION type="choice" id="METHOD" name="Method" index="0">band width smoothing</OPTION>
<OPTION type="double" id="BAND_WIDTH" name="Bandwidth (Cells)">10.000000</OPTION>
<OPTION type="boolean" id="NORMALIZE" name="Normalize Features">FALSE</OPTION>
<OPTION type="choice" id="DW_WEIGHTING" name="Weighting Function" index="3">gaussian weighting</OPTION>
<OPTION type="double" id="DW_IDW_POWER" name="Inverse Distance Weighting Power">1.000000</OPTION>
<OPTION type="boolean" id="DW_IDW_OFFSET" name="Inverse Distance Offset">TRUE</OPTION>
<OPTION type="double" id="DW_BANDWIDTH" name="Gaussian and Exponential Weighting Bandwidth">5.000000</OPTION>
</PARAMETERS>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
