Optional resized/compressed local copy after upload (instead of full delete)

[space0815]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Immich already has a great "Free Up Space" feature (introduced in 2.5, see docs) that removes local files once backed up to the server.

It would be great to have an additional option: instead of fully deleting the local file, keep a resized/compressed version on the device (e.g., an iPhone-optimized resolution or configurable quality settings). This would help optimize local storage usage while still keeping a usable offline copy — similar to how iCloud's "Optimize iPhone Storage" works, but with the original always safely stored on the Immich server.

Related discussions (full-delete only, not resizing):

#3546
#17039
#23042

Platform

• Server
• Web
• Mobile

[bo0tzz]

#9706

[akshob]

I think #9706 is related but different, so here is a concrete design to see whether it would be welcome in the mobile app.

Use case

I want the server to keep every original, while my iPhone's own Photos library keeps the whole timeline as small copies. Everything stays in the system Photos app, shared sheets, widgets, and other apps that read the photo library, including offline. #9706 caches previews inside the Immich app, which helps browsing in Immich, but the phone's library still holds full-size originals or nothing.

Proposal: "Replace with compact copy" (opt-in, next to Free Up Space)

1. Eligible assets are chosen with the same rules as Free Up Space (cutoff date, keep favorites, keep albums), and only if the server copy is confirmed by checksum.
2. The app makes a compact copy on the device with the platform encoders: photos at a configurable long edge (for example 2048 px, HEIC or JPEG), and videos as HEVC (for example 720p).
3. On iOS, Live Photos stay Live Photos. The motion part is re-encoded with AVFoundation so the still and video stay paired.
4. The compact copy is saved to the device library with the original's capture date, location, favorite flag, and album membership. The original is then deleted with the normal system confirmation and goes to Recently Deleted / Trash.
5. The app records that the new local asset is a compact copy of remote asset X. Backup then never uploads it again or counts it as pending, and the timeline shows one merged item. "View original" opens the server version as it does today for remote assets.

Why it needs to be inside Immich

A separate app can do steps 1–4, but Immich's backup would see each compact copy as a new file (different checksum). It would upload a duplicate and show "items remaining to back up." The only workaround is to put compact copies in an album and exclude it from backup, which is fragile, and the timeline still shows two items. Step 5 needs the app's own local-to-remote mapping.

Experience so far

I run this workflow outside Immich today on about 37,000 items, with a server pipeline and manual import:

• Photos at 2048 px: 19.6 GB → 3.7 GB.
• Live Photo motion re-encoded with AVFoundation: 22.2 GB → 3.7 GB. PHLivePhoto validated every pair, and the Live badge survived import into Photos.
• FFmpeg-transcoded Live Photo motion did not stay paired. It loses the timed-metadata links iOS needs, so this part has to use AVFoundation on iOS.
• On-device numbers aren't measured yet. Hardware HEVC output will be larger than server-side x265.

Questions for maintainers

1. Would an opt-in feature like this be accepted in the mobile app, or does it conflict with the direction in [Feature] Improved caching on mobile app #9706?
2. Should the compact-copy link live only in the mobile local database, or should the server know about it (for example for multiple devices)?
3. Any preference on encoder settings, or on starting iOS-first and adding Android (MediaStore) later?

[bo0tzz]

Please read main/CONTRIBUTING.md#use-of-generative-ai and post in your own words.

[akshob]

apologies. my bad. my first time trying to contribute and i got a bit too excited. i will post my use case and thoughts on #9706

[akshob]

#9706 (comment)