Project

# Title Team Members TA Documents Sponsor
23 Portable RAW Reconstruction Accelerator for Legacy CCD Imaging
Arnav Gaddam
Guyan Wang
Yuhong Chen
Gerasimos Gerogiannis design_document1.pdf
final_paper1.pdf
other1.docx
other2.pdf
video
# **RFA: Portable RAW Reconstruction Accelerator for Legacy CCD Imaging**

Group Member: Guyan Wang, Yuhong Chen

## **1\. Problem Statement**

**The "Glass-Silicon Gap":** Many legacy digital cameras (circa 2000-2010) are equipped with premium optics (Leica, Zeiss, high-grade Nikon/Canon glass) that outresolve their internal processing pipelines. While the optical pathway is high-fidelity, the final image quality is bottlenecked by:

- **Obsolete Signal Chains:** Early-stage Analogue-to-Digital Converters (ADCs) and readout circuits introduce significant read noise and pattern noise.
- **Destructive Processing:** In-camera JPEGs destroy dynamic range and detail. Even legacy RAW files are often processed with rudimentary demosaicing algorithms that fail to distinguish high-frequency texture from sensor noise.
- **Usability Void:** Users seeking the unique "CCD look" are forced to rely on cumbersome desktop post-processing workflows (e.g., Lightroom, Topaz), preventing a portable, shoot-to-share experience.

## **2\. Solution Overview**

**The "Digital Back" External Accelerator:** We propose a standalone, handheld hardware device-a "smart reconstruction box"-that interfaces physically with legacy CCD cameras. Instead of relying on the camera's internal image processor, this device ingests the raw sensor data (CCD RAW) and applies a hybrid reconstruction pipeline.

The core innovation is a **Hardware-Oriented Hybrid Pipeline**:

- **Classical Signal Processing:** Handles deterministic error correction (black level subtraction, gain normalization, hot pixel mapping).
- **Learned Estimator (AI):** A lightweight Convolutional Neural Network (CNN) or Vision Transformer model optimized for microcontroller inference (TinyML). This model does not "hallucinate" new details but acts as a probabilistic estimator to separate signal from stochastic noise based on the physics of CCD sensor characteristics.

The device will feature a touchscreen interface for file selection and "film simulation" style filter application, targeting an output quality perceptually comparable to a modern full-frame sensor (e.g., Sony A7 III) in terms of dynamic range recovery and noise floor.

## **3\. Solution Components**

### **Component A: The Compute Core (Embedded Host)**

- **MCU:** STMicroelectronics **STM32H7 Series** (e.g., STM32H747/H757).
- _Rationale:_ Dual-core architecture (Cortex-M7 + M4) allows separation of UI logic and heavy DSP operations. The Chrom-ART Accelerator helps with display handling, while the high clock speed supports the computationally intensive reconstruction algorithms.
- **Memory:** External SDRAM/HyperRAM expansion (essential for buffering full-resolution RAW files, e.g., 10MP-24MP) and high-speed QSPI Flash for AI model weight storage.

### **Component B: Connectivity & Data Ingestion Interface**

- **Physical I/O:** USB OTG (On-The-Go) Host port.
- _Function:_ The device acts as a USB Host, mounting the camera (or the camera's card reader) as a Mass Storage Device to pull RAW files (.CR2, .NEF, .RAF, .DNG).
- **Storage:** On-board MicroSD card slot for saving processed/reconstructed JPEGs or TIFFs.

### **Component C: Hybrid Reconstruction Algorithm**

- **Stage 1 (DSP):** Linearization, dark frame subtraction (optional calibration), and white balance gain application.
- **Stage 2 (NPU/AI):** A quantization-aware trained model (likely TFLite for Microcontrollers or STM32-AI) trained specifically on _noisy CCD -to- clean CMOS_ image pairs.
- _Task:_ Joint Demosaicing and Denoising (JDD).
- **Stage 3 (Color):** Application of specific "Film Looks" (LUTs) selected by the user via the UI.

### **Component D: Human-Machine Interface (HMI)**

- **Display:** 2.8" to 3.5" Capacitive Touchscreen (SPI or MIPI DSI interface).
- **GUI Stack:** TouchGFX or LVGL.
- _Workflow:_ User plugs in camera -> Device scans for RAWs -> User selects thumbnails -> User chooses "Filter/Profile" -> Device processes and saves to SD card.

## **4\. Criterion for Success**

To be considered successful, the prototype must meet the following benchmarks:

- **Quality Parity:** The output image, when blind-tested against the same scene shot on a modern CMOS sensor (Sony A7 III class), must show statistically insignificant differences in perceived noise at ISO 400-800 equivalent.
- **Edge Preservation:** The AI reconstruction must demonstrate a reduction in color moiré and false-color artifacts compared to standard bilinear demosaicing, without "smoothing" genuine texture (measured via MTF charts).
- **Latency:** Total processing time for a 10-megapixel RAW file must be under **15 seconds** on the STM32 hardware.
- **Universal RAW Support:** Successful parsing and decoding of at least two major legacy formats (e.g., Nikon .NEF from D200 era and Canon .CR2 from 5D Classic era).

## **5\. Alternatives**

- **Desktop Post-Processing (Software Only):**
- _Pros:_ Infinite computing power, established tools (DxO PureRAW), highly customized.
- _Cons:_ Destroys the portability of the photography experience; cannot be done "in the field." Need to be proficient with parameters inside the software, which requires self-training and tutoring (not user-friendly).
- **Smartphone App (via USB-C dongle):**
- _Pros:_ Powerful processors (Snapdragon/A-Series), high-res screens, easy to use.
- _Cons:_ Lack of low-level control over USB mass storage protocols for obscure legacy cameras; high friction in file management; operating system overhead prevents bare-metal optimization of the signal pipeline; unique algorithms may not be suitable for legacy cameras.
- **FPGA Implementation (Zynq/Cyclone):**
- _Pros:_ Parallel processing could make reconstruction instant.
- _Cons:_ Significantly higher complexity, cost, and power consumption compared to an STM32 implementation; higher barrier to entry for a "mini project."

Microcontroller-based Occupancy Monitoring (MOM)

Vish Gopal Sekar, John Li, Franklin Moy

Microcontroller-based Occupancy Monitoring (MOM)

Featured Project

# Microcontroller-based Occupancy Monitoring (MOM)

Team Members:

- Franklin Moy (fmoy3)

- Vish Gopal Sekar (vg12)

- John Li (johnwl2)

# Problem

With the campus returning to normalcy from the pandemic, most, if not all, students have returned to campus for the school year. This means that more and more students will be going to the libraries to study, which in turn means that the limited space at the libraries will be filled up with the many students who are now back on campus. Even in the semesters during the pandemic, many students have entered libraries such as Grainger to find study space, only to leave 5 minutes later because all of the seats are taken. This is definitely a loss not only to someone's study time, but maybe also their motivation to study at that point in time.

# Solution

We plan on utilizing a fleet of microcontrollers that will scan for nearby Wi-Fi and Bluetooth network signals in different areas of a building. Since students nowadays will be using phones and/or laptops that emit Wi-Fi and Bluetooth signals, scanning for Wi-Fi and Bluetooth signals is a good way to estimate the fullness of a building. Our microcontrollers, which will be deployed in numerous dedicated areas of a building (called sectors), will be able to detect these connections. The microcontrollers will then conduct some light processing to compile the fullness data for its sector. We will then feed this data into an IoT core in the cloud which will process and interpret the data and send it to a web app that will display this information in a user-friendly format.

# Solution Components

## Microcontrollers with Radio Antenna Suite

Each microcontroller will scan for Wi-Fi and Bluetooth packets in its vicinity, then it will compile this data for a set timeframe and send its findings to the IoT Core in the Cloud subsystem. Each microcontroller will be programmed with custom software that will interface with its different radio antennas, compile the data of detected signals, and send this data to the IoT Core in the Cloud subsystem.

The microcontroller that would suit the job would be the ESP32. It can be programmed to run a suite of real-time operating systems, which are perfect for IoT applications such as this one. This enables straightforward software development and easy connectivity with our IoT Core in the Cloud. The ESP32 also comes equipped with a 2.4 GHz Wi-Fi transceiver, which will be used to connect to the IoT Core, and a Bluetooth Low Energy transceiver, which will be part of the radio antenna suite.

Most UIUC Wi-Fi access points are dual-band, meaning that they communicate using both the 2.4 GHz and 5 GHz frequencies. Because of this, we will need to connect a separate dual-band antenna to the ESP32. The simplest solution is to get a USB dual-band Wi-Fi transceiver, such as the TP-Link Nano AC600, and plug it into a USB Type-A breakout board that we will connect to each ESP32's GPIO pins. Our custom software will interface with the USB Wi-Fi transceiver to scan for Wi-Fi activity, while it will use the ESP32's own Bluetooth Low Energy transceiver to scan for Bluetooth activity.

## Battery Backup

It is possible that the power supply to a microcontroller could fail, either due to a faulty power supply or by human interference, such as pulling the plug. To mitigate the effects that this would have on the system, we plan on including a battery backup subsystem to each microcontroller. The battery backup subsystem will be able to not only power the microcontroller when it is unplugged, but it will also be able to charge the battery when it is plugged in.

Most ESP32 development boards, like the Adafruit HUZZAH32, have this subsystem built in. Should we decide to build this subsystem ourselves, we would use the following parts. Most, if not all, ESP32 microcontrollers use 3.3 volts as its operating voltage, so utilizing a 3.7 volt battery (in either an 18650 or LiPo form factor) with a voltage regulator would supply the necessary voltage for the microcontroller to operate. A battery charging circuit consisting of a charge management controller would also be needed to maintain battery safety and health.

## IoT Core in the Cloud

The IoT Core in the Cloud will handle the main processing of the data sent by the microcontrollers. Each microcontroller is connected to the IoT Core, which will likely be hosted on AWS, through the ESP32's included 2.4GHz Wi-Fi transceiver. We will also host on AWS the web app that interfaces with the IoT Core to display the fullness of the different sectors. This web app will initially be very simple and display only the estimated fullness. The web app will likely be built using a Python web framework such as Flask or Django.

# Criterion For Success

- Identify Wi-Fi and Bluetooth packets from a device and distinguish them from packets sent by different devices.

- Be able to estimate the occupancy of a sector within a reasonable margin of error (15%), as well as being able to compute its fullness relative to that sector's size.

- Display sector capacity information on the web app that is accurate within 5 minutes of a user accessing the page.

- Battery backup system keeps the microcontroller powered for at least 3 hours when the wall outlet is unplugged.

Project Videos