fletch
fletch copied to clipboard
Kitware
WIP: Add Libsvm
Pending Paul's reply, is the kernel added in a modular way? In other words, is it easily patchable or does the change require hooks throughout the code?
One good way to find out if upstream would be interested is to open a PR and see what they say.
On Wed, Jul 18, 2018 at 1:28 PM, Mmanu Chaturvedi [email protected] wrote:
@m-chaturvedi commented on this pull request.
In CMake/fletch-tarballs.cmake https://github.com/Kitware/fletch/pull/415#discussion_r203464697:
@@ -519,6 +519,12 @@ if(NOT WIN32) list(APPEND fletch_external_sources Caffe_Segnet) endif()
+# LibSVM +set(Libsvm_url "https://github.com/m-chaturvedi/libsvm-3.1-custom/archive/master.zip")
OK, yeah, we added at least one new kernel which works better for images and modified some other code. I am not sure if upstream would be interested in them. Paul [ @Purg https://github.com/Purg ] can tell you more, perhaps.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kitware/fletch/pull/415#discussion_r203464697, or mute the thread https://github.com/notifications/unsubscribe-auth/AFRAWqS5z8AUTmYkHx8fitcR09hiCtrqks5uH3AtgaJpZM4VTVfa .
-- David Stoup Principal Engineer
Kitware, Inc. 28 Corporate Drive Clifton Park, NY. 12065 518-881-4949 (W) 518-312-3946 (M) 518-371-4573 (F)
Another question I had was related to svm.def. There seems to svm.def in the source code which is a super set of this, other than lacking svm_destroy_model. Is svm_destroy_model why we are patching it?
https://github.com/cjlin1/libsvm/blob/master/svm.def
@m-chaturvedi That would be a question for you since this is your branch ;)
The original build of libSVM was done in a different repo as I mentioned and that was against an old version of libSVM. I think that version did not have a def file, thus the patch. I don't know what version you're using in your listed repo.
:), now the upstream have a svm.def (the link I sent in the previous comment) and we have added a couple more functions to it in our modification.
Am I correct in assuming this repo coming from your github account is a copy of what is in SMQTK? If so, the only reason we were using this fork was because it natively (read: in C++) handled the use of a histogram-intersection distance/similarity kernel better than my young, naive use of the custom kernel interface many years ago (which, at the time, I was probably using incorrectly). Calling this a "new kernel which works better for images" is not quantified and probably false. We don't have any evidence that a euclidean distance kernel (option "-t 0", which is in the upstream libsvm) is better or worse than an HI kernel (that I am aware of at least) for the purpose of SMQTK's RelevancyIndex algorithm.
My intuition is that a normal euclidean kernel is probably no worse, if not better than, the current use of a histogram-intersection kernel because:
- the original use of an HI kernel was motivated when we were specifically using SIFT descriptors quantized over video frames.
- deep-learning based descriptors are usually compared using euclidean distance in what I had seen when looking at their use in nearest-neighbor algorithms.
Additionally, SMQTK should probably make use of scikit-learn for SVM use instead of libsvm directly. scikit-learn uses liblinear and libsvm under the hood anyway.
new kernel which works better for images
I'm sorry for being vague. By 'better' I meant, if the images are high dimensional, then this is fast and has comparable accuracy. http://web.stanford.edu/group/mmds/slides2008/malik.pdf
The point I was trying to make was if we already tried to get it to upstream, or if you think they might be interested? And if you'd like to PR it in case you made the change?
I'm not sure I can accurately interpret those slides (they're a lot of math and arrows that don't make a lot of sense to me). Are we sure that the use of HIK didn't just match their feature generation method better as compared to the current use of deeply learned features?
I don't think we've tried to get any of that repo's differences upstream. The modified libsvm repo originally came from @z-harry-sun so what's been done with it outside of SMQTK is more of a question for him.
Are we sure that the use of HIK didn't just match their feature generation method better as compared to the current use of deeply learned features?
Probably, you're right. When I conducted experiments, at least RBF kernel wasn't working that well (very low accuracy) with the features generated via keras which uses deep learning.
I've never used an RBF kernel to much success but linear should perform fine. Is it possible to perform your previous experiments with a linear kernel? What model were you using in your use of keras (alexnet, resnet-#, etc.)?
I've never used an RBF kernel to much success but linear should perform fine.
I see.
I'd used VGG16. This is experiments' repository for svm-active that I'd experimented with: https://github.com/m-chaturvedi/svm-active
Sorry, missed this:
Is it possible to perform your previous experiments with a linear kernel?
I could.
@dstoup I removed svm.def and relevant code from CMakeLists.txt.
@mattdawkins , I am guessing that upstreaming it may take more time than we expect it to be finished in. I can create an issue respecting David's concerns. Would a faster option be to upload it where we place Darknet, that you'd mentioned?
@dstoup I created an issue respecting your concern. And I have tested the build on MSVS 2017.
Any more progress here? It would be nice to have libsvm get built by VIAME on Windows.
Right, but will this be in master soon? Could it at least be added to viame/master in its current state?
Certainly adding to viame/master at any time is a good idea so you can use it. The caution, of course is that changes required to land in master are updated into viame/master as well so it maintains usability for you.