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

[svn_grass at osgeo.org]

Author: momsen
Date: 2012-05-29 08:22:33 -0700 (Tue, 29 May 2012)
New Revision: 51874

Modified:
   grass-addons/grass7/imagery/i.segment/outline
Log:
continued discussion

Modified: grass-addons/grass7/imagery/i.segment/outline
===================================================================
--- grass-addons/grass7/imagery/i.segment/outline	2012-05-29 15:12:49 UTC (rev 51873)
+++ grass-addons/grass7/imagery/i.segment/outline	2012-05-29 15:22:33 UTC (rev 51874)
@@ -68,6 +68,7 @@
 /*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... */
 /*ML: I'm not sure I really understand what this is about: distance in feature space will be an important element of a region-growing algorithm, so nothing that can be added later. Please elaborate on what you mean to do with color space, here ?*/
+/*EM: I'm basing these comments on "Color image segmentation: advances and prospects" by H.D. Cheng*, X.H. Jiang, Y. Sun, Jingli Wang.  They make some strong statements that using standard color spaces (which I think are similar to landsat bands) as unable to deal with shadows - the magnitude of the color values change with the intensity, so a shadow looks like a different color because the color is muted, not because it is a different color.  Apparently using the non-linear conversion (to get L*u*v*) breaks the correlation of each band to the intensity, and helps segmentation algorithms put together contiguous objects that are partially in shadow.  ! But then they go onto say that non-linear color spaces have their own problems.  So the part that would be added later is to do the preprocessing to convert the color space inside the module.  From your other comments - I expect this should be lower priority and/or included in a seperate module, since it is a different task.*/
 
 /* output parameters */
 need name for new raster and vector map
@@ -140,6 +141,7 @@
 /*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.*/
 /*ML: Exactly, this is why I said that IMHO areas should not be required to be contiguous. The classification argument was just an example to show why. ;-) */
+/*EM: OK! So a check for continueity could be used to lower memory requirements - if there are discontinuous areas, each can be processed sequentially. */
 
 
 Check for null cells?  If found, what should be done?
@@ -159,17 +161,19 @@
 /*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?*/
 /*ML: Here is where a difference comes into play between lines that are boundary polgons and lines as linear features. In my eyes pixels that are on boundarylines of polygons should be part of the segments that are internal to that boundary. Linear features would have to be treated differently. During discussions with colleagues we did have some difficulties finding actual use cases for linear features. Maybe we can start with only polygon features and if the use case of a linear features comes up try to integrate that then ?*/
+/*EM: But for polygons covering the entire map, there is a segment on either side of the polygon line.  If the line crosses the pixel, what should be done... It looks like this will not be a problem for multi-scalar segmentation, the polygons generated in a high level segmentation will be exactly between pixels.  This will only be an issue for polygons generated elsewhere, smoothed, at different resolution, etc.*/
 
-
 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? */
 /*ML: In my eyes mask and input seed regions are different things. You might have some areas for which you already have data (i.e. seed polygons), but this does not mean that you do not want to segment other areas. So, my answer to your question would be no.*/
+/*EM: OK, that makese sense.  So first all pixels inside of polygons can be checked, and finally all remaining pixels are segmented.  This final step will mask what is in the polygons, so they can't be merged.*/
 
 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.*/
 /*ML: I think you should offer the option of inputting a vector map as seed together with the option of which types of features from that input map should be used. No need to do any extraction pre-processing. (See the use of the G_OPT_V_TYPE standard option, and further treatment of the choices made by the user, for example in d.vect or v.distance).*/
+/*EM: sounds good*/
 
 
 /*******************************************/