Like a lot of people on this sub, I’ve migrated away from using Google Docs and Photos (most of the time) in favor of self-hosted services. For photo use, I’m really impressed by everything that’s gone in to Immich, Photoprism and Memories, with the latter coming the closest to my preferred way for such an app to work.
But I still find some difficulty with the workflow and design philosophy with of these apps when it comes to two things.
-
Working with large existing libraries, like one exported from Google Photos using takeout, while maintaining the organization of the original library.
-
Updating metadata.
On point 1 – I’ve got a few hangups about this. The biggest is how duplicates are handled. For instance, let’s say in Google Photos, you had your favorite photo from your 30th birthday both in an album called “2009 favorites” and another “30th birthday pics.” When (for instance) Photoprism is scanning those photos for its library, it’ll import the first one it finds, and ignore the second, without any indication in the UI that happened (but it will be in the logs). Then, later, when you go looking in the “30th birthday pics” photos in Photoprism’s "folders "view and it’s not there, it’s not clear to the user why. This is particularly confusing since the file IS in both places on the disk, and you’d think a “folders” view would represent the filesystem as-is.
Yet just ignoring the fact that you have duplicates, as Memories does, and leaving it you to manage them separately, also doesn’t seem ideal.
On point 2 - Of the above, only Memories writes changes to EXIF. This is mostly great for my purposes since I keep good backups to undo any unwanted changes, but Immich and Photoprism have good reason to be cautious about messing with original files. It seems to me there’s a halfway measure that would work well with both.
Here’s what I’d love for file imports/organization:
- Never try to adopt an existing file structure (like a bunch of folders from a Google Takeout) and simply use it in place. If the app is being pointed to one, use it for imports only, and copy everything over to the app’s own folders/file organization.
- Organize that new file structure however the developers like, without touching the originals.
- During the import, offer to convert all the folders from the original file system (ie the Google Takeout folders) to albums, managed in the app’s own database. If the user declines, import the photos in a flat structure without assigning them to albums.
- During import, the app may notice a photo appearing in more than one of the original system’s folders. If so, only copy it to the new file structure once, but assign it to both corresponding albums. This way, that birthday photo appears in both in the newly created “2009 favorites” and “30th birthday pics” albums without actually being in the new file structure twice.
- If you’re regarding anything other than exact file matches as duplicates, let the user see somewhere in your UI which files have been detected as duplicates and override the detection if necessary.
- Don’t expose a “folder view” to the user under normal circumstances. Optionally have it available as an advanced feature, disabled by default. The user should manage things as albums, and the app takes care of the underlying folder structure on its own, however, the developers find makes sense.
And for metadata:
- When importing files, check for EXIF, json, xmp and any other sidecar files. In your advanced settings, have an option letting the user specify which to prioritize if the existing files have incompatible metadata in multiple places (including an option for a prompt). Import than metadata into your database.
- When updating metadata via the app, only write those changes to the database (or, optionally, the databased and a human-readable sidecar file, like Photoprism does). Do not, by default, write it directly back into the EXIF.
- Important: If the database’s metadata is different than what’s currently in the EXIF, because the user has updated it in your app, give the user an option to write it to the EXIF as a batch operation. Warn the user these changes are irreversible before proceeding. Have a flag in the UI that shows the user when the EXIF data and database data are not the same, and allow the user to filter their view by it.
- Important: When exporting a photo from your app, if the EXIF metadata and database data aren’t the same, by default write the database data to the EXIF of the exported photo. Do not change the original photo stored in the app’s file structure – only make this change to the exported version. Have an option to disable this. That way, under normal circumstances, when someone exports a photo from your app, and imports it into a photo editor or other library, it’ll carry over the changes they made in your app unless otherwise specified … without risking the original files that remain untouched for safety.
- Optional: Provide a command-line script to interpret your human-readable sidecar files and apply them to photos’ EXIF data in batches using something like EXIFtool (I wish Photoprism had this already and I’m surprised I haven’t found anything generated by a user to do it).
There are continuous discussion on what’s the best way to organize your photo collections. It’s fair to say that none of them stands out as the predominant winner. My way (and of course Les Pas is implemented exactly as this is) looks like the following:
Shoot as much as I can with my phone and digital camera.
After the trip or event or simply a period of time like a month or so, revisit the photos, choose the best of them, then edit and put them into a new album in Les Pas. Then publish (means share in Les Pas’s term) the album to others if I think they care.
For those photos deem to be mediocre, they stay in the camera roll (which is nicely backup on the server) or in their respective folder organized in date. And eventually I will move them to an external hard drive and they stay offline. I have very bad experience in the past of hard drive broke down after short period of time because they are kept spinning all days. I currently have only 5000 photos in 30 albums online, and they come out of those tens of thousands which are now sleeping in the offline drive.
I also have albums which won’t end in a specific day, like the one documenting the growth of my kids, and the one collecting recipes footage. Whenever I shot a good one or found a piece of interesting stuff on the Internet, I add it to my collections respectively.
Each member of my family follows these procedure. Whenever we need someone else help, we can publish the album as Joint Album, so that others can contribute by adding photos into it.
If I need to show my works to someone who doesn’t have account setup on my server, I can make a photo blog out of an existing album and Nextcloud would be happy to share it to the outside world.
I believe organize photo in albums and the cleansing job in step 2 is a effective way to enhance my memory of those moments. I can locate a specific photo more quickly then using date/location/AI search among thousands of photos, even though Les Pas provide ways to do some of these search. It will take some extra time to do it, but you will get reward in the long run.
If you haven’t looked already, my app Damselfly might work. It uses the existing folder structure, displays all files (duplicates or otherwise) and has metadata editing and updating.
You can run it alongside other apps, so you could use Damselfly and Photoprism, for example, and get the best of both.
Album support is not really there, but it focuses on folders mainly (because that’s my use case). I have it running on a Synology, with a 5tb collection of 670k photos, and it’s fast.
Thanks for the heads up on this project. It looks like it might work very well for some people who basically want a web app as a view right into a filestystem for dealing with folders.
Unfortunately, it doesn’t really meet the needs I’m laying out. The use case I’m describing is still one where the web app abstracts away the file system and uses albums. It just lays out a (smart, I think) way of recognizing and interpreting the organization in a pre-existing library, like one created from a Google Photos takeout, when bringing photos into its own system – accounting for duplicates in albums without doubling them up on disks.
Direct editing of EXIF is handy. Memories does that too, and it’s part of why it’s what I’m using. But my ideal situation would be one where the app only writes metadata changes to its own database initially, but then (optionally) applies it to EXIF when exporting/downloading files without touching the original files. And it would also give the user an option to apply metadata to EXIF for the original files, but only after first prompting with warnings.
It seems your design goals are pretty different than any of that – which isn’t a criticism, as I’m sure it works well for the way a lot of people like to work (just not me).
To be fair, the amount of text you had to write to explain your ideal solutions (at least to me) hints at the fact that photo management software is very complicated. Specifically, there are lots of use cases and choices to make about the design and implementation, all with their tradeoffs and complexities. Supporting all of them is quite hard to do, so it is no surprise to me this is the state of things right now.
(disclosure - core Immich maintainer)