04:24 < nilay> hello tham.

04:25 < tham> hello

04:25 < nilay> you said opencv does not tell us how to train structured random forest

04:26 < tham> I mean, it do not implement that part

04:26 < tham> atleast I can not find it from the codes

04:27 < nilay> https://github.com/Itseez/opencv_contrib/blob/master/modules/ximgproc/include/opencv2/ximgproc/structured_edge_detection.hpp

04:28 < nilay> is there something there.. i could not find the main cpp file

04:29 < nilay> this one: https://github.com/Itseez/opencv_contrib/blob/master/modules/ximgproc/src/structured_edge_detection.cpp

04:30 < tham> https://github.com/Itseez/opencv_contrib/blob/master/modules/ximgproc/src/structured_edge_detection.cpp

04:30 < nilay> yes

04:31 < tham> Atleast it show you how to detect

04:31 < nilay> but how can we detect if we don't train random forest

04:31 < tham> opencv provide us a pretrain model

04:32 < tham> For more details, look at http://stackoverflow.com/questions/33317152/model-file-for-opencvs-structured-edge-detector

04:32 < tham> I think there are two way solve the problem

04:33 < tham> you can find a way to reuse to trained model(if zoq think this is ok)

04:33 < tham> or reimplement the training part

04:34 < tham> we need to study the codes and the paper if we want to know how to implement it

04:35 < nilay> i studied the paper. i have some problems in their approach

04:36 < tham> To tell you the truth, me too

04:37 < tham> So I dig into the codes to find out how to implement it

04:37 < tham> What is your problem?

04:38 < tham> You already decided you want to implement edgeBoxes?

04:38 < nilay> i don't know

04:38 < tham> Or selective search?

04:39 < nilay> it is not my decision only, you and zoq can also decide it.

04:39 < nilay> in section 3.2 of the paper how are they calculaqting w_b(s_i)

04:41 < tham> We could give you some suggestions, but you are the one who determine which mehtods you want to pick

04:42 < tham> this is your project, you should pick the one you like to implement :)

04:43 < tham> About section 3.2, please wait a moment

04:44 < nilay> i think, if edgeboxes can be done we can do edgeboxes. but i don't know if i can do it.

04:48 < nilay> for training the random forest their matlab code and paper are the only sources?

04:52 < tham> Maybe not, but this is the only source I know

04:52 < tham> open source

04:53 < tham> I think it is possible to transform matlab code to c++

04:53 < tham> There is c++ implementation of section 3.2 out there

04:54 < tham> I could send you the link

04:54 < nilay> ok

04:56 < tham> https://github.com/ultrafro/opencv_contrib/blob/edgeBoxes/modules/saliency/src/EdgeBoxes/objectnessEdgeBoxes.cpp

04:56 < tham> But there are different

04:56 < tham> atleast the k value they use is 1.0, not 1.5

05:01 < nilay> https://github.com/ArtanisCV/StructuredForests

05:02 < nilay> this is a python version, to train random forests. do you think i can use this a reference.. because i find python more readable, and i don't have matlab on my machine.

05:02 < tham> nice search

05:03 < tham> you can install octave if you do not have matlab

05:03 < nilay> and we can use the machine zoq provided, to test whether this indeed does give a competitive performance. he says 12gb ram is required.

05:03 < nilay> i have octave.. but he uses matlab image processing toolbox, so i guess i will get stuck at some point if i try to run that matlab code.

05:04 < nilay> and they also use a toolbox that they made themselves.

05:04 < tham> I think octave also has the toolbox

05:05 < tham> I think it is ok to use the python codes as reference if you think it is more readable

05:05 < nilay> ok

05:07 < tham> If you think edgeBoxes is overwhelmed, you can switch to another algorithm

05:07 < nilay> yes but i can only know that by trying it out first.

05:07 < tham> Like selective search(I think this one is easier to understand and implement)

05:08 < tham> Agree

05:08 < nilay> do you think if we can train random forest rest of the part we can follow from opencv implementation..

05:09 < nilay> then i start with random forest with the python code as reference, and also develop a rough interface that zoq talked about.

05:10 < tham> The codes of opencv, you can use it as reference, but better try to map the implementation with the description of the paper

05:11 < tham> since it is not accepted yet, the implementation details may have some flaws

05:11 < nilay> ok

05:11 < tham> I will take a look at the implementation of python later

05:12 < nilay> ok thanks. i will start with this, let's see how much i can do :P :)

05:15 < tham> Maybe you can reuse the Hoeffding tree of mlpack

05:15 < tham> random forest is build on top of dtree

05:15 < tham> if Hoeffding tree do not work, rcurtin can help us refactor it :)

05:16 < tham> Good luck :)

05:17 < nilay> zoq said this could be used: https://github.com/cloudhan/mlpack/tree/weak_learner/src/mlpack/methods/weak_learner

05:17 < nilay> wait no\

05:17 < nilay> yes this one only

05:28 < tham> ok, so we have decision tree already

05:28 < tham> Then we should be able to build random forest on top of it

05:29 < nilay> yes

12:31 < nilay> hello zoq

12:32 < nilay> root privileges are required to make install mlpack on remote machine.

12:39 < nilay> i get following error when loading data in arma matrix: /usr/bin/ld: /tmp/cczyATX3.o: undefined reference to symbol 'wrapper_dgemm_' //usr/lib/libarmadillo.so.4: error adding symbols: DSO missing from command line

12:40 < zoq> nilay: Hello, there is basically no need to run 'make install' you can just use e.g. 'bin/mlpack_pca'

12:40 < zoq> nilay: if you run an executable?

12:41 < nilay> yes it works

12:41 < nilay> this error i get in my home machine.. loading into arma mat

12:44 < zoq> nilay: you mean if you build mlpack?

12:44 < nilay> no after i try to run some program.

12:44 < nilay> like this one: http://www.mlpack.org/docs/mlpack-2.0.1/doxygen.php?doc=sample.html

12:44 < nilay> finding covariance

12:45 < nilay> also in the remote machine, how can i run sample programs if i do not make install

12:45 < zoq> can you run 'export LD_LIBRARY_PATH=/usr/local/lib/' what command do you used to build the example?

12:46 < nilay> g++ 1.cpp -o foo -lmlpack -std=c++11

12:46 < nilay> i have already added 'export LD_LIBRARY_PATH=/usr/local/lib/' to .bashrc

12:46 < nilay> brb

12:49 < zoq> you can always specify the location like 'clang++ example.cpp -L/home/nilay/mlpack/build/libmlpack.so -I/home/nilay/mlpack/build -I/Users/marcus/src/mlpack/build/include/ -std=c++11'

12:50 < zoq> try building using: g++ 1.cpp -o foo -std=c++11 -larmadillo -lmlpack

12:53 < zoq> you probably also have to link against boost: g++ -std=c++11 -lmlpack -larmadillo -lboost_serialization -lboost_program_options 1.cpp -o foo

13:04 < nilay> g++ 1.cpp -o foo -std=c++11 -larmadillo -lmlpack works..

13:05 < nilay> do you think when compiling other programs i will also have to use: g++ -std=c++11 -lmlpack -larmadillo -lboost_serialization -lboost_program_options 1.cpp -o foo

13:05 < nilay> can i do something about this, so that i have to only link -lmlpack?

13:06 < nilay> and in the remote machine i cannot compile such programs until i do make install...

13:06 < nilay> i also pm you a list of python and python libraries to install

13:07 < zoq> nilay: if -lmlpack works for you that's all you need

13:07 < nilay> it doesn't work. i have to link -larmdillo

13:07 < zoq> nilay: yeah, I'm about to install everything

13:07 < nilay> ok thank you..

13:07 < nilay> and make install mlpack also?

13:08 < zoq> nilay: ah, if '-lmlpack and -larmadillo' works fo you you don't have to link against e.g. '-lboost_serialization' etc.

13:09 < zoq> nilay: you can also write a small Makefile, if you like, or I can write you a simple Makefile

13:09 < nilay> yes i will writ a makefile, thanks

13:09 < nilay> write*

13:11 < zoq> nilay: if libmlpack isn't in /usr/local like on the remote you can manually specify the location with like: 'g++ 1.cpp -o foo -std=c++11 -L/home/nilay/mlpack/build/ -larmadillo -lmlpack

13:12 < zoq> and also specify the include dir with -I/home/nilay/mlpack/build/include/

13:14 < nilay> i get a bunch of errors when i compile this way

13:14 < zoq> can you post the command?

13:15 < nilay> g++ 1.cpp -o foo -I/home/nilay/mlpack/build/include/ -lmlpack -std=c++11

13:15 < nilay> on the remote machine

13:16 < nilay> i tried adding -larmadillo also but doesn't work on remote machine.

13:16 < nilay> is mlpack already installed on remote, that is why you are asking me to include library this way?

13:18 < nilay> error comes related to arma_snprintf

13:18 < nilay> i can paste the error here if you like

13:18 < zoq> nilay: that would be great

13:20 < nilay> ok now when i type this command: g++ 1.cpp -o foo -I/home/nilay/mlpack/build/include/ -larmadillo -lmlpack -std=c++11, the error i get on remote is: In file included from /home/nilay/mlpack/build/include/mlpack/core.hpp:195:0, from 1.cpp:1: /home/nilay/mlpack/build/include/mlpack/prereqs.hpp:17:19: fatal error: cstdlib: No such file or directory

13:24 < zoq> nilay: clang++ 1.cpp -I/usr/local/include/ /home/nilay/mlpack/build/lib/libmlpack.so -I/home/nilay/mlpack/build/include -std=c++11 -L/usr/local/lib/ -larmadillo

13:25 < nilay> clang++ isn't installed

13:26 < zoq> on the remote?

13:26 < nilay> oh wait, sorry

13:26 < nilay> there are many warnings generated

13:27 < zoq> I guess, boost related?

13:27 < nilay> yes

13:28 < nilay> and when i run ./a.out i get: Shared object "libmlpack.so.2" not found, required by "a.out"

13:31 < zoq> export LD_LIBRARY_PATH=/home/nilay/mlpack/build/lib/:/usr/local/lib/

13:33 < nilay> the program runs but the warnings are still there.

13:35 < zoq> don't worry about the warnings, most of them are boost style warnings and unsued parameters

13:35 < nilay> ok

13:38 < zoq> nilay: it hasn't anything to do with mlpack, you could suppress the warnings using some compiler settings if you like

13:39 < zoq> nilay: Also, the python code looks promising. I'll have to take a closer thought.

13:40 < zoq> nilay: python, numpy, matplotlib, sklearn and ipython installed

13:45 < zoq> I think the implementation should be too much of a hassle since we already have a bunch of code we can use or reuse.

14:01 < tham> Looks like python codes are easier to read

14:03 < zoq> tham: I think, you can basically write ugly code in every language.

14:04 < tham> zoq : I agree with that

17:16 < nilay> ok zoq, i am taking a look at some related mlpack code right now and running it, then i will look at the python code, then i will start...

17:17 < zoq> nilay: Sounds good, if you need any help, we are here

17:18 < nilay> ok thanks :)

17:27 < nilay> zoq: is this the complete linking or do we need to give some more files to link? g++ -std=c++11 -lmlpack -larmadillo -lboost_serialization -lboost_program_options 1.cpp -o foo

17:29 < zoq> nilay: I think that's it

17:30 < nilay> zoq: i still get these... 1.cpp:(.text+0x421): undefined reference to `mlpack::Log::Info' 1.cpp:(.text+0x426): undefined reference to `mlpack::util::PrefixedOutStream::operator<<(char const*)' 1.cpp:(.text+0x438): undefined reference to `mlpack::util::PrefixedOutStream::operator<<(unsigned long)' 1.cpp:(.text+0x445): undefined reference to `mlpack::util::PrefixedOutStream::operator<<(char const*)' 1.cpp:(.text+0x450): undefined referenc

17:31 < nilay> and many more

17:32 < zoq> nilay: on your local system?

17:32 < nilay> yes

17:32 < zoq> using the same example as before?

17:33 < nilay> the next example... nearest neighbor

17:33 < nilay> every example gives some new errors :p

17:34 < zoq> nilay: try: g++ 1.cpp -o foo -std=c++11 -lmlpack -larmadillo -lboost_serialization -lboost_program_options

17:35 < zoq> nilay: g++ is picky about the 'right' order

17:35 < nilay> ohh

17:36 < zoq> nilay: does that work for you?

17:36 < nilay> yes

17:36 < zoq> nilay: great :)

17:36 < nilay> so, the link options(-lmlpack, -larmadillo) can be in any order?

17:36 < zoq> nilay: yes

17:37 < nilay> ok. . . if there was a tutorial somewhere about these things, i won't bother you this much

17:41 < zoq> nilay: yeah, I agree, we should write some kind of document for all this little flaws.

17:45 < zoq> nilay: Some of the problems are really system specific, like if you use clang instead of gcc the order doesn't make any difference.

17:48 < nilay> is this because clang is supposed to be improvement over gcc

17:50 < zoq> nilay: I wouldn't say that, both have their strengths and weaknesses.

17:52 < nilay> ok

18:26 < nilay> where does the Log::Info output get printed?

18:27 < nilay> ok it gets printed.. no worries.

18:31 < nilay> sometimes Log::Info does not get printed even if we provide -v option

19:01 < zoq> nilay: oh, can you provide an example?

19:03 < zoq> nilay: if you use Log::Info inside a unittest you have to reset Log::Info but otherwise it should always work