[GRASS-dev] Image Segmentation - Summer of Code
Markus Metz
markus.metz.giswork at googlemail.com
Fri May 25 04:47:02 EDT 2012
On Thu, May 24, 2012 at 7:29 PM, Eric Momsen <eric.momsen at gmail.com> wrote:
> Hi,
>
> Thanks everyone for the nice greetings, I'm very impressed with how polite
> and helpful the GRASS community is.
>
> There is a wiki [1] and source code repository [2] for the Image
> Segmentation - Google Summer of Code project.
>
> The mentors for the project have already provided a lot of advice, if there
> is anyone else with an interest in segmentation you are welcome to add to
> the Specifications or other areas of the wiki.
>
> For the "code" I have started an outline, but I think there are still too
> many questions to call it pseudocode yet!. Many of the questions are for
> myself to research and answer. Of course, I welcome input and suggestions
> for all of it, but some of the bigger questions are:
>
> 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.
>
> 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.
>
> 3. Would any functions would be useful as a general library function.
What functions exactly do you have in mind?
>
> 4. If library functions are already available for any steps.
>
I hope the above comments help a bit. A lot of useful functionality is
implemented not only in libraries but also in modules.
>
> 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.
Hope that helps,
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
More information about the grass-dev
mailing list