[GRASS-SVN] r51837 - grass-addons/grass7/imagery/i.segment

[svn_grass at osgeo.org]

Author: momsen
Date: 2012-05-27 21:09:48 -0700 (Sun, 27 May 2012)
New Revision: 51837

Modified:
   grass-addons/grass7/imagery/i.segment/outline
Log:
comment responses

Modified: grass-addons/grass7/imagery/i.segment/outline
===================================================================
--- grass-addons/grass7/imagery/i.segment/outline	2012-05-27 16:52:33 UTC (rev 51836)
+++ grass-addons/grass7/imagery/i.segment/outline	2012-05-28 04:09:48 UTC (rev 51837)
@@ -66,8 +66,8 @@
 weights for shape and compactness
 Color space? (RGB, HSI, L*u*v*, L*a*b*)
 /*ML: Again, I don't think that you should think in terms of color space. As Ned mentioned feature space is probably the most appropriate and which variables define that space is up to the user by defining which maps go into the relevant group. IMHO it should also be up to the user to ensure that the different maps in the chosen group (i.e. the different variables defining the feature space) can be used together and are of the same order of magnitude*/
+/*EM: OK, I certainly agree that feature space is the most important concept.  But I think this could be considered for the last few weeks, If there are some common conversions that are used, it could help smooth the workflow.  (As with stats, maybe this is a seperate module that is called by setting a flag from this one... */
 
-
 /* output parameters */
 need name for new raster and vector map
 default to use: inputname_segmented and inputname_segment_stats  ??
@@ -82,8 +82,8 @@
 
 -e  Maybe an option for basic vs. extended output statistics 
 /*ML: I think we need to discuss whether the calculation of statistics should be part of the actual segmentation module, or whether putting that task into a separate module might be a better idea, i.e. a module which would take as input a (vector?) map of the segments and then calculate statistics. This would also allow to use segments created elsewhere, but still access the statistics for further analysis. I'm currently more inclined towards the separate module option.*/
+/*EM: From a user perspective, my impression is that statistics will be wanted >50% of the time.  Is this correct?  If so, I would want the front end to allow calculating statistics without having to run another module.  If it is OK to have a flag in this module to call the statistics module from the front end, I don't have a preference yet for splitting statistics into a seperate module.  As for input to the statistics module - it seemed the output of the segmentation is a raster map, the input to statistics is this raster map, with the output from statistics is the vector map with attribute table.*/
 
-
 Should user input allowed memory usage, or is there a way to find out what is reasonable?
 /*ML: Sounds like a reasonable idea. Look at r.watershed for inspiration (-m flag + memory parameter)*/
 
@@ -122,6 +122,7 @@
 Resolution
 Again, this could be required as preprocessing and/or second priority.
 /*ML: If your speaking of pixel size, then this is part of the region settings. If you mean scale of segmentation, then this should be part of the algorithm parameters*/
+/*EM: This check was for pixel size.*/
 
 But if the resolution of the input raster and current region settings don't match - are there straightforward modules that could be applied?  If yes, take action and output a message of what change was made.
 /*ML: AFAIK, raster maps are automatically resampled to current region resolution. Again, this is standard GRASS procedure and probably does not have to be handled by your module(s)*/
@@ -133,7 +134,9 @@
 
 Does it make sense to require the area to be contiguous?
 /*ML: No, I don't think so. If you think about top-down multi-scalar segmentation, i.e. first coarse segmentation, then further segmentation of selected larger segments, non-contiguous areas make sens. Ex: Segment into coarse segments that allow to distinguish vegetation-covered areas from others, then segment these vegetation-covered areas further in order to distinguish types of vegetation.*/
+/*EM: This is different from my understanding, and sounds more like classification.  Wouldn't each further segmentation be handled as unique segements, and later grouped by the classification module into specific types of vegetation?  So if the area isn't contiguous, each island could be processed independently in an outer loop on the algorithm.
 
+
 Check for null cells?  If found, what should be done?
 
 
@@ -149,13 +152,18 @@
 
 If vector borders are provided, do we need to convert them to rasters?  Would lines and polygon's be treated the same?
 /*ML: vector to raster conversion is probably necesary. Pixels crosses by a line (polygon boundary or not) have to become part of a segment boundary.*/
+/*EM: hmm, OK, something else for discussion: These pixels that are on a vector line, should they eventually be included in one of the adjacent segments?  Is "segment boundary" just the edge pixels of the segment, or are the not included in any segment?*/
 
+
 If polygons constraints, check if all pixels are inside of polygons?
 /*ML: What do you mean by "all pixels" ?*/
+/*EM: 100% of the pixels in the raster input map.  But I supposed there will be the boundary pixels.  But my question here is more about what should be done if the input polygon constraints only enclose a portion of the map.  Should it be considered as a mask, and all pixels outside of the polygons are excluded from calculations? */
 
 later: if allow polygons as seeds, get the centroids to use as seeds.
 /*ML: Innocent question: can't you use all pixels in the polygon as seeds ?*/
+/*EM: Yes, if the polygons are input as strict borders, then all pixels in the polygon will be seeds.  but IF the polygon's centroids are only being used to define a sparse set of seeds:  The basic workflow is to require the user to do the preprocessing and give points/centroids vector map as input.  This preprocessing ("later" = if time permits) step would include the step of extracting centroids from an existing polygon vector map inside of the module instead of making the user create a new vector map.*/
 
+
 /*******************************************/
 /************ Processing ********************/
 /*******************************************/
@@ -172,6 +180,7 @@
 
 How to find irregular neighbors for irregular shaped segments?  If we have line constraints, the neighbor selection should not cross the borders.
 /*ML: As you will be working in raster, neighbourhood can be defined at pixel⁻level and so there are no "irregular" neighbors. The question of diagonal neighborhood is obviously open. How does eCognition handle this ?*/
+/*EM: Looks like it is an option to be selected by the user.  According to one power point presentation (not from eCognition, but how to use eCognition software: Normally use 4 neightbor, go to 8 neighbor only if pixels size is similar to feature size. */
 
 If we have polygon constraints.  Outer for loop to process the image one polygon at a time.  (Need to check if all pixels are included in a polygon, otherwise process all those pixels last.)