Re: [boost] [Boost.GIL] GSoC 2020 Project 1 - Seeking Mentor

Yes, I am really interested in submitting a PR for the same. Could please help me with how to get started? I was planning to implement a file named morph.hpp in boost/gil/image_processing module. Also was there any previous discussion about implementation of dilation and erosion which I should keep in mind? Also, what would be the most convenient mode of discussion for you in case I have any further doubts? Finally, Thank you so much for taking the time to help me out. :) On Fri, Jan 31, 2020 at 10:16 PM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

On Fri, 31 Jan 2020 at 03:24, Ayush Bansal via Boost wrote:

...

On Thu, Jan 30, 2020 at 8:01 PM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

On Thu, 30 Jan 2020 at 15:05, Ayush Bansal via Boost < boost@lists.boost.org> wrote:

...

For my competency test, I was interested in doing the implementation

of

...

convolution filter and use it to detect edges.

FYI, please watch https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-2020 as the GIL competency test section may receive some updates during next days.

In order to get familiar with the GIL, I tried implementing a basic version of Erosion and Dilation. It would be really great for me if you could take a look at it and tell me if I could use it as part of my Competency test Any other suggestions are also welcomed. https://github.com/ayushbansal07/GSOC_Boost/blob/master/morph.cpp

Since your competency test solution aims to implement an algorithm an actual feature with potential of being useful as part of the GIL, then I'd suggest you to consider submitting it as a proper PR.

IMHO, PR efforts come with numerous benefits for GSoC candidates, e.g.: - Makes you actively participate as part of the project community - Teaches the actual real life development workflow - Teaches workflows involving Git, GitHub - Teaches iterative workflows of PR reviews - Motivates you to aim for quality, e.g.: - compliance with contributor guidelines (makes you actually read them!) - necessity to work on tests (and, ideally, documentation) - Presents your code as part of the big picture, if/how it integrates with the library and not as a random project written using random build system following random personal conventions and preferences - Makes it easier for others to review your code - Uses of common CI builds to verify your code - Gives your efforts public visibility

Don't be shy about submitting a PR with an unfinished code, a proof of concept, a code that you have more questions than answers about, a code that you have not tested using all toolsets/environments, etc.

Have a look at PRs submitted by students last year https://github.com/boostorg/gil/pull/259 https://github.com/boostorg/gil/pull/258 If you read through the commentary you should get a basic understanding of how things work :-)

Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost