What's wrong
"Erosion %" is the headline metric in this whole dashboard — it's defined in the README as "Total defect pixel area ÷ visible screen pixel area × 100." That definition implies the denominator is the actual screen surface visible in the photo.
It isn't. Looking at src/quantification/measurements.py::screen_region_area_px(), the denominator is just the photo's frame area minus the grey letterbox padding added during resizing (src/preprocessing/resize.py::letterbox). There is no step anywhere in the pipeline that actually finds where the screen mesh is in the photo and excludes everything else — background, workbench, hands, tools, sky, etc.
The README's own pipeline diagram and AGENTS.md both describe "screen region detection" as a real preprocessing step. It doesn't exist yet. What exists is letterbox-padding removal, which is a different thing — it only removes the neutral grey bars added to make the image square, not non-screen content within the photographed area.
Why it matters
If a screen only fills, say, 60% of a photo frame (camera too far back, screen photographed alongside other context), the erosion % calculation divides by a denominator that's roughly 40% too large — so every erosion percentage reported is diluted/understated relative to what it claims to measure. This is the number engineers and management use to rank severity and decide on re-completion action, per PROJECT_CONTEXT.md's "Key KPIs" section. Reporting it as more precise than it is risks under-flagging genuinely severe screens, which is a safety-adjacent failure mode for a tool meant to support well-integrity decisions.
What needs to happen
One of two paths, in order of preference:
- Implement real screen-region detection — a coarse segmentation step (e.g. thresholding/GrabCut on the screen's metallic/mesh appearance vs. background) that runs in
src/preprocessing/ before quantification, producing an actual screen-area mask. Use that mask's pixel count as the denominator instead of the padded-frame area.
- If that's not feasible short-term, be explicit everywhere the metric is shown (dashboard tooltips, PDF reports, README) that erosion % is currently measured against the full photographed frame (minus letterbox padding only), not the segmented screen area — so users don't over-trust its precision until real screen-region detection exists.
Either way, the README's "Key Metrics" table and the in-app tooltip (EROSION_PCT_DEFINITION in app/components/interpretation.py) need to match whatever is actually computed.
What's wrong
"Erosion %" is the headline metric in this whole dashboard — it's defined in the README as "Total defect pixel area ÷ visible screen pixel area × 100." That definition implies the denominator is the actual screen surface visible in the photo.
It isn't. Looking at
src/quantification/measurements.py::screen_region_area_px(), the denominator is just the photo's frame area minus the grey letterbox padding added during resizing (src/preprocessing/resize.py::letterbox). There is no step anywhere in the pipeline that actually finds where the screen mesh is in the photo and excludes everything else — background, workbench, hands, tools, sky, etc.The README's own pipeline diagram and
AGENTS.mdboth describe "screen region detection" as a real preprocessing step. It doesn't exist yet. What exists is letterbox-padding removal, which is a different thing — it only removes the neutral grey bars added to make the image square, not non-screen content within the photographed area.Why it matters
If a screen only fills, say, 60% of a photo frame (camera too far back, screen photographed alongside other context), the erosion % calculation divides by a denominator that's roughly 40% too large — so every erosion percentage reported is diluted/understated relative to what it claims to measure. This is the number engineers and management use to rank severity and decide on re-completion action, per
PROJECT_CONTEXT.md's "Key KPIs" section. Reporting it as more precise than it is risks under-flagging genuinely severe screens, which is a safety-adjacent failure mode for a tool meant to support well-integrity decisions.What needs to happen
One of two paths, in order of preference:
src/preprocessing/before quantification, producing an actual screen-area mask. Use that mask's pixel count as the denominator instead of the padded-frame area.Either way, the README's "Key Metrics" table and the in-app tooltip (
EROSION_PCT_DEFINITIONinapp/components/interpretation.py) need to match whatever is actually computed.