mirror of
https://github.com/zebrajr/opencv.git
synced 2026-01-15 12:15:17 +00:00
71c759b7cd
Fixed multiband blender memory leak 27333 #28085 Fixes #27333 This PR fixes a memory leak in MultiBandBlender where memory from pyramid vectors was not being released when prepare() was called multiple times or when the blender object was reused. Problem: MultiBandBlender retains hundreds of MB to several GB of memory even after the blender pointer is released. The issue occurs because: 1. The resize() function on std::vector does not release memory when the new size is less than or equal to the current size 2. It only adjusts the size marker while retaining the capacity and existing data 3. When prepare() is called, the pyramid vectors are resized but old data remains allocated Example from the bug report: Blending 14 images (1920x1080) retained ~200MB after blender.release(). With larger images, several GB could be retained. Root Cause: GPU path (lines 254-256): Correctly calls clear() before operations Non-GPU path (lines 285-298): Missing clear() calls, causing resize() to retain old data Solution: Added .clear() calls before .resize() in the non-GPU path to match the GPU path behavior. This ensures: - Memory from previous blend operations is released in prepare() - Reusing a blender object doesn't accumulate memory - Behavior is consistent between GPU and non-GPU code paths Changes: modules/stitching/src/blenders.cpp: Added 2 clear() calls (dst_pyr_laplace_.clear() and dst_band_weights_.clear()) before resize() in the non-GPU path Pull Request Readiness Checklist: - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch (4.x) - [x] There is a reference to the original bug report and related work (issue #27333) - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable N/A - This is a memory management fix that doesn't affect algorithm behavior. Existing stitching tests verify correctness. - [x] The feature is well documented and sample code can be built with the project CMake The fix maintains existing API behavior, no documentation changes needed
OpenCV: Open Source Computer Vision Library
Resources
- Homepage: https://opencv.org
- Courses: https://opencv.org/courses
- Docs: https://docs.opencv.org/4.x/
- Q&A forum: https://forum.opencv.org
- previous forum (read only): http://answers.opencv.org
- Issue tracking: https://github.com/opencv/opencv/issues
- Additional OpenCV functionality: https://github.com/opencv/opencv_contrib
- Donate to OpenCV: https://opencv.org/support/
Contributing
Please read the contribution guidelines before starting work on a pull request.
Summary of the guidelines:
- One pull request per issue;
- Choose the right base branch;
- Include tests and documentation;
- Clean up "oops" commits before submitting;
- Follow the coding style guide.
Additional Resources
- Submit your OpenCV-based project for inclusion in Community Friday on opencv.org
- Subscribe to the OpenCV YouTube Channel featuring OpenCV Live, an hour-long streaming show
- Follow OpenCV on LinkedIn for daily posts showing the state-of-the-art in computer vision & AI
- Apply to be an OpenCV Volunteer to help organize events and online campaigns as well as amplify them
- Follow OpenCV on Mastodon in the Fediverse
- Follow OpenCV on Twitter
- OpenCV.ai: Computer Vision and AI development services from the OpenCV team.