Feature request: no-std support so purecv can run on microcontrollers such a esp32

[rsaccon]

I would love to do some image processing like motion detection on a microcontroller with camera attached.

I saw that "std" is default feature. I expcted, in case the "std" feature is disbaled, some special handling for "no-std" environment, but could not find anything hinting at that in the codebase.

My question: is it planned to support no-std environments at some point, or are there specific reasons for this to be out of scope.

[kalwalt]

I would love to do some image processing like motion detection on a microcontroller with camera attached.

I saw that "std" is default feature. I expcted, in case the "std" feature is disbaled, some special handling for "no-std" environment, but could not find anything hinting at that in the codebase.

My question: is it planned to support no-std environments at some point, or are there specific reasons for this to be out of scope.

Hi @rsaccon welcome to webarkit and thanks for you request!
My primary goal was to develop purecv without any ffi bindings to C++ code (OpenCV) and serve as a modular system for our webarkit project that is targeted to WebAR (with wasm-bigden). I have nothing against to develop a "non-std" feature. Anyway at the moment i have not a schedule for this feature, but for sure after the milestone 7 and other improves that i want to accomplish, but in the meantime we can accomplish a plan for this request, identifying potential issues and how we can solve them.

[kalwalt]

Following up on the plan — here's a rough breakdown of what "no-std support" would actually involve, crate by crate, so we can scope it properly before scheduling it:

• purecv-core (Matrix, Scalar, core math) is the most portable part of the codebase. It's essentially pure algebra with no real OS dependency — the main work is swapping std::vec::Vec → alloc::vec::Vec and std::f64::consts → core::f64::consts. This should get us no_std + alloc support without much churn, and is a good first milestone.
• purecv-imgproc (canny, sobel, filters, morphology) is conceptually portable too, but the parallel feature (Rayon) is a hard blocker — Rayon requires OS threads and can't run under no_std. This would need to be strictly gated behind feature = "std", falling back to the existing scalar path otherwise. I also need to check whether pulp (the simd feature) has no_std support — if not, it needs the same treatment as parallel for now.
• purecv-video (optical flow) and purecv-calib3d (pose estimation, SVD) are the heaviest computationally. They're probably portable in principle, but whether they're practical on something like an ESP32 without a strong FPU/PSRAM is a separate question worth evaluating rather than assuming.

Given that, I'd suggest splitting this into staged sub-issues rather than one big effort:

1. Phase 1 — purecv-core compiles under no_std + alloc
2. Phase 2 — purecv-imgproc compiles under no_std with parallel/simd disabled
3. Phase 3 (exploratory) — evaluate whether video/calib3d are worth porting for embedded targets, or should stay std-only with that documented clearly

This way each phase is independently useful and testable (e.g. Phase 1 alone already gives access to the core Matrix/math types on embedded), and we're not blocked on solving the hardest cases (video/calib3d) before shipping something usable.

I'll open the sub-issues linked to this one and we can prioritize Phase 1 once milestone 7 is wrapped up. @rsaccon if you have a specific ESP32 variant in mind (Xtensa vs RISC-V), that'd help pin down which target triple to validate against in CI.

[rsaccon]

Sounds like a great plan. I currently have only eps32s3 at hand (extensa), but i plan to order some esp32p4 (RISC-V) which is also the most performant one of the esp32 family and therefore a good choice for phase 3 of the plan, if it turns out to be practical/doable.

[kalwalt]

@rsaccon with PR #86 the first Phase 1 is on the way. If you want you can take a look at the code and tell me if you find some bug or inconsistencies. I tested on an esp32-s3 with simply adding two Matrix, and it works, but i think we have to wait Phase 2 for some more interesting feature. Note that there is also smoke test and a i added a CI building step, you can find more infos in the PR itself.