Reports

Console report

Every run prints a table with one row per analyzed file:

file                  sharpness      global  verdict
-----------------------------------------------------
photos/IMG_0003.CR3        18.4         6.2  BLURRY
photos/IMG_0002.CR3       154.9        40.3  sharp
photos/IMG_0004.CR3                          error  (BMFF parse failed: ...)
photos/IMG_0001.CR3       512.3        88.1  sharp

4 file(s): 2 sharp, 1 blurry, 1 error(s)  [threshold = 100.0]

• sharpness is the score the verdict is based on; global is the whole-frame variance, informative only (see Pipeline). Both are rounded to one decimal.
• The file column adapts to the longest path, capped at 55 characters; longer paths are truncated from the left with an ellipsis so the file name stays visible.
• error rows show the reason in parentheses and leave the score columns empty.
• With --sort, rows are ordered from blurriest to sharpest — handy for eyeballing where your threshold should sit — and error rows sink to the end.

CSV report

--csv FILE writes the same information as machine-readable CSV:

file,verdict,sharpness_score,global_score,error
photos/IMG_0001.CR3,sharp,512.3,88.1,
photos/IMG_0002.CR3,BLURRY,42.7,12.9,
photos/IMG_0004.CR3,error,,,unable to extract preview

• The column set file,verdict,sharpness_score,global_score,error is a stable interface: the companion calibration script calibrate_blur.py (kept outside this repository) consumes it directly, and the golden parity tests byte-compare it across versions.
• Scores are rounded to one decimal and left empty on error rows.
• Fields containing commas, quotes or newlines are quoted, with inner quotes doubled (standard CSV escaping).
• A CSV file that cannot be written prints an error but does not change the exit code — the console report already happened.

Exit status

Scripts should treat error rows as the per-file failure signal and the exit code only as “did the batch run at all”.

Error handling

Batch analysis is designed to always finish:

• A file that cannot be decoded or scored becomes an error row carrying the failure message; the rest of the batch is unaffected.
• This includes panics inside the RAW parser: rawler can panic on malformed containers (for example a CR3 missing its co64 box), so each file’s analysis runs under a panic catcher that converts the panic into that file’s error message instead of letting it abort the whole run.
• Unreadable directories or directory entries print a warning on stderr and are skipped.
• error rows are never moved by --move-blurry-to / --move-sharp-to.