Question
cv::Mat memory ownership during legacy IplImage migration
Ira Orbit
0 reputation · 21 Nov 2020, 13:51 UTC
117.2K views1
Loading…
0 reputation · 21 Nov 2020, 13:51 UTC
OpenCV 4.x has deprecated the legacy C API in favor of the C++ cv::Mat interface. A primary driver for this transition is the shift from manual memory management with IplImage to the automatic reference counting implemented in cv::Mat.
When migrating existing pipelines, developers often use conversion functions to maintain interoperability between the two APIs. However, the implicit sharing of data buffers in cv::Mat introduces uncertainty regarding memory ownership when a matrix is derived from a legacy C structure.
If a cv::Mat is created as a wrapper around an existing IplImage buffer, the reference counting mechanism may not automatically track the lifecycle of the underlying C-allocated memory.
cv::Mat wrapper assume ownership of the IplImage data buffer, or must the developer manually call cvReleaseImage?35275 reputation · 21 Nov 2020, 15:26 UTC
Does the cv::Mat wrapper assume ownership of the IplImage data buffer?
No. When you create a cv::Mat from an IplImage using cv::cvarrToMat, the operator= overload, or cv::Mat::operator=(IplImage const*), the Mat header simply points to the same data buffer. The reference counter in Mat does not track the lifetime of the underlying IplImage. Therefore the original IplImage must remain valid for as long as any cv::Mat that references its data exists.
Must the developer manually call cvReleaseImage?
Yes, the developer is responsible for freeing the IplImage when it is no longer needed. The cv::Mat will not free that memory for you; calling Mat::release() only frees memory that Mat itself owns.
cpp
opencvIplImage* oldImg = cvLoadImage(\"file.jpg\", CV_LOAD_IMAGE_COLOR);
cv::Mat matFromIpl = cv::cvarrToMat(oldImg, false); // share data
IplImage:
cv::Mat matCopy = matFromIpl.clone(); // allocates new buffer and copies data
cvReleaseImage(&oldImg);
matCopy for all subsequent processing. It owns its data and is safe to use in multi‑threaded contexts.If you know the IplImage is contiguous and you do not need to modify the data, you can skip the clone and keep the IplImage alive for the lifetime of the cv::Mat. However, in most migration scenarios, the clone step eliminates accidental side‑effects and avoids hard‑to‑debug crashes.
If the image data is not contiguous or you plan to modify it in place, the clone step may incur a performance penalty. In that case, you might want to know:
IplImage guaranteed to be continuous?IplImage be destroyed before the cv::Mat is used?Providing those details would let you decide whether a shallow share or a deep copy is the most efficient approach.
Use comments to ask for clarification. Post a solution as an answer.
6,130 reputation · 22 Nov 2020, 00:15 UTC
One critical detail to verify during this migration is the memory layout of the source IplImage. While cv::Mat handles strides (step) internally, legacy IplImage structures often include padding bytes at the end of each row for alignment.
If you wrap an IplImage and subsequently pass that cv::Mat to a function that assumes a contiguous memory block (e.g., certain raw pointer operations or external C-libraries), you may encounter memory corruption or skewed images. You can verify if the resulting wrapper is contiguous using:
if (!matFromIpl.isContinuous()) {
// Data contains padding; a .clone() is mandatory for contiguous access
}In OpenCV 4.x, .clone() not only solves the ownership issue mentioned in the previous response but also ensures the resulting buffer is contiguous, removing the legacy stride dependencies.