Clean samples

[vpisarev]

Describe the feature and motivation

samples is one of the main faces of the library. Currently, we have a lot of poorly organized, mainly obsolete samples in OpenCV. We need to clean it up in OpenCV 5 and maybe even in OpenCV 4.

• C++ samples:
  • bgfg_segm.cpp - old and low-quality
  • camshiftdemo.cpp - old and low-quality. Deep-learning based object detection and tracking demos can be used instead
  • cloning_demo and cloning_gui - low-quality. Deep-learning based computational photography demos could be added later.
  • contours2.cpp, convexhull.cpp - old. can easily be removed. Example how to call convexHull can be added to documentation.
  • create_mask.cpp is almost useless example. can be removed.
  • dbt_face_detection.cpp - obsolete
  • delaunay2 - obsolete. Delaunay triangulation might still be useful, but it's quite stupid way to demonstrate it.
  • demhist - we can retain it, but it shall definitely be improved. For now we can keep it as-is.
  • detect_blob - too specialized. Can be removed.
  • detect_mser - possibly retain, but make more useful.
  • dft - too artificial example. Can be removed.
  • digits_lenet - keep, but make it more entertaining, let user to draw digits with mouse.
  • digits_svm - remove
  • dis_opticalflow - remove. We now support RAFT deep learning model.
  • distrans - keep, but need to improve.
  • drawing - keep, but need to significantly improve.
  • edge - we can retain it if we demonstrate many different methods, including deep learning based.
  • ela - looks almost useless. remove
  • em - demo for ML. move to opencv_contrib.
  • epipilar_lines - remove it in favor of essential_mat_reconstr
  • facedetect - remove in favor of deep learning-based demo
  • facial_features - remove in favor of deep learning-based demo
  • falsecolor - probably keep for now, improve later
  • fback - another old demo of optical flow. Remove in favor of deep learning-based demo
  • ffilldemo - we can keep it as long as it's more educative. There should be a gallery of special sample images.
  • filestorage - can be kept, but should be improved
  • fitellipse - looks nice. probably can be kept and extended to demonstrate other figures like convex hull etc.
  • flann_search_dataset - remove it. Probably should have face recognition demo (or place recognition demo) instead.
  • ... (skip several)
  • inpaint - remove. Need to replace it with deep learning-based demo.
  • kalman - remove. We already have very fast deep-learning based trackers
  • kmeans - too primitive. Remove.
  • laplace - too primitive. Remove.
  • letter_recog - remove in favor of deep learning-based demo working with real images.
  • lkdemo - classic. Keep it for now, but we need a better point tracking algorithm and demo. Something like PTAM.
  • logistic_regression - move to opencv_contrib/ml/samples.
  • lsd_lines - remove. Add deep learning-based demo as soon as we have such an algorithm.
  • mask_tmpl - remove.
  • matchmethod_orb_... - remove. It's enough to have planar object tracking demo using SIFT/A-SIFT.
  • minarea - too primitive, remove.
  • morphology2 - entertaining but primitive. May be kept, but should be improved. E.g. it can be converted to object counting demo.
  • neural_network - it's obsolete. remove.
  • npr_demo - keep and improve.
  • pca - somewhat old, but might be useful for education purposes. Can keep, but need to be improved.
  • peopledetect - remove in favor of deep learning-based demo.
  • phase_corr - remove
  • points_classifier - move to opencv_contrib/ml/samples
  • polar_transforms - remove perhaps
  • segment_objects - replace with a demo of SAM or a similar model.
  • simd_basic - may keep, but needs to be extended perhaps to demonstrate more useful stuff.
  • smile_detect - remove. The feature (smile detection) would be a useful addition to the deep learning-based face detection example.
  • squares - too old. remove.
  • stereo_calib - keep, but probably improve.
  • stereo_match - same.
  • stitching_detailed and stitching - good demos, but need improvements. Do we need 2 variants of image stitching demo?
  • text_skeweness_correction - remove. replace with text detection and recognition demo.
  • train_HOG - obsolete. Remove.
  • train_svmsgd - move to opencv_contrib/ml/samples.
  • travelsalesman - move to opencv_contrib/ml/samples.
  • tree_engine - same.
  • video_capture_* - combine multiple examples into 1-3 examples. For example, conventional 2D capture and 3D capture (using depth sensor).
  • warpperspective_demo - remove. Probably, we need a demo of various image augmentations using OpenCV.
  • watershed - probably, keep or combine with grabcut demo.
• Python samples:
  • Python samples are generally better, but need to remove obsolete demos, demos for ML or simple demos which are duplicates of C++ samples.
• DNN samples:
  • Mostly they are fine, but we can consolidate text detection/recognition examples and also merge "tf_" examples into the respective examples for ONNX (since ONNX is now our main format).
• do we need dedicated "java/" if we have "android/"?
• winrt, winrt_universal and wp8 should probably be removed
• example of HAL should be non-trivial. We need to polish Carotene, we need to move IPP-based HAL from 'embedded HAL' to 3rdparty. They will be much more realistic examples for HAL than opencv/samples/hal.
• openvx shall be removed, we no longer support it.
• probably, put directx, opengl, sycl, va_intel, opencl under "interoperability" directory. Are they all still relevant?
• since non-CPU HAL and, correspondingly, UMat, will evolve, tapi and gpu samples could probably be put to cpp/python directories.

Additional context

No response

[LaurentBerger]

Why don't you clean all samples and create a new repo opencv/samples?

[s-trinh]

Off-topic, but the calibration.cpp code is very useful to calibrate a camera using a set of data from few of my experiences.

[LaurentBerger]

Off-topic,

Clean samples it is the topic.

Removing all samples in opencv 5 and ask user to contribute for specific sample with new rule to follow

[mshabunin]

Why don't you clean all samples and create a new repo opencv/samples?

We need applications in the repository to make sure they can be built (-DBUILD_EXAMPLES=ON), for code snippets in the docs, as templates for user's applications.

And I also agree, that it would be nice to have a separate repository with more utilitarian samples/tools/applications which support multiple OpenCV versions and can depend on other libraries. It would serve as an example for users on how to create their own applications and transition between OpenCV versions.

Off-topic, but the calibration.cpp code is very useful to calibrate a camera using a set of data from few of my experiences.

The interactive-calibration app should be more convenient for this purpose.

[LaurentBerger]

1. May be tutorials folder should be at the top. Something is in Tutorials if there is cpp python and java code (as in https://docs.opencv.org/4.x/dc/dd3/tutorial_gausian_median_blur_bilateral_filter.html). It will improve quality.

2. About samples I still think all samples should be removed in opencv 5 and start from scratch with a guide line to fill a new folder .

3. For opencv 4 changes nothing for samples (legacy)

[mshabunin]

1. May be tutorials folder should be at the top

Do you mean single samples/tutorials folder instead of samples/cpp/tutorial_code, samples/java/tutorial_code, samples/python/tutorial_code? Or on the very top, e.g. opencv/tutorials?

[LaurentBerger]

Tutorials at the top and samples in another repo.
We can find python samples in sample/python but in sample/dnn too (and in opencv_zoo too) and in tutorials. I think a good way is everything in opencv repo must be in doxygen doc.

[mshabunin]

Ok, I see.

Some time ago I had ideas of moving samples to respective modules like it is done in opencv_contrib, for example: https://github.com/opencv/opencv_contrib/tree/4.x/modules/face
So that all samples (including tutorial apps and java/python) would reside in <module>/samples. Tutorials (documents and images) in <module>/tutorials and documentation pages in <module>/doc. This would also require samples rework: for example, simpler apps could be combined into one (load image, run algorithm, show image), some dependencies would need to be broken. And doxygen examples page would be more structured with this approach, because now it is quite hard to navigate - https://docs.opencv.org/4.x/examples.html - to check brief explanation one needs to click each example one by one.

BTW, opencv_zoo can be seen as a standalone samples repository for modern DL-based algorithms. Perhaps it might be possible to generate some HTML pages/docs for it and integrate them with OpenCV doc.