What it does, in order

1. Extract the embedded metadata with ExifTool and persist it as a JSON record. That record is the durable answer to "what was this photo carrying" — it outlives the stripped copy.
2. Disclose it onto the photo row: whether there were GPS coordinates, what they were, the camera make/model, the device serial, the capture time.
3. Strip — ExifTool writes a new copy with -all=. The original file is never mutated and no _original backup is made.
4. Thumbnail — from the stripped copy.

⛔⛔ Step 4 takes the STRIPPED copy as its source, and that is load-bearing, not tidiness. Verified live on 2026-07-30: vips thumbnail writes PNG with no strip option, and a thumbnail taken from the original carried 31 metadata keys through, including full GPS. So a pack that stripped the delivery copy but thumbnailed the original would hand out a clean photo and leak the customer's coordinates in the preview beside it. Thumbnailing the stripped copy yields a clean file — also verified.

⚠ vips image.to_jpeg and image.to_webp strip on their own (their save options end in strip), so if you add a web-sized variant later you do not need a second ExifTool pass. image.thumbnail, image.resize and image.convert do not — they are the PNG paths, and they carry metadata through.

⚠ Images only. Add a photo to a set refuses non-images, and that boundary matters here: ExifTool documents PDF metadata edits as reversible because old objects can remain in the file, so -all= on a PDF is nullification, not removal. This pack never sees a PDF.

⚠ GPS is disclosed as ExifTool formats it — 51 deg 30' 12.56", not a decimal pair. It is recorded to be read by a human deciding whether to send, not to be computed on.

⚠ Re-running is refused once a photo is prepared. Each run persists new content-addressed copies, and re-preparing would orphan the previous ones with nothing to reclaim them. Delete the photo row and re-add it if you need to redo the work.