Re: [mlpack] GS0C 2020

2020-03-12 Thread Gopi Manohar Tatiraju
Hey Marcus,
Sorry for late reply, I was busy with my exams but they are over now and I
can give my complete attention here.

I want to implement Image Segmentation Models for sure. I want to go with
two models:

   1. SegNet
   2. SqueezeNet


   - Main attraction of SegNet is it's Encoder-Decoder Layer. Here the
   fully connected layers are discarded which makes our model much smaller.
   - I am planning to add this layer not specifically for SegNet but into
   the library so that it can be used for other implementation in the future
   as well. Doing this will ensure the code re usability and will increase the
   productivity and will make our library network rich!!!
   - SqueezeNet again has a Fire Module which is its main feature to
   decrease the number of input channel.
   - This will also be implemented library wide so that it can be used in
   future implementation as well.
   - Any more layers or functions required for these models will also we
   implemented library wide

Phase 1

Add all the pre-required layers and functions library wide and perform
extensive testing on them.
Testing parameters can be decided hand in hand while implementing these
layers and functions.


Phase 2

This phase will be completely dedicated to implement the architecture of
both the models.
This should not take much time as by now we will have all the required
layers and function.
We will just need to dictate the flow and build the architecture. Also
testing will be started.

Phase 3

Here we can make final tweaks as per our requirements and testing results.
Once the models are finally done we can start training them.
I am also planning to write more extensive tutorial on how to use these
models.
Also based on the results virtualisation will be created to display it in
more
understandable ways.
I am also planning to apply Segmentation Models on the video, it will be a
great way to
show off the model repo.


Both models have less training time and more efficiency when considered
against complexity of the models. Also once trained both can run on mobile
devices.
What are your thoughts about this plan?
Do I need to add more detailing?

Regards
Gopi M Tatiraju

On Sat, Mar 7, 2020 at 4:00 AM Marcus Edel  wrote:

> Hello Gopi,
>
> Also, I did some more reading regarding Segmentation Models, I think
> reading
> survey papers on this topic would be a better option as by that we can
> analyze
> the speed and requirements of the model and then can implement those which
> provides better timings. What do you think?
>
>
> Yes, sounds totally reasonable to me.
>
> I think it would be better to decide the models now, once decided we can
> start
> focusing on Model Implementation & Visualization.
>
>
> Do you already have a preference, I don't really want to dictate what
> model has
> to be implemented, but I can take a closer look at the models you find
> interesting and then we can discuss from that point?
>
> Let me know what you think.
>
> Thanks,
> Marcus
>
> On 5. Mar 2020, at 17:25, Gopi Manohar Tatiraju 
> wrote:
>
> Hey Mentors,
>
> I just went through the idea page for GSoC 2020 Mlpack and found that this
> project was added
> https://github.com/mlpack/mlpack/wiki/SummerOfCodeIdeas#visualization-tool
>
> In my previous mail I mentioned that I was planning to do this as a part
> of
> https://github.com/mlpack/mlpack/wiki/SummerOfCodeIdeas#application-of-ann-algorithms-implemented-in-mlpack
> And also a new project regarding Improvisation of ANN module was added(
> https://github.com/mlpack/mlpack/wiki/SummerOfCodeIdeas#improvisation-and-implementation-of-ann-modules
> ).
>
> I was also planning to add the required functionalities by myself in the
> pre-coding phase but now as these are assigned to different projects I
> think we can try and implement more than 2-3 models over the course of
> summer and perform testing. Also if nobody takes up the visualisation
> project I still would like to perform that under the  Application of ANN
> Algorithms Implemented in mlpack.
>
> Regards.
> Gopi M Tatiraju
>
> On Mon, Mar 2, 2020 at 12:07 PM Gopi Manohar Tatiraju <
> deathcod...@gmail.com> wrote:
>
>> Hey Marcus,
>> I agree that we should focus on one topic only, I am more interested in
>> Segmentation Models.
>>
>> I started implementing SegNet(https://github.com/mlpack/models/issues/54)
>> but as UpSampling Layer is not implemented in mlpack I got stuck. As you
>> can see in the discussion said that they will implement of the layer is in
>> progress and I think soon we will know the status.
>>
>> Also, I did some more reading regarding Segmentation Models, I think
>> reading survey papers on this topic would be a better option as by that we
>> can analyze the speed and requirements of the model and then can implement
>> those which provides better timings. What do you think?
>>
>> I read this article(
>> https://medium.com/@arthur_ouaknine/review-of-deep-learning-algorithms-for-image-semantic-segmentation-509a600f7b57
>> )
>> 

[mlpack] GSoC 2020: Visualization Tool

2020-03-12 Thread Gopi Manohar Tatiraju
Hey,

Regarding Visualization Tool, I think we may need to use one or more
different libraries to build it, so a discussion regarding the dependencies
is needed to proceed further.

I took the example of Digit Recogniser
 and started working
on it.

I started by visualising the dataset itself. Using OpenCV I wrote code to
read images from CSV file and display them(OpenCV doesn't have any function
to read csv files as images).

Now I think another good visual will be a list of all the layers and
activation function which are used and connections between them. Now we
have some options to do this:

   1. *Total Naive Approach: *We can use file handling. Our tool will take
   code file as input. All layers are added like this(Add). We can
   detect the parameters and using openCV we can arrange them in a graph
   fashion.
   2. *A better approach: *A better approach will be to add a variable or
   function (for ex. FNN class) which keep track of the layers being added and
   other required parameters. Then we can create an object of visual class,
   and the FNN class object can be passed to this visual class which then can
   produce the required visualization.

*Method 1 *maybe not that efficient and is prone to many errors as here we
also have to ensure code file given by the user contains right code and all
the connections are properly done. But here we don't need to touch any of
the base code of the library so required testing will be only be limited to
Visual Tool Class

*Method 2 *is efficient but changing the base code of the library will
required extensive testing before we can merge it. Testing will take more
time here, but using objects can we more beneficial.

I need some views regarding what method should be chosen and how to proceed
from here. Once the flow is established other parameters like accuracy,
bias and other parameters can be visualised using graphs. I have some
parameters in mind for now, we can also take some inspiration from
tensor-board  for that.

Waiting for suggestion as  I am planning to implement a proof of concept so
that we can understand the project better.

Regards
Gopi M Tatiraju
___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] Regarding GSOC Proposal for ANN Algorithms Implemented in mlpack

2020-03-12 Thread Kartik Dutt
Hello Marcus,

Thank you for your encouraging response, I think testing, proper documentation 
and a tutorial will be very important. I think testing for all layers and 
metrics that I add in mlpack, shouldn't be very hard. Hopefully by then models 
repo would have been re-structured to support tests, tutorials and ready to 
deploy models. For object localization, we could implement the following tests:

1. Load weights and run for a few epochs (same as other models).
2. Take random images from validation dataset and set a minimum IoU (such that 
test don't fail yet show that the models is working fine.)
3. Run classification accuracy test that I am currently working on for object 
detection models in the repo as part of restructuring.

I think the most important part would be API (to increase flexibility 
especially for a model such as YOLO), proper documentation and tutorial. A user 
should be able to link a video or image and we directly save the frames / 
videos with bounding boxes. CLI would be very useful here.
For documentation I think I will add a ReadMe in each folder of models repo to 
describe uses, parameters, function call. Tutorials might be the ones that 
would require some time because they need to be simple enough so that a user 
can understand them without understanding all of the underlying code.

The differences between the models are minor so I think supporting other models
should be straightforward.

And Yes I agree, If we add some more layers and some residual blocks to Darknet 
19 we can get Darknet 53, so I can the same thing that I did with LeNet (v1, v4 
and v5). So, We can have a Darknet class add according to version we can return 
the layers and later add an alias to the version so that we can call DarkNet19 
and DarkNet53.

Yeah, time-consuming indeed, but possible, we have a bunch of machines we could
provide for training models.

That would be really great but I think I think loading weights of Darknet to 
YOLO makes sense so that at least that portion of the model doesn't have to 
change much in terms of weights.So it would overall take lesser time, and we 
are already training Darknet so we can easily use those weights.Later on, when 
bindings for other languages are added I think this will prove to be a very 
useful model especially in devices like Raspberry-Pi.
I think after I implement this, I would run inference on real-time videos on 
RPi3 and we could add those results in the readme as well. I would love to hear 
you opinions on the same to improve the proposal more. Thanks a lot.

Regards,
Kartik Dutt,
Github id: karikdutt18

___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] GSoC 2020: Visualization Tool

2020-03-12 Thread Rahul Prabhu
Hey Gopi,
Thanks for the interest in this project. I was wondering, to visualize the
neural network, could we not just parse the serialized model returned by
data::Save()?

On Thu, Mar 12, 2020 at 11:59 PM Gopi Manohar Tatiraju <
deathcod...@gmail.com> wrote:

> Hey,
>
> Regarding Visualization Tool, I think we may need to use one or more
> different libraries to build it, so a discussion regarding the dependencies
> is needed to proceed further.
>
> I took the example of Digit Recogniser
>  and started working
> on it.
>
> I started by visualising the dataset itself. Using OpenCV I wrote code to
> read images from CSV file and display them(OpenCV doesn't have any function
> to read csv files as images).
>
> Now I think another good visual will be a list of all the layers and
> activation function which are used and connections between them. Now we
> have some options to do this:
>
>1. *Total Naive Approach: *We can use file handling. Our tool will
>take code file as input. All layers are added like this(Add). We
>can detect the parameters and using openCV we can arrange them in a graph
>fashion.
>2. *A better approach: *A better approach will be to add a variable or
>function (for ex. FNN class) which keep track of the layers being added and
>other required parameters. Then we can create an object of visual class,
>and the FNN class object can be passed to this visual class which then can
>produce the required visualization.
>
> *Method 1 *maybe not that efficient and is prone to many errors as here
> we also have to ensure code file given by the user contains right code and
> all the connections are properly done. But here we don't need to touch any
> of the base code of the library so required testing will be only be limited
> to Visual Tool Class
>
> *Method 2 *is efficient but changing the base code of the library will
> required extensive testing before we can merge it. Testing will take more
> time here, but using objects can we more beneficial.
>
> I need some views regarding what method should be chosen and how to
> proceed from here. Once the flow is established other parameters like
> accuracy, bias and other parameters can be visualised using graphs. I have
> some parameters in mind for now, we can also take some inspiration from
> tensor-board  for that.
>
> Waiting for suggestion as  I am planning to implement a proof of concept
> so that we can understand the project better.
>
> Regards
> Gopi M Tatiraju
>
> ___
> mlpack mailing list
> mlpack@lists.mlpack.org
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
>
___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] GSoC 2020: Visualization Tool

2020-03-12 Thread Gopi Manohar Tatiraju
Hey Rahul,

If you don't mind me asking, are you mentoring this project? Coz it was not
listed on the idea page and there are many things which I would I like to
discuss about this project from a mentor's perspective.
About serialized model, I need to go through the saved .h5 file to see how
exactly we can use it. Also I am just trying to determine what all can be
included in this project, I am yet to decide how to implement these things
coz there are many options available. As it was mentioned on the idea page
that proof of concept is required so I am just working on determining the
outlines of the project first,

Regards.
Gopi M Tatiraju


On Fri, Mar 13, 2020 at 1:35 AM Rahul Prabhu  wrote:

> Hey Gopi,
> Thanks for the interest in this project. I was wondering, to visualize the
> neural network, could we not just parse the serialized model returned by
> data::Save()?
>
> On Thu, Mar 12, 2020 at 11:59 PM Gopi Manohar Tatiraju <
> deathcod...@gmail.com> wrote:
>
>> Hey,
>>
>> Regarding Visualization Tool, I think we may need to use one or more
>> different libraries to build it, so a discussion regarding the dependencies
>> is needed to proceed further.
>>
>> I took the example of Digit Recogniser
>>  and started
>> working on it.
>>
>> I started by visualising the dataset itself. Using OpenCV I wrote code to
>> read images from CSV file and display them(OpenCV doesn't have any function
>> to read csv files as images).
>>
>> Now I think another good visual will be a list of all the layers and
>> activation function which are used and connections between them. Now we
>> have some options to do this:
>>
>>1. *Total Naive Approach: *We can use file handling. Our tool will
>>take code file as input. All layers are added like this(Add). 
>> We
>>can detect the parameters and using openCV we can arrange them in a graph
>>fashion.
>>2. *A better approach: *A better approach will be to add a variable
>>or function (for ex. FNN class) which keep track of the layers being added
>>and other required parameters. Then we can create an object of visual
>>class, and the FNN class object can be passed to this visual class which
>>then can produce the required visualization.
>>
>> *Method 1 *maybe not that efficient and is prone to many errors as here
>> we also have to ensure code file given by the user contains right code and
>> all the connections are properly done. But here we don't need to touch any
>> of the base code of the library so required testing will be only be limited
>> to Visual Tool Class
>>
>> *Method 2 *is efficient but changing the base code of the library will
>> required extensive testing before we can merge it. Testing will take more
>> time here, but using objects can we more beneficial.
>>
>> I need some views regarding what method should be chosen and how to
>> proceed from here. Once the flow is established other parameters like
>> accuracy, bias and other parameters can be visualised using graphs. I have
>> some parameters in mind for now, we can also take some inspiration from
>> tensor-board  for that.
>>
>> Waiting for suggestion as  I am planning to implement a proof of concept
>> so that we can understand the project better.
>>
>> Regards
>> Gopi M Tatiraju
>>
>> ___
>> mlpack mailing list
>> mlpack@lists.mlpack.org
>> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
>>
>
___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] Regarding GSOC Project for Idea: ANN Algorithms Implemented in mlpack

2020-03-12 Thread Marcus Edel
Hello Prince,

thanks for reaching out, and thanks for all the contributions over the last
weeks.

Personally, I would focus on one project, you can always implement another
method if there is time left at the end, but since the models behind both ideas
a somewhat different it makes sense to focus on a single one. Also, I think I
said this before, but testing takes time, sometimes more time than the actual
method implementation. Besides, documentation and writing a tutorial shouldn't
be underestimated as well. That said I think each project is interesting and
definitely enough work for a GSoC project.

Thanks,
Marcus

> On 8. Mar 2020, at 09:49, Prince Gupta  wrote:
> 
> Hello everyone
> I am Prince Gupta, currently a 1st year Engineering student from India. I've 
> been getting familiar with MLPack codebase, especially ANN and made some PRs 
> since February 2020. I wanted to get some opinions on the GSOC project I've 
> decided on.
> I apologize in advance if this email gets too long.
> 
> Earlier I discussed with @zoq about implementing YOLO for GSOC project but 
> @kartikdutt18 was already working on it, so I decided to change my project 
> idea as two people working on same thing will be redundant.
> 
> For GSOC I would like to implement the following two applications of ANN:
> 1) Neural Style Transfer
> 2) Face Recognition
> 
> To work on them I would also need to implement the following prerequisites 
> which I hope to implement before the GSOC period starts:
> 1) VGG-19 Model for Neural Style Transfer
> 2) Triplet Margin Loss for Face Recognition(I've opened a PR on it already 
> #2208)
> 3) Inception Network for Face Recognition
> If training is out of scope I'll try to use pre-trained weights.
> 
> I would love to hear opinions on my project idea, is this sufficient? is this 
> too much? other things I should consider or anything else.
>  
> Project: Application of ANN Algorithms Implemented in mlpack
> Mentors: Marcus Edel, Sumedh Ghaisas, Shikhar Jaiswal, Saksham Bansal
> 
> Thanks
> Prince Gupta
> Github ID: prince776
> ___
> mlpack mailing list
> mlpack@lists.mlpack.org
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack

___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] Structuring mlpack RL

2020-03-12 Thread Ryan Curtin
On Fri, Feb 28, 2020 at 04:40:30PM +, Adithya Praveen wrote:
> Hey there! Adi here.
> From what I understand, right now DQN's and other methods in mlpack
> are implemented in only the test file for "q_learning", and are
> limited to the environments implemented in mlpack. If I'm not
> mistaken, these environments return state spaces / observations that
> are limited to vectors.

Hey Adi,

Thanks for getting in touch.  I'm not 100% familiar with the
reinforcement learning code, but I do believe that you're right that the
only implementations and usage is in the test file.

I actually can't really answer the first question, but maybe I can
provide an opinion on the second one.

> 2. I would also like to know if adding an "agents" folder with
> different RL algos, to the RL section makes sense? You know, so that
> mlpack user's could just create, say, a "DQN Agent" for an environment
> and try running it.

Personally, I think that this would be cool.  Take a look at the issue
opened up for discussion in the models/ repository:

https://github.com/mlpack/models/issues/61

The way that discussion is going, it seems like some implementations of
RL tasks might fit nicely into that repository.  But perhaps something
more general can be made---I'm not sure exactly what you have in mind.

As a side note, your email didn't directly address this, but I think it
would be great if we could come up with a tutorial or some kind of
demonstration/example of how mlpack's reinforcement learning code could
actually be used for real-world tasks.  Perhaps that might be worth
thinking about also?  I'm not sure if there are already any efforts for
that underway.

Thanks!

Ryan

-- 
Ryan Curtin| "Are those... live rounds?"
r...@ratml.org | "Seven-six-two millimeter.  Full metal jacket."
___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack


Re: [mlpack] GSoC - mlpack on RPi and other resource-constrained devices

2020-03-12 Thread Ryan Curtin
On Tue, Mar 10, 2020 at 03:06:03PM -0300, Emanuel Lima wrote:
> Hello! My name is Emanuel Lima and I am an undergraduate student from the
> University of São Paulo (USP), in Brazil. I am very interested in the GSoC
> project "mlpack on RPi and other resource-constrained devices". Apart from
> deploying models to Raspberry Pis and old computers (as the description
> states), I would very much like to work on top of Labrador. That is an open
> hardware Single Board Computer totally developed at my university, with the
> help of people like John Maddog Hall:
> https://caninosloucos.org/en/labrador-en/
> I have one of these boards available because I am the cofounder of the
> Physics Institute Hackerspace at USP, and we received two of them to study.
> We also have some old Raspberries and Arduinos.
> I think this would be an amazing opportunity for the brazilian ML and IoT
> communities.
> I have some experience on C++, Python, Linux and compilers (LLVM in
> particular).
> 
> I hope this makes sense and that I would be a good fit for the project. If
> so, what would be the next steps?

Hey Emanuel,

Thanks for getting in touch and sorry for the slightly slow response.
Labrador seems very cool; it seems like making mlpack work on the
Labrador might not be very difficult since the Labrador seems to be
basically a fully functional ARM system with 2GB of RAM.  Honestly that
might even compile mlpack successfully as-is on the device. :)

However, I don't mean that making Labrador work with mlpack is a bad
idea for a GSoC project.  I think that it could be a really compelling
part of a project, and it would be a nice advertisement for both
Labrador and mlpack.  I think that it could be used as a launching point
for smaller devices like the Raspberry Pis and Arduinos that you
mentioned.

I think that for a student to be effective on this project they'd need
to have a good background with Linux systems and using compilers, and
C++ knowledge would also be necessary.  Especially knowledge about
linking and how compiled programs work would be useful, since getting
mlpack programs to run on really small devices will probably mean
stripping every unnecessary function out of a compiled program or
library.

If you do put together a proposal, note that my project description is
pretty ambiguous and leaves a lot of room.  So you are welcome to drive
it in a different direction.  Some additional thoughts:

 * I really would like to get mlpack running on that 386, and we could
   make a pretty cool Youtube video out of it.  So hopefully a proposal
   might touch on making this work too, or at least setting up the
   groundwork for it. :)

 * "Edge computing" is a really hot topic for machine learning right
   now.  A lot of papers at the SysML conference this year and various
   ICML and NeurIPS workshops are concerned with machine learning on
   'edge' devices.  There are even efforts like EdgeML:
   https://github.com/microsoft/EdgeML and Arm NN:
   https://github.com/ARM-software/armnn
   If you were interested, it might be worth thinking about how we could
   bring something new to the table with mlpack, and we might be able to
   then turn that into a conference or workshop publication.  In your
   case it may even be possible to collaborate with the Labrador team
   to find some cool thing that could be done.

Anyway, I hope that this helps.  Please let me know if I can clarify
anything.  If you're looking to get involved in contributing to mlpack
(probably a good idea to get familiar with it), take a look at
https://mlpack.org/involved.html and https://mlpack.org/gsoc.html .

Thanks!

Ryan

-- 
Ryan Curtin| "Long live the new flesh."
r...@ratml.org |   - Max
___
mlpack mailing list
mlpack@lists.mlpack.org
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack