I've been looking for something like this for a while to organise photos from my phone, also without success. I hold all my photos locally and then securely sync them to a remote NAS.
My photo album folder naming structure is slightly different from this, but this will still speed up sorting photos.
The biggest problem I have found is that there are so many metadata tags, with many different formats, which complicates taking the dates accurately.
I'd say the pain is the manual work that you need to do to organize the photos without recognized or proper metadata, but still, it's less painful than organizing everything manually.
I have the same problem. I personally just chunk all my photos into albums like this
...
2019q4
2020q1
2020q2
2020q3
2020q4
it is too hard with 10+ years of photos to maintain all that metadata when many of them are from different operating systems / file systems so some times "sort by date" doesn't work.
My app is a quite smaller subset of what PhotoStructure seems to provide.
Unfortunately, I can't try it, but I believe that it can certainly replace my app, and I wouldn't have built it if PhotoStructure works as it promises.
In fact, my first idea was to build an app like that, with a nice UI, but it's simply too much effort, and I didn't had the required amount, I just needed something that worked for my use case to actually get my photo album.
The main difference right now is that you can use my app, and I don't know when PhotoStructure will be available, but I already signed up to the beta list.
Why can't you try it? You're certainly welcome to!
Beta users get installation instructions emailed to them automatically as soon as they sign up. If you didn't receive that email, email me at hello@photostructure.com or send me a chat on the website, and I'll send you the link.
* 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]
Hi everybody, this is a command-line app that I created while working with my wife on filling a family album, where we needed to choose pictures per month/year, unfortunately, I wasn't able to find any software doing this while holding my photos out of the cloud, and ended up writing it.
It's pretty simple right now, it takes a source directory, and processes the photos by taking the creation date from its metadata, producing an output directory where each photo is inside a specific directory for its year/month, like 2020/02-february/photo-1.img.
It was build to fulfill my needs, and hopefully, it can be useful for others.
At last, this is was my proof that creating cli apps in Scala is now feasible.
Thanks!
EDIT: Apparently, I'm a guy still in the caverns because most of my friends seem to prefer to use Google Photos/iCloud/etc, while I prefer to still keep some privacy, what a time to live it.
exiftool -d %Y-%m-%d "-directory<datetimeoriginal" image.jpg
Move 'image.jpg' into a directory with a name given by DateTimeOriginal, in the form '2006-03-27'.
exiftool -r -d %Y/%m/%d/image_%H%M%S.%%e "-filename<filemodifydate" DIR
Recursively rename all images in 'DIR' and any contained subdirectories to the form 'image_HHMMSS.EXT' (where 'ext' is the original file extension), and move them into a new directory hierarchy based on date of file modification, with path names like '2006/03/27/image_105859.jpg'.
Readit News
My photo album folder naming structure is slightly different from this, but this will still speed up sorting photos.
The biggest problem I have found is that there are so many metadata tags, with many different formats, which complicates taking the dates accurately.
I'd say the pain is the manual work that you need to do to organize the photos without recognized or proper metadata, but still, it's less painful than organizing everything manually.
... 2019q4 2020q1 2020q2 2020q3 2020q4
it is too hard with 10+ years of photos to maintain all that metadata when many of them are from different operating systems / file systems so some times "sort by date" doesn't work.
[0]: https://photostructure.com/about/introducing-photostructure/
Unfortunately, I can't try it, but I believe that it can certainly replace my app, and I wouldn't have built it if PhotoStructure works as it promises.
In fact, my first idea was to build an app like that, with a nice UI, but it's simply too much effort, and I didn't had the required amount, I just needed something that worked for my use case to actually get my photo album.
The main difference right now is that you can use my app, and I don't know when PhotoStructure will be available, but I already signed up to the beta list.
Thanks for sharing.
Beta users get installation instructions emailed to them automatically as soon as they sign up. If you didn't receive that email, email me at hello@photostructure.com or send me a chat on the website, and I'll send you the link.
* 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/ [1] https://photostructure.com/faq/why-doesnt-photostructure-mov... [2] https://photostructure.com/server/tools/#show-me-all-the-dup... [3] https://photostructure.com/faq/what-do-you-mean-by-dedupe/
Deleted Comment
It's pretty simple right now, it takes a source directory, and processes the photos by taking the creation date from its metadata, producing an output directory where each photo is inside a specific directory for its year/month, like 2020/02-february/photo-1.img.
It was build to fulfill my needs, and hopefully, it can be useful for others.
At last, this is was my proof that creating cli apps in Scala is now feasible.
Thanks!
EDIT: Apparently, I'm a guy still in the caverns because most of my friends seem to prefer to use Google Photos/iCloud/etc, while I prefer to still keep some privacy, what a time to live it.
exiftool -d %Y-%m-%d "-directory<datetimeoriginal" image.jpg Move 'image.jpg' into a directory with a name given by DateTimeOriginal, in the form '2006-03-27'.
exiftool -r -d %Y/%m/%d/image_%H%M%S.%%e "-filename<filemodifydate" DIR
Recursively rename all images in 'DIR' and any contained subdirectories to the form 'image_HHMMSS.EXT' (where 'ext' is the original file extension), and move them into a new directory hierarchy based on date of file modification, with path names like '2006/03/27/image_105859.jpg'.