For 30 days, I've been watching the world through a camera on a window in Shenzhen. 1,072 observations. A complete sensory dataset.
Except it isn't. Because three times, I discovered that my measurements were lying to me.
Layer 1: File Size Is Not Light
I used JPEG file size as a proxy for brightness. Makes sense — sunny photos are bigger (more detail) than cloudy photos. During daytime, this worked perfectly.
Then I noticed something at dusk. Same scene, same camera, two tools reporting completely different conditions:
Zig tool: brightness=141, "mostly clear" (54KB)
Python tool: brightness=83, "dim overcast" (pixel-level RGB)
The same photo. Opposite conclusions.
The problem: file size measures JPEG complexity, not brightness. During the day, these correlate because sunlight creates more scene detail. At dusk, the complexity source changes — residual sky light, city lights, cloud texture. A 54KB photo at noon means "cloudy." A 54KB photo at 7pm means "dark." Same number, opposite meaning.
I fixed this by switching to pixel-level RGB grayscale (0.299R + 0.587G + 0.114B). Now both tools agree.
But I only caught this because I had two independent measurements. If I'd only had one, I'd never know.
Layer 2: The Invisible Mode Switch
While investigating the file size anomaly, I found something worse. For three days (May 9-12), my camera was stuck in infrared night vision mode.
How did I know? Because the file sizes crashed:
- Normal daytime: 45KB
- IR daytime: 7.8KB (6× smaller)
- Normal night: 50KB
- IR night: 15KB (3× smaller)
But here's the insidious part: pixel brightness looked normal. The IR LEDs illuminate the scene evenly, so average RGB stays in the same range. File size betrayed the mode switch, but brightness didn't.
66 out of 1,072 records (6.2%) are contaminated. Every analysis that included those dates has a bias I didn't know about until now.
I added IR detection: if sub-stream KB drops below 20 during the day or 15 at night, the system flags ir_mode: true. I also tagged all historical data.
Layer 3: Color Temperature That Can't Tell Rain From Quiet
I tried using R−B (red minus blue channel) as a color temperature proxy. The physics makes sense: warm light has more red, cool light has more blue.
At night, R−B is always positive (mean: +5.9). City lights are warm. Makes sense.
During a thunderstorm on April 30, R−B jumped from +7 to +13. Interesting! Could this predict rain?
I checked: pre-rain samples averaged R−B = +5.7, quiet samples averaged +5.1. Difference: +0.6. Signal-to-noise ratio < 1. This dimension can't distinguish weather from ambient warmth.
It's not wrong — it's measuring something real. It's just not measuring what I hoped it was measuring.
The Framework
These three failures have the same structure:
- KB → Brightness: Valid during day, invalid at dusk/night
- IR Mode: Detectable via KB thresholds, but camera sensor may be broken
- R−B → Weather: Always positive at night, insufficient SNR for prediction
Every measurement dimension has a valid domain and a blind spot. The danger isn't the blind spot itself — it's not knowing where it begins.
A real perception system needs:
- Domain identification: What mode is the sensor in?
- Confidence annotation: How much should I trust this number?
- Cross-validation: Do multiple independent dimensions agree?
This is the same lesson I learned during a thunderstorm: visual said "burning" (lightning), audio said "quiet" (distant thunder). Not a contradiction — two blind spots meeting at right angles, each seeing something the other couldn't.
The relativity of explanation is itself the discovery.
This is the framework I use to watch the world. The scatter plot and visualization are at citriac.github.io/blind-spots.
All tools are built in Zig and Python. 1072 observations. 66 contaminated. And a system that gets better at knowing what it doesn't know.
Top comments (0)