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

Yang, Bo (yangb2) yangb2 at mail.uc.edu
Fri Mar 25 10:03:51 PDT 2016


Dear Moritz,

Thanks for the suggestions. Below is my reactions accordingly.
1. I have eliminated some parts of the algorithm review and add a part of "Possible difficulties and solution", which stated the working plan, obligations and possible continue work after the GSoC. Please see attached pdf file for detail and let me you if you have any comments. After all, I have no other obligations and am completely free to work on the project during this summer. I will definitely dedicate to the work for first 8 weeks, if the progress is satisfied I would take 1 week break. Otherwise  I will be working on this project full time as of now.
2. Yes I have tried using Ubuntu10 as my daily drive previously, and have used MAC OS (I assume it is Unix based) a lot when I was doing an internship for IOS APP development at Ihandysoft.inc 4 years ago. Currently I use windows mostly and use Cygwin instead of Linux when I need to compile some cross-platform program. 
3. Yes I worked with BST before during the course work when pursuing master degree. It has more efficient time complexity for search, insert and delete operations (O(logN) for all three operations). I attached an BST class I wrote before for the coursework.
Currently I am engaging a lot of research of processing big volumn remote sensing data, for example, a single full scene of Landsat 7 could more as large as 5000 by 5000 pixels, if include temporal dimension it would be much larger. My previous work include the spatio-temporal cokriging fusion algorithm did a lot of optimizations for processing time-series data, main program are in python code and the optimizations including:
Moving window algorithm to process the large volume data,
Using auto-delete elements method to reconstruct the covariance matrix to adapt matrix to the extendable moving window.
Incorporate CUDA module to implement the parallel process.
Using the Sparse matrix, tapering matrix to speed up solving the covariance matrix. 
Pre-mark the full scene of image to speed up the missing data filling process. 
I attached my main fusion code which included all the optimization I mentioned above (except CUDA module, it is in another version). Some parts might need further explanation and I would be glad to discuss with you more detail later. 

Best,
Bo Yang

-----Original Message-----
From: Moritz Lennert [mailto:mlennert at club.worldonline.be] 
Sent: Friday, March 25, 2016 8:24 AM
To: Yang, Bo (yangb2) <yangb2 at mail.uc.edu>
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

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/1Qanh7sUdJZfiusTVIBHmlbC6NY9kKFVR18
> OL3icreoM/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
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSoC2016_Proposal_Yang0325.pdf
Type: application/pdf
Size: 108694 bytes
Desc: GSoC2016_Proposal_Yang0325.pdf
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160325/52560547/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImageFusion_SoC.py
Type: application/octet-stream
Size: 23953 bytes
Desc: ImageFusion_SoC.py
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160325/52560547/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: BST.cpp
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160325/52560547/attachment-0001.ksh>


More information about the grass-dev mailing list