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

[Pietro Zambelli]

On Thursday 31 Oct 2013 10:09:20 Moritz Lennert wrote:
> Great ! Then I won't continue on that and rather wait for your stuff. Do
> you have code, yet (except for i.segment.hierarchical) ? Don't hesitate
> to publish early.

I did some stuff here: https://github.com/zarch/ml.class

But I'm working to a main re-factoring to integrate my work with 
"v.class.mlpy". It is still under development.


> I guess we should focus on getting the functionality, first and then
> think about optimisation for size...

I agree, but I'm a phD student and I need the results now! :-)


> > 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.
> 
> Any reason other than preference for git over svn for not putting your
> module into grass-addons ?

No, I was worry to add too much stuff on grass-addons, and moreover is 
still under development so maybe it is not ready for a production 
environment...
But I think that now I can move i.segment.hierarchical to grass-addons.


> > 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!).
> 
> That's still only 7 hours for segmentation of a billion-cell size image.
> Not bad compared to other solutions out there...

I never used other solutions, so I'm not able to compared the results, but I 
think that we have some chance to speed-up the process some 
parallelization, I've started to study the i.segment code, but I need time.


> >  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).
> 
> Does your python module load the values into an attribute table ? I
> would guess that that's the slow part in v.to.db. Generally, I think
> that's another field where optimization would be great (if possible):
> database interaction, notably writing to tables. IIUC, in v.to.db there
> is a seperate update operation for each feature. I imagine that there
> must be a faster way to do this...

yes, this is the main problem GRASS is quite bad/slow writing to the db, I've 
skipped the GRASS API and use directly the python interface that is faster.
Moreover the v.to.db create only a column per time, and if you are using 
the sqlite driver it mean that each time you have to create a new table and 
copy all the data.

Even this module is not ready yet... it is just a python function.


> > 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.
> 
> You extended v.class.mlpy ? Is that code available somewhere ?

No, I wrote ml.class and now I'm rewriting to integrate the things together.


> > 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.
> 
> Great ! I guess the more the merrier ;-)
> See also [1]. Maybe its just a small additional step to add that at the
> same time ?

I would love to have this too! :-)


> > 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).
> 
> How do you do that ? Do you generate training points (or small areas)
> and then select the areas these points fall into ?
>
> I thought it best to select training areas among the actual polygons
> coming out of i.segment.


Yes I think so, I've generated some training areas using i.gui.class, then 
I've extract all the segments that overlap this areas and assign the 
category of the training vector map. I'm working on it (so no code ready 
yet!)

So I can write here as soon as I have something to test... :-)

Best regards

Pietro

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