# Competitor tests — measured, not claimed

All numbers below come from one synthetic test polygon: **67 files with
known ground truth**, generated by [`poligonas_gen.py`](../poligonas_gen.py)
(ships in this repository — you can reproduce every run yourself).
The polygon contains the traps a real family archive is full of:

- 30 EXIF photos whose file dates (mtime) are **fresh** — the classic
  "I copied my archive once and every file date became today" situation;
- 12 WhatsApp-named files (`IMG-20230318-WA0006.jpg`) with **no EXIF**;
- 8 screenshots (name is the only date source);
- 6 files where honest mtime is the only truth;
- duplicate pairs (`DSC_9000.JPG` / `DSC_9000 - Copy.JPG`);
- a corrupted-EXIF file, a 0-byte file, a fake `.jpg` (wrong content).

Each tool ran on an identical fresh copy of the polygon and was scored
against the same 67-point ground truth. PHOTO home's own run is a
regression test in this repository (`foto_namai/_patikros/
patikra_e6_egzaminas.py`) — the full pipeline: scan → index → plan →
execute → **UNDO back to zero, originals byte-identical**.

## Results

| Criterion | MRImageSorter 0.20 | PhotoMove 2.5 Free | phockup | elodie | OrganizeMediaFiles | **PHOTO home** |
|---|---|---|---|---|---|---|
| **Polygon score** | 34/67 | 38/67 | 46/67 | 47/67 | 0/67 (won't start on Windows) | **67/67** |
| EXIF sorting | ✅ | ✅ | ✅ | ✅ | — | ✅ |
| Date from file name (WhatsApp) | ❌ filed into *today* | ❌ left behind | ❌ `unknown\` | ❌ **invents a date** | — | ✅ name patterns |
| Fallback when no EXIF | ❌ ctime (= today) | 💰 Pro only | flag-gated | ❌ unlabeled (a lie) | — | ✅ mtime + honest "unreliable" label |
| Duplicates during the move | ❌ silently left | ❌ multiplied | ✅ | ✅ checksum | — | ✅ content-checked, never copied twice |
| Junk traps (0-byte, fake .jpg) | ❌ moved as photos | ✅ left alone | ❌ copied | ✅ left alone | — | ✅ left alone + explained |
| Keeps original file names | ✅ | ✅ | ❌ renames | ❌ renames (with a bug) | — | ✅ never renames |
| External dependencies | — | — | ExifTool | ExifTool | ExifTool (not found on Win) | **none** |
| Review before acting | text log | counters | dry-run text | ❌ | — | ✅ visual plan you edit |
| **UNDO** | ❌ | ❌ | ❌ | ❌ | — | ✅ full journal + one button |
| Price / state | free alpha | $8.99 for the essentials | free CLI | archived project | free, broken on Windows | free, no ads |

## Per-tool notes (what the numbers mean)

**MRImageSorter 0.20 Alpha — 34/67.** EXIF photos land correctly. But
files without EXIF fall back to file *creation* time — which after any
copy equals *today*, so all 12 WhatsApp photos and 8 screenshots went
into a `2026\08` folder. It also moved the 0-byte file and the fake
`.jpg` as if they were photos, and left duplicates unsorted without
telling the user.

**PhotoMove 2.5.3.2 Free — 38/67.** EXIF handled correctly, junk left
alone (good). But **all 29 files without EXIF were simply left
behind** — "Use File Date" is a Pro ($8.99) feature; on a real phone
dump that is roughly 40 % of the files. Name-date patterns are absent
even in Pro (per the vendor's own FAQ). Default duplicate matching is
by *file name*, so `DSC_9000.JPG` and `DSC_9000 - Copy.JPG` were both
moved — duplicates multiplied.

**phockup — 46/67.** Solid EXIF handling and real duplicate detection.
But its only name pattern requires a time-of-day component that
WhatsApp names lack → all 12 went to a flat `unknown\`. mtime fallback
exists only behind a flag. It *copied the junk files* into the archive,
renames everything to `20210514-143000.jpg` (your original names are
gone), and requires ExifTool on PATH. No UNDO.

**elodie (archived) — 47/67.** EXIF and honest-mtime files handled.
But the worst failure mode of the whole test is here: **all 20
name-dated files received an invented "2026-07" date with no label** —
filed as if that were the real capture date. Not "I don't know" but a
confident wrong answer. It also has no name patterns at all, renames
files (with a sanitization bug: `photo (1).jpg` → `photo-(1.jpg`), and
the project is no longer maintained.

**OrganizeMediaFiles — 0/67.** Would not run on Windows / Python 3.13
at all: a SyntaxError in its own code, an ExifTool lookup that can
never succeed on Windows (`exiftool` without `.exe`), and after
patching both, a crash on the first copy. A Unix-centric tool; for a
Windows user it effectively does not exist.

**sortphotos — not scored.** It requires Perl on Windows, which our
target user does not have. From reading its source: EXIF-driven,
no name patterns, honestly *skips* undated files (no lie, no
`unknown\`) — a projected ~34–38/67.

**PHOTO home — 67/67**, followed by a full UNDO that returned every
file and left the originals byte-for-byte identical. The same polygon
also passes at the index level (`patikra_e2_egzaminas.py`: dates,
sources, reliability labels).

## Reproduce it

```
python poligonas_gen.py            # builds the polygon with TIESA (ground truth)
python foto_namai\_patikros\patikra_e6_egzaminas.py   # our full-pipeline run
```

Then point any other organizer at a fresh copy of the polygon and score
it against the generated ground-truth file. If you get different
numbers for any tool above — open an issue, we will re-measure and
correct this page.

*A note on fairness: the polygon's "fresh mtime on old photos" trap is
not an artificial gotcha — it is what every archive looks like after a
single disk-to-disk copy. Tools were run with default settings, the
way a non-technical person would run them.*