[Bug/Feature] Issues around "edited" photos on iPhone

[truppelito]

This is a bit confusing even for me and a bit difficult to explain, but I'll do my best.

A few facts:

• My iPhone 12 Pro takes photos (using the main camera) which are 3024x4032.
• The iOS Photos app shows the photos cropped with size 2268x4032, but the originals are still 3024x4032. I can verify this if I try to edit a (seemingly) 2268x4032 photo on the Photos app in iOS, and I suddenly see the sides of the (original) 3024x4032 photo. In other words, it seems like a 3024x4032 photo is taken and immediately editted to be cropped to 2268x4032.
• Immich iOS app uploads the edited version (2268x4032) only. I know for sure this is the case because not only is the 2268x4032 version shown on the Web, but I confirmed it by looking at the actual files in the Immich library folder.
• Up until now, I've used the macOS Photos app to backup all my photos/videos from my iPhone. The Photos app imports the original 3024x4032 version and the corresponding "crop edit". If I look at a photo on the Photos app, it shows up as 2268x4032 initially, but if I edit it, the cropped sides are revealed (just like on iOS). The files saved on my Mac by Photos are 3024x4032.

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:

• If I use the CLI tool to upload all media from macOS Photos to Immich, I'm uploading the 3024x4032 photos. But Immich iOS uploads 2268x4032 versions and therefore I end up with a bunch of duplicate photos for those I had on both macOS Photos and my iPhone.
• If I only use Immich iOS to upload what I have on my iPhone, I'm not uploading all my media (like I said, some are only on macOS Photos).

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:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>adjustmentBaseVersion</key>
	<integer>0</integer>
	<key>adjustmentData</key>
	<data>
	bZDLTsMwEEX/ZdahSlMI4B3qhm6oBBIsEItpMkmM/IjsSUtV9d+ZOE3Fgp1953XvOYEl
	xhoZQZ3AYmQKz6TbjkHd5qsiu2gfuuYOVFGUDxn4oMkxsvYOVHnOoPHBIr9TiElaZrCf
	3hvX+HHxbtCmfhnsjgIoKPJ1eQcZYN9fZ0D+serI4ivt9aTlGfQGedwuDXr7BnIL6+8h
	shUDEdTn6Z/b5HBnqAbFYSDZSszatXH0ccRDWisJWu3QrIPv576fbRJTPVoMQqBBE6Vy
	mMJPPI5z2+peUEQOONIi9+RaQ6BuZBoH9tfh7kJzQld5l0Ycz5SX5V/1wvlRkmuu5JVL
	ZF1LWt3oBC9ZnpFv/lYqbxeC1NCi77w4OH+dfwE=
	</data>
	<key>adjustmentEditorBundleID</key>
	<string>com.apple.camera</string>
	<key>adjustmentFormatIdentifier</key>
	<string>com.apple.photo</string>
	<key>adjustmentFormatVersion</key>
	<string>1.4</string>
	<key>adjustmentTimestamp</key>
	<date>2023-04-11T17:47:16Z</date>
</dict>
</plist>

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.

[belgio99]

I’m having the exact same issue. The easiest way to have a first implementation of this would be just to:

1. Automatically upload all the 3 files from the iOS app (original, edited, and .aae). (Apps like photosync can do this)
2. Create a “stacked asset” with the original and edited version, showing only the edited
3. When the user exports the photo from immich, create a “.photoasset” file (which is basically just a folder that contains the three files) that can be imported into macOS’s Photos for further editing.

This would retain all Photos’s nondistructive editing, and there’s more! This would retain even all the data from:

• Portrait mode (Portrait depth map, lighting effects…)
• Slow motion videos (in/out points of the Slo-mo part)
• Live Photos (Key frame)
• Cinematic mode (Depth map to change the focus after the shot)

So this is a super good idea!

[pablosp76]

That would be an incredible feature for IOS users. I wish it could be implemented.

[truppelito]

If we upload all data available (when using the CLI for macOS Photos and when using the Immich iOS app for iPhone photos), then the problem is indeed solved. Immich would serve as a full lossless backup of macOS Photos/iOS photos and the syncing issues would disappear because Immich would be able to tell, having all data, which photos from iOS have been uploaded to the server already.

[skywalker04aby]

Love this idea. As a minimum, I think it would be nice if both the original and edited versions were uploaded to the server (maybe with a setting to turn this on or off, or allow the user to choose which to upload, depending on user preference). Uploading the .aae would have the added benefit of Apple’s sidecar being available if the user wanted to use macOS Photos. Uploading the .aae file could also be a setting the user can choose to turn on or off.

For me, having the original and edited versions stacked in the library would be an added bonus, though I suspect this wouldn’t be too challenging since it appears this may already be what’s happening with Live Photos.

The Image Capture app in macOS imports all three files with the edited version having an “E” in front of the image number (e.g., IMG_E1234). Unfortunately, because of the placement of the “E” the edited versions all end up grouped together when viewing a folder of images that are sorted by name in Finder or other applications. Maybe there is something I’m missing, but it seems to me that it would make more sense to add the “E” (or some other designator, if Immich devs choose to implement uploading original and edited versions and use a designator of some kind in the file name) to the end of the file name so that the edited version is next to its original, in this scenario.

[Skywalker8510]

Does anyone know if something like this has been implemented yet? this is the only thing stopping me from using immich for my photos. if this is added I can finally get rid of my completely full 200GB of iCloud that is no longer backing up my photos.

[qkrrmsdud1]

This could also become part of the editor, so there would be a "Revert" option in the editor that would clear the aae file, delete the edited version of the photo, and replace it with the original, exactly the same way iOS and Google Photos handle edited photos (on the frontend, at least). Moreover, Immich implementing this model of reversibly replacing a photo with its edited version (storing original and edited version while displaying the edited version and sharing the edited version, but having a button to revert it back to the non-edited original) into the upcoming native editor would be amazing.

[lexcao1729]

我觉得CLI是不是可以先放开aae文件的上传，保留原始文件是有必要的

[alextran1502]

Please try keeping discussion in English

[lexcao1729]

I think the Immich cli could support aae file upload first.—— Oh sorry, I didn’t know English was only allowed here.

[alextran1502]

No problem, none of the maintainers and core contributors speak Mandarin AFAIK

[ravishekharco]

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.

[Skywalker8510]

@alextran1502 considering that Immich is starting to get closer and closer to a stable release is this something that is planned to be added anytime soon? I know that it doesn’t have many likes but this change would make Immich so much more usable for Apple users.

[Skywalker8510]

Good news. The issue for the request is no longer missing requirements and may be worked on. fluttercandies/flutter_photo_manager#1070

[Skywalker8510]

even more good news. as of the end of febuary this year theres a pull request thats been reviewed that fixes part of this.
fluttercandies/flutter_photo_manager#1339

[JakobLichterfeld]

Flutter Photo Manager now supports AAE sidecard files: "Add AssetEntity.darwin.getAdjustmentData() to export AAE edit data on iOS/macOS" fluttercandies/flutter_photo_manager#1070 --> fluttercandies/flutter_photo_manager#1413

[tom-barbarossa]

@alextran1502 in case you missed the above - seems like the feature has been added to photo_manager, hopefully with this being done it can also land on the Immich roadmap 👀

whether it does or not however, thanks a lot for Immich and all the work y'all put into it!

[tom-barbarossa]

cross-reference, this tracks the thing in an issue: #5818

[nS-Gecko]

Well, I found out this ticket and that's exactly the problem I'm currently facing today with immich and Portrait Photos. The Immich iOS app only sends the "edited" version of any Portrait Photo with the blur in the background which display fine in the immich app and web app. But the original photo is not copied over and lost in case it is deleted from the phone.

Photos.app on the Mac can export the original to immich but unfortunately, the background blur is lost in the process, the depth data not being kept or at least understood by immich at this state of development.

iCloud can export a folder with all versions from the Portrait Photo but in immich, the image does not seems to be stacked automatically.

So I don't see any good solution to treat those kind of assets right now. Am I missing something here or did I summarize the situation well enough ?

Except from that point, the app is rock solid, thanks for the hard work !

[Skywalker8510]

This thread is the most up to date information about the current situation
#4750 (comment)

[intiazrohan]

This is the only issue that is blocking me from switching to immich. Do we have any update regarding this?

[bo0tzz]

https://justinmayer.com/posts/any-updates/