GRASS GSoC 2012 Image Segmentation - Revision history

Neteler: r.seg --> r.smooth.seg

2015-12-22T08:02:38Z

r.seg --> r.smooth.seg

← Older revision		Revision as of 08:02, 22 December 2015
Line 27:		Line 27:
	=Background=		=Background=

	Image classification techniques already implemented in GRASS GIS include supervised and unsupervised classification. Classification of images based on pixels can often be very noisy. By first segmenting the image, later classification of 'objects' can be more effective. Noise is reduced, classification speed is increased, and most importantly the classification is performed on objects instead of pixels. The {{cmd\|i.smap}} module does include a segmentation step (based on Gaussian mixture distribution), but there does not exist a module intended to segment the image and provide segment data for general use. A summary of the existing methods implemented in GRASS are at [[Image classification]]. Furthermore, the module {{AddonCmd\|r.seg}} in GRASS-addons uses internally the Mumford-Shah variational model for image segmentation.		Image classification techniques already implemented in GRASS GIS include supervised and unsupervised classification. Classification of images based on pixels can often be very noisy. By first segmenting the image, later classification of 'objects' can be more effective. Noise is reduced, classification speed is increased, and most importantly the classification is performed on objects instead of pixels. The {{cmd\|i.smap}} module does include a segmentation step (based on Gaussian mixture distribution), but there does not exist a module intended to segment the image and provide segment data for general use. A summary of the existing methods implemented in GRASS are at [[Image classification]]. Furthermore, the module {{AddonCmd\|r.smooth.seg}} in GRASS-addons uses internally the Mumford-Shah variational model for image segmentation.

	== Segmentation Methods ==		== Segmentation Methods ==

⚠️NikosA: /* SPOT5 scene */ put code in

2013-08-08T12:48:09Z

SPOT5 scene: put code in <source lang="bash">

← Older revision		Revision as of 12:48, 8 August 2013
Line 297:		Line 297:
	Here's the code used to generate this segmentation result:		Here's the code used to generate this segmentation result:

			<source lang="bash">
	i.segment group=spot output=spot_seg threshold=0.01 endt=10000 min=30 --o		i.segment group=spot output=spot_seg threshold=0.01 endt=10000 min=30 --o
			</source>

	The segmentation performed in 87m3.870s on a Intel Core 2 workstation with 8Go RAM. The memory consumption was around 170 Mo.		The segmentation performed in 87m3.870s on a Intel Core 2 workstation with 8Go RAM. The memory consumption was around 170 Mo.

⚠️NikosA: /* Ortho-photo */ put code inside

2013-08-06T22:03:39Z

Ortho-photo: put code inside <source lang="bash">

← Older revision		Revision as of 22:03, 6 August 2013
Line 283:		Line 283:
	Here's the code used to generate this segmentation result:		Here's the code used to generate this segmentation result:

			<source lang="bash">
	i.segment group=ortho output=ortho_segs_ha threshold=0.02 endt=10000 final_mean=ortho_segs_mean_ha min=20 --o		i.segment group=ortho output=ortho_segs_ha threshold=0.02 endt=10000 final_mean=ortho_segs_mean_ha min=20 --o
			</source>

	The segmentation performed in 22m53.255s on a Intel i5 laptop with 4Go RAM. The memory consumption was around 38 Mo.		The segmentation performed in 22m53.255s on a Intel i5 laptop with 4Go RAM. The memory consumption was around 38 Mo.

⚠️HamishBowman: moved to trunk

2013-04-14T06:03:17Z

moved to trunk

← Older revision		Revision as of 06:03, 14 April 2013
Line 12:		Line 12:
	\|-		\|-
	\|-		\|-
	\| Repository: \|\| ~~AddOns~~, browse at: [https://trac.osgeo.org/grass/browser/grass~~-addons~~/~~grass7~~/imagery/i.segment i.segment]		\| Repository: \|\| GRASS 7, browse at: [https://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.segment i.segment]
	\|-		\|-
	\|}		\|}

⚠️Emomsen: /* ToDo List */ finalized list.

2012-08-20T15:13:43Z

ToDo List: finalized list.

← Older revision		Revision as of 15:13, 20 August 2012
Line 187:		Line 187:

	The following list was developed at the "mid" point review, with about 1 month left. Rating system is 1: must do, 2: would be nice, 3: probably only will be finished if it is a quick task.		The following list was developed at the "mid" point review, with about 1 month left. Rating system is 1: must do, 2: would be nice, 3: probably only will be finished if it is a quick task.

			The list has been updated for the status at the end of GSoC 2012. Remaining items to be developed later are added to the TODO manual section. Further progress and new features requests will not be added to this listing.

	== Functionality ==		== Functionality ==

⚠️Emomsen: /* Polish */

2012-08-20T15:11:48Z

Polish

← Older revision		Revision as of 15:11, 20 August 2012
Line 252:		Line 252:
	<del>2: Make the output segment ID's sequential (currently they have what ID the "first" pixel in the segment had).</del> Decided not to do this.		<del>2: Make the output segment ID's sequential (currently they have what ID the "first" pixel in the segment had).</del> Decided not to do this.

	<del>2: There are many small TODO scattered in the code. Resolve some easy questions to clean up the code.<del> Resolved most. Some are left as enhancement suggestions for later.		<del>2: There are many small TODO scattered in the code. Resolve some easy questions to clean up the code.</del> Resolved most. Some are left as enhancement suggestions for later.

	<del>2: Change G_percentage: estimate total number of passes expected from histogram and threshold. (If this isn't reliabe, maybe change to show 1% for each pass, i.e. % complete out of first 100 passes, then % complete out of next 100 passes, etc.)</del> Using % complete of the input number of passes threshold.		<del>2: Change G_percentage: estimate total number of passes expected from histogram and threshold. (If this isn't reliabe, maybe change to show 1% for each pass, i.e. % complete out of first 100 passes, then % complete out of next 100 passes, etc.)</del> Using % complete of the input number of passes threshold.

⚠️Emomsen: /* Polish */ Updated list

2012-08-20T15:11:04Z

Polish: Updated list

← Older revision		Revision as of 15:11, 20 August 2012
Line 248:		Line 248:
	== Polish ==		== Polish ==

	1: Add error traps. (Certainly for memory allocation, Minimum number of non-NULL cells in the input bands?anything else?)		<del>1: Add error traps. (Certainly for memory allocation, Minimum number of non-NULL cells in the input bands?anything else?)</del> Added some additional checks.

	2: Make the output segment ID's sequential (currently they have what ID the "first" pixel in the segment had).		<del>2: Make the output segment ID's sequential (currently they have what ID the "first" pixel in the segment had).</del> Decided not to do this.

	2: There are many small TODO scattered in the code. Resolve some easy questions to clean up the code.		<del>2: There are many small TODO scattered in the code. Resolve some easy questions to clean up the code.<del> Resolved most. Some are left as enhancement suggestions for later.

	2: Change G_percentage: estimate total number of passes expected from histogram and threshold. (If this isn't reliabe, maybe change to show 1% for each pass, i.e. % complete out of first 100 passes, then % complete out of next 100 passes, etc.)		<del>2: Change G_percentage: estimate total number of passes expected from histogram and threshold. (If this isn't reliabe, maybe change to show 1% for each pass, i.e. % complete out of first 100 passes, then % complete out of next 100 passes, etc.)</del> Using % complete of the input number of passes threshold.

	3: GUI (to combine i.segment with the stats module)		<del>3: GUI (to combine i.segment with the stats module)</del> Wait until there is user demand for this.

	== Documentation ==		== Documentation ==

⚠️Emomsen: /* Memory */ Updated list

2012-08-20T15:09:09Z

Memory: Updated list

← Older revision		Revision as of 15:09, 20 August 2012
Line 240:		Line 240:
	2: Consider putting the optional boundary constraints raster into RAM (dependent on available RAM).		2: Consider putting the optional boundary constraints raster into RAM (dependent on available RAM).

	2: Use "zero" for segment ID's of Null cells, discard the NULL flag. (Need to check speed impact with Seg ID in SEG storage.)		<del>2: Use "zero" for segment ID's of Null cells, discard the NULL flag. (Need to check speed impact with Seg ID in SEG storage.)</del> Decided not to do this.

	3: Check input map type(s), currently storing in DCELL sized SEG file, could reduce this dynamically depending on input map time. (Could only reduce to FCELL, since will be storing mean we can't use CELL. Might not be worth the added code complexity.)		3: Check input map type(s), currently storing in DCELL sized SEG file, could reduce this dynamically depending on input map time. (Could only reduce to FCELL, since will be storing mean we can't use CELL. Might not be worth the added code complexity.)

	3: Put segment ID in SEG instead of RAM. (Possibly make this dependent on available RAM?) (Only consider if we run into RAM limitations.)		<del>3: Put segment ID in SEG instead of RAM. (Possibly make this dependent on available RAM?) (Only consider if we run into RAM limitations.)</del> Implemented

	== Polish ==		== Polish ==

⚠️Emomsen: /* Speed */ updated list

2012-08-20T15:08:21Z

Speed: updated list

← Older revision		Revision as of 15:08, 20 August 2012
Line 226:		Line 226:
	<del>2: Search continuation. If Ri isn't Rk's best neighbor, then use Rk as the next Ri. (Skips one neighbor finding routine.)</del> TODO: need to decide if this should stay in or out, or as an option. Currently implemented as an option. Need to do some speed tests to see if it is faster or slower after finishing some other changes.		<del>2: Search continuation. If Ri isn't Rk's best neighbor, then use Rk as the next Ri. (Skips one neighbor finding routine.)</del> TODO: need to decide if this should stay in or out, or as an option. Currently implemented as an option. Need to do some speed tests to see if it is faster or slower after finishing some other changes.

	2: Consider peano or other ordering for pixel processing (instead of row major order), should help processing time if an entire "row" of segments are not in RAM.		<del>2: Consider peano or other ordering for pixel processing (instead of row major order), should help processing time if an entire "row" of segments are not in RAM.</del> implemented. No significant time change on the small maps it was tested on. Probably this will be helpful if disk I/O becomes limiting.

	3: neighbor finding: When checking for Rk's neighbors, account for already knowing Ri and skip those pixels.		3: neighbor finding: When checking for Rk's neighbors, account for already knowing Ri and skip those pixels.

	?: change candidate flag to int (compare with pass number) to avoid resetting each time. (32x RAM requirement for the flag, is it worth it?)		<del>?: change candidate flag to int (compare with pass number) to avoid resetting each time. (32x RAM requirement for the flag, is it worth it?)</del> Decided not to change this.

	?: RAM storage of the segment membership and the neighboring segments (calculate first the requirements, if this is even possible for reasonable (what size?) maps). (check what % of the processing time is spent finding neighbors.)		?: RAM storage of the segment membership and the neighboring segments (calculate first the requirements, if this is even possible for reasonable (what size?) maps). (check what % of the processing time is spent finding neighbors.)

⚠️Emomsen: /* Project Plan */ Added links to reports.

2012-08-20T15:05:56Z

Project Plan: Added links to reports.

← Older revision		Revision as of 15:05, 20 August 2012
Line 147:		Line 147:
	* Week 1: Develop pseudocode to outline the work [http://lists.osgeo.org/pipermail/soc/2012-May/001747.html Report 1]		* Week 1: Develop pseudocode to outline the work [http://lists.osgeo.org/pipermail/soc/2012-May/001747.html Report 1]
	* Week 2-4: Implement the main algorithm [http://lists.osgeo.org/pipermail/soc/2012-June/001779.html Report 2] [http://lists.osgeo.org/pipermail/soc/2012-June/001804.html Report 3] [http://lists.osgeo.org/pipermail/soc/2012-June/001826.html Report 4]		* Week 2-4: Implement the main algorithm [http://lists.osgeo.org/pipermail/soc/2012-June/001779.html Report 2] [http://lists.osgeo.org/pipermail/soc/2012-June/001804.html Report 3] [http://lists.osgeo.org/pipermail/soc/2012-June/001826.html Report 4]
	* Week 5: Add vector maps as a constraint to the segmentation		* Week 5: Add vector maps as a constraint to the segmentation [http://lists.osgeo.org/pipermail/soc/2012-June/001854.html Report 5]
	* Week 6: Validation		* Week 6: Validation [http://lists.osgeo.org/pipermail/soc/2012-June/001879.html Report 6]
	* Week 7: Debugging		* Week 7: Debugging [http://lists.osgeo.org/pipermail/soc/2012-July/001898.html Report 7]
	* Week 8: Contingency time for finishing the above, ensure a solid main program.		* Week 8: Contingency time for finishing the above, ensure a solid main program. [http://lists.osgeo.org/pipermail/soc/2012-July/001921.html Report 8]
	* July 9: Midterm Evaluation: Evaluate the existing program, determine the plan for the remaining 3-4 weeks. Options include:		* July 9: Midterm Evaluation: Evaluate the existing program, determine the plan for the remaining 3-4 weeks. Options include:
	* Improving the main algorithm		* Improving the main algorithm
Line 157:		Line 157:
	* GUI		* GUI
	* Adding a second image segmentation algorithm		* Adding a second image segmentation algorithm

			[http://lists.osgeo.org/pipermail/soc/2012-July/001941.html Report 9], [http://lists.osgeo.org/pipermail/soc/2012-July/001960.html Report 10], [http://lists.osgeo.org/pipermail/soc/2012-August/001986.html Report 11], [http://lists.osgeo.org/pipermail/soc/2012-August/002002.html Report 12], [http://lists.osgeo.org/pipermail/soc/2012-August/002041.html Report 13]

	= Region Growing Algorithm =		= Region Growing Algorithm =