ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
yuvraj has joined #mlpack
yuvraj has quit [Remote host closed the connection]
ImQ009 has joined #mlpack
yashwants19[m] has left #mlpack []
< sakshamb189[m]>
Hey himanshu_pathak I think it looks great! There are a few minor grammatical and punctation issues.
< sakshamb189[m]>
Could you copy and paste the text from the report on a word doc and try fixing those?
< rcurtin>
shrit[m]: sounds good, have you had any further issues with SFINAE? I think you should be able to just have two definitions of is_loading(): one for when it is a cereal archive, and one for when it isn't
yashwants19[m] has joined #mlpack
< shrit[m]>
I was working on my last blog post this morning, I will post it now
< KimSangYeon-DGU[>
sakshamb189: kartikdutt18 Are you there?
< KimSangYeon-DGU[>
Okay, do you think it's better to get a set of images to draw bounding boxes instead of a single image?
< KimSangYeon-DGU[>
I meant in API, user can pass a color of box I think :)
< KimSangYeon-DGU[>
User might want to draw a specific object using their color
< kartikdutt18[m]>
I think we can have both. For single image input would have a single column and for multi image it would have multipltle columns
< KimSangYeon-DGU[>
Yes, both are find for me
< kartikdutt18[m]>
* I think we can have both. For single image input would have a single column and for multi image it would have multiple columns
< KimSangYeon-DGU[>
* Yes, both are fine for me
< KimSangYeon-DGU[>
* Yes, both are fine with me
< kartikdutt18[m]>
Ahh, I undestand. I think then it would make sense to have two definitions one for single object type where user could specify color and second would be the current one with additional input of map?
< KimSangYeon-DGU[>
Yes, also, I think the current implementation can't distinguish the same object because they which is involved in the same class are colored with different colors.
< KimSangYeon-DGU[>
<kartikdutt18[m] "Ahh, I undestand. I think then i"> That's my point :)
< kartikdutt18[m]>
Right.
< kartikdutt18[m]>
<KimSangYeon-DGU[ "That's my point :)"> Ahh, got it I will make the changes for this.
< KimSangYeon-DGU[>
We can set the rules of functions
< KimSangYeon-DGU[>
What is your thoughts?
< KimSangYeon-DGU[>
* We can set the rules of methods
< KimSangYeon-DGU[>
* What are your thoughts?
< kartikdutt18[m]>
I agree, I think having multiple definitions would be better. One where we take input a map (if empty we color code classes on the fly) and the other one where user can specify the color of the object. Kindly let me know if this makes sense.
< KimSangYeon-DGU[>
I agree with you
< kartikdutt18[m]>
Great, I'll make the changes.
< KimSangYeon-DGU[>
Thanks
< kartikdutt18[m]>
Also since we will merging all YOLO parts, could you also take a look at the loss function.
< sakshamb189[m]>
kartikdutt18: I think the reports looks great! Thanks for making the changes.
< KimSangYeon-DGU[>
Yes
< kartikdutt18[m]>
* Also since we will be merging all YOLO parts, could you also take a look at the loss function.
< KimSangYeon-DGU[>
<sakshamb189[m] "kartikdutt18: I think the report"> Awesome :)
< kartikdutt18[m]>
<sakshamb189[m] "kartikdutt18: I think the report"> Great. Thanks for the review.
< kartikdutt18[m]>
Also, the report that we submit, will it be a link that I can update as more PRs get merged?
< sakshamb189[m]>
yes you can just submit the link to this repo.
< sakshamb189[m]>
I don't think it should be updated after GSoC is over since it is only meant to document the work that was done through GSoC.
< kartikdutt18[m]>
Ohh, makes sense.
< sakshamb189[m]>
Since this is going to be our last meet (although we can have organise other's if you want to discuss something) I would like to say that I am very happy with the work that you were able to complete.
< sakshamb189[m]>
Object detection models are definitely a great addition to mlpack models repo and definitely useful from a user point of view.
< sakshamb189[m]>
Hopefully we can also finish the YOLO models and have the merged in the codebase as well.
< kartikdutt18[m]>
Awesome, Thanks a lot. I think the YOLO PRs are good to go as well. Once I incorporate all changes in the Detector PR as well, we can merge them all at once. Hopefully we should be able to merge in the visualization PR as well.
< KimSangYeon-DGU[>
Yes, right :)
< KimSangYeon-DGU[>
Thanks a lot as well
< sakshamb189[m]>
were you able to test out the YOLO model? kartikdutt18
< kartikdutt18[m]>
Yes I did, I made all the changes to fix the model. The only function that I would like to add there is the detector part not for training but converting the feature map to feild type (the ones in the form of the input).
< kartikdutt18[m]>
I think that would be seperate PR since the model won't be changed.
< kartikdutt18[m]>
* Yes I did, I made all the changes to fix the model. The only function that I would like to add there is the detector part not for training but converting the feature map to bounding boxes of field type (the ones in the form of the input).
< sakshamb189[m]>
Also we should work on fixing the serialisation issue with batchnorm
< kartikdutt18[m]>
I think we can work on that after visualization PR. Kindly let me know if that makes sense.
< kartikdutt18[m]>
Current output is feature map which matches PyTorch so I think we are able to reproduce the results. Once we add a post processing function that converts feature maps to field, I would like to add maybe an image to models repo with bounding boxes. That would be really cool.
< KimSangYeon-DGU[>
:)
< kartikdutt18[m]>
I think the visualization tool should be the same as the one in the image.
< kartikdutt18[m]>
In the second image, both persons have the same color.
< KimSangYeon-DGU[>
Yes, I think it's based on the order in label file
< kartikdutt18[m]>
I think we also to need to add label name to it. Current name only plot the bounding box.
< KimSangYeon-DGU[>
Yes
< kartikdutt18[m]>
* I think we also to need to add label name to it. Current implementation only plot the bounding box.
< kartikdutt18[m]>
* I think we also to need to add label name to it. Current implementation only plots the bounding box only.
< kartikdutt18[m]>
Great, I will start making the changes.
< KimSangYeon-DGU[>
Ok, thanks
< KimSangYeon-DGU[>
I'm done
< KimSangYeon-DGU[>
Is there anything to discuss more?
< kartikdutt18[m]>
I think that's it from my side.
< KimSangYeon-DGU[>
Ok, great, thanks for the meeting and have a nice week and weekend!
< KimSangYeon-DGU[>
I'll review the detector and loss
< KimSangYeon-DGU[>
in the meanwhile
< kartikdutt18[m]>
Great, Have a great week.
< rcurtin>
shrit[m]: awesome update, thanks for taking the time to write that!
< shrit[m]>
@rcrutin Thanks for the updates, I think I have resolved the SFINAE issue, I will just make a push so you can tell me if it is right
< rcurtin>
if it compiles, then it is probably right :-D
< shrit[m]>
It compiles well so far,
< rcurtin>
:)
< rcurtin>
shrit[m]: this looks like a good solution to me
< rcurtin>
I want to modify it slightly to be a bit more "forward-looking", so that it can capture whether `Archive` has an `is_loading` member, and use `Archive::is_loading::value` if `Archive::is_loading` exists, otherwise it will use the `is_cereal_archive` implementation you have already
< rcurtin>
but I can work on that part
< shrit[m]>
I am happy if you approve it
< shrit[m]>
You can modify it as you wnat
< shrit[m]>
want*
< shrit[m]>
In fact the cereal/version.hpp does not seem to exist in older version of cereal
< rcurtin>
check out the "TLDR version" paragraph; it suggests that cereal provides versioning!
< rcurtin>
I think we must have read some out-of-date documentation earlier
< rcurtin>
so, I guess, according to that documentation, we could add a `const uint32_t version` parameter to all the serialization functions instead of the hack serialization of `version` that we're doing now
< rcurtin>
maybe try it with one class and see if it works, and if it does, apply it to other files?
ImQ009 has quit [Quit: Leaving]
< himanshu_pathak[>
Hey sakshamb189 Can you please look at my report again
< himanshu_pathak[>
I tried to remove nitpticks
< shrit[m]>
rcurtin: we need to discuss this in a video chat maybe, the amount of effort required to remove all the versioning does require a considerable amount of time and adding back what we had before.
< shrit[m]>
It will be easier to ship cereal with mlpack as we do with ensmallen than remodifying everything to make it adapted to ubuntu 16
< shrit[m]>
Considering the versioning we knew that cereal provides versioning. However, our method is much better since we are providing unit8_t instead of 4 bytes int
< shrit[m]>
I had done a diff between cereal 1.3 and cereal 1.1.2. The amount of refactoring is considerable for 4 years work.
< rcurtin>
shrit[m]: you might be right, maybe tomorrow morning my time / early afternoon your time?
< rcurtin>
I had hoped we could avoid an autodownloader, but it seems like that will be necessary, and also that 1.3 will be the minimum allowable version