As you might have gathered from my other messages on the list, we are currently running tests of i.segment in our department. A few questions came up (with my attempts at answers).
***************************
I had a look at the results, they are interesting. Maybe you could also try
a combination of panchromatic, red and near-infrared bands and leave the
other bands out. If it is possible to give different weights to the bands,
then maybe 2 for the pan, 1 for red and 1 for NIR.
I think that is possible, but I have to check how. I imagine you would
work at the resolution of the pan for this...
Regarding the size of the segments, we generally combine different
segmentations, fine and coarse, depending on the type of objects that we
have to classify. We also combine different segmentations because then we
can use the classification of a fine segmentation as attribute for
classifying a coarse segmentation (e.g. counting trees or houses in a large
segment). Here we have very small segments and also very large ones together
in the results, it is a bit different.
So to be able to do what you do now, you would need homogenous segment
sizes, i.e. not only a minsize (which I set fairly low in this first
trial: 2 pixels), but also the equivalent of a maxsize. Then, if you set the two fairly close to each other (i.e. minsize=900 and maxsize=1100 to get segments of +/- 1000 pixels).
I'll see how that can be achieved with the currently implemented module.
*******************************
Any hints on possible answers to these issues ?
Moritz
On Thu, Jul 4, 2013 at 11:13 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
As you might have gathered from my other messages on the list, we are
currently running tests of i.segment in our department. A few questions came
up (with my attempts at answers).
***************************
I had a look at the results, they are interesting. Maybe you could also
try
a combination of panchromatic, red and near-infrared bands and leave the
other bands out. If it is possible to give different weights to the bands,
then maybe 2 for the pan, 1 for red and 1 for NIR.
I think that is possible, but I have to check how. I imagine you would
work at the resolution of the pan for this...
You could first resample the pan band to the resolution of the other
bands, then r.mapcalc - multiply the pan band with 2 and use i.segment
-w.
Regarding the size of the segments, we generally combine different
segmentations, fine and coarse, depending on the type of objects that we
have to classify. We also combine different segmentations because then we
can use the classification of a fine segmentation as attribute for
classifying a coarse segmentation (e.g. counting trees or houses in a
large
segment). Here we have very small segments and also very large ones
together
in the results, it is a bit different.
So to be able to do what you do now, you would need homogenous segment
sizes, i.e. not only a minsize (which I set fairly low in this first
trial: 2 pixels), but also the equivalent of a maxsize. Then, if you set the
two fairly close to each other (i.e. minsize=900 and maxsize=1100 to get
segments of +/- 1000 pixels).
This is currently controlled with the threshold value. I am not sure
if a max size makes sense. There might be homogenous objects with
identical pixel values (difference = 0) that are larger than a given
max size. Splitting such objects to respect a max size would be
arbitrary. I would rather try to find a good combination of threshold
and minsize, and do hierachical segmentation using the output of the
previous run as input for the next run with increasing threshold.
Technically, a maxsize option is possible for i.segment.
Markus M
I'll see how that can be achieved with the currently implemented module.
*******************************
Any hints on possible answers to these issues ?
Moritz