Zoph has a CLI for importing photos, which by default moves photos rather than copying them, into its storage. I have imported collections like this, but I tend to use
zoph --copy --album some_album some_album/*.jpg
to preserve the originals, and import into albums, and sub albums which reflect the directory structure, and then remove the original tree once it is imported. As part of the import zoph creates thumbnail and mid-sized versions of the photos for display, so there are files created as well as database entries. When I have a lot of photos coming in at once which should be organised better i sometimes import them all into an album called - say new-2021-02-28, and then work through that album adding the photos to a more appropriate place and removing them from the new-whatever album.
Photos can be in several albums at once, and I also use categories as an alternative way of sorting and finding photos.
Thanks for explaining your workarounds. What I have not fully understood is what you mean by “then remove the original tree once it is imported”.
I see there are a lot of users that want to keep their original, on-disk photo directory structure (user-data), while the photo manager can keep cache and meta-data separtely (app-data) where it can not be embedded in the exif data.
I don’t think that implementing cloud storage backends has to be a prerequisite to support custom local photo directory structure.
A typical example, someone scans a lot of family photos from an old collection, and puts them into folders, one per set of pictures. He then copies all the ones with some person into a folder for photos about that person, and so on for some set of people, similarly for photos set in a place, and others for significant subjects. These folders are then zipped and (in a sensible way to get a backup), sent to family members. Thus the original on disk structure, good for browsing in Windows, is an inefficient use of space. It also presents a dilemma for the future, in that if new photos of some of these people are taken should they be added to the original folders etc. Thus once all the information can be retrieved via Zoph it is best to conserve the space and remove the original structure.
The link to cloud backends is that zoph stores its mid and thumb images, at present, in the same on disk structure as the photos. If it was used as an index to Google photos, flickr etc, the there would have to be a separation (or dynamic generation) of the thumbs and mids
The use of the filesytem for temporary file separation is a little different from a mostly static, but still re-arrangeable, basic filesystem tree, though. For example, year/event/camera/… directories.
Photo viewers and managers come and go, likely different ones need to be usable at times and locations.
The files are there to stay, and to be synced with other people and devices.