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

svn_grass at osgeo.org svn_grass at osgeo.org
Fri Oct 26 07:19:42 PDT 2012


Author: momsen
Date: 2012-10-26 07:19:41 -0700 (Fri, 26 Oct 2012)
New Revision: 53562

Modified:
   grass-addons/grass7/imagery/i.segment/create_isegs.c
   grass-addons/grass7/imagery/i.segment/i.segment.html
   grass-addons/grass7/imagery/i.segment/iseg.h
   grass-addons/grass7/imagery/i.segment/open_files.c
   grass-addons/grass7/imagery/i.segment/parse_args.c
Log:
text reflow for html man page and some code comments

Modified: grass-addons/grass7/imagery/i.segment/create_isegs.c
===================================================================
--- grass-addons/grass7/imagery/i.segment/create_isegs.c	2012-10-26 14:03:33 UTC (rev 53561)
+++ grass-addons/grass7/imagery/i.segment/create_isegs.c	2012-10-26 14:19:41 UTC (rev 53562)
@@ -38,8 +38,11 @@
     struct Range range;
 
     /* Modify the threshold for easier similarity comparisons.
-     * For Euclidean, square the threshold so we don't need to calculate the root value in the distance calculation.
-     * In either case, multiplie by the number of input bands, so the same threshold will achieve similar thresholds even for different numbers of input bands.*/
+     * For Euclidean, square the threshold so we don't need to calculate
+     * the root value in the distance calculation.
+     * In either case, multiply by the number of input bands, 
+     * so the same threshold will achieve similar thresholds 
+     * even for different numbers of input bands.*/
     if (functions->calculate_similarity == calculate_euclidean_similarity)
 	functions->threshold =
 	    functions->threshold * functions->threshold * files->nbands;
@@ -58,7 +61,9 @@
 	}
 	Rast_get_range_min_max(&range, &lower_bound, &upper_bound);
 	/* speed enhancement, when processing with bounds: get the unique values.
-	 * As is, we will iterate at one time over the entire raster for each integer between the upper and lower bound, even if no regions exist with that value. */
+	 * As is, we will iterate at one time over the entire raster for 
+	 * each integer between the upper and lower bound, 
+	 * even if no regions exist with that value. */
     }
 
     /* processing loop for polygon/boundary constraints */
@@ -79,8 +84,10 @@
 	files->maxrow = files->maxcol = 0;
 
 	if (files->bounds_map == NULL) {
-	    /* check the NULL flag to see where the first/last row/col of real data are, and reduce the processing window.
-	     * This could help (a little?) if a MASK is used that removes a large border portion of the map. */
+	    /* check the NULL flag to see where the first/last row/col of 
+	     * real data are, and reduce the processing window.
+	     * This could help (a little?) if a MASK is used that 
+	     * removes a large border portion of the map. */
 	    for (row = 0; row < files->nrows; row++) {
 		for (col = 0; col < files->ncols; col++) {
 
@@ -252,7 +259,8 @@
 #endif
 		    Rk_count = 0;
 
-		    /* First pixel in Ri is current row/col pixel.  We may add more later if it is part of a segment */
+		    /* First pixel in Ri is current row/col pixel.  
+		     * We may add more later if it is part of a segment */
 		    Ri_count = 1;
 		    newpixel = (struct pixels *)link_new(files->token);
 		    newpixel->next = NULL;
@@ -322,10 +330,14 @@
 			    }	/* finished similiarity check for all neighbors */
 
 			    /* *** merge all the "very close" pixels/segments *** */
-			    /* doing this after checking all Rin, so we don't change the bands_val between similarity comparisons
-			     * ... but that leaves the possibility that we have the wrong best Neighbor after doing these merges... 
-			     * but it seems we can't put this merge after the Rk/Rkn portion of the loop, because we are changing the available neighbors
-			     * ...maybe this extra "very close" idea has to be done completely differently or dropped???  */
+			    /* doing this after checking all Rin, so we don't 
+			     * change the bands_val between similarity comparisons
+			     * ... but that leaves the possibility that we have 
+			     * the wrong best Neighbor after doing these merges... 
+			     * but it seems we can't put this merge after the Rk/Rkn 
+			     * portion of the loop, because we are changing the available neighbors
+			     * ...maybe this extra "very close" idea has to be 
+			     * done completely differently or dropped???  */
 #ifdef VCLOSE
 			    for (current = Rclose_head; current != NULL;
 				 current = current->next) {
@@ -363,7 +375,8 @@
 				     (files->candidate_flag,
 				      Ri_bestn->row, Ri_bestn->col))) {
 				    /* this check is important:
-				     * best neighbor is not a valid candidate, was already merged earlier in this time step */
+				     * best neighbor is not a valid candidate, 
+				     * was already merged earlier in this time step */
 				    Ri_bestn = NULL;
 				}
 			    }
@@ -428,7 +441,8 @@
 				}
 				else {	/* they weren't mutually best neighbors */
 
-				    /* checked Ri once, didn't find a mutually best neighbor, so remove all members of Ri from candidate pixels for this iteration */
+				    /* checked Ri once, didn't find a mutually best neighbor, 
+				     * so remove all members of Ri from candidate pixels for this iteration */
 				    set_candidate_flag(Ri_head, FALSE, files);
 
 				    if (FLAG_GET
@@ -590,7 +604,8 @@
 				newpixel->col = Ri_bestn->col;
 				Rk_head = newpixel;
 
-				/* get the full pixel/cell membership list for Rk *//* speed enhancement: a seperate function for this, since we don't need the neighbors */
+				/* get the full pixel/cell membership list for Rk */
+				/* speed enhancement: a seperate function for this, since we don't need the neighbors */
 				find_segment_neighbors(&Rk_head, &Rkn_head,
 						       &Rk_count, files,
 						       functions);
@@ -634,8 +649,11 @@
     return TRUE;
 }
 
-    /* perimeter todo, for now will return borderPixels instead of passing a pointer, I saw mentioned that each parameter slows down the function call? */
-    /* perimeter todo, My first impression is that the borderPixels count is ONLY needed for the case of initial seeds, and not used later on.  Another reason to split the function... */
+    /* perimeter todo, for now will return borderPixels instead of passing a pointer,
+     * I saw mentioned that each parameter slows down the function call? */
+    /* perimeter todo, My first impression is that the borderPixels count is 
+     * ONLY needed for the case of initial seeds, and not used later on.  
+     * Another reason to split the function... */
 int find_segment_neighbors(struct pixels **R_head,
 			   struct pixels **neighbors_head, int *seg_count,
 			   struct files *files, struct functions *functions)
@@ -787,10 +805,13 @@
 			    newpixel->count_shared = 1;	/*for shared perimeter */
 			    *neighbors_head = newpixel;	/*change the first pixel to be the new pixel. */
 			}
-			else {	/* todo perimeter we need to keep track of (and return!) a total count of neighbors pixels for each neighbor segment, to update the perimeter value in the similarity calculation. */
+			else {	/* todo perimeter we need to keep track of (and return!) a 
+				 * total count of neighbors pixels for each neighbor segment, 
+				 * to update the perimeter value in the similarity calculation. */
 			    /* todo perimeter: need to initalize this somewhere!!! */
 			    /* todo perimeter... need to find pixel with same segment ID....  countShared++;
-			     * hmmm,  Should we change the known_iseg tree to sort on segment ID...need to think of fast way to return this count?  with pixel?  or with something else? */
+			     * hmmm,  Should we change the known_iseg tree to sort on segment ID...
+			     * need to think of fast way to return this count?  with pixel?  or with something else? */
 
 			    /* need to increment the count of border pixels for later know the shared border for calculating the new perimeter. */
 			    if (functions->radio_weight < 1) {	/* TODO: any reason to calculate this if we have a weight of 0 for the shape features? */
@@ -902,7 +923,9 @@
 
     /* similarity / distance functions between two points based on their input raster values */
     /* assumes first point values already saved in files->bands_seg */
-    /* speed enhancement: segment_get was already done for a[] values in the main function.  Could remove a[] from these parameters, reducing number of parameters in function call could provide a speed improvement. */
+    /* speed enhancement: segment_get was already done for a[] values in the main function.  
+     * Could remove a[] from these parameters, reducing number of parameters in 
+     * function call could provide a speed improvement. */
 
 double calculate_euclidean_similarity(struct pixels *a, struct pixels *b,
 				      struct files *files,
@@ -923,7 +946,8 @@
 					    files->second_val[n]);
     }
 
-    /* use squared distance, save the calculation time. We squared the similarity threshold earlier to allow for this. */
+    /* use squared distance, save the calculation time. 
+     * We squared the similarity threshold earlier to allow for this. */
     /* val = sqrt(val); */
 
     if (functions->radio_weight < 1) {
@@ -931,7 +955,8 @@
 	val = val * functions->radio_weight;
 
 	/*remaining part of similarity is based on the current shape of the object. */
-	/*I assume the idea is to add to the similarity information about the shape of the new segment if the two candidates were to be merged. */
+	/*I assume the idea is to add to the similarity information about the 
+	 * shape of the new segment if the two candidates were to be merged. */
 
 	PL = files->bands_val[files->nbands + 1] +
 	    files->second_val[files->nbands + 1] - b->count_shared;
@@ -1016,7 +1041,11 @@
     int n, Ri_iseg, Rk_iseg;
     struct pixels *current;
 
-    /*get input values *//*speed enhancement: Confirm if we can assume we already have bands_val for Ri, so don't need to segment_get() again?  note...current very_close implementation requires getting this value again... */
+    /*get input values */
+    /*speed enhancement: Confirm if we can assume we already have 
+     * bands_val for Ri, so don't need to segment_get() again?  
+     * note...current very_close implementation requires 
+     * getting this value again... */
     segment_get(&files->bands_seg, (void *)files->bands_val, Ri_head->row,
 		Ri_head->col);
     segment_get(&files->bands_seg, (void *)files->second_val,
@@ -1098,7 +1127,8 @@
 
 	/* add in the shape values */
 	files->bands_val[files->nbands] = count;	/* area (Num Pixels) */
-	files->bands_val[files->nbands + 1] = borderPixels;	/* Perimeter Length *//* todo perimeter, not exact for edges...close enough for now? */
+	files->bands_val[files->nbands + 1] = borderPixels;	/* Perimeter Length */
+	/* todo perimeter, not exact for edges...close enough for now? */
 
 	/* save the results */
 	for (current = R_head; current != NULL; current = current->next) {
@@ -1149,7 +1179,8 @@
 
     /* functions used by binary tree to compare items */
 
-    /* speed enhancement: Maybe changing this would be an improvement? "static" was used in break_polygons.c  extern was suggested in docs.  */
+    /* speed enhancement: Maybe changing this would be an improvement? 
+     * "static" was used in break_polygons.c  extern was suggested in docs.  */
 
 int compare_ids(const void *first, const void *second)
 {

Modified: grass-addons/grass7/imagery/i.segment/i.segment.html
===================================================================
--- grass-addons/grass7/imagery/i.segment/i.segment.html	2012-10-26 14:03:33 UTC (rev 53561)
+++ grass-addons/grass7/imagery/i.segment/i.segment.html	2012-10-26 14:19:41 UTC (rev 53562)
@@ -1,110 +1,114 @@
 <h2>DESCRIPTION</h2>
 Image segmentation is the process of grouping similar pixels into 
-unique segments. Boundary and region based algorithms are described in 
-the literature, currently a region growing and merging algorithm is 
-implemented.  Each grouping (usually refered to as objects or segments) 
-found during the segmentation process is 
-given a unique ID and is a collection of contiguous pixels meeting some 
-criteria.  (Note the contrast with image classification, where 
-continuity and spatial characteristics are not important, but rather 
-only the spectral similarity.)  The results can be useful on their own, 
-or used as a preprocessing step for image classification.  The 
+unique segments. Boundary and region based algorithms are described 
+in the literature, currently a region growing and merging algorithm 
+is implemented.  Each grouping (usually refered to as objects or 
+segments) found during the segmentation process is given a unique ID 
+and is a collection of contiguous pixels meeting some criteria.  
+(Note the contrast with image classification, where continuity and 
+spatial characteristics are not important, but rather only the 
+spectral similarity.)  The results can be useful on their own, or 
+used as a preprocessing step for image classification.  The 
 segmentation preprocessing step can reduce noise and speed up the 
 classification.
 
 <H2>NOTES</h2>
 
 <h3>Region Growing and Merging</h3>
-This segmentation algorithm sequentially examines all current segments 
-in the map.  The similarity between the current segment and each of its 
-neighbors is calculated according to the given distance formula.  
-Segments will be merged if they meet a number of criteria, including: 
-1.  The pair is mutually most similar to each other (the similarity 
-distance will be smaller then all other neighbors), and 2. The 
-similarity must be lower then the input threshold.  All segments are 
-checked once per pass.  The process is repeated until no merges are 
-made during a complete pass.
+This segmentation algorithm sequentially examines all current 
+segments in the map.  The similarity between the current segment and 
+each of its neighbors is calculated according to the given distance 
+formula. Segments will be merged if they meet a number of criteria, 
+including: 1.  The pair is mutually most similar to each other (the 
+similarity distance will be smaller then all other neighbors), and 
+2. The similarity must be lower then the input threshold.  All 
+segments are checked once per pass.  The process is repeated until 
+no merges are made during a complete pass.
 
 <h3>Similarity and Threshold</h3>
-The similarity between segments and unmerged pixels is used to determine 
-which are merged.  The Euclidean version uses the radiometric distance 
-between the two segments and also the shape characteristics.  
-The Manhatten calculations currently only uses only the radiometric distance 
-between the two segments, but eventually shape characteristics will be 
-included as well.  NOTE: Closer/smaller distances mean a lower value for 
-the similarity indicates a closer match, with a similarity score of zero 
-for identical pixels.
+The similarity between segments and unmerged pixels is used to 
+determine which are merged.  The Euclidean version uses the 
+radiometric distance between the two segments and also the shape 
+characteristics. The Manhatten calculations currently only uses only 
+the radiometric distance between the two segments, but eventually 
+shape characteristics will be included as well.  NOTE: 
+Closer/smaller distances mean a lower value for the similarity 
+indicates a closer match, with a similarity score of zero for 
+identical pixels.
 <p>
-During normal processing, merges are only allowed when the similarity 
-between two segments is lower then the calculated threshold value.  
-During the final pass, however, if a minimum segment size of 2 or 
-larger is given with the <em>minsize</em> parameter, segments with a 
-smaller pixel count will be merged with their most similar neighbor 
-even if the similarity is greater then the threshold.
+During normal processing, merges are only allowed when the 
+similarity between two segments is lower then the calculated 
+threshold value. During the final pass, however, if a minimum 
+segment size of 2 or larger is given with the <em>minsize</em> 
+parameter, segments with a smaller pixel count will be merged with 
+their most similar neighbor even if the similarity is greater then 
+the threshold.
 <p>
 Unless the <em>-w</em> flag for weighted data is used, the threshold 
 should be set by the user between 0 and 1.0. A threshold of 0 would 
-allow only identical valued pixels to be merged, while a threshold of 1 
-would allow everything to be merged.
+allow only identical valued pixels to be merged, while a threshold 
+of 1 would allow everything to be merged.
 <p>
-The threshold will be multiplied by the number of rasters included in 
-the image group.  This will allow the same threshold to achieve similar 
-segmentation results when the number of rasters in the image group varies.
+The threshold will be multiplied by the number of rasters included 
+in the image group.  This will allow the same threshold to achieve 
+similar segmentation results when the number of rasters in the image 
+group varies.
 <p>
-The -t flag will estimate the threshold, it is calculated at 3% of the
-range of data in the imagery group.  Initial empirical tests indicate
-threshold values of 1% to 5% are reasonable places to start.
+The -t flag will estimate the threshold, it is calculated at 3% of 
+the range of data in the imagery group.  Initial empirical tests 
+indicate threshold values of 1% to 5% are reasonable places to start.
 
 <h4>Calculation Formulas</h4>
-Both Euclidean and Manhattan distances use the normal definition, considering
-each raster in the image group as a dimension.
+Both Euclidean and Manhattan distances use the normal definition, 
+considering each raster in the image group as a dimension.
 
-Furthermore, the Euclidean calculation also takes into account the shape
-characteristics of the segments.  The normal distances are multiplied by 
-the input radiometric weight.  Next an additional contribution is added:
-(1-radioweight) * {smoothness * smoothness weight + compactness * (1-smoothness weight)},
-where compactness = the Perimeter Length / sqrt( Area ) and smoothness = Perimeter Length / 
-the Bounding Box.  The perimeter length is estimated as the number of pixel sides
-the segment has.
+Furthermore, the Euclidean calculation also takes into account the 
+shape characteristics of the segments.  The normal distances are 
+multiplied by the input radiometric weight.  Next an additional 
+contribution is added: (1-radioweight) * {smoothness * smoothness 
+weight + compactness * (1-smoothness weight)}, where compactness = 
+the Perimeter Length / sqrt( Area ) and smoothness = Perimeter 
+Length / the Bounding Box.  The perimeter length is estimated as the 
+number of pixel sides the segment has.
 
 <h3>Seeds</h3>
 The seeds map can be used to provide either seed pixels (random or 
-selected points from which to start the segmentation process) or seed 
-segments (results of previous segmentations or classifications).  The 
-different approaches are automatically detected by the program: any 
-pixels that have identical seed values and are contiguous will be 
-lumped into a single segment ID.
+selected points from which to start the segmentation process) or 
+seed segments (results of previous segmentations or 
+classifications).  The different approaches are automatically 
+detected by the program: any pixels that have identical seed values 
+and are contiguous will be lumped into a single segment ID.
 <p>
-It is expected that the <em>minsize</em> will be set to 1 if a seed map 
-is used, but the program will allow other values to be used.  If both 
-options are used, the final iteration that ignores the threshold also 
-will ignore the seed map and force merges for all pixels (not just 
-segments that have grown/merged from the seeds).
+It is expected that the <em>minsize</em> will be set to 1 if a seed 
+map is used, but the program will allow other values to be used.  If 
+both options are used, the final iteration that ignores the 
+threshold also will ignore the seed map and force merges for all 
+pixels (not just segments that have grown/merged from the seeds).
 
 <h3>Maximum number of starting segments</h3>
-For the region growing algorithm without starting seeds, each pixel is 
-sequentially numbered.  The current limit with CELL storage is 2 
-billion starting segment ID's.  If the initial map has a larger number 
-of non-null pixels, there are two workarounds:
+For the region growing algorithm without starting seeds, each pixel 
+is sequentially numbered.  The current limit with CELL storage is 2 
+billion starting segment ID's.  If the initial map has a larger 
+number of non-null pixels, there are two workarounds:
 <p>
-1.  Use starting seed pixels.  (Maximum 2 billion pixels can be labeled 
-with positive integers.)
+1.  Use starting seed pixels.  (Maximum 2 billion pixels can be 
+labeled with positive integers.)
 <p>
 2.  Use starting seed segments.  (By initial classification or other 
 methods.)
 
 <h3>Boundary Constraints</h3>
-Boundary constraints limit the adjacency of pixels and segments.  Each 
-unique value present in the <em>bounds</em> raster are considered as a 
-MASK.  Thus no segments in the final segmentated map will cross a 
-boundary, even if their spectral data is very similar.
+Boundary constraints limit the adjacency of pixels and segments.  
+Each unique value present in the <em>bounds</em> raster are 
+considered as a MASK.  Thus no segments in the final segmentated map 
+will cross a boundary, even if their spectral data is very similar.
 
 <h3>Minimum Segment Size</h3>
-To reduce the salt and pepper affect, a <em>minsize</em> greater than 1 
-will add one additional pass to the processing.  During the final pass, 
-the threshold is ignored for any segments smaller then the set size, 
-thus forcing very small segments to merge with their most similar 
-neighbor.
+To reduce the salt and pepper affect, a <em>minsize</em> greater 
+than 1 will add one additional pass to the processing.  During the 
+final pass, the threshold is ignored for any segments smaller then 
+the set size, thus forcing very small segments to merge with their 
+most similar neighbor.
 
 <h2>EXAMPLES</h2>
 This example uses the ortho photograph included in the NC Sample 
@@ -113,10 +117,10 @@
 i.group group=ortho_group input=ortho_2001_t792_1m at PERMANENT
 </pre></div>
 
-<p>Because the segmentation process is computationally expensive, start 
-with a small processing area to confirm if the segmentation results 
-meet your requirements.  Some manual adjustment of the threshold may be 
-required. <br>
+<p>Because the segmentation process is computationally expensive, 
+start with a small processing area to confirm if the segmentation 
+results meet your requirements.  Some manual adjustment of the 
+threshold may be required. <br>
 
 <div class="code"><pre>
 g.region rast=ortho_2001_t792_1m at PERMANENT n=220400 s=220200 e=639000 w=638800
@@ -153,13 +157,15 @@
           threshold=10 method=region_growing minsize=5 endt=5000
 </pre></div>
 <p>
-Processing the entire ortho image (over 9 million pixels) took about a day.
+Processing the entire ortho image (over 9 million pixels) took about 
+a day.
 
 <h2>TODO</h2>
 <h3>Functionality</h3>
 <ul>
-<li>Further testing of the shape characteristics (smoothness, compactness),
-if it looks good it should be added to the Manhatten option.
+<li>Further testing of the shape characteristics (smoothness, 
+compactness), if it looks good it should be added to the Manhatten 
+option.
 <b>in progress</b></li>
 <li>Malahanobis distance for the similarity calculation.</li>
 </ul>
@@ -193,12 +199,14 @@
 after the seed map has been processed.)
 <H2>REFERENCES</h2>
 This project was first developed during GSoC 2012.  Project 
-documentation, Image Segmentation references, and other information is 
-at the <a href="http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation">project wiki</a>.
+documentation, Image Segmentation references, and other information 
+is at the <a href=
+"http://grass.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation">
+project wiki</a>.
 <p>
-Information about
-<a href="http://grass.osgeo.org/wiki/Image_classification">classification 
-in GRASS GIS</a> is also available on the wiki.
+Information about <a href=
+"http://grass.osgeo.org/wiki/Image_classification">classification in 
+GRASS GIS</a> is also available on the wiki.
 
 <h2>SEE ALSO</h2>
 <em>

Modified: grass-addons/grass7/imagery/i.segment/iseg.h
===================================================================
--- grass-addons/grass7/imagery/i.segment/iseg.h	2012-10-26 14:03:33 UTC (rev 53561)
+++ grass-addons/grass7/imagery/i.segment/iseg.h	2012-10-26 14:19:41 UTC (rev 53562)
@@ -30,7 +30,10 @@
     struct pixels *next;
     int row;
     int col;
-    int count_shared;		/* todo perimeter: will hold the count how many pixels are shared on the Border Between Ri and Rk.  Not used for all pixels... see if this is an OK way to do this... */
+    int count_shared;		/* todo perimeter: will hold the count how 
+				 * many pixels are shared on the Border Between 
+				 * Ri and Rk.  Not used for all pixels... see if 
+				 * this is an OK way to do this... */
 };
 
 /* input and output files, as well as some other processing info */
@@ -64,7 +67,8 @@
 
     /* processing flags */
     /* candidate flag for if a cell/segment has already been merged in that pass. */
-    /* seeds flag for if a cell/segment is a seed (can be Ri to start a merge).  All cells are valid seeds if a starting seeds map is not supplied. */
+    /* seeds flag for if a cell/segment is a seed (can be Ri to start a merge).
+     *   All cells are valid seeds if a starting seeds map is not supplied. */
     FLAG *candidate_flag, *null_flag, *orig_null_flag, *seeds_flag;
 
     /* memory management, linked lists */
@@ -90,14 +94,20 @@
     int limited;		/* flag if we are limiting merges to one per pass */
     int estimate_threshold;	/* flag if we just want to estimate a suggested threshold value and exit. */
 
-    /* todo: is there a fast way (and valid from an algorithm standpoint) to merge all neighbors that are within some small % of the treshold?
-     * There is some code using "very_close" that is excluded with IFDEF
-     * The goal is to speed processing, since in the end many of these very similar neighbors will be merged.
-     * But the problem is that the find_segment_neighbors() function only returns a single pixel, not the entire segment membership.
-     * The commented out code actually slowed down processing times in the first tries. */
+    /* todo: is there a fast way (and valid from an algorithm 
+       standpoint) to merge all neighbors that are within some small % 
+       of the treshold? * There is some code using "very_close" that is 
+       excluded with IFDEF * The goal is to speed processing, since in 
+       the end many of these very similar neighbors will be merged. * 
+       But the problem is that the find_segment_neighbors() function 
+       only returns a single pixel, not the entire segment membership. 
+       * The commented out code actually slowed down processing times 
+       in the first tries. */
 #ifdef VCLOSE
-    double very_close;		/* segments with very_close similarity will be merged without changing or checking the candidate flag.
-				 *   The algorithm will continue looking for the "most similar" neighbor that isn't "very close". */
+    double very_close;		/* segments with very_close similarity 
+				 * will be merged without changing or checking the candidate flag. 
+				 * The algorithm will continue looking for the "most similar" 
+				 * neighbor that isn't "very close". */
 #endif
 };
 

Modified: grass-addons/grass7/imagery/i.segment/open_files.c
===================================================================
--- grass-addons/grass7/imagery/i.segment/open_files.c	2012-10-26 14:03:33 UTC (rev 53561)
+++ grass-addons/grass7/imagery/i.segment/open_files.c	2012-10-26 14:19:41 UTC (rev 53562)
@@ -152,7 +152,8 @@
     /* ******* remaining memory allocation ********* */
 
     /* save the area and perimeter as well */
-    /* perimeter todo: currently saving this with the input DCELL values.  Better to have a second segment structure to save as integers ??? */
+    /* perimeter todo: currently saving this with the input DCELL values.  
+     * Better to have a second segment structure to save as integers ??? */
     /* along with P and A, also saving the bounding box - min/max row/col */
 
     /* Why was this being reset here??? commented out... 
@@ -276,7 +277,8 @@
     files->token = link_init(sizeof(struct pixels));
 
     /* if we have seeds that are segments (not pixels) we need to update the bands_seg */
-    /* also renumber the segment ID's in case they were classified (duplicating numbers) instead of output from i.segment. */
+    /* also renumber the segment ID's in case they were classified 
+     * (duplicating numbers) instead of output from i.segment. */
     if (files->seeds_map != NULL) {
 
 	/*initialization */
@@ -290,7 +292,9 @@
 	current = NULL;
 	set_all_candidate_flags(files);
 	for (row = 0; row < files->nrows; row++) {
-	    G_percent(row, files->nrows, 1);	/* I think this is the longest part of open_files() - not entirely accurate for the actual %, but will give the user something to see. */
+	    G_percent(row, files->nrows, 1);	/* I think this is the longest part of open_files()
+						 * - not entirely accurate for the actual %,
+						 *  but will give the user something to see. */
 	    for (col = 0; col < files->ncols; col++) {
 		if (!(FLAG_GET(files->candidate_flag, row, col)) ||
 		    FLAG_GET(files->null_flag, row, col))
@@ -302,8 +306,13 @@
 		newpixel->col = col;
 		R_head = newpixel;
 
-		/* get pixel list, possible initialization speed enhancement: could use a custom (shorter) function, some results from find_segment_neighbors are not used here */
-		/* bug todo: There is a small chance that a renumbered segment matches and borders an original segment.  This would be a good reason to write a custom function - use the candidate flag to see if the pixel was already processed. */
+		/* get pixel list, possible initialization speed enhancement: 
+		 * could use a custom (shorter) function, some results from 
+		 * find_segment_neighbors are not used here */
+		/* bug todo: There is a small chance that a renumbered segment 
+		 * matches and borders an original segment.  This would be a 
+		 * good reason to write a custom function - use the candidate 
+		 * flag to see if the pixel was already processed. */
 		borderPixels =
 		    find_segment_neighbors(&R_head, &Rn_head, &R_count, files,
 					   functions);

Modified: grass-addons/grass7/imagery/i.segment/parse_args.c
===================================================================
--- grass-addons/grass7/imagery/i.segment/parse_args.c	2012-10-26 14:03:33 UTC (rev 53561)
+++ grass-addons/grass7/imagery/i.segment/parse_args.c	2012-10-26 14:19:41 UTC (rev 53562)
@@ -20,7 +20,9 @@
 #endif
 
     /* required parameters */
-    group = G_define_standard_option(G_OPT_I_GROUP);	/* enhancement: consider giving the option to process just one raster directly, without creating an image group. */
+    /* enhancement: consider giving the option to process just one
+     * raster directly, without creating an image group. */
+    group = G_define_standard_option(G_OPT_I_GROUP);
 
     output = G_define_standard_option(G_OPT_R_OUTPUT);
 
@@ -105,7 +107,8 @@
     weighted->description =
 	_("Weighted input, don't perform the default scaling of input maps.");
 
-    /* Raster for initial segment seeds *//* future enhancement: allow vector points/centroids for seed input. */
+    /* Raster for initial segment seeds */
+    /* future enhancement: allow vector points/centroids for seed input. */
     seeds = G_define_standard_option(G_OPT_R_INPUT);
     seeds->key = "seeds";
     seeds->required = NO;
@@ -130,9 +133,12 @@
     endt->description =
 	_("Maximum number of passes (time steps) to complete.");
 
-    /* Leaving path flag out of user options, will hardcode TRUE for this option.  This does change the resulting segments, but I don't see any
-     * reason why one version is more valid.  It reduced the processing time by 50% when segmenting the ortho image. 
-     * Code in the segmenation algorithm remains, in case more validation of this option should be done. */
+    /* Leaving path flag out of user options, will hardcode TRUE for 
+       this option.  This does change the resulting segments, but I 
+       don't see any reason why one version is more valid.  It 
+       reduced the processing time by 50% when segmenting the ortho 
+       image. Code in the segmenation algorithm remains, in case more 
+       validation of this option should be done. */
     /*
        path = G_define_flag();
        path->key = 'p';
@@ -211,7 +217,8 @@
     }
     /* speed enhancement: Check if function pointer or IF statement is faster */
 
-    /* default/0 for performing the scaling, but selected/1 if user has weighted values so scaling should be skipped. */
+    /* default/0 for performing the scaling, but selected/1 if 
+     * user has weighted values so scaling should be skipped. */
     files->weighted = weighted->answer;
 
     /* check if optional seeds map was given, if not, use all pixels as starting seeds. */
@@ -258,7 +265,8 @@
 
     /* other parameters */
 
-    /* default/0 for no pathflag, but selected/1 to use Rk as next Ri if not mutually best neighbors. */
+    /* default/0 for no pathflag, but selected/1 to use 
+     * Rk as next Ri if not mutually best neighbors. */
     /* functions->path = path->answer; */
     functions->path = TRUE;
     /* see notes above about pathflag. */



More information about the grass-commit mailing list