Dust + Haze-Aware Computer Vision for Saudi Industrial Sites

What sandstorms actually do to camera images

Three image-statistics shifts happen during a KSA sandstorm:

1. Contrast collapse in the visible band as small particulate scatters light.
2. MTF degradation — the modulation transfer function drops at spatial frequencies in the 10–30 µm particulate range, blurring edges that the detector relies on.
3. Dynamic-range clipping as auto-exposure responds to the high-luminance scattered field, crushing dark detail.

These are not the same as gamma jitter. A model trained with brightness augmentation alone will fail when MTF drops, even if the average brightness looks correct.

For the underlying model context see the object detection glossary and the computer vision glossary.

Three augmentation strategies that matter

A 2026-grade training pipeline applies:

1. MTF degradation transform. Synthetic blur kernels that reproduce the spatial-frequency loss of dust-laden air.
2. Heavy gamma + HSV jitter. Standard but necessary — gamma 0.6–1.6, HSV-S ±30.
3. Dust occlusion overlays. Procedurally generated dust streaks across regions of the frame, preserving annotation when the underlying object is still visible.

For the augmentation sources, anchor in the public datasets and the operational validation sets. Private KSA storm-conditions sets remain the differentiator.

A held-out storm-conditions validation set

The single most important deliverable for an audit-ready KSA model is a held-out validation set captured during real KSA storm conditions. A defensible set includes:

Layer	Frames	Notes
Daylight clear	1,500+	Reference baseline
Daylight dust-mild (PM10 200–600)	1,000+	Common operating condition
Daylight storm (PM10 600+)	500+	Worst case
Dusk transition	500+	Mixed lighting
Sodium-vapor night	800+	Common at gates

Each frame stamped with measured PM10, time-of-day and camera ID. Validation precision/recall reported per layer, not aggregate.

The fallback class

Rather than emitting low-confidence detections during storms, a 2026-grade system declares its own degraded state. The low_visibility class triggers when:

1. Frame mean luminance is outside the trained range.
2. Detected feature density (a proxy for visible structure) drops below a threshold.
3. PM10 reading from a co-located sensor crosses the storm threshold.

When the class fires, the system:

• Logs “monitoring degraded — low visibility” with start/stop timestamps.
• Suppresses violation-class events that would otherwise trigger.
• Continues to log motion presence, so a human can re-review if needed.
• Surfaces the state on the AI analytics platform dashboard.

This is operationally honest and PDPL-defensible.

Model-gating logic

A simple state machine handles the day-to-day:

State	Trigger	Behaviour
Normal	All checks pass	Full detection
Monitoring degraded	One degradation signal	Suppress safety-critical violations, retain motion log
Failure	Multiple degradation signals + sensor disagreement	Notify ops, fail-safe to manual oversight

This avoids the worst failure mode — silent low-confidence noise dressed up as detections.

Camera-side mitigations

Software is not the only intervention. Three hardware controls help:

1. Hooded camera housings with anti-static coating reduce dust adherence.
2. Quarterly housing rotation in coastal Oxagon-style sites where salt and dust combine.
3. Auto-clean wiper on critical cameras (gate, hot-work zone, perimeter intersection).

These reduce — but do not eliminate — the need for software robustness.

Where this matters most

Three workloads where storm robustness is non-negotiable:

1. NEOM construction monitoring — Trojena alpine and The Line corridor both see major dust events.
2. Aramco contractor PPE detection — gates that produce false positives during storms get disabled by ops.
3. Vehicle-pedestrian safety — yards must continue safe operation through dust.

For broader context see the Vision 2030 construction digitisation piece.

Validation cycle

A defensible quarterly cycle:

1. Capture storm-condition footage during the natural KSA dust season.
2. Add to the held-out validation set with metadata.
3. Re-evaluate the production model.
4. If precision drops below 0.85 in the storm layer, retrain with the new data.
5. Update the model card with the new validation results.

Common mistakes that kill robustness

1. Training only on European or COCO data. Predictably fails on first KSA storm.
2. Aggregate metrics only. Hides the per-condition collapse.
3. No PM10 sensor co-location. Cannot tie degradation to environmental cause.
4. Silent low-confidence detections instead of explicit fallback.
5. No housing rotation schedule. Cameras quietly degrade over months.

For the broader accuracy lens see the hard-hat detection accuracy piece.

Field deployment checklist

1. Storm-conditions validation set captured and signed.
2. MTF-degradation transform in the training pipeline.
3. low_visibility fallback class implemented and tested.
4. PM10 sensor co-located with each major camera cluster.
5. Quarterly storm-data refresh planned.
6. Camera housing maintenance schedule in operations calendar.

Next steps

If you are scoping a vision system that must survive KSA dust and haze, start with the NEOM monitoring piece, the hard-hat detection accuracy piece, and the edge inference glossary. Cross-reference the object detection glossary and the worker fatigue piece.

Book a robustness scoping call and we will produce a storm-condition validation plan and augmentation spec within 10 working days.

React to this article

🔥...💡...🤔...👏...❤️...