Replies: 2 comments 5 replies
-
You're looking for the storage template feature.
Indeed, and we are planning to change it, but that's a breaking change and so will need some care.
It sure can, it's just not a good idea because of files being moved from the upload dir, if it's a separate mount then that's a full transfer rather than an atomic move.
The upload folder is structured as it is because files are stored there from the first moment they are uploaded and never moved (unless storage template is on). This is done because it offers the least IO overhead, and the least risk (of a move going wrong). The reason for the structure/filenames is because at the point these files are created there is simply no (time, etc) information available to use. |
Beta Was this translation helpful? Give feedback.
-
I understand that point from a technical view, but that also means that you are about to give up all easy interoperability with other third party software, including photo editing software in the default setup? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm currently trying out Immich and am generally impressed. However the way the assets are stored is not really satisfying, I think. My concern is that I want to store my personal photos in some concept that will survive the software managing them, e.g. as the least common denominator it should be a somehow sensible file system structure.
So I came to the conclusion that the best thing is to use an "external library". But integrating that correctly with other workflows is kind of a mess IMHO.
Yes, there is an UPLOAD_LOCATION, but this variable is pretty misnomed, as it is not really an upload location (which is the subfolder $UPLOAD_LOCATION/uploads) but more of a base-dir for Immich's data. Single folders within this base dir can be fine tuned, but the most importand one, the library, can't be given a custom path.
However, from some other page in the docs I then learned that this library subfolder is not really used any longer, only if you set up an storage template. It seems that nowadays the folder structure within $UPLOAD_LOCATION/uploads is the place where Immich wants to permanently store the photos by defaut. This directory is, however, IMHO both misnomed and not really structured in a human-readable way which I would like to have (at minimum, some kind of time-based folder naming to be able to use the pictures with other software than Immich).
I try to play around with docker mounts and Immich's environment variables to get some universally usable filesystem, but it does not really work out. Immich as main entry point to view the pics, Digikam to edit the pics, and Nextcloud (with Memories) as additional way to view the photos (e.g. to be able to import photos not importable by Immich's app), but there is really no way to get this going in a sensible way?
Do I see it right that Immich currently seems to insist on its own idea of storing photos? Or has anybody ideas of integrating Immich with other photo workflows out there?
Beta Was this translation helpful? Give feedback.
All reactions