4 ms·
Many things are different. * This tool is designed to do one task, once: move photos from one directory structure, into another directory structure. It has no
by mceachen 6y ago
Many things are different.
* This tool is designed to do one task, once: move photos from one directory structure, into another directory structure. It has no state persistence, so if you ask it to reorganize twice, it has to redo prior work, like recompute file SHAs.
* PhotoStructure is designed to be long-running service, and stores state persistently in a library database[0]. This enables efficient incremental imports, and does so automatically (say, when SyncThing or Resilio Sync copies photos into your NAS).
* PhotoStructure has a web-based UI to browse and interact with the photos and videos in your library. This tool has no UI other than command line.
* PhotoStructure doesn't move files[1] out of an abundance of caution. It copies novel SHAs into a new hierarchy. There are extensive tools[2] to do subsequent source file cleanup, if you want.
* PhotoStructure handles videos and raw images.
* PhotoStructure detects and skips over images and videos that are corrupt (either through bad backups or bit rot).
* PhotoStructure looks for the captured-at from > 10 different source tags (using heuristics proven over several thousand different make and model cameras), including Lightroom XMP, MIE, and Google Takeout .json sidecars.
* For files with missing/stripped metadata, PhotoStructure interpolates captured-at using sibling files (if the siblings are considered "close enough," due to matching make/model and similar ctime/mtime).
* This tool is using the Metadata Extractor (which a previous version of PhotoStructure used, when it used a JVM). PhotoStructure uses ExifTool, which considered the "gold standard" for reading metadata. ME works in many cases, but ExifTool works in more cases.
* PhotoStructure uses a job queue for imports, automatically multi-threads based on the host machine's RAM and CPU metrics, and "renices" the processes to ensure your system is still usable even during imports. If there are only a handful of images to parse, a job queue is totally over-engineering. When there are many days worth of images to parse, and the process can get "hung" (even with process and read timeouts) due to OS hiccups, having a persistent work queue means the difference between supporting ~10k assets, and several million assets.
* PhotoStructure doesn't just de-dupe based on SHA: it also can gather together "variations" of a single image or video, using metadata comparison, rotation-invariant Lab* image hashes, and dominant color correlation[3]
[0] https://photostructure.com/faq/library/ https://photostructure.com/faq/library/
[1] https://photostructure.com/faq/why-doesnt-photostructure-move-original-files/ https://photostructure.com/faq/why-doesnt-photostructure-mov...
[2] https://photostructure.com/server/tools/#show-me-all-the-duplicate-variant-filenames-for-each-asset https://photostructure.com/server/tools/#show-me-all-the-dup...
[3] https://photostructure.com/faq/what-do-you-mean-by-dedupe/ https://photostructure.com/faq/what-do-you-mean-by-dedupe/