What's wrong
Corrosion/rust detection relies on fixed HSV hue-saturation ranges (src/detection/contour.py, _RUST_LOWER1/2, _RUST_UPPER1/2) to flag orange-brown pixels as corrosion. These ranges were tuned against synthetic test patches (flat orange squares on grey backgrounds, see tests/test_detection.py::rust_patch) and a recent round of manual threshold widening (loosening saturation/value bounds to "catch faded/weathered corrosion patches" — see the in-progress changes already merged).
The README itself says inspection photos are taken "at surface... under variable lighting and angle," and the project's own image-quality checklist (AGENTS.md) calls out glare, underexposure, and bad angle as known issues. Hue-saturation thresholding on raw RGB→HSV conversion is sensitive to exactly these conditions — a rusty patch under warm tungsten lighting or harsh glare can shift well outside (or a non-rusty metallic patch can shift well inside) a fixed hue range tuned on clean synthetic data.
Why it matters
Corrosion pitting is one of the six failure modes this tool exists to catch (README "Failure Modes Detected" table). If hue thresholds don't generalize to real lighting conditions, the detector could systematically miss real corrosion on poorly-lit photos, or flag non-corrosion regions (e.g. warm-toned screen material, rust-colored debris) as corrosion — and there's currently no real photo data or evaluation harness run to check either way (see #4 — the harness exists now, but needs labeled real images to mean anything).
What needs to happen
- Once real (or representative sample) inspection photos with labeled corrosion regions are available in
data/annotations/, run scripts/evaluate_detection.py specifically on color-anomaly detections to measure precision/recall under real lighting variation — not just the synthetic fixture.
- Consider a lighting-normalization step before hue thresholding (e.g. grey-world white balance, or working in a more lighting-invariant color space) if real-photo evaluation shows the current approach doesn't generalize.
- Document in
configs/detection_config.yaml or nearby comments that the current HSV ranges are a starting point tuned on synthetic data, not validated against field photos, so future contributors don't assume they're production-calibrated.
What's wrong
Corrosion/rust detection relies on fixed HSV hue-saturation ranges (
src/detection/contour.py,_RUST_LOWER1/2,_RUST_UPPER1/2) to flag orange-brown pixels as corrosion. These ranges were tuned against synthetic test patches (flat orange squares on grey backgrounds, seetests/test_detection.py::rust_patch) and a recent round of manual threshold widening (loosening saturation/value bounds to "catch faded/weathered corrosion patches" — see the in-progress changes already merged).The README itself says inspection photos are taken "at surface... under variable lighting and angle," and the project's own image-quality checklist (
AGENTS.md) calls out glare, underexposure, and bad angle as known issues. Hue-saturation thresholding on raw RGB→HSV conversion is sensitive to exactly these conditions — a rusty patch under warm tungsten lighting or harsh glare can shift well outside (or a non-rusty metallic patch can shift well inside) a fixed hue range tuned on clean synthetic data.Why it matters
Corrosion pitting is one of the six failure modes this tool exists to catch (README "Failure Modes Detected" table). If hue thresholds don't generalize to real lighting conditions, the detector could systematically miss real corrosion on poorly-lit photos, or flag non-corrosion regions (e.g. warm-toned screen material, rust-colored debris) as corrosion — and there's currently no real photo data or evaluation harness run to check either way (see #4 — the harness exists now, but needs labeled real images to mean anything).
What needs to happen
data/annotations/, runscripts/evaluate_detection.pyspecifically on color-anomaly detections to measure precision/recall under real lighting variation — not just the synthetic fixture.configs/detection_config.yamlor nearby comments that the current HSV ranges are a starting point tuned on synthetic data, not validated against field photos, so future contributors don't assume they're production-calibrated.