2014-06-23 01:51:15 -0600 | answered a question | Median filter greater than 5. Linear complexity median filter (such as OpenCV's 8-bit single and multichannel versions) is based on a moving histogram implementation. Naturally for floating point, there is none or it would be close to infinite sized histogram. Simplest workaround would be discretization - say - to 8-bit :) if that suits you. Or then increasing the number of bins in a custom way. You can follow one of these guidelines or just implement O(N^3) version yourself. The last N comes from the search using |
2013-06-24 13:42:24 -0600 | received badge | ● Nice Question (source) |
2013-05-17 03:42:04 -0600 | received badge | ● Student (source) |
2013-05-17 03:39:32 -0600 | asked a question | [email protected] 7x slower than CvEM @ 2.2.0 Hi folks, I just changed from OpenCV 2.2.0 to 2.4.5 and what I observe is CvEM (expectation maximization) speed dropping by a factor of 7. Searching around a bit, I found this bug report: http://code.opencv.org/issues/1435 but that or the one it links to has not been updated for a while. I see that CvEM has been moved to legacy code, but nevertheless the problem appears to be not using LAPACK at all. BTW, is cv::EM just a wrapper around CvEM? I just wonder if there would be a solution. At least I think it is good to raise this issue. For my case, time increase (to put in numbers: from 3 to 21 seconds) is not acceptable. At time, I plan to put the few new 2.4.5. features that I need into a DLL, and continue using 2.2.0 for my actual project. I have compiled both 2.2.0 and 2.4.5 from source using Visual C++ 9.0, and configured the project hand picking every single CMake option. I suppose there shouldn't be any config issue. I don't have EIGEN2 (which was already an option in 2.2.0), and I'm using Win XP 32-bit (Intel Core i5 Arrandale). |
2013-02-15 08:04:59 -0600 | answered a question | [C++] OpenCV2.4.3, cv::resize produces empty image Instead of questioning cv::resize, I would look at your displayMat. I never use MFC, but Gdiplus::Bitmap(INT width,INT height,INT stride,PixelFormat format, BYTE *bits) looks similar to yours. In RGB24, the length of the stride is equal (or larger if "strided" data) 3 * width bytes and not 4 * height. Maybe you should nevertheless check that the CV type is actually CV_8UC3 before expecting it. In OpenCV 2-D images the stride is always given in img.step.p[0].
|
2012-12-20 07:42:28 -0600 | received badge | ● Teacher (source) |
2012-12-20 05:08:12 -0600 | received badge | ● Editor (source) |
2012-12-20 05:06:04 -0600 | answered a question | How to use Mat_ ? Write as a template: template< class _Type > class Foo { public: static void Diff( cv::Mat_<_Type> &a, cv::Mat_<_Type> &b); private: Foo(){} ~Foo(){} }; |