There is a related problem, which I hit while scanning family archives going back slightly more than 100 years. There is no good photo archival software.
If you now rushed to click "reply" to say that yes, of course there is, right here, hold your horses. You probably do not understand the problem.
Good photo archival software would let me keep my photos in formats that will be readable 25 years from now. It must not rely on any company being in business or offering any service.
It must support storing the same picture in multiple formats. It must support assigning dates to pictures that are not the same as the file date nor the EXIF date. It must support assigning imprecise dates (just a year, or ideally an interval).
It must support storing multiple files as part of the same "image", and I do not mean multiple versions/formats of an image here. Examples: front and back of a scanned paper photo, or 24 scans of a large format picture that are then merged together into a resulting stitched image.
All that information must be preserved in ways that will let me recover it even without any software (e.g. files in the filesystem).
I used many solutions over the years, and got royally screwed by most, the most recent one being Apple shutting down Aperture (which did most of these things pretty well). I am now close to writing my own software.
EDIT: to all those who respond with "just store it as files" — yes, of course they should be stored as files. But that's not an answer. You do want searchability, nice visual access, and other niceties on top of the basic plumbing.
It's open-source, so no worries about a company shutting it down, and it handles a lot of the stuff you're asking for. It’s designed for organizing and managing research photos, but it has features that fit archival needs pretty well.
Open and future-proof: Metadata is stored in JSON-LD, so even if Tropy disappears, your data isn’t locked up. It doesn’t modify your files either, so your originals are safe.
Flexible metadata: You can assign custom dates (even imprecise ones like "circa 1920" or a date range) and add other metadata fields to fit your needs. It’s not tied to EXIF or file timestamps, which is a big plus.
Related files: Tropy lets you group multiple images (e.g., front and back of a photo or parts of a large scanned image) into a single "item." Relationships are preserved, and you can see them all in the same context.
Search and organization: It’s way better than just dumping files into a folder. You get tags, categories, and a solid search interface to make your archive usable.
That is actually a really good suggestion! Thank you, I did not know about this project, and it is quite close to what I'm looking for. Perhaps I won't have to write all of the software myself!
My photo archival software is jpegs in a directory called 'photos'. Sometimes with subdirectories by date. Backed up however I'm backing up my computer.
For true durability, you've got to embrace the lowest common denominator.
Those rare features you can only get from Software X will lock you into Software X. If you want your archive to outlive Software X, you gotta do without them.
100% agreed. Protip: You can store metadata tags like the location or people in the picture by including them in the filenames of those jpegs, and then search it with a tool like "find".
Technically, you could do this in Mylio but probably not in the way you want.
Mylio stores “Live Photos” as
Photo.extension <- the “photo” it shows in the interface
Photo.xmp <- all the metatdata
Photo.myb <- everything else
Literally the myb is just a zip of everything else associated with the photo. So in the “Live Photo” case that would be the associated video file. If you have edited the file in Apple photos that also includes the XML Apple uses to non destructively perform the edit. As well as a copy of the original photo.
In your case you could just manually create the myb file by zipping up all the associated extra photos and changing the extension.
However the interface would only show the single main photo.
The best solution I've come up with is jpgs in a yyyy/mm folder structure + EXIF metadata. I know it's not your ideal, but it'll be supported and platform agnostic for the forseeable future, and there are plenty of apps that can search metdata tags.
That said - I used to rigorously tag photos for the event, place, and people in them, but it's just too much work. Some tooling around batch and auto tagging would be great, so long as it wrote back to the original image EXIF.
darktable does all of this. It’s a complex application like Aperture or Light Table. You run it on your own macos, Windows or Linux computer. You can write your own software to extend or change it. Photos.app does most of this sans the Windows, Linux or “write your own” parts.
This was my first reaction too, but it scratches an itch for me as well - I've thought about making a proper photo archival system many times and just never got around to giving it a shot.
If you now rushed to click "reply" to say that yes, of course there is, right here, hold your horses. You probably do not understand the problem.
Good photo archival software would let me keep my photos in formats that will be readable 25 years from now. It must not rely on any company being in business or offering any service.
It must support storing the same picture in multiple formats. It must support assigning dates to pictures that are not the same as the file date nor the EXIF date. It must support assigning imprecise dates (just a year, or ideally an interval).
It must support storing multiple files as part of the same "image", and I do not mean multiple versions/formats of an image here. Examples: front and back of a scanned paper photo, or 24 scans of a large format picture that are then merged together into a resulting stitched image.
All that information must be preserved in ways that will let me recover it even without any software (e.g. files in the filesystem).
I used many solutions over the years, and got royally screwed by most, the most recent one being Apple shutting down Aperture (which did most of these things pretty well). I am now close to writing my own software.
EDIT: to all those who respond with "just store it as files" — yes, of course they should be stored as files. But that's not an answer. You do want searchability, nice visual access, and other niceties on top of the basic plumbing.