Issue 1:
System information (version)

OpenCV => 4.2

Operating System / Platform => Windows 10

Compiler => Visual C++ 2019

Detailed description

This is not a duplicate of similar looking issues reported earlier because it explains how those unreleased blocks accumulate in certain cases and this situation cannot be resolved by suppressing the report as suggested here #16464 (comment)

Suppose there's ProcessingModule.dll made by a user and it links to opencv_core420d.dll via a .lib file - such that when anyone tries to load ProcessingModule.dll then Windows automatically loads opencv_core420d.dll too.

Each time ProcessingModule.dll is loaded using LoadLibrary() Windows loads opencv_core420d.dll and this causes OpenCV to constructs some global objects some of which allocate dynamic memory. When ProcessingModule.dll is unloaded with FreeLibrary() Windows also unloads opencv_core420d.dll and dynamic memory from those global objects remains unfreed. If LoadLibrary()/FreeLibrary() are called in a loop those unreleased blocks accumulate and form a leak which gets worse over time because those global objects are created anew every time opencv_core420d.dll is loaded and those global objects are never released.

So the code to reproduce the problem would be something like this:

int main()
{
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG ) | _CRTDBG_LEAK_CHECK_DF);
for (int c = 0; c < 50; c++)
{
HMODULE h = LoadLibraryW(L"ProcessingModule.dll");
FreeLibrary(h);
}
}

and after this runs and the program exits there's a huge number of leaks reported in Visual Studio debugger output - about ten leaks per each iteration of the loop and all of them belong to global objects when OpenCV created for its own needs and never released. When upper limit is increased from 50 to a larger number then the number of reported unreleased blocks increases.

You may say "don't write stupid programs" but the scenario above is perfectly natural when using in-proc COM servers. Here's how:

user calls CoCreateInstance() to instantiate an object which is served by ProcessingModule.dll

Windows loads ProcessingModule.dll and also opencv_core420d.dll, those global objects are initialized

user releases the object he requested earlier

some time passes and Windows calls DllCanUnloadNow() in ProcessingModule.dll to find whether it's still serving any objects

ProcessingModule.dll returns "no objects, you may unload me" and Windows unloads ProcessingModule.dll and also opencv_core420d.dll

some more time passes and user again calls CoCreateInstance() to instantiate an object which is served by ProcessingModule.dll

the cycle continues

This is effectively the same as a "stupid for loop" above and it may occur naturally when using in-proc COM servers on Windows.

This cannot be resolved by ignoring those unreleased blocks using valgrind suppressions or their equivalent.

Steps to reproduce

Issue submission checklist

I report the issue, it's not a question

I checked the problem with documentation, FAQ, open issues,

forum.opencv.org, Stack Overflow, etc and have not found solution

I updated to latest OpenCV version and the issue is still there

There is reproducer code and related data files: videos, images, onnx, etc

Issue 2:
System information (version)

OpenCV => 4.1.0

Operating System / Platform =>Ubuntu 18.04

Detailed description

I want to test out the pipeline for stereo camera calibration and depth map estimation. I used the OpenCV sample (samples/data/left01.jpg – left14.jpg and right ...) for calibration. Is there any pair of images on which I could test depth map estimation after the stereo set has been calibrated with the given example?

Relevant Documentation

The camera calibration tutorial uses the same sample (samples/data/left01.jpg – left14.jpg and right ...) for calibration as I did. Next, it is unclear whether the pair of images from depth map from stereo images tutorial is actually the pair of images taken with the same stereo camera that was calibrated in the previous tutorial. Also, this tutorial only shows how to compute disparity but not actually estimate the depth.

It'd be great if the depth map tutorial had a stereo image pair, so that depth from this pair could be estimated using camera parameters from the calibration tutorial.