Sightline
A smart cane that costs ₱43,000 is not a mobility solution for most visually impaired people in Baguio. So we asked a cheaper question: if you shrink the image before the obstacle detector sees it, how much faster does the detector run on hardware someone can actually afford?
The answer was 39.36% faster, on a machine throttled down to Raspberry Pi speed. That measurement needs the hardware. What you cancheck here is the assumption underneath it: that a frame compressed past recognition to the eye is still perfectly legible to the detector.
“Evaluating Image Compression Techniques for Low-Cost Assistive Navigation Devices”was presented at the 25th Philippine Computing Science Congress, Baguio City, May 2025.
Throw away 95% of the bytes
The premise the study rests on is that a compressed frame still contains the obstacles. That part you can check right now. Your image is resized to 640×480, compressed to JPEG quality 50, and run through a MobileNet-SSD detector at a 0.2 confidence threshold (the study's parameters), then compared object for object. Nothing leaves your device; there is no server here.
Drop a street scene here
or pick a source: urban scenes with people and vehicles work best
The detector weights (~6 MB) download on your first run, not on page load.
detected:
detected:
Getting the frame off the device
An extension beyond the paper, which measured detection time only. If the cane offloads frames instead of processing them locally, the link is the bottleneck: raw pixels against the JPEG.
| Link | Raw | JPEG q50 | Compressed throughput |
|---|
Why this page doesn't time the detector
The obvious demo would have been a stopwatch: detect on both images, show that the compressed one is faster, watch the paper's 39.36% appear live. I built that first. It doesn't work, and the reason is worth writing down.
coco-ssd calls tf.browser.fromPixels() and hands the result to a graph whose input resolution is fixed. Whatever you give it gets rescaled to the same tensor before a single convolution runs. Measured on this stack:
- 640×480 input: 645 ms
- 160×120 input: 667 ms
Sixteen times fewer pixels, no improvement at all. The same held on the CPU backend, where I had expected the effect to be clearest. Inference cost here is a constant, so any timing difference between the two images on this page would be scheduler noise with a percentage sign after it.
OpenCV's cv2.dnn path, which the study used, sizes its work from the decoded array, so a smaller image is genuinely less work, which is why the effect is real on a Raspberry Pi and absent in a browser. That is a limitation of this runtime, not of the result.
So the lab measures what it can measure honestly: whether the detector still finds the same objects once 95% of the bytes are gone. The timing result stays where it belongs: below, with the original per-case data behind it.
The original measurements
Ten urban street scenes from Baguio City and a public dataset, each processed five times per condition. Bars show mean detection time.
- 1Pedestrian crossing, multiple people
- 2Crossing with white vehicle
- 3Busy crossing, high object density
- 4Overpass bridge over traffic
- 5Two men crossing, moving cars
- 6Session Road sidewalk, parked cars
- 7Baguio crossing, multiple people
- 8Crossing with distant overpass
- 9Crossing with signage occlusion
- 10Crossing with white vehicle (repeat)
Statistical test
Levene's test rejected equal variances (F(1, 98) = 175.00, p < .001), so Welch's t-test was used instead of Student's.
| Group | N | Mean | SD | SE |
|---|---|---|---|---|
| Without compression | 50 | 0.1006 | 0.01856 | 0.00263 |
| With compression | 50 | 0.0396 | 0.00461 | 0.00065 |
t(55.017) = 22.552, p < .001, mean difference 0.061s, Cohen's d = 4.51.
The compressed group's standard deviation is a quarter of the uncompressed group's. For a navigation aid that matters as much as the mean: consistent latency is what makes feedback trustworthy, and a detector that occasionally stalls is one a user stops relying on.