2019-04-20 22:15:47 -0500 received badge ● Popular Question (source) 2017-06-25 07:45:34 -0500 commented question cv2.so missing on ubuntu I am running into the same missing cv2.so problem on attempting to upgrade from 3.1 to 3.2 ; -- Python 2: cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D INSTALL_PYTHON_EXAMPLES=ON -D INSTALL_C_EXAMPLES=OFF -D OPENCV_EXTRA_MODULES_PATH=/home/jeremy/sw/opencv_contrib-3.2.0/modules -D BUILD_EXAMPLES=ON ..  gives a suspiciously missing python (for build) field: -- Interpreter: (ver 2.7.12) -- -- Python 3: -- Interpreter: (ver 3.5.2) -- -- Python (for build):  2016-08-14 08:59:22 -0500 received badge ● Editor (source) 2016-08-14 08:26:44 -0500 asked a question segfault on python calls from caffe in container I have a thorny issue - when I call cv2 functions from a certain code (caffe) in a docker container I hit the following segfault, which does not occur if not running in a container; however the nvidia container claims to be trouble free. I am not expert in reading stacktraces like these so any pointers to solution would be appreciated. I hit the segfault on using cv2 functions like cv2.flip or getrotationmatrix. However if I just call those functions (in the container) from a python command line, everything is ok.... ==15165== Syscall param msync(start) points to uninitialised byte(s) ==15165== at 0x721892D: ??? (syscall-template.S:81) ==15165== by 0x121D7123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1) ==15165== by 0x121D9EF6: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1) ==15165== by 0x121DB151: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1) ==15165== by 0x121DB4E8: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1) ==15165== by 0x121D7A30: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1) ==15165== by 0x5ABA442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0) ==15165== by 0x5ABFB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0) ==15165== by 0x715ACAF: ??? (in /lib/x86_64-linux-gnu/libc-2.19.so) ==15165== by 0x11220C45: cv::flip(cv::_InputArray const&, cv::_OutputArray const&, int) (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4.8) ==15165== by 0x82BDEDC3: pyopencv_cv_flip(_object*, _object*, _object*) (in /opencv/build/lib/cv2.so) ==15165== by 0x65E60D3: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== Address 0xffeffd000 is on thread 1's stack ==15165== in frame #6, created by google::GetStackTrace(void**, int, int) (???:) ==15165== *** SIGSEGV (@0x1010000) received by PID 15165 (TID 0x406abc0) from PID 16842752; stack trace: *** @ 0x715acb0 (unknown) @ 0x11220c46 (unknown) @ 0x82bdedc4 pyopencv_cv_flip() @ 0x65e60d4 (unknown) @ 0x65e6059 (unknown) @ 0x65e754d (unknown) @ 0x65e5dd8 (unknown) @ 0x65e6059 (unknown) @ 0x65e754d (unknown) @ 0x661c6d0 (unknown) @ 0x6588d43 (unknown) @ 0x65147bd (unknown) @ 0x6588d43 (unknown) @ 0x6601577 (unknown) @ 0x6544617 (unknown) @ 0x715a34d5 caffe::PythonLayer<>::Reshape() @ 0x50d24b5 caffe::Net<>::Init() @ 0x50d3345 caffe::Net<>::Net() @ 0x508066a caffe::Solver<>::InitTrainNet() @ 0x508187c caffe::Solver<>::Init() @ 0x5081baa caffe::Solver<>::Solver() @ 0x5103053 caffe::Creator_SGDSolver<>() @ 0x411fc6 caffe::SolverRegistry<>::CreateSolver() @ 0x40af42 train() @ 0x40897c main @ 0x7145f45 (unknown) @ 0x409283 (unknown) @ 0x0 (unknown) ==15165== ==15165== Process terminating with default action of signal 11 (SIGSEGV) ==15165== at 0x11220C46: cv::flip(cv::_InputArray const&, cv::_OutputArray const&, int) (in /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4.8) ==15165== by 0x82BDEDC3: pyopencv_cv_flip(_object*, _object*, _object*) (in /opencv/build/lib/cv2.so) ==15165== by 0x65E60D3: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x65E6058: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x65E754C: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x65E5DD7: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x65E6058: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x65E754C: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x661C6CF: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0) ==15165== by 0x6588D42: PyObject_Call (in /usr/lib ... 2015-03-01 11:38:50 -0500 commented question change source and recompile To convert the extant variable accum (which is a (numrho+2)*(numangle+2) long vector of ints) into a 2-dimensional Mat of uchars called accumulator, and put that Mat into an OutputArray called _acc, I did the following - int s = sizeof(accum[0]); _acc.create(numangle+2,numrho+2,s); //JR Mat accumulator = _acc.getMat(); //JR for(int r = 0; r < numrho; r++ ) for(int n = 0; n < numangle; n++ ) { int base = (n+1) * (numrho+2) + r+1; accumulator.data[base*s+3] = accum[base]%256; //JR accumulator.data[base*s+2] = (accum[base]>>8)%256; //JR accumulator.data[base*s+1] = (accum[base]>>16)%256; //JR accumulator.data[base*s+0] = (accum[base]>>24)%256; //JR }  reasonable? 2015-03-01 05:47:09 -0500 commented question change source and recompile ok so now that I have my new arguments and don't crash anything I'd like to finally get the data I am after which is located in an 'autobuffer' AutoBuffer _accum((numangle+2) * (numrho+2));  and I'd like to get that data into my inputarray ; I don't seem to be able to access Mat values using m.[row][column] , how would I do this efficiently? Specifically I have a Mat called accumulator which I made as follows Mat accumulator = _acc.getMat(); //JR accumulator.create(numangle+2,numrho+2,sizeof(accum[0])); //JR for(int r = 0; r < numrho; r++ ) for(int n = 0; n < numangle; n++ ) { int base = (n+1) * (numrho+2) + r+1; accumulator[r][n] = accum[base]; //JR }  but that last line is not going to hack it I blv . 2015-03-01 02:10:58 -0500 received badge ● Enthusiast 2015-02-28 17:22:21 -0500 commented question change source and recompile I'm not sure what was wrong before but this one has started to work: Mat image = _image.getMat(); std::vector lines; Mat accumulator = _image.getMat(); if( srn == 0 && stn == 0 ) HoughLinesStandardWithAccumulator(image, (float)rho, (float)theta, threshold, lines, accumulator, INT_MAX, min_theta, max_theta ); Mat(lines).copyTo(_lines); image.copyTo(_accumulator);  2015-02-28 12:47:08 -0500 commented question change source and recompile I have yet to crack this nut Mat image = _image.getMat(); Mat accumulator = _image.getMat(); HoughLinesStandardWithAccumulator(image, (float)rho, (float)theta, threshold, lines, accumulator, INT_MAX, min_theta, max_theta ); _accumulator.assign(image);  gets me an error 139 on exiting my function HoughLinesWithAccumulator 2015-02-26 11:07:09 -0500 commented question change source and recompile so is the doc here wrong ( "m - Destination matrix. If it does not have a proper size or type before the operation, it is reallocated") or is it the case that this is only true for calls to copyTo from outside opencv, or what? in any case in meantime i tried  _accumulator.create(src.size(), src.type()); Mat accumulator = _accumulator.getMat(); for( int i = 0; i < src.rows; i++ ) for( int j = 0; j < src.cols; j++ ) { accumulator.at(i, j) = src.at(i,j); }  This gave trouble (an assertion fail in some malloc) . I'm looking for an opencv coding guide so maybe that'll help 2015-02-26 04:34:52 -0500 commented question change source and recompile another small step forward (i think) - now i get an error 139 in python indicating bad memory access - so I'll try something besides the test I was attempting namely _image.copyTo(_accumulator);  which was an attempt to get the input image back as output image. I'll try Mat accumulator; _accumulator = accumulator;  2015-02-25 13:07:55 -0500 commented question change source and recompile Now I get a working cv2.so (which i have to copy by hand into /usr/lib/python2.7/dist-packages , make install doesn't seem to do this). But I don't seem to have access to the extra output argument : when i try lines = cv2.HoughLinesWithAccumulator(edges,1,np.pi/180,200) lines, arr = cv2.HoughLinesWithAccumulator(edges,1,np.pi/180,200)  the first line is ok while the second gives a 'too many values to unpack' so i guess my OutputArray is not getting picked up by the gen2 and/or hdr_parser scripts. I'll see if I can find output of those guys somewhere. 2015-02-25 11:45:11 -0500 commented question change source and recompile ok, seems as tho the cv2.so wasn't getting regenerated after the cmake, make -j2 , and make install. So I wiped out the build directory and am trying again . 2015-02-25 08:36:36 -0500 commented question change source and recompile I can't seem to figure it - I added exactly one argument to the .cpp function and same to the .hpp, in the same place, with same type - .hpp entry below , in /opencv_src/modules/imgproc/include/opencv2/imgproc.hpp (and not in the .../include/opencv2/imgproc/imgproc.hpp which it looks like is not the right one): CV_EXPORTS_W void HoughLinesWithAccumulator( InputArray image, OutputArray lines, OutputArray accumulator, double rho, double theta, int threshold, double srn = 0, double stn = 0, double min_theta = 0, double max_theta = CV_PI );  2015-02-25 07:45:59 -0500 commented question change source and recompile a few birthing pains. I tried adding an output array to my function void cv::HoughLinesWithAccumulator( InputArray _image, OutputArray _lines, OutputArray _accumulator, double rho, double theta, int threshold, double srn, double stn, double min_theta, double max_theta )  along with the corresponding declaration in the .hpp header. This suffices to break my opencv install - i get the following ImportError: /usr/lib/python2.7/dist-packages/cv2.so: undefined symbol: _ZN2cv25HoughLinesWithAccumulatorERKNS_11_InputArrayERKNS_12_OutputArrayEddidddd I don't think its related to allocating an array for the accumulator , i tried a few things such as Mat accumulator; accumulator.copyTo(_accumulator) or _accumulator = _image but no dice 2015-02-24 05:34:30 -0500 commented question change source and recompile whoops it looks like i shoudlve realized from your answer that i needed to copy the newly generated cv2.so to /usr/lib/python2.7/dist-package . Having done so I can now call my newly minted function, great! Now I will try changing arguments etc to actually get the output i need. Just saw your above answer, yes that wouldve taken care of it. Thanks again for help, it looks like i am in right direction for the time being 2015-02-24 05:00:41 -0500 commented question change source and recompile Thanks for your help first off, so far no dice: I had a declaration in include/opencv2/imgproc.hpp, monkeying the declaration that was already there for houghlines, for my version which i called houghlineswithaccumulator (in meantime keeping same arguments) CV_EXPORTS_W void HoughLinesWithAccumulator( InputArray image, OutputArray lines, double rho, double theta, int threshold, double srn = 0, double stn = 0, double min_theta = 0, double max_theta = CV_PI  I read the link, thx I'm not sure how to resintall cv2.pyd , I tried find -name cv2.pyd and locate cv2.pyd but didn't find it. The C++ ide was just to check whether i can first of all call my new function from C++, next step pyt 2015-02-22 05:14:09 -0500 asked a question change source and recompile Hi I'd like to change the opencv source a bit and recompile (I'd like access to the hough transform 'accumulator' image, which I see in the modules/imgproc/hough.cpp source but isn't exposed). So what I did was make a copy of the function cv::HoughLines in hough.cpp , called it cv::HoughLinesWithAccumulator and made the corresponding definition in the imgproc.hpp file, then did a cmake which seemed to go ok (although there is some sort of download step, which I hope isn't somehow avoiding my changed code). Hoping for a miracle (actually hoping for automatic wrapper-creation) I tried calling cv2.HoughLinesWithAccumulator instead of the working cv2.HoughLines call from my python code (which is where I've been using opencv for abt 1 yr) and as expected no such function exists in the opencv module. So I'm downloading a C++ IDE and will try to call my new func from there; if that works, then I'll try to figure out how the python wrappers get made, and add my new function there. Does this sound reasonable, are there some pitfalls and/or easier ways? 2014-08-13 10:50:01 -0500 asked a question doc error at cascade_classification.html I believe there may be an error in the docs here . In the fifth paragraph, second sentence "For example, in the case of the third line feature (2c) the response is calculated as the difference between the sum of image pixels under the rectangle covering the whole feature (including the two white stripes and the black stripe in the middle) and the sum of the image pixels under the black stripe multiplied by 3 in order to compensate for the differences in the size of areas." I think the "multiplied by 3" should be "multiplied by 2" since the black area was counted as white once, so it must be subtracted one time to arrive at the sum of the two white areas, and then must be subtracted again to get white areas minus black areas, in total then requiring subtraction twice and not thrice.