[Bug/Feature] Issues around "edited" photos on iPhone #4750
Replies: 3 comments 7 replies
-
I’m having the exact same issue. The easiest way to have a first implementation of this would be just to:
This would retain all Photos’s nondistructive editing, and there’s more! This would retain even all the data from:
So this is a super good idea! |
Beta Was this translation helpful? Give feedback.
-
我觉得CLI是不是可以先放开aae文件的上传,保留原始文件是有必要的 |
Beta Was this translation helpful? Give feedback.
-
This issue is what’s stopping me from switching to Immich as my main backup solution. I currently use PhotoSync to backup to my NAS. PhotoSync backs up both original as well as edited versions of photos and videos. |
Beta Was this translation helpful? Give feedback.
-
This is a bit confusing even for me and a bit difficult to explain, but I'll do my best.
A few facts:
Currently I'm in the process of migrating from macOS Photos to Immich. I have photos/videos only on macOS Photos, photos/videos only on my iPhone and photos/videos on both. Ideally, at the end of this, all photos/videos are saved in Immich, and I start using the iOS Immich app to backup any new photos/videos I take. This means, after moving everything to Immich, whatever I still have on my iPhone that was taken in the past is recognized as being synced with the Immich server (and whatever was only on macOS Photos shows up on the Immich iOS app as present only on the Immich server).
My issue:
Solutions?
As it turns out, macOS Photos saves the original 3024x4032 photos along with extra "edit" files with extension
.aae
. Here is an example of the contents of one such file:This seems different than the
.xmp
sidecar metadata I've seen referenced in multiple other issues here on GitHub. In fact, if I export a photo from macOS Photos, three files are produced: the original 3024x4032 photo, an.xmp
which does not contain edit data, and an.aae
with the edit (crop) data. I've tested the CLI tool and it does not read the.aae
file. One potential solution could perhaps be to read this file, if available? Then either crop the photo before uploading or upload the original and the edits separately. To be honest, this sounds like too much work to get going, especially because I expect these edits can become much more complex than a simple crop (color grading, etc). I tried to see if I could find how to read the.aae
files online and couldn't find anything, but maybe Apple provides APIs we can use.Another solution could be to let the user choose if Immich iOS uploads the edited version or original version of the photos. In this case, I would choose original, and the syncing issue of double photos would no longer happen (but I would have to enable this for all photos, and I could potentially lose other edits such as color grading, text, etc... this is not ideal either).
Or finally, maybe the comparison between server photos and device photos during syncing could be improved such that cropped versions of the same photo are detected, and then the double photos issue I have would be solved. But even there this is not obvious: which version should you actually keep in the server? Ask the user every time? I can see legitimate reasons for all three options: keep original, keep cropped, keep both (or more, even, if the user has multiple crops of the same photo).
I'm posting here because I don't think this is a bug per se: uploading edited versions on Immich iOS is not necessarily wrong, and parsing
.aae
files, if that is the solution, is more of a feature request. But I don't have an idea of what the best solution here is, and I'm happy to discuss potential options and also to provide example files for this issue.Beta Was this translation helpful? Give feedback.
All reactions