User talk:Weekly report - Revision history

Wiki-Hao2309 at 14:52, 30 May 2016

2016-05-30T14:52:45Z

Wiki-Hao2309: Hao2309 moved page GRASS GSoC 2016 Segment Algorithms/weekly report to User talk:Weekly report: Weekly report page has been move to GRASS trac

2016-05-30T14:52:20Z

Hao2309 moved page GRASS GSoC 2016 Segment Algorithms/weekly report to User talk:Weekly report: Weekly report page has been move to GRASS trac

Wiki-Hao2309 at 17:30, 29 May 2016

2016-05-29T17:30:52Z

Wiki-Hao2309: /* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual */

2016-05-29T17:29:14Z

16 – 21 May week 0: Setup coding environmental, get familiar with programming manual

Wiki-Hao2309: /* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual */

2016-05-29T17:25:42Z

16 – 21 May week 0: Setup coding environmental, get familiar with programming manual

Wiki-Hao2309: /* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual */

2016-05-29T17:24:28Z

16 – 21 May week 0: Setup coding environmental, get familiar with programming manual

Wiki-Hao2309 at 17:22, 29 May 2016

2016-05-29T17:22:00Z

Wiki-Hao2309 at 17:21, 29 May 2016

2016-05-29T17:21:33Z

Wiki-Hao2309 at 17:17, 29 May 2016

2016-05-29T17:17:26Z

Wiki-Hao2309: Created page with " == GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment == {| {{Prettytable}} | Student Name: | Bo Yang |- | Organization: | [http://www.osgeo.org/ OSGeo..."

2016-05-29T17:16:15Z

Created page with " == GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment == {| {{Prettytable}} | Student Name: | Bo Yang |- | Organization: | [http://www.osgeo.org/ OSGeo..."

New page

== GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment ==

{| {{Prettytable}}
| Student Name:
| Bo Yang
|-
| Organization:
| [http://www.osgeo.org/ OSGeo - Open Source Geospatial Foundation]
|-
| Mentors:
| Moritz Lennert, Markus Neteler, Markus Metz
|-
| Title:
| Additional segmentation algorithms for [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|-
| Repository:
| GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|}

← Older revision		Revision as of 14:52, 30 May 2016
Line 21:		Line 21:
	== 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==		== 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==
	* A small exercise too get you more familiar with basic GRASS code		* A small exercise too get you more familiar with basic GRASS code
−
−	~~{{{~~
−	As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices: As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current'Settings' tab becomes overcrowded.
−	~~}}}~~
−
−	The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
−
−	~~You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.~~
−
−	~~Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.~~
−
−	* Exercise has been finished
−	~~{{{~~
−	~~I think I've finished the exercise. For the time being I applied the following changes to the module GUI:~~
−	1. I kept "required" tab and add the selection of algorithms. Because I think for all of the three algorithms the input data and output location are required, so this tab now is designed for the inputs and outputs for all three algorithms
−	~~2. The "setting" tab has been changed to the setting of "region growth" since previously it only provided the setting of that algorithm.~~
−	3. Two Tabs of "shift_mean" and "watershed" were added to input the setting of each algorithm. I just give some preliminary input parameters for them, when we start coding I will give more substantial parameters required in the algorithm.
−	The user are supposed to give the input, output, and select which algorithm are utilized. Then define settings of that algorithm in the corresponding tab. The option tab are supposed to be additional settings. Please see attached pics for new GUI and advise if you think this setting logistic works.
−	~~}}}~~
−
−	~~== 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==~~

@@ Line 22: / Line 22: @@
 * A small exercise too get you more familiar with basic GRASS code
-> As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices: As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three  mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current'Settings' tab becomes overcrowded.
+{{{
-> The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
+As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices: As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three  mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current'Settings' tab becomes overcrowded.
-> You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
+}}}
-> Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.
 * Exercise has been finished

@@ Line 21: / Line 21: @@
 == 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==
 * A small exercise too get you more familiar with basic GRASS code
-{{{
-As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices:
+> As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices: As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three  mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current'Settings' tab becomes overcrowded.
- As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current 'Settings' tab becomes overcrowded.
+> The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
- The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
+> You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
- You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
+> Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.
- Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.
 * Exercise has been finished
 {{{

@@ Line 21: / Line 21: @@
 == 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==
 * A small exercise too get you more familiar with basic GRASS code
->> As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices:
+{{{
->> As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current 'Settings' tab becomes overcrowded.
+As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices:
->> The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
+ As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current 'Settings' tab becomes overcrowded.
->> You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
+ The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
->> Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.
+ You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
 * Exercise has been finished
-> I think I've finished the exercise. For the time being I applied the following changes to the module GUI:
+{{{
-> 1.  I kept "required" tab and add the selection of algorithms. Because
+I think I've finished the exercise. For the time being I applied the following changes to the module GUI:
-> I think for all of the three algorithms the input data and output location are required, so this tab now is designed for the inputs and outputs for all three algorithms 2. The "setting" tab has been changed to the setting of "region growth" since previously it only provided the setting of that algorithm.
+.  I kept "required" tab and add the selection of algorithms. Because I think for all of the three algorithms the input data and output location are required, so this tab now is designed for the inputs and outputs for all three algorithms
-> 3. Two Tabs of "shift_mean" and "watershed" were added to input the setting of each algorithm. I just give some preliminary input parameters for them, when we start coding I will give more substantial parameters required in the algorithm.
+. The "setting" tab has been changed to the setting of "region growth" since previously it only provided the setting of that algorithm.
-> The user are supposed to give the input, output, and select which algorithm are utilized. Then define settings of that algorithm in the corresponding tab. The option tab are supposed to be additional settings. Please see attached pics for new GUI and advise if you think this setting logistic works.
+. Two Tabs of "shift_mean" and "watershed" were added to input the setting of each algorithm. I just give some preliminary input parameters for them, when we start coding I will give more substantial parameters required in the algorithm.
 == 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==

← Older revision		Revision as of 17:24, 29 May 2016
Line 20:		Line 20:

	== 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==		== 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==
		+	* A small exercise too get you more familiar with basic GRASS code
		+	>> As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices:
		+	>> As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current 'Settings' tab becomes overcrowded.
		+	>> The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.
		+	>> You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.
		+	>> Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.
		+	* Exercise has been finished
		+	> I think I've finished the exercise. For the time being I applied the following changes to the module GUI:
		+	> 1. I kept "required" tab and add the selection of algorithms. Because
		+	> I think for all of the three algorithms the input data and output location are required, so this tab now is designed for the inputs and outputs for all three algorithms 2. The "setting" tab has been changed to the setting of "region growth" since previously it only provided the setting of that algorithm.
		+	> 3. Two Tabs of "shift_mean" and "watershed" were added to input the setting of each algorithm. I just give some preliminary input parameters for them, when we start coding I will give more substantial parameters required in the algorithm.
		+	> The user are supposed to give the input, output, and select which algorithm are utilized. Then define settings of that algorithm in the corresponding tab. The option tab are supposed to be additional settings. Please see attached pics for new GUI and advise if you think this setting logistic works.

	== 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==		== 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==

← Older revision	Revision as of 14:52, 30 May 2016
(No difference)

@@ Line 18: / Line 18: @@
 | GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html  i.segment]
 |}
 == 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==

← Older revision		Revision as of 17:17, 29 May 2016
Line 18:		Line 18:
	\| GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]		\| GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
	\|}		\|}
		+
		+	== 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==