Accomplished-Lack721

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.

1. Working with large existing libraries, like one exported from Google Photos using takeout, while maintaining the organization of the original library.

2. 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).