[GRASS-dev] FW: FW: OSGeo-SoC 2016 application

[Moritz Lennert]

Bo,

I've read through your application. It is quite long, so I think you can 
shorten the overview of the different algorithms a bit.

Maybe I was, again, unclear in my previous mails, but I would qualify 
mean-shift and watershed as top-down algorithms. If your not comfortable 
with these notions (of top-down/bottom-up), better not to include them 
in the proposal.

Other than that, it seems fine to me.

Some elements you could add to make it stronger:

- The specific question of how to handle large data. i.segment uses 
binary search trees. Have you already worked with those ? As you say 
that you "coded to process large volume" data, could you provide one or 
two examples including information about your approaches ?
- Possible difficulties and how you plan on solving them (including 
other obligations you might have during that time, vacation plans, etc).
- Have you ever worked in a *nix environment ? Even though GRASS runs on 
Windows, it does come from a *nix environment and understanding that 
helps...

I won't be available for most of (my) afternoon. I'll try to have a 
quick look at my mail around 18h (CET), i.e. 2 hours before deadline, 
but can't absolutely guarantee it.

Maybe MarkusM has something to add ?

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:mlennert at club.worldonline.be]
> Sent: Thursday, March 24, 2016 7:52 AM
> To: Yang, Bo (yangb2) <yangb2 at mail.uc.edu>; Luca Delucchi
> <lucadeluge at gmail.com>
> Cc: grass-dev at lists.osgeo.org; Markus Metz <markus.metz.giswork at gmail.com>
> 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
>