<div class="gmail_quote">Follow up on some of the questions below.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Also, I posted a brief project report to the other mail list:</div><div class="gmail_quote">
<a href="http://lists.osgeo.org/pipermail/soc/2012-May/001747.html">http://lists.osgeo.org/pipermail/soc/2012-May/001747.html</a>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, May 25, 2012 at 3:47 AM, Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@googlemail.com" target="_blank">markus.metz.giswork@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, May 24, 2012 at 7:29 PM, Eric Momsen <<a href="mailto:eric.momsen@gmail.com" target="_blank">eric.momsen@gmail.com</a>> wrote:<br>
> 1. How to best deal with images that are larger then available memory. (I<br>
> assume too much disk I/O would be slow, but simple tiling could lead to poor<br>
> segmentation at the tile borders.)<br>
<br>
</div>There are two tile cache mechanisms in GRASS, once the read-only cache<br>
used by r.proj and i.rectify, once the more flexible and read/write<br>
cache of the segment library. In this case I would opt for the segment<br>
library because the data stored there can be any size, determined on<br>
run-time. You could e.g. put all input bands (all maps in a group)<br>
into one array and cache that array with the segment lib. The size of<br>
the array corresponds thus to the number of input bands.<br>
<div><br></div></blockquote><div>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.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
><br>
> 2. How to find neighbors. (Is this already available somewhere in GRASS?)<br>
<br>
</div>What neighbors do you mean? The eight adjacent neighbors or neighbours<br>
in a larger neighborhood? You could look at r.neighbors for a general<br>
solution of any neighborhood size and at r.watershed for the eight<br>
adjacent neighbors.<br>
<div><br></div></blockquote><div>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)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div>
> I saw GSoC is on the agenda for the Sprint, if it would be helpful (and<br>
> isn't too early in the day!) I can join by Google video / IRC / etc.<br>
><br>
</div>We address items on the agenda more in an ad-hoc approach, no fixed<br>
schedule, but you can contact us any time.<br>
<br></blockquote><div>Sure, but my schedule is pretty flexible, I wouldn't need much warning to get online.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hope that helps,<br>
<br></blockquote><div>Yes, thanks</div><div>Eric</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Markus M<br>
<div><br>
> Regards,<br>
> Eric<br>
><br>
> [1] <a href="http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation" target="_blank">http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation</a><br>
><br>
> [2]<br>
> <a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment</a><br>
><br>
</div>> _______________________________________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div><br>