Fog & Visibility Detection System for Camera Feeds

A computer-vision project that watches camera frames — from a webcam, traffic camera, or any video source — and classifies each frame’s atmospheric condition into visibility levels (clear, light fog, dense fog, and so on), producing a visibility estimate with a confidence score and a time-series alert log. It is the atmospheric-visibility counterpart of an image classifier: instead of recognizing objects in a scene, it reasons about how well the scene can be seen, which makes it a genuinely different computer-vision job.

>This is a prototype monitoring aid, not a safety system. Visibility estimates depend on camera quality, lighting, and conditions a model cannot see (night, rain on the lens, sensor noise), so the output is a research-grade indication — never a guarantee of road safety, driving readiness, or accident prevention. It is built to inform humans and to be validated against real conditions before anyone acts on it.

Who Is This For?

• Students learning computer vision on a non-trivial task with a clear evaluation story
• Meteorology and transportation students exploring low-cost visibility monitoring
• Smart-city hobbyists and road-authority pilots prototyping camera-based fog watches
• Environmental-monitoring developers who want a reusable fog/visibility classifier

The Problem

Fog develops faster than forecasts refresh, and it is intensely local: one valley can be in dense fog while the next ridge is clear. Road and weather services would benefit from cheap, camera-based fog detection, but most visibility sensors are specialized instruments that cost too much to deploy broadly. Meanwhile, the cameras already pointing at roads, harbors, and campuses capture exactly the visual signal needed — if a model could turn “how foggy does this frame look” into a usable visibility category. The missing piece is a well-scoped classifier: one that detects atmospheric visibility degradation, reports confidence honestly, and records a time series that a human can review.

How It Works

1. Collect and Structure Data

The project needs labeled fog/visibility data. Established public options include Foggy Cityscapes and FRIDA, research datasets of foggy road scenes built by simulating or capturing fog over real imagery. For a local MVP, a smaller self-built set can be labeled by hand into coarse classes (clear / light fog / dense fog) from public webcam archives. The data is split into train/validation/test sets with temporal awareness — frames from the same camera should not appear in both training and test.

2. Preprocess Frames

Each frame is resized and normalized like any classifier input. Because fog is a scene-level property, global statistics matter: preprocessing can include per-frame brightness/histogram features as model inputs alongside the image itself, giving the model explicit cues about contrast loss.

3. Extract Fog and Visibility Features

Two complementary feature families feed the model:

• Learned features — the convolutional backbone’s representation of the image
• Hand-crafted visibility cues — global contrast, high-frequency energy (detail loss is the signature of fog), and horizon/region statistics

Combining both makes the model’s decisions more interpretable and more robust to non-fog scene differences.

4. Classify or Regress

Two viable framings, and the project should pick one explicitly:

• Classification — predict a coarse visibility category (clear / light / dense). Simpler, robust, good for alerting.
• Regression — predict a visibility-distance value. More useful but harder to evaluate honestly, since precise ground-truth distance is rarely available in public datasets.

A sensible intermediate: classification for alerting plus a continuous “fog score” that ranks frames within a category.

5. Add Temporal Consistency

Fog changes slowly, and single-frame flicker is noise. The pipeline smooths predictions across frames (for example, a rolling median or a small state machine that requires N consecutive frames to change category), which cuts false alarms dramatically. Temporal consistency is one of the most important engineering decisions in the project.

6. Evaluate Honestly

Evaluation reports per-class precision/recall/F1 plus a confusion matrix, with special attention to the two failure modes that matter: false fog alarms (clear day flagged as foggy) and missed dense fog. Lighting variation is called out: night frames, lens flare, and rain are documented as known failure regions, and evaluation can be split by day/night if the data supports it.

7. Visualize and Alert

A simple dashboard shows the current category with confidence, the smoothed fog score over time, and an alert log with timestamps and frame thumbnails. Alerts are advisory: the system recommends a human look, it does not take action.

Key Features

• Fog/visibility classification — coarse categories with confidence per frame
• Hybrid features — learned image features plus hand-crafted contrast/detail cues
• Temporal smoothing — state-machine or rolling-median consistency to kill flicker
• Honest evaluation — per-class precision/recall/F1, confusion matrix, day/night split where possible
• Advisory alerting — time-series log with thumbnails; humans decide what to do
• Extensible input — any camera/video source (webcam, RTSP stream, recorded clips)

Functional Requirements

User Stories

• As a transportation student, I want per-class precision and recall, so that I can see whether the system cries “fog” too often on clear days.
• As a smart-city hobbyist, I want temporal smoothing, so that a single bad frame doesn’t set off the alert log.
• As a road-authority pilot, I want an advisory alert with a frame thumbnail and confidence, so that a human verifies before anything is acted on.
• As a developer, I want the day/night evaluation split, so that I know the model’s real limits in low light.

MVP Scope

Regression to visibility distance, multi-camera aggregation, and edge deployment are natural second-phase additions.

Project Timeline

• Phase 1 — Data (Weeks 1–2): Source the dataset, inspect frame quality, and build the temporally split train/validation/test sets.
• Phase 2 — Features and baseline (Week 3): Contrast/detail features, a simple baseline classifier, and a first confusion matrix.
• Phase 3 — Model (Weeks 4–5): Pre-trained backbone with hybrid inputs, fine-tuning, and validation monitoring.
• Phase 4 — Temporal consistency (Week 6): Smoothing, the category state machine, and false-alarm reduction experiments.
• Phase 5 — Evaluation and dashboard (Weeks 7–8): Full metrics, day/night split, alert log, and a documented limitations section.

Testing Strategy

• Feature tests — synthetic fog-like images (Gaussian-blurred) produce the expected drop in high-frequency energy.
• Split-integrity tests — no camera’s frames appear in both train and test (temporal separation enforced).
• Smoothing tests — a single misclassified frame does not flip the state machine; sustained changes do.
• Metric tests — precision/recall/F1 and confusion-matrix values match hand computation on a fixture.
• Failure-region tests — night and rain frames (where available) are evaluated as their own group and reported separately.
• Alert tests — the alert log records timestamps and thumbnails only on confirmed category transitions.

Security and Privacy Considerations

• Cameras see people and places. If live camera feeds are used, the project must respect the operator’s authority and local privacy rules; the MVP should prefer public webcams or the operator’s own cameras, with no face/plate identification anywhere in the pipeline.
• No surveillance features. The model classifies atmosphere, not people or objects; the project explicitly does not add people/vehicle detection to keep the scope defensible.
• No safety guarantees. Visibility estimates are advisory; the documentation states the system must not be used as a safety or driving-assistance system.
• Data licensing. Public datasets carry licenses; the project records sources and respects terms, especially for redistribution.
• Honest metrics. All reported performance comes from this project’s own evaluation runs, never borrowed from other models.

Success Metrics

• The temporally split test set yields per-class precision/recall/F1 and a confusion matrix — reported, not just computed.
• The dense-fog class has high recall (missed dense fog is the worst failure) without exploding clear-day false alarms.
• Temporal smoothing measurably reduces alert-flip frequency versus single-frame predictions on the same clip.
• The day/night (or lighting) evaluation split is published, with documented performance differences.
• An alert log from a real recorded clip contains only genuine category transitions.

Common Challenges

• Fog vs other low-contrast conditions — rain, snow, night, and lens artifacts reduce contrast too; the model card documents these confusions.
• Ground truth is fuzzy — visibility categories are judgment calls; coarse classes and explicit labeling rules keep labels consistent.
• Single-frame noise — flicker between categories is the top usability killer; temporal smoothing is mandatory, not optional.
• Dataset realism — simulated fog differs from real fog; field performance may be lower than dataset test scores, and the docs say so.
• Scope creep toward object detection — adding cars/people detection would change the project’s purpose and risk profile; the MVP stays atmospheric.

Learning Objectives

• Build a computer-vision system whose objective is scene-level (atmospheric visibility), not object-level.
• Combine learned and hand-crafted features and reason about why both matter.
• Implement temporal smoothing and evaluate its effect on false alarms.
• Practice honest failure analysis: confusion matrices, lighting splits, and documented limits.
• Design an advisory system that informs humans rather than claiming to protect them.

Why This Idea Is Different

This project’s objective — how well can this scene be seen — is distinct from every existing computer-vision Idea on the site. The AI-Powered Campus Attendance via Facial Recognition detects and matches people’s faces; the Medical Image Annotation Tool for Researchers builds labeling workflows over medical images; and the Real-Time Dashboard Builder for IoT Data Streams visualizes sensor time series. This project classifies atmospheric fog and visual visibility from camera frames — a weather-monitoring task, not a people, medical, or dashboard task — while sharing the computer-vision foundation of the first two and the time-series alerting pattern of the last. It is also the site’s first environment-domain project, pairing with the air-quality prediction Idea as the environmental-monitoring family.

What Similar Tools Exist

| Tool type | Approach | Limitation |
|———–|———-|————|
| Professional visibility sensors | Laser/scatter instruments | Expensive; sparse deployment |
| Weather-service human observations | Trained observers | Manual, infrequent, not camera-scalable |
| Generic scene classifiers | Pre-trained models | Not trained on fog; no visibility framing |
| Commercial smart-camera systems | Integrated weather analytics | Opaque, costly, often bundled with surveillance features |

This project’s differentiators: a fully transparent, student-buildable fog classifier, hybrid learned+hand-crafted features, temporal consistency engineered for low false alarms, and an explicit advisory-only boundary.

Technology Stack

• Python — the full pipeline
• PyTorch or TensorFlow/Keras — model and training
• Pre-trained backbone (ResNet or EfficientNet family) — learned features
• OpenCV / PIL — frame capture, preprocessing, contrast/detail features
• NumPy + pandas — feature computation and smoothing
• matplotlib / Streamlit — dashboard and alert log
• pytest — feature, split, smoothing, and metric tests

Future Enhancements

• Regression to an estimated visibility distance (with documented ground-truth limits)
• Multi-camera aggregation and per-location fog maps
• Edge deployment on a low-power device at a fixed camera
• Integration with weather-station data to cross-check the visual signal
• Night-specific training data to close the documented low-light gap

Related Ideas

• AI-Powered Campus Attendance via Facial Recognition — the CV family’s people-detection member; this project classifies atmosphere instead
• Medical Image Annotation Tool for Researchers — image-analysis tooling with a different subject (medical images vs scene visibility)
• Real-Time Dashboard Builder for IoT Data Streams — the time-series and alerting pattern this project’s visibility log follows

Browse more Project Ideas · Intermediate Ideas