cvBridge + opencv memory leak problem

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

cvBridge + opencv memory leak problem

chriss lei
Hello.

I'm using cvbridge to get camera images and using some opencv functions for image processing.
However, memory blows up whenever I use opencv functions on IplImages converted from the imgMsgToCv method.
Using cvCopy, cvCloneImage, cvNormalize, etc... any one of these good' ol opencv functions on IplImage blows up the memory.

So I referred to stereo view.cpp file in http://www.ros.org/doc/api/image_view/html/stereo__view_8cpp_source.html#l00340
It seems like the file uses the new cv::Mat_ data structure to perform operations on images.

Should I always use the new opencv2.1 image data structure( cv::Mat ) if I want to work on opencv images converted from sensor_msgs::Image ?
Or is there a way to work with the IplImages ?

Thanks.

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

rusu
Administrator
Chriss,

The main difference between IplImage and cv::Mat is that you don't need to explicitly deallocate data. When using
IplImage you have to manually deallocate/free the buffer, which is probably why you're seeing memory leaks right now.
cv::Mat is part of the new C++ API that OpenCV 2.x provides.

Cheers,
Radu.

On 05/22/2010 04:36 PM, Chriss Lei wrote:

> Hello.
>
> I'm using cvbridge to get camera images and using some opencv functions
> for image processing.
> However, memory blows up whenever I use opencv functions on IplImages
> converted from the imgMsgToCv method.
> Using cvCopy, cvCloneImage, cvNormalize, etc... any one of these good'
> ol opencv functions on IplImage blows up the memory.
>
> So I referred to stereo view.cpp file in
> http://www.ros.org/doc/api/image_view/html/stereo__view_8cpp_source.html#l00340
> It seems like the file uses the new cv::Mat_ data structure to perform
> operations on images.
>
> Should I always use the new opencv2.1 image data structure( cv::Mat ) if
> I want to work on opencv images converted from sensor_msgs::Image ?
> Or is there a way to work with the IplImages ?
>
> Thanks.
>
>
>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users

--
| Radu Bogdan Rusu | http://rbrusu.com/
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

chriss lei
Hello Radu,

I'm well aware of using cvReleaseImage..
Memory leak happens even if I use a single function on IplImage converted from sensor_msgs.
Here's my callback function to illustrate. Usage of cvCopy here introduces memory blowup problem.

void callback(const sensor_msgs::CameraInfo::ConstPtr& info,
                            const sensor_msgs::ImageConstPtr& left,
                            const stereo_msgs::DisparityImageConstPtr& disparity_msg)
        {
       
                im_left = left_bridge.imgMsgToCv(left, "passthrough");

                disp_bridge.fromImage(disparity_msg->image, "passthrough");
                dispImg = disp_bridge.toIpl();
               
                cvShowImage("left", im_left);

                IplImage* test = NULL;
                test = cvCreateImage(cvGetSize(dispImg), dispImg->depth, 1);
                cvCopy(dispImg, test);
                cvShowImage("disp", test);
       }

Also, I'm not supposed to deallocate any IplImages that are converted from sensor_msgs as described in cvBridge tutorial.
Is there a way to use opencv functions on IplImages and not use cv::Mat ?
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

Suat Gedikli
Hi,

but what about the iplimage "test" which you are creating within your
callback funtion but dont releas ?

Suat

Am Samstag, den 22.05.2010, 16:54 -0700 schrieb chriss lei:

> Hello Radu,
>
> I'm well aware of using cvReleaseImage..
> Memory leak happens even if I use a single function on IplImage converted
> from sensor_msgs.
> Here's my callback function to illustrate. Usage of cvCopy here introduces
> memory blowup problem.
>
> void callback(const sensor_msgs::CameraInfo::ConstPtr& info,
>    const sensor_msgs::ImageConstPtr& left,
>    const stereo_msgs::DisparityImageConstPtr& disparity_msg)
> {
>
> im_left = left_bridge.imgMsgToCv(left, "passthrough");
>
> disp_bridge.fromImage(disparity_msg->image, "passthrough");
> dispImg = disp_bridge.toIpl();
>
> cvShowImage("left", im_left);
>
> IplImage* test = NULL;
> test = cvCreateImage(cvGetSize(dispImg), dispImg->depth, 1);
> cvCopy(dispImg, test);
> cvShowImage("disp", test);
>        }
>
> Also, I'm not supposed to deallocate any IplImages that are converted from
> sensor_msgs as described in cvBridge tutorial.
> Is there a way to use opencv functions on IplImages and not use cv::Mat ?
>


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

Patrick Mihelich
In reply to this post by chriss lei
In your example, im_left is owned by left_bridge and should not be released. However any images you create yourself do need to be released. The memory leak is from not releasing "test".

The original OpenCV C API works with IplImage's. The new C++ API cv::Mat is easier to use and avoids having to release memory manually.

cv_bridge only uses IplImage because it predates the OpenCV C++ API. The next revision of cv_bridge will likely use cv::Mat, precisely to avoid this sort of confusion.

Patrick

On Sat, May 22, 2010 at 4:54 PM, chriss lei <[hidden email]> wrote:

Hello Radu,

I'm well aware of using cvReleaseImage..
Memory leak happens even if I use a single function on IplImage converted
from sensor_msgs.
Here's my callback function to illustrate. Usage of cvCopy here introduces
memory blowup problem.

void callback(const sensor_msgs::CameraInfo::ConstPtr& info,
                           const sensor_msgs::ImageConstPtr& left,
                           const stereo_msgs::DisparityImageConstPtr& disparity_msg)
       {

               im_left = left_bridge.imgMsgToCv(left, "passthrough");

               disp_bridge.fromImage(disparity_msg->image, "passthrough");
               dispImg = disp_bridge.toIpl();

               cvShowImage("left", im_left);

               IplImage* test = NULL;
               test = cvCreateImage(cvGetSize(dispImg), dispImg->depth, 1);
               cvCopy(dispImg, test);
               cvShowImage("disp", test);
      }

Also, I'm not supposed to deallocate any IplImages that are converted from
sensor_msgs as described in cvBridge tutorial.
Is there a way to use opencv functions on IplImages and not use cv::Mat ?

--
View this message in context: http://ros-users.122217.n3.nabble.com/cvBridge-opencv-memory-leak-problem-tp837144p837162.html
Sent from the ROS-Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------

_______________________________________________
ros-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ros-users
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

grbradsk
I'm at home not on a computer with code, but I believe you can use Mat in the old cv functions as follows

Mat planes = ... from bridge or wherever. (whereever an IplImage is produced, you can just assign it to a Mat).
. . .
IplImage cv_planes_0 = planes;

Then use IplImage as normal in the old cv functions.  The memory will do the right thing.


On Sat, May 22, 2010 at 5:20 PM, Patrick Mihelich <[hidden email]> wrote:
In your example, im_left is owned by left_bridge and should not be released. However any images you create yourself do need to be released. The memory leak is from not releasing "test".

The original OpenCV C API works with IplImage's. The new C++ API cv::Mat is easier to use and avoids having to release memory manually.

cv_bridge only uses IplImage because it predates the OpenCV C++ API. The next revision of cv_bridge will likely use cv::Mat, precisely to avoid this sort of confusion.

Patrick


On Sat, May 22, 2010 at 4:54 PM, chriss lei <[hidden email]> wrote:

Hello Radu,

I'm well aware of using cvReleaseImage..
Memory leak happens even if I use a single function on IplImage converted
from sensor_msgs.
Here's my callback function to illustrate. Usage of cvCopy here introduces
memory blowup problem.

void callback(const sensor_msgs::CameraInfo::ConstPtr& info,
                           const sensor_msgs::ImageConstPtr& left,
                           const stereo_msgs::DisparityImageConstPtr& disparity_msg)
       {

               im_left = left_bridge.imgMsgToCv(left, "passthrough");

               disp_bridge.fromImage(disparity_msg->image, "passthrough");
               dispImg = disp_bridge.toIpl();

               cvShowImage("left", im_left);

               IplImage* test = NULL;
               test = cvCreateImage(cvGetSize(dispImg), dispImg->depth, 1);
               cvCopy(dispImg, test);
               cvShowImage("disp", test);
      }

Also, I'm not supposed to deallocate any IplImages that are converted from
sensor_msgs as described in cvBridge tutorial.
Is there a way to use opencv functions on IplImages and not use cv::Mat ?

--
View this message in context: http://ros-users.122217.n3.nabble.com/cvBridge-opencv-memory-leak-problem-tp837144p837162.html
Sent from the ROS-Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------

_______________________________________________
ros-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ros-users
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

chriss lei
In reply to this post by rusu
Thank you.

I obviously forgot to release the image.

Also, converting cv::Mat into IplImage also worked.

I guess I'll slowly migrate towards using cv::Mat.
Reply | Threaded
Open this post in threaded view
|

Re: cvBridge + opencv memory leak problem

grbradsk
Here's a snippet from something I just wrote

Mat scratch;  // part of the state of the node -- if the image size stays constant, it will only allocate once

    //PROCESS THE IMAGE
    if (img_bridge_.fromImage(*msg, "bgr8"))
    {
        Mat I = img_bridge_.toIpl();
        I.copyTo(scratch);
. . .
you don't have to deallocate ever (you could ... using scratch.release() but you almost never need to



On Sat, May 22, 2010 at 6:39 PM, chriss lei <[hidden email]> wrote:

Thank you.

I obviously forgot to release the image.

Also, converting cv::Mat into IplImage also worked.

I guess I'll slowly migrate towards using cv::Mat.
--
View this message in context: http://ros-users.122217.n3.nabble.com/cvBridge-opencv-memory-leak-problem-tp837144p837271.html
Sent from the ROS-Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------

_______________________________________________
ros-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ros-users
_______________________________________________


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users