Feature Request: Update EasyOpenCV to utilize the new OpenCV 5.0 core

[chriswn]

Hi OpenFTC Team,
With the official release of OpenCV 5.0, there are massive structural updates and performance enhancements (such as the rewritten graph-based DNN engine, faster findContours via the TRUCO algorithm, and improved warping speeds).
Currently, EasyOpenCV (v1.7.3) is tracking the OpenCV 4.x line (v4.10.0). Because OpenCV 5.0 introduces breaking changes like removing the legacy C API and splitting up calib3d into separate geometry/calib modules, it would require a structural update on the wrapper side.
Are there any plansto migrate EasyOpenCV to the 5.x branch for upcoming FTC SDK releases? The performance jumps on ARM devices would be incredible for team vision pipelines next season.
Thank you for all your hard work on this library!

[Windwoes]

Hi there - there are no existing plans for migration to 5.x, but if you have some benchmarks to show that it really does improve performance on the Control Hub, then some plans for migration may be made 🙂

[chriswn]

Hey @Windwoes, appreciate you being open to revisiting this.
So I ran the numbers on a Control Hub (RK3328, quad-core A53) OpenCV 4.x vs 5.0 build and honestly, it's mixed.
For the general pipeline of 1000 frames, synthetic 640x480 HSV conversion, thresholding, perspective warping, finding contours, standard FTC color-tracking, OpenCV 5 is genuinely faster. 58.1 FPS / 17.21ms on 4.x vs 123.4 FPS / 8.10ms on 5.0. That's about 2.1x, and it matches what you said about the improved findContours implementation.
AprilTag is where things fall apart, though. I compared EasyOpenCV's native apriltag C wrapper (decimate=3.0, 4 threads) against OpenCV 5's ArucoDetector running DICT_APRILTAG_36h11 with a stripped-down config (3 threads, single adaptive-threshold pass, no corner refinement). Native Apriltag hit 355.3 FPS (2.81ms/decode). ArucoDetector came in at 18.3 FPS, 54.67ms/decode, about 19x slower!
This isn't really apples-to-apples. It's more a purpose-built AprilTag C library vs. a general ArUco-family detector that happens to support 36h11. ArucoDetector also has nothing like it, so some of that gap is probably the missing decimation step, not the algorithm itself being slower. Also, I can confirm the API breakage you flagged is real. getPerspectiveTransform Moved Imgproc into a new org.opencv.geometry.Geometry class in the 5.0 build I'm running, so existing code won't just drop in as-is.

Caveats: the benchmarks used synthetic in-memory Mats, not a live camera feed, and this is one Control Hub.

Net takeaway: a solid win for general vision pipelines, clear loss for AprilTag via ArUco as currently set up. Happy to post the full benchmark OpModes if useful, and I could try a decimation-equivalent downsample step to see if it narrows the AprilTag gap, if that'd help with the migration call.

[Windwoes]

Is this analysis AI generated? It reads as such.

[chriswn]

No, it was improved with AI

[chriswn]

This was the original So I ran the numbers on a Control Hub (RK3328, quad-core A53) OpenCV 4.x vs 5.0 The result is very mixed as put a normal pipeline of 1000 frames using synthetic 640x480 HSV conversion, thresholding, perspective warping, finding contours, standard FTC color-tracking Open CV5 was faster leads 58.1 FPS per 172.21fpson cv 4 and 123.4 fps/ 8.10ms for 5 The problem starts with the April tag when I compared easy open series native appetite wrapper usingdecimate=3.0, 4 threads against OpenCV 5's ArucoDetector DICT_APRILTAG_36h11 with a stripped-down config 3 threads, single adaptive-threshold pass, no corner refinement cv4 Apriltag hit 355.3 FPS 2.81ms/decode. ArucoDetector came in at 18.3 FPS, 54.67ms/decode, But I would say this is not really apples to apples it's more because of the built in every tag see library versus the general ArUco family Because it's missing the decimation step and it might not be because of the algorithm is actually slow itself and I can also come from about the API changes because there were a bunch of stuff to move from Imgproc into a new org.opencv.geometry.Geometry class in the 5.0 build I'm running, so existing code won't just drop in as-is. but this is not really a full benchmark because of using synthetic mats and other live camera and I only ran this on one control hub so I would say that it's it will be very in for general vision pipelines but there's a problem with the way deeper tag was set up with our code detector I'll be happy to give you the benchmark OP modes there I could also try the decimation and aownsample stap to see If there's any changes