Learn/rusty_esp_imageesp32-cameraesp32jpegrust

rusty_esp_image Is a Pure Rust Alternative to esp32-camera

rusty_esp_image is a pure Rust alternative to calling esp32-camera from a sketch: borrowed frames, a two-buffer pool, and sensor tables as data. The driver stays.

Signed by M·
Dawn brick lake with a small camera brick on a post at the shore, its orb joining the homes around the water
Is rusty_esp_image a pure Rust alternative to esp32-camera?

For the sketch, yes. The driver stays. rusty_esp_image is a pure Rust alternative to calling esp32-camera yourself: one wrap behind an ImageSource trait, a fixed frame pool, and sensor tables as data. On Track A it does not replace Espressif's driver. A pure esp-hal backend is planned and not built.

Related reading

Builder field note

ESP32 Camera Capture in Rust: Frame Pools, JPEG, Sensor Tables

APIs, composition, and home deployment for ESP32 Camera Capture in Rust: Frame Pools, JPEG, Sensor Tables live on the field note.

rusty_esp_image is a pure Rust alternative to esp32-camera for the code you write, not for the driver underneath. Espressif's esp32-camera is the market standard capture driver on ESP-IDF. On Track A this crate wraps that driver once, behind a Rust ImageSource trait, and hands the sketch a borrowed frame. This page is the comparison, and the first sentence is the limit. The builder field note on rusty_esp_image is the pool record. It belongs to the See vision.

What calling esp32-camera from a sketch costs

The C driver works. A sketch that reaches into it tends to copy a frame into a fresh buffer, then copy it again for JPEG, then wonder why the rate fell. The chip did not get slower. The copies did.

One wrap, then a borrow

grab writes into memory the caller owns and returns a view that borrows it. No frame is allocated per capture. IdfCamera copies one frame per grab out of the driver's PSRAM buffer and then stops. A pure Rust alternative to esp32-camera that claimed the C driver was gone would be false on Track A. A pure esp-hal backend for the S3 is planned and not built.

Two buffers, measured

On a XIAO ESP32-S3 Sense one buffer gave 13.882 fps and two gave 27.764 fps, a factor of 2.000003. A third buffer produced the same frame count and only cost PSRAM. The generated firmware asks for two. 581 captures had zero failures. When the pool is starved, the measured driver does not fail the call. It blocks until a buffer is free, so the symptom is a lower rate.

Tables as data, not a second driver

The OV2640 and OV5640 register sequences were converted from esp32-camera's headers: 302 steps across seven OV2640 tables and 216 steps across nine OV5640 tables, gamma and white balance included, with delay steps where the datasheet asks for them. They replay over SCCB through embedded-hal 1.0. A test applies the full OV2640 init table on a fake bus. The OV2640 ran on an AI-Thinker ESP32-CAM. An OV3660 answered on the XIAO. Other sensors are not tables yet. The source of those tables is Apache-2.0 and attributed.

Pixels moved to the kernel home

YUYV to RGB565, RGB888, or grayscale, and the reverse, plus downscale, crop, and rotate, started here and moved to rusty_esp_dsp, byte-identical to the copies they replaced. The image crate re-exports them. That split is why a pure Rust alternative to esp32-camera can stay a capture seam and not a pile of pixel loops. The DSP comparison is the pure Rust alternative to esp-dsp.

JPEG, usually the sensor's

Most boards use the sensor's JPEG mode, which needs no encoder on the chip. A jpeg encode path over rusty_jpeg is no_std, compiles for the ESP32-S3 bare-metal target, and is tested on the host. It is not the path the measured 27.764 fps row used.

Where esp32-camera still wins

Call the C driver yourself when you are already in an IDF example and you do not want a Rust trait in the way. A pure Rust alternative to esp32-camera is the wrong layer if you needed a new sensor driver this week. Track B is not built.

Honest limits

  • Track A wraps esp32-camera. Say that in the same breath as the title.
  • Sensor tables exist for OV2640 and OV5640. An OV3660 answered on one board. That is not a table for every module in the header.
  • The streaming page that consumes these frames is rusty_esp_video, the pure Rust alternative to CameraWebServer.

If your sketch today calls esp_camera_fb_get and then copies the buffer because the lifetime scared you, the seam is the thing to port, not the sensor driver. A pure Rust alternative to esp32-camera gives that seam a name and a pool size that was measured. It does not give you permission to delete the IDF component on Track A. When Track B exists, this page should grow a silicon row for it. Until then the honest sentence stays in the lead answer, where an answer engine will quote it. A pure Rust alternative to esp32-camera lives or dies by that sentence. A pure Rust alternative to esp32-camera that hid the wrap would rank for a query it does not satisfy. A pure Rust alternative to esp32-camera is the API above one driver, plus tables you can replay on a fake bus.

Where to start

Choose a camera board, flash with espino, and read a smart home without the cloud for why the frames stay on the LAN. The Learn index lists the field notes.

The crate is part of Remade With Rust, the household identity is MATA, and the language is Rust. When a sensor datasheet needs to become a retrieval corpus, the same house runs RAG Converter.

FAQ

Quick answers for builders evaluating this technology.

Does Track A remove the esp32-camera C driver?

No. IdfCamera wraps that driver once and copies one frame per grab out of the driver's PSRAM buffer into memory the caller owns. Replacing the driver is a Track B plan, not a feature.

How many frame buffers should the pool use?

Two, on the measured XIAO ESP32-S3 Sense. One buffer gave 13.882 fps and two gave 27.764 fps. A third buffer produced the same frame count, so it only costs PSRAM. 581 captures had zero failures.

Which sensors have register tables?

OV2640 and OV5640, converted from esp32-camera headers: 302 steps and 216 steps. The OV2640 ran on an AI-Thinker ESP32-CAM. An OV3660 answered on the XIAO ESP32-S3 Sense. Other sensors in the plan are not tables yet.

Can the ESP32 encode JPEG without the sensor?

The jpeg encode path over rusty_jpeg is no_std, compiles for the ESP32-S3 bare-metal target, and is tested on the host. Most setups use the sensor's own JPEG mode and need no encoder on the chip.

How do I tell that the pool is exhausted?

Watch the frame rate. On the measured driver a starved pool did not return a failure. The driver blocks until a buffer is free, so exhaustion shows up as a lower rate, not as an error counter.