Мне нужно конвертировать изображение, которое было загружено с Библиотека CImg в формат изображения, который может быть использован в 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 вызвать проблемы с памятью. Примеры сообщений 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
Других решений пока нет …