From fe28373433334dbe143e1293f9b47797e8dc6bf7 Mon Sep 17 00:00:00 2001 From: Hadrian Burkhardt Date: Wed, 14 Oct 2026 13:38:33 +0200 Subject: [PATCH] docs: correct the Balanced/Aggressive pHash ceilings in the README table The table said 12 and 18 bits; DuplicatePolicy says 15 and 22, and the device agrees: with a 22-photo library the fit has too little data and falls back to the ceiling, and the results screen prints "similarity cut: pHash <= 15 bits (default)" - 15, not 12. The RGB column of the same table already matched the enum (60 and 84), which is what a pHash-only edit looks like: the ceilings were evidently retuned and this one column was not carried along. The old 18 was not invented - it is the measured F1 optimum that AGGRESSIVE's doc comment calls out ("set above the measured F1 optimum (~18 on real photographs)"), i.e. the value the ceiling is deliberately placed above rather than the ceiling itself. Saying so here keeps the corrected row from reading as though a measured optimum had been changed. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6fa3a55..6fa8f01 100644 --- a/README.md +++ b/README.md @@ -121,8 +121,8 @@ Sensitivity presets (both values are ceilings; the pHash one is adapted per scan | Policy | pHash ceiling | RGB ceiling | Notes | |---|---|---|---| | Exact copies only | – | – | byte-identical files, no decoding at all | -| Balanced (default) | 12 bits | 60 / 192 | the recommended setting | -| Aggressive | 18 bits | 84 / 192 | catches heavier re-edits | +| Balanced (default) | 15 bits | 60 / 192 | the recommended setting | +| Aggressive | 22 bits | 84 / 192 | catches heavier re-edits | Banding gives *exact* candidate recall for pHash distances up to 7 (see the comment in `DuplicateGrouper`).