boaz001's profile - activity

I've added the valgrind output with debug info enabled, this shows a function initLabTabs() in color_lab.cpp this functi

Memory leak in RGB2Lab There is a memory leak when using RBG2Lab. Is this an issue with OpenCV? The version is 3.4.11.

The OS is CentOS 6.10. It is not progressive. cv::getBuildInformation() output added to the question.

Memory leak in RGB2Lab There is a memory leak when using RBG2Lab. Is this an issue with OpenCV? The version is 3.4.11.

The OS is CentOS 6.10. It is not progressive.

Memory leak in RGB2Lab There is a memory leak when using RBG2Lab. Is this an issue with OpenCV? The version is 3.4.11.

Memory leak in RGB2Lab There is a memory leak when using RBG2Lab. Is this an issue with OpenCV? The version is 3.4.11.

this answer suggests to use addWeighted

Why not pass the image (as an argument) to the c++ program that you call from the script?

I know how to obtain the dimensions of the text using cv::getTextSize(), but this only works correctly for non-antialiased linetypes (default=8 and 4).

When using CV_AA (linetype=16) the text is partially outside the size defined by cv::getTextSize().

Edit: Should I file an issue for this on GitHub? For now I've decided to not use a anti-aliased linetype.

cv::Ptr is not just a 'normal' pointer. It is a smart pointer and you cannot treat it as a normal pointer. It also has some advantages over a normal pointer. Read the docs for that: cv::Ptr

full video link to save you the trouble of registering

I don't mean to be rude, but you really should try to ask better questions, show some effort! We - just like you - don't like to waste valuable time.

Please guarantee binary-level compatibility between major versions. This I think is the best way to avoid dependency 'hell' and most clear to developers and users, especially from a linux background. Semantic Versioning. As a side-note; I personally like the way Intel IPP deprecates functionality and notifies users (link). They mark many things they believe should be deprecated as such and users are encouraged to report if a deprecation of a particular feature will cause problems for them.

Is const_cast what you're looking for?

don't new the return Mat in both places (inside decompose function and where you call it), Btw there is really no need to use new anyway.

Versioning is added here. So you can modify the cmake file there to not add the version to the filename.

The question you should ask yourself is why you want to link to unversioned libraries.

If you have just one application or library that also distributes the opencv DLL's it isn't that important. But when you start to have multiple applications or libraries (that are all linked to an unversioned DLL) you would have to recompile them all when you want to upgrade opencv. With versioned DLL's library A could be linked against opencv_core2410.dll and application B can be linked agains opencv_core300.dll and both DLL's can be distributed to the client without interfering.

Therefore, it is advisable to use versions.

Tip: start simple, with still images for example instead of video. If you need more help, explain what you want to achieve.

area[i+1] is simply wrong. What have you already tried so far? You seem to have good understanding of what you want to do.

What is the hsv value of the color according to opencv? Is it what you expect? Also, avoid posting/using compressed image formats (jpg) for accurate color detection/conversion stuff.

Post your CMake output please.

maybe related to: this?

Hi, I built cv2.so for python2.7 and python3.4 in raspbian. They both work and I can do import cv2.

However, when I wanted to understand where all the binaries are installed by cmake, I noticed something strange and I didn't understand.

Both py2.7 and py3.4 cv2.so files are depending on the same shared objects. The following is the ldd output

    $ldd py27cv2.so  #python 2.7 
    linux-vdso.so.1 (0x7ee2d000)
    /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76e66000)
    **libpython2.7.so.1.0 => /usr/lib/arm-linux-gnueabihf/libpython2.7.so.1.0 (0x76b2f000)        **
    libopencv_core.so.3.0 => /lib/libopencv_core.so.3.0 (0x7691c000)
    libopencv_flann.so.3.0 => /lib/libopencv_flann.so.3.0 (0x768c9000)
    libopencv_imgproc.so.3.0 => /lib/libopencv_imgproc.so.3.0 (0x765f8000)
    libopencv_ml.so.3.0 => /lib/libopencv_ml.so.3.0 (0x76561000)


    $ldd py34cv2.so #python 3.4         
    linux-vdso.so.1 (0x7ef97000)
    /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76dce000)
    **libpython3.4m.so.1.0 => /usr/lib/arm-linux-gnueabihf/libpython3.4m.so.1.0 (0x769fe000)        **
    libopencv_core.so.3.0 => /lib/libopencv_core.so.3.0 (0x767eb000)
    libopencv_flann.so.3.0 => /lib/libopencv_flann.so.3.0 (0x76798000)
    libopencv_imgproc.so.3.0 => /lib/libopencv_imgproc.so.3.0 (0x764c7000)
    libopencv_ml.so.3.0 => /lib/libopencv_ml.so.3.0 (0x76430000)

Do note the offsets in brackets seem to differ between the two versions. Otherwise both py2.7 cv2.so and py34 cv2.so are dependent on the shared objects (libopencv_core.so.3.0 etc).

Is this correct or is something wrong and it may cause problems later. If this right, could you please tell me how this works and why mixing so files is ok here?
Thanks T

What if you choose 'Reload All'?. Did you notice that it isn't actually using IPP 9? Check the cmake output. Also it looks like it is trying to build after the cmake has run (see bottom of 'OpenCV Build Output.txt'). Have you tried to start over with a clean build/ directory and re-run cmake?

What does your cmake output look like?

I don't understand what you don't understand;). Without this control there would be multiple declaration's of the struct. That does not necessarily hurt, but this way you give the header the full responsibility to declare (and define) the struct. In my opinion this is just another case of enabling 'things', in this case it is the not needing to declare a struct again... nothing special going on.

Can you explain how this is going to leak? Or how you analysed and concluded the leak?

But that 'someone' is going to be the header that defines that struct ID3D11Device, it should never be defined by your own code. This is merely a interface class it doesn't know anything about the types. That is why it only declares it, but does not define it difference. It trusts the header that has __d3d11_h__ defined to also declare the struct ID3D11Device. You also might want to google this to see how that works.

Code and possibly image please, no screenshots, thank you

No, it shouldn't.

It does not include the structures, only declares it. And it probably does it this way so it can compile even if no DirectX header is available.

In the header there are 3 tests for __d3d11_h__ and 10 and 9 versions, but the tests only include the structures if these are NOT defined!

#if !defined(__d3d11_h__)
struct ID3D11Device;
...

Shouldn't the negate be removed, so:-

#if defined(__d3d11_h__)
struct ID3D11Device;
...

For building the attached cpp file I receive CMAKE_MODULE_PATH error while running make command on Terminal.

It uses Gphoto2 and OpenCV to capture live images from a digital camera. This files is based on http://docs.opencv.org/master/db/d56/...

I believe the problem is caused by a wrong CMakeLists.txt file, however I do not know how to fix it. Thanks for your guidance in advance.

grayp.cpp file:

#include <opencv2/imgproc.hpp>
#include <opencv2/highgui.hpp>
#include <opencv2/structured_light.hpp>
#include <iostream>
#include <stdio.h>
using namespace cv;
using namespace std;
int main( )
{

// Open camera,  using libgphoto2
VideoCapture cap1( CAP_GPHOTO2 );

if( !cap1.isOpened() )
{
// check if cam1 opened
cout << "cam1 not opened!" << endl;}
else
cout <<"FFFFFFFFFFFFFFFF"<< endl;

 // the camera will be deinitialized automatically in VideoCapture destructor
cout << "Closing program" << endl;
return 0;
}

CMakeLists.txt file:

cmake_minimum_required(VERSION 2.8)
project( grayp )
find_package( OpenCV REQUIRED )
add_executable( grayp grayp.cpp )
target_link_libraries( grayp ${OpenCV_LIBS} )
option(GPHOTO2 "test" ON)
find_package( GPHOTO2 REQUIRED )
include_directories(/usr/local/include/gphoto2)
include_directories(/home/pi/Downloads/libgphoto2-2.5.9/libgphoto2)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/home/pi/code/prof/gray")

What exactly do you mean with 'does not work'? How did you reinstalled opencv?

convertTo

besides.. malloc() is not what you should use if your doing c++. And if you encounter problems 'when i do some image processing' its better to describe what the 'problems' and 'some image processing' are. Now we have no idea!

I remember having to put this for my Macbooks iSight camera to open properly, don't ask me how I figured this out..

// set video capture properties for MacBook' iSight camera
videoCapture.set(CV_CAP_PROP_FRAME_WIDTH, 500);
videoCapture.set(CV_CAP_PROP_FRAME_HEIGHT, 600);

So you are only modifying m_croppedRenderImg->data? What about it's dimensions? I don't know your reasons to do so much pointer fiddling, you know about OpenCV's memory management already being quite efficient right?

The apertureSize parameter as described by the canny documentation does not give any difference in the detected edges.

Here is my code:

thresh1 = 100
thresh2 = 200
aperture1 = 3
aperture2 = 7
img = cv2.imread("lena.png", 0)
edges1 = cv2.Canny(img, thresh1, thresh2, aperture1)
edges2 = cv2.Canny(img, thresh1, thresh2, aperture2)
cv2.imshow("result aperture 3", edges1)
cv2.imshow("result aperture 7", edges2)
cv2.waitKey()

Why are both result images identical?

thank you @berak. Python beginner here.., thanks for explaining