[GRASS-dev] Image Segmentation - Summer of Code

Eric Momsen eric.momsen at gmail.com
Fri May 25 12:44:50 EDT 2012


Follow up on some of the questions below.

Also, I posted a brief project report to the other mail list:
http://lists.osgeo.org/pipermail/soc/2012-May/001747.html

On Fri, May 25, 2012 at 3:47 AM, Markus Metz <
markus.metz.giswork at googlemail.com> wrote:

> On Thu, May 24, 2012 at 7:29 PM, Eric Momsen <eric.momsen at gmail.com>
> wrote:
> > 1.  How to best deal with images that are larger then available memory.
>  (I
> > assume too much disk I/O would be slow, but simple tiling could lead to
> poor
> > segmentation at the tile borders.)
>
> There are two tile cache mechanisms in GRASS, once the read-only cache
> used by r.proj and i.rectify, once the more flexible and read/write
> cache of the segment library. In this case I would opt for the segment
> library because the data stored there can be any size, determined on
> run-time. You could e.g. put all input bands (all maps in a group)
> into one array and cache that array with the segment lib. The size of
> the array corresponds thus to the number of input bands.
>
> OK, I'll take a look at these, my biggest concern is how to deal with the
interior borders, to make sure segmentation can continue across those
artificial boundaries.


> >
> > 2.  How to find neighbors. (Is this already available somewhere in
> GRASS?)
>
> What neighbors do you mean? The eight adjacent neighbors or neighbours
> in a larger neighborhood? You could look at r.neighbors for a general
> solution of any neighborhood size and at r.watershed for the eight
> adjacent neighbors.
>
> Does 4 or 8 neighbors make more sense for segmentation?  (I'm thinking
with diagonal neighbors, you could end up with two larger regions only
joined at a diagonal in the center - but maybe that is over thinking what
will occur with real images)

Finding pixel neighbors will be just the first step.  After the segments
are growing larger, the both the center region can be irregular (not just
one pixel), and the set of possible neighbors will include irregular shapes
and pixels.

So I guess this is probably similar to finding a 1 pixel buffer, then
reducing those pixels to just check the unique segments.... so I'll look at
r.buffer as well.


>  > I saw GSoC is on the agenda for the Sprint, if it would be helpful (and
> > isn't too early in the day!) I can join by Google video / IRC / etc.
> >
> We address items on the agenda more in an ad-hoc approach, no fixed
> schedule, but you can contact us any time.
>
> Sure, but my schedule is pretty flexible, I wouldn't need much warning to
get online.


> Hope that helps,
>
> Yes, thanks
Eric




> Markus M
>
> > Regards,
> > Eric
> >
> > [1] http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation
> >
> > [2]
> >
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20120525/73f3f179/attachment.html


More information about the grass-dev mailing list