[opencv] update to 4.9

[cenit]

Fixes #41418
Fixes #41250
Fixes #41094
Fixes #41038
Fixes #40680
Fixes #40568
Fixes #40393
Fixes #40406
Fixes #39884
Fixes #39835
Fixes #39651
Fixes #39454
Fixes #39224
Fixes #38321
Fixes #36771
Fixes #36093
Fixes #36009
Fixes #35937
Fixes #34559
Fixes #34279
Fixes #33742
Fixes #32228
Fixes #17850
Fixes #13120
Fixes #4937

Depending on #39703 (need to remove ffmpeg from ci.baseline here after that PR acceptance)

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[JavierMatosD]

any news?

We are experimenting with a new internal review process. We were using vcpkg-team-review to reflect something else, but that is no longer the case. My apologies for the confusion.

This PR lgtm, but I'd prefer that @Neumann-A's review comments be addressed. I'm placing the PR in draft for now.
Please mark 'ready for review' when you have either addressed Neumann-A's feedback or responded. I will not look at this PR if it is in Draft. Marking it 'ready for review' lets me know that it is ready to be looked at again.

[JavierMatosD]

Just need a response to Neumann-A's review

[cenit]

I tried to answer all points and I applied a modification for what concerns the python3[extensions] clause.
Let's wait for CI, then if @Neumann-A is fine I will make the PR ready for review again

[cenit]

assuming the approval as a generic go for all open points, i resolved all of them and marked pr as ready

[AdrianEddy]

@cenit I'd like to express my gratitude for you for putting in all the work on this PR and sticking with it for all the needed changes and fixes. I was watching it regularly and seeing you going through so many reference updates, issues with dependencies and extremely long CI runs and I just wanted to say thank you. You did a great job for all of us!

[theoractice]

@cenit thank you very much!
BTW I just found this update installs all opencv headers into opencv4 directory on windows. Needs a little fix?
I am using the latest vcpkg.exe.

[dg0yt]

I'm happy to see opencv 4.9 merged. However:

• I see downstream regressions in some PRs which involve opencv4 at least indirectly due to changes to ci baseline, e.g. [itk] Revise, test, fix #41525.
• I have a direct fail for opencv4[core,tesseract]:x64-android (during analysis of the other failures).
• I stumble again over the updated patches with no relevant changes. They really make it harder to analyse what has changed and what hasn't.

[cenit]

I'm happy to see opencv 4.9 merged. However:

• I see downstream regressions in some PRs which involve opencv4 at least indirectly due to changes to ci baseline, e.g. [itk] Revise, test, fix #41525.
• I have a direct fail for opencv4[core,tesseract]:x64-android (during analysis of the other failures).
• I stumble again over the updated patches with no relevant changes. They really make it harder to analyse what has changed and what hasn't.

openvino is a dependency of opencv, so if opencv can be a dependency of openvino (i don't know it very well) that might create a circular dependency that vcpkg has many times failed to serve properly (it would require building base opencv, then openvino, then again opencv with openvino). Creating openvino forcing it without opencv might be the best solution if we cannot solve the circular problem above.

opencv4 has no tesseract feature. Which fail do you notice? I tried many combinations and all were working. I found that with opencv 4.10 I had to change something in opencv4[core,contrib], which has a dependency on tesseract. Is it what you meant? I didn't find this problem with OpenCV 4.9 when i tested it in the same test matrix i run...

which patches have no relevant changes here? i will try my best to help you find any regression that might have been lost, even before the #41985 gets interesting

[dg0yt]

Creating openvino forcing it without opencv might be the best solution if we cannot solve the circular problem above.

It is a requirement. Implemented in #42017.

opencv4 has no tesseract feature. ... opencv4[core,contrib], which has a dependency on tesseract.

Yes. #42015.

which patches have no relevant changes here?

To clarify: no relevant changes wrt to the patch for 4.8. Such as ports/opencv4/0006-fix-uwp.patch.

[dg0yt]

FTR I really don't expect every port and feature configuration to work immediately after a major update, given the complexity fo the ports.

[cenit]

About #42015, strange that i didn't notice it in the test matrix and it appeared for the 4.10... sorry for that. It's not a config set we use very much, thanks for the PR

About the relevant change...

this is the relevant one: the new line to which apply the fix. Some configs are very strict about patch application, if the line does not match exactly they fail, and I prefer to be compliant with those requirements.

[dg0yt]

FTR the openvino failure is quite interesting:

CMake Error at /vcpkg/downloads/tools/cmake-3.30.1-linux/cmake-3.30.1-linux-x86_64/share/cmake-3.30/Modules/FindOpenSSL.cmake:210 (pkg_check_modules):
  Unknown CMake command "pkg_check_modules".
Call Stack (most recent call first):
  /mnt/vcpkg-ci/installed/x64-android/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
  /vcpkg/scripts/buildsystems/vcpkg.cmake:813 (include)
  /vcpkg/downloads/tools/cmake-3.30.1-linux/cmake-3.30.1-linux-x86_64/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /mnt/vcpkg-ci/installed/x64-android/share/curl/CURLConfig.cmake:60 (find_dependency)
  /mnt/vcpkg-ci/installed/x64-android/share/curl/vcpkg-cmake-wrapper.cmake:11 (_find_package)
  /vcpkg/scripts/buildsystems/vcpkg.cmake:813 (include)
  /vcpkg/downloads/tools/cmake-3.30.1-linux/cmake-3.30.1-linux-x86_64/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /mnt/vcpkg-ci/installed/x64-android/share/tesseract/TesseractConfig.cmake:24 (find_dependency)
  /vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
  /vcpkg/downloads/tools/cmake-3.30.1-linux/cmake-3.30.1-linux-x86_64/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /mnt/vcpkg-ci/installed/x64-android/share/opencv4/OpenCVModules.cmake:41 (find_dependency)
  /mnt/vcpkg-ci/installed/x64-android/share/opencv4/OpenCVConfig.cmake:139 (include)
  /mnt/vcpkg-ci/installed/x64-android/share/opencv/vcpkg-cmake-wrapper.cmake:3 (_find_package)
  /vcpkg/scripts/buildsystems/vcpkg.cmake:813 (include)
  cmake/extra_modules.cmake:7 (find_package)
  cmake/extra_modules.cmake:177 (ov_generate_dev_package_config)
  CMakeLists.txt:165 (include)

The only scenario where this should happen is with CMAKE_DISABLE_FIND_PACKAGE_PkgConfig=ON,
I didn't want to debug this any further. Just quickly fixing the baseline regression.

[cenit]

i was constantly getting this regression with openvino on android in this pr if you remember. I wrote also about it along the thread. Then it disappeared

[dg0yt]

Hm, I find the old posts now, but I have no memories. That's remarkable, given https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9709. But that was triggered from changes in CURL.

So with the next CMake version in vcpkg, this particular error will no longer occur...

[sandye51]

I'm happy to see opencv 4.9 merged. However:

• I see downstream regressions in some PRs which involve opencv4 at least indirectly due to changes to ci baseline, e.g. [itk] Revise, test, fix #41525.
• I have a direct fail for opencv4[core,tesseract]:x64-android (during analysis of the other failures).
• I stumble again over the updated patches with no relevant changes. They really make it harder to analyse what has changed and what hasn't.

openvino is a dependency of opencv, so if opencv can be a dependency of openvino (i don't know it very well) that might create a circular dependency that vcpkg has many times failed to serve properly (it would require building base opencv, then openvino, then again opencv with openvino). Creating openvino forcing it without opencv might be the best solution if we cannot solve the circular problem above.

opencv4 has no tesseract feature. Which fail do you notice? I tried many combinations and all were working. I found that with opencv 4.10 I had to change something in opencv4[core,contrib], which has a dependency on tesseract. Is it what you meant? I didn't find this problem with OpenCV 4.9 when i tested it in the same test matrix i run...

which patches have no relevant changes here? i will try my best to help you find any regression that might have been lost, even before the #41985 gets interesting

OpenCV is used only in testing / sampler by OpenVINO, so it's not a produce level dependency.
As tests / samples are turned off in vcpkg, disabling OpenCV in OpenVINO's cmake is the right decision.