https://bugs.kde.org/show_bug.cgi?id=426175
--- Comment #28 from caulier.gil...@gmail.com --- Hi Marcel, The problem is not directly in dnnfacedetectorssd. Look well the back-trace. All continue in low level inside... OpenCV API. The memory problem is at this place. This is what we suspect since a while: the big puzzle named OpenCV as too many way to optimize computation / process/ data management, using hardware, as GPU. I'm in contact with team from KDenlive project (video montage application) which use also OpenCV in background with the same problem. The solution is to disable optimizations at OpenCV compilation. I do it for all bundles, but it's not possible for native digiKam version where we don't have control of OpenCV configuration. So the ultimate solution is to find a real solution in digiKam code to prevent this memory leak. The problem is to find the context where this dysfunction appear, and it's certainly sue to compilation option in OpenCV, as, i never reproduce this memory leak on all Linux version installed in my computer since many year. This want mean that OpenCV here is compiled without a specific optimization. The Q is which one? If you look in OpenCV CMake top level options, you will see a very huge list of possibility. It's completely crazy... This is what's i use for the bundles : https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/3rdparty/ext_opencv/CMakeLists.txt#L11 Another possibility, is a problem with a specific kernel option or a GPU driver bug, used indirectly by OpenCV. Here again, the complexity to found the reasons is similar to the distance which separate the sun and the earth. Gilles -- You are receiving this mail because: You are watching all bug changes.
