[GRASS-dev] Object-based image classification in GRASS

[Pietro Zambelli]

Hi Moritz,

I'm writing some modules (in python) to basically do the same thing. 

I'm trying to apply a Object-based classification for a quite big area (the 
region is more than 14 billions of cells).

At the moment I'm working with a smaller area with "only" ~1 billions of 
cells, but it is still quite challenging.

To speed-up the segmentation process I did the i.segment.hierarchical 
module [0]. that split the region in several tiles, compute the segment for 
each tile, patch all the tiles together and run a last time i segment using 
the patched map as a seed.

for a region of 24k row for 48k cols it required less than two hour to run 
and patch all the tiles, and more than 5 hours to run the "final" i.segment 
over the patched map (using only 3 iterations!).

>From my experience I can say that the use "v.to.db" is terribly slow if you 
want to apply to a vector map with more than 2.7 Millions of areas. So I've 
develop a python function that compute the same values, but it is much 
faster that the v.to.db module, and should be possible to split the 
operation in several processes for further speed up... (It is still under 
testing).


On Wednesday 30 Oct 2013 21:04:22 Moritz Lennert wrote:
> - It uses the v.class.mlpy addon module for classification, so that
> needs to be installed. Kudos to Vaclav for that module ! It currently
> only uses the DLDA classifier. The mlpy library offers many more, and I
> think it should be quite easy to add them. Obviously, one could also
> simply export the attribute table of the segments and of the training
> areas to csv files and use R to do the classification.

I'm extended to use tree/k-NN/SVM Machine learning from MLPY [1] (I've 
used also Parzen, but the results were not good enough) and to work also 
with the scikit [2] classifiers.
Scikit it seems to have a larger community and should be easier to install 
than MLPY, and last but not least it seems generally faster [3].


> - Many other variables could be calculated for the segments: other
> texture variables (possibly variables by segment, not as average of
> pixel-based variables, cf [1]), other shape variables (cf the new work
> of MarkusM on center lines and skeletons of polygons in v.voronoi), band
> indices, etc. It would be interesting to hear what most people find 
useful.

I'm working to add also a C function to the GRASS library to compute the 
barycentre and the a polar second moment of Area (or Moment of Inertia), 
that return a number that it is independent from the orientation and 
dimension.


> - I do the step of digitizing training areas in the wxGUI digitizer
> using the attribute editing tool and filling in the 'class' attribute
> for those polygons I find representative. As already mentioned in
> previous discussions [2], I do think that it would be nice if we could
> have an attribute editing form that is independent of the vector digitizer.


I use the i.gui.class to generate the training vector map, and then use this 
map to select the training areas, and export the final results into a file (at 
the moment only csv and npy formats are supported).


> More generally, it would be great to get feedback from interested people
> on this approach to object-based image classification to see what we 
can
> do to make it better.

I'm definitely interested on the topic! :-)

Some days ago I've discussed with MarkusM, that may be I could do a GSoC 
next year to modify the i.segment module to automatically split the domain 
in tiles, run as a multiprocess, and then "patch" only the segments that 
are on the border of the tiles, this solution should be much faster than my 
actual solution[0]. Moreover we should consider to skip to transform the 
segments into vector to extract the shape parameters and extract shape 
and others parameters (mean, median, skewness, std, etc.) directly as 
last step before to free the memory from the segments structures, writing 
a csv/npy file.

All the best.

Pietro

[0] https://github.com/zarch/i.segment.hierarchical
[1] http://mlpy.sourceforge.net/
[2] http://scikit-learn.org/
[3] http://scikit-learn.org/ml-benchmarks/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20131030/4d6d176a/attachment-0001.html>