OpenCV 库的内存问题答案

【问题标题】：Memory problems of OpenCV LibraryOpenCV 库的内存问题
【发布时间】：2013-01-05 16:12:35
【问题描述】：

我需要将使用CImg library 加载的图像转换为图像格式，可以在OpenCV 中使用。

问题是CImg创建了uchar数组，其中数据存储方式如下（以3通道图像为例）：

首先是红色通道的像素，
然后绿色通道的所有像素都跟随，
然后 - 蓝色通道。

看起来像这样：R R R R R R .... G G G G G G ... B B B B B B...

OpenCV 以不同的方式存储数据：B G R B G R B G R B G R...

这是我从 CImg 转换为 IplImage 的代码：

CImg<uint8_t> src;
src.load_jpeg_buffer(srcData, size);
size_t width = src._width;
size_t height = src._height;
size_t nChannels = src._spectrum;
size_t depth = 8;

IplImage* m_image = cvCreateImage(cvSize(width, height), depth, nChannels); 
for(size_t i = 0; i < height; i++)
{
    for(size_t j = 0; j < width;j++)
    {
        for(size_t k = 0; k < nChannels; k++)
        { 
            ((m_image->imageData + i * m_image->widthStep))[j * nChannels + nChannels - 1 - k] =
                    src._data[k * src.size() / 3 + k + (i * m_image->widthStep + j * nChannels) / 3];   
        }
    }
}

这段代码运行良好。 OpenCV格式的转换图像是原始图像的完整副本。

我用 valgrind 测试了这段代码。它说它会导致很多内存问题。我找不到这个内存问题的原因。

如果您对此事有任何想法，我将不胜感激！或者您可能知道另一种方法，它可以从 OpenCV 中的缓冲区加载图像（不是 cvDecodeImage）。

【问题讨论】：

我建议你使用 OpenCV 的 C++ 包装器，从我的角度来看它很容易使用，并且可以避免使用指针，这将帮助你避免内存泄漏。无论如何，您在这部分代码之后释放了 m_image 吗？也许 OpenCV 有这个功能，比如 CvFree...
每次使用图像后我都会做 cvReleaseImage(&image)

标签： c++ opencv memory-leaks type-conversion cimg

【解决方案1】：

问题不在我的代码中。我发现 OpenCV 库函数 会导致内存问题。 valgrind 的消息示例如下：

Use of uninitialised value of size 8
==16460==    at 0x6500539: void cv::CvtColorLoop<cv::RGB2Gray<unsigned char> >(cv::Mat const&, cv::Mat&, cv::RGB2Gray<unsigned char> const&) (in /usr/local/lib/libopencv_imgproc.so.2.4.2) 

==16488== 151,812 bytes in 1 blocks are possibly lost in loss record 3,419 of 3,425
==16488==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16488==    by 0x56A2470: cv::fastMalloc(unsigned long) (in /usr/local/lib/libopencv_core.so.2.4.2)

==16488== LEAK SUMMARY:
==16488==    definitely lost: 19,988 bytes in 171 blocks
==16488==    indirectly lost: 15,201,012 bytes in 311 blocks
==16488==      possibly lost: 1,202,769 bytes in 3,618 blocks
==16488==    still reachable: 693,651 bytes in 3,733 blocks
==16488==         suppressed: 0 bytes in 0 blocks

【讨论】：