Clean Imgproc module

[vpisarev]

Describe the feature and motivation

Image processing (imgproc) is one of OpenCV flagship modules, actively used by many people, even in deep-learning era. Most of the stuff it contains is quite useful, but there is some old, obsolete functionality.

Let's clean it up a bit in OpenCV5. Namely:

• Move old corner detectors to opencv_contrib/ximgproc: cornerMinEigenVal, cornerHarris, cornerEigenValsAndVecs, preCornerDetect. Those functions are all well replaced with goodFeaturesToTrack.
• Move accumulate*() to opencv_contrib (or to some compatibility header). accumulate() and accumulateWeighted() are already covered by add() and addWeighted(). The other 2 can be replaced with slightly less efficient combination of 2 functions: multiply() and add(). There is no much use for those functions currently.
• move EMD (Earth mover distance) to opencv_contrib.
• possibly remove compeltely pyrMeanShiftFiltering. It's very old algorithm that gives very poor quality by today's standards.
• move moments() and HuMoments() to opencv_contrib.
• move HoughLines (all variations), HoughCircles(), GeneralizedHoughTransform and LSD (line segment detector) to opencv_contrib. Currently there are significantly, incomparably better deep learning methods to detect lines, circles and other simple objects that with proper optimizations and some tricks can be made equally efficient to traditional methods (or even more efficient when using dedicated accelerators). See https://arxiv.org/pdf/2003.04676.pdf for example
• not to remove, but we need to normalize color conversion API. The new cvtColor() should take 2 color spaces, input and output, and choose the proper conversion algorithm. It should cover different variations of YUV color space, including subsampled options like 4:2:0, 4:2:2 etc. Color space conversion should also be able to convert the result to proper data type (e.g. FP16 or FP32) with or without scaling. It can be done as a part of the parallel loop.

Additional context

No response

[crackwitz]

May I also suggest completely redoing all the drawing primitive calls?

• cv::line() doesn't produce lines that are anywhere near the requested thickness

• Circles are lumpy, as seen in cv::getStructuringElement()

• No way to draw flat-shaded or textured triangles/polygons in 2D or 3D-orthogonal projection. At least drawing a single textured triangle should be available, without hacks that involve warpAffine or warpPerspective and leave hairline artefacts.

• No core facility to draw 3D perspective geometry, such as wireframes, single or multiple flat/textured triangles with Z-buffer, perhaps into a Mat that already contains data. It needn't be high performance. It needs to be simple and accessible and always there. All the existing "3D drawing" facilities require external dependencies that don't come with the official opencv-python packages.

• Drawing calls do support sub-pixel coordinates via shift argument, but I find that inconvenient. There should be overloads that take float scalars or float-typed Mats/vectors/numpy arrays.

[vpisarev]

@crackwitz, thanks! I have better implementation of a part of the drawing functions based on the supersampling idea, possible that would solve some of the problems.

for 3D visualization with have a pending PR with a lot of new stuff: #20371. Any help in finalizing that PR is greatly appreciated.

On sub-pixel coordinates as float's - yes, that should be rather easy to implement.

There should be several subsequent feature request to improve, not just cleanup, imgproc. They will touch batch processing, parallel implementation of filters etc. You are welcome to submit "drawing" stuff related feature request(s)