Dear Bo,
Thanks for the document. I have to give classes now, but will try to
read while the students work ;-)
Apparently, I was not concentrating while writing some of my mails:
split-window is not a segmentation algorithm. Sorry about that. I meant
general (top-down) image splitting algorithms, such as quad-tree, etc.
BTW, maybe there was a misunderstanding: you spoke about dynamic
thresholding and markov random field (MRF) for classification. I'm no
expert on these, but AFAIK, they are also used for segmentation. So,
while my remark concerning classification remains true, don't hesitate
to integrate these algorithms into the segmentation part, if you want to.
Moritz
On 25/03/16 06:21, Yang, Bo (yangb2) wrote:
Dear Moritz,
Please find the attachment for my first draft of the proposal.
GoogleDoc:
https://docs.google.com/document/d/1Qanh7sUdJZfiusTVIBHmlbC6NY9kKFVR18OL3icreoM/edit?usp=sharing
Thanks for your advices, such as Orfeo Toolbox, those are really helpful
for further understanding the segmentation algorithms.
However, I find few literature about the split-window algorithm, So for
the time being I put mean-shift and watershed as my highest priority
algorithm to be implemented.
Please let me know if you and/or Markus have any suggestions. I didn't
strictly follow the proposal template[1] because there is no methods
part. I restructure the proposal and included all the required
information in the template. If needed I can revise it to exactly follow
template's format. The proposal is due tomorrow afternoon for me (3pm
EST) so I think I still have enough time to refine it.
Yes, I fully understand there is no guarantee that the proposal will be
accepted, and I am totally fine with it. Thanks for pointing it out. Be
engaging in the GSoC process is more valuable for me since I've learning
about groups of people that extend beyond just GSoC. I will try my best.
Best regards,
Bo Yang
[1]
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students#Application_questions_we.27ll_ask_you
-----Original Message-----
From: Moritz Lennert [mailto:[email protected]]
Sent: Thursday, March 24, 2016 7:52 AM
To: Yang, Bo (yangb2) <[email protected]>; Luca Delucchi
<[email protected]>
Cc: [email protected]; Markus Metz <[email protected]>
Subject: Re: [GRASS-dev] FW: FW: OSGeo-SoC 2016 application
Dear Bo,
On 24/03/16 06:26, Yang, Bo (yangb2) wrote:
> Dear Moritz,
>
> Thank you for the reply, and thanks you and Markus could be the mentor
> of the i.segment project! There are only two days left for submitting
> the proposal, take into consideration I think I need to switch to the
> topic of i.segment project now.
Thank you for the flexibility !
> For my cokriging fusion
> topic I think I could do it after this summer in the future work.
Great !
> I've read the source code and Eric's wiki of GSoC 2012 [0]. I think I
> will prepare the proposal following the direction of adding new
> algorithms to segment an image into objects-- more than region-growing
> algorithm. Moritz, you mentioned segmentation
> algorithm: mean-shift, split-window and watershed.
Yes, as the general logistics of the i.segment module is in place,
adding new segmentation algorithms should not be too hard, so adding
several should be possible during this GSoC.
> I think some
> unsupervised classification algorithms would also be possible such
> as: dynamic thresholding and markov random field (MRF).
Unsupervised classification could be an interesting addition.
However, I would think KISS. So, concentrate on the segmentation. You
can add classification in the the project as a possible extension, in
case you finish early with the segmentation.
In any case, classification should be a separate module. The idea is to
have each module do one thing. Currently classification is proposed by
v.class.ml and v.class.mlR (but the latter is a very simple hack I did
for teaching - I'm currently busy rewriting it), but they are supervised.
For classification segment characterization is also important. Currently
we have two Python-based modules for that v.class and i.segment.stats.
One option might be to think about more efficient approaches and more
variables for that.
> If you think
> it is OK, I will start the preparing the draft of proposal from now
> on, and I think I could have the first version send back to you by
> tomorrow (Thursday).
Perfect. Markus and I are in Europe so don't forget about time zones
when thinking about when to send us your draft...
> If you have any suggestions and comments please let me know.
Markus can give you more details about the actual implementation. I
think in your proposal you should show that you have a general idea of
how i.segment works, and you should review different segmentation
techniques, possibly with relevant literature references. You might also
want to have a look at Orfeo Toolbox and their implementation of some of
the segmentation algorithms.
In general, it would be nice to add at least one or two top-down methods
as this would allow top-down hierarchical segmentation, while the
current region growing approach only allows bottom-up hierarchical
segmentation.
Final note just to make sure that this is clear: please be aware that
there are other GRASS-related proposals and that we do not know how many
slots we will get for GRASS. There is thus no guarantee that your
proposal will be chosen.
Best wishes,
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
