Compress images on upload

[leandroperin]

I would like to see a feature that adds the option to auto compress images and videos on upload.

[alliedsincro]

Will this feature be added anytime soon? If not, then Ente can't be used for personal use as one takes several photos and videos during trips which one doesnt need in its full resolution when backed up to cloud.

If all those media gets uploaded at full resolution, then the storage quota will fill up exponentially faster than its competitors

[mathsen]

For me this is also a killer feature. If this would be available, it would be so great.

[gabriele2000]

Maybe let's add an internal converter with AVIF too and with quality levels (also add the lossless mode for AVIF so the user can fine-tune it)

[bxxcvrx]

+1

[iadaz]

Videos taken on a phone a always a lot larger than they need to be because phones don't/can't apply strong compression to them quickly enough. When I organise my videos I usually recompress them with ffmpeg and they usually come out under 30% of the original size with no appreciable loss of quality. Even a quick recompression might save quite a lot of space. If there's no capacity to do this in the cloud then an option to do this in the desktop app would be great. For me though, I'd still compress the originals to save space locally too.

[iadaz]

I'd propose to add a scheduled upload. For example, the following conditions:

• When charging
• When the device isn't hot

Apply a compression (defined by the user, codec, quality level, quality preset) then upload them.

I think no one cares about an instant compression, but to not waste your data while uploading

I would also like it if the recompressed video had a custom meta tag that contained the compression settings used, a bit like https://superuser.com/a/1580036

[gabriele2000]

Desktop might be the best place, the server is pretty lightweight and only keeps meta information, all encryption happens in client side, in which desktop is most performant and versatile

My preference is to only compress largest video/images, would be great if the app can sort by size, then select a few to compress in-place:

* video: simply `c:v libx265 -crf 24` should be enough for phone shoots and screencasts

* image: `cjpeg -quality 85`

(I do this by myself so it's fine for new contents, but existing ones are painful to compress again)

Let users decide the codec and the quality rate factor.
Let users have a "pro" mode that can select everything and for "noobs" make them choose between "minimal quality loss" "medium quality loss" with examples generated on-the-fly or something like that.

I'm not gonna progressively lose details using ancient codecs (yes, jpeg is ancient by now) that degrades quality too much if you want to save space.

[ahxxm]

I had a different opinion on ancient and quality loss, for my fullframe DSLR images, cjpeg -q85 strikes a balance between visually lossless and small file size, and I can share them to any os/device/platform without worrying about compatibility.

As for candidate new formats I've tried, HEIC is not bad but even after these years it's not universally supported, newer formats like jpegli is more like a marginal improvement to mozjpeg, and jxl is yet to be adapted universally, I hope we can use jxl soon though, it's about 20%-25% smaller

[gabriele2000]

Key point: let the user decide.
Our opinion is irrilevant at the end of the day.

[ahxxm]

While 'letting the user decide' sounds 100% correct, the options we’re discussing require a level of background knowledge and understanding of the tradeoffs, for example obviously not all of users knows -q 85 and its corresponding butteraugli distance or visual loss, thus dumping options as a Pro mode could lead to poor decisions.

As a power user, I’d like to customize things like codec and CRF. However, it would be even better if there were well-thought-out presets that suit my needs before diving into Pro Mode—ideally, with links to reading materials for those who want to learn more.

[gabriele2000]

Any news devs?

[dhcgn]

A support of JPEG-XL (jxl) would be very helpful in the case of JPEG images. JPEG-XL is a modern image format that could address the compression need while offering additional benefits:

1. Space savings: JPEG-XL can save around 20% of space compared to standard JPEG without losing any information. It can also be losslessly transcoded back to the exact original JPEG if needed.

2. Improved quality: For new images, using JPEG-XL natively (not just transcoding) could provide even better compression and quality.

3. Additional features: JPEG-XL supports higher bit depths, wider color gamuts, and progressive decoding for faster perceived loading.

While JPEG-XL wouldn't address video compression, it could be a valuable part of an overall strategy to optimize storage use for images. Implementation would need to consider compatibility with various devices and platforms, but it could be a powerful option for users looking to maximize their storage efficiency.

See also: #599 "Support uploading of JPEG XL"

[gabriele2000]

I'd rather have AVIF too, but I understand that would be "weird" because people see AVIF as a slow format, even if it can be fast as hell with the right encoding informations.

[stefanosweb]

Auto compress images and videos on upload would be great 👍

[handygaber2]

This would be a great addition to Ente!

[huntfx]

I take all my phone photos in HEIF at 9248x6936, so they work out around 15MB each. I have the files at full quality on my own PC, plus I run a backup, so I don't need Ente to triple up the storage. I just need a photo library to access at reasonable quality on my phone.

Some options like these would go a long way without being too complex:

• Downscale all photos to [1500] x [1500]
• Resample all photos to [jpg quality 85]

I imagine pressing the button would:

1. Warn the user that it's not reversible
2. Do a search to find photos matching the criteria
3. Download each matching photo, process it, then upload it
4. Save the settings so any future photo uploads are processed automatically

I'd be more willing to pay for storage if I know it won't be eaten up by massive filesizes.

[huntfx]

I wrote a quick Python script to convert a folder of images/videos, since I imagine the feature won't be added for quite some time.
It's currently a mess and I'll clean it up later, but if anyone else wants it, the link is here.

• Converts images to max width/height of 2048 and saves as JPG quality 85, keeps EXIF data intact
• Converts videos to max width/height of 1280 with high ffmpeg compression

I ran it on a 63GB selection of photos/videos and the output was 5gb, so I should just about be able to squeeze my 1TB library into 50GB if I skip the RAW files.

Edit: I've uploaded 19k videos/photos and it's used up 18GB, I've got so much breathing room here.

[wadid]

I wrote a quick Python script to convert a folder of images/videos, since I imagine the feature won't be added for quite some time. It's currently a mess and I'll clean it up later, but if anyone else wants it, the link is here.

• Converts images to max width/height of 2048 and saves as JPG quality 85, keeps EXIF data intact
• Converts videos to max width/height of 1280 with high ffmpeg compression

I ran it on a 63GB selection of photos/videos and the output was 5gb, so I should just about be able to squeeze my 1TB library into 50GB if I skip the RAW files.

Edit: I've uploaded 19k videos/photos and it's used up 18GB, I've got so much breathing room here.

What would be a good workflow for this? For example if you take photos with mobile phone and then upload them then there would be no place for python script? This means you would need to upload them and then download them on desktop and run the script and then it syncs the changed photos?

[huntfx]

What would be a good workflow for this? For example if you take photos with mobile phone and then upload them then there would be no place for python script? This means you would need to upload them and then download them on desktop and run the script and then it syncs the changed photos?

Yeah for this to work you'd need to have a copy of all your photos on the PC. It's unfortunately quite a manual process and certainly not for everyone.

Think of it as an excuse to curate an offline version of your photo library.

1. I'll copy photos to PC and add/sort them to various albums in my main photo library. I note down which albums have changed.
2. Go to cmd, type cd /path/to/photos, and type ente-convert /path/to/output.
3. Assuming path/to/output contains existing files, it'll only process the new photos.
4. Drag and drop those changed albums back into Ente. It does a good job of de-duplication so will only upload the new photos.

Deleting photos is more of a pain as my script doesn't handle that, though as I type this I realise it would be easily possible, so I'll add the functionality soon.

[n3rdcub]

Should be possible via Termux if on android and maybe iOS via a-shell

[huntfx]

I've updated the script by the way, it handles deletions now and puts everything in a subfolder automatically.

It would be great if Ente added a post-upload hook that would allow users to modify the images/videos, but I'd imagine something like that would be a nightmare to add security for and make cross platform.

[stefanosweb]

Since a lot of people use a phone it would be better to find an application for that. The most convenient way I am thinking is an auto compression app that has a specific output folder and then choose to auto upload that folder through ente.

Example: https://play.google.com/store/apps/details?id=com.ab.autoresizer

[gabriele2000]

No no and again no.
Autocompression app, with (maybe) stupid parameters that you can't choose?

[KeSch]

+1 for a compression option

Compression and/or resizing would be great, to have a choice if you want to save your photos in original or resized/compressed quality.

@enteio since one of your developers said in your subreddit already 3 years ago that this is on your roadmap, please let us know what your current implementation plan is.

[vishnukvmd]

We will look into this once there's a clear path towards writing the original metadata into compressed items during download / export across all clients.

[KeSch]

Thanks and keep my fingers crossed 🤞

[humble-new-student-89]

Same here, but I request jpeg xl over avif. Reason is that the company and consortium behind avif (gooXX) is stopping lots of good things - for both avif and others (it booted out jpegxl from all its products - browser, os etc).

So in future, avif will not be as open as jpeg xl for any features - like gps exif metadata etc.

So, overall featureset wise and future proofing at same compression levels, jpeg xl is good.

[gabriele2000]

Everything would be solved by integrating an ffmpeg frontend and letting the user choose everything (with good defaults pre-set)

[kobus-v-schoor]

We will look into this once there's a clear path towards writing the original metadata into compressed items during download / export across all clients.

@vishnukvmd FWIW, I use exiftool to transfer image and video metadata across after compressing my photos and videos. Haven't run into any issues and it preserves (almost) everything across formats.

+1 Would love to see this feature added, at the moment I manually download, re-compress and upload which is a pain.

[maddada]

+1 for this request. I always use the "Data Saver" setting on Google Photos and I won't be able to move to Ente unless photo/video compression is available. Otherwise storage will fill up MUCH faster compared to on Google Photos.
Please add this soon!

[szszl0]

Any news form Devs?

[jorge2000x]

It's a missing feature; all that's needed is to add an opt-in option and use a newer algorithm, JXL is the most suitable. Nowadays we still use the old JPEG; I've been doing some conversions on my cold backups, converting from JPEG to AVIF (which is more efficient but I don't think it's ideal) reduced the size of most images from 3-5MB to... 250-500KB, Without losing much quality, except for camera noise (JPEGXL manages to preserve noise a little better). It's a huge difference in size; you could upload many more photos in the same space without losing much quality. Remember, this should be an opt-in option.

[gabriele2000]

I actually converted all of them to AVIF when transferring them from Google Photos, using a CQ of 18, which preserves everything visually, but in size there's a HUGE reduction.
We're talking about stuff that retains everything, except a 2% of quality maybe... it's an acceptable loss or a 80% of size reduction, even more depending on the case.

[chinkung]

It is 2026, any update on this feature.

[Grosbof]

Same asking over here. New phones have larger and larger sensors where, even with some configuration on the camera app, files sizes are larger and larger. Compression solve this problem while downsizing the photos with a perfectly and almost unnoticeable loss of quality.

[EndrII]

I also noticed that there's an archive feature, and it could be improved. Essentially, users could upload their old photos and videos to the archive—or, for example, have them uploaded after, say, a month (automatically)—and everything that ends up in the archive would be compressed to a readable level sufficient for memories. For example, videos up to 720p or full HD (without fps loss) and photos up to 2K.
And, of course, it would be possible to choose the compression level.

[gabriele2000]

To archive something means to store it in the best futureproof format, which means FFV1 for videos (lossless) and PNG for images (lossless).

So no, let's not do it in that section please.

[r3lativo]

I was looking for a separated solution and I found out FFShare: however as the name suggests it only compresses one file at a time that is sent through the app via sharing feature.

Looking for a way to compress locally, I was able to set up a routine with Termux, running a bash script to compress videos and images and sending them to a specific folder. I was able to compress 5.5GB of files to only 2.2GB (images to 85% quality, videos set to 28 on ffmpeg compression), while also having the option to remove Exif data and GPS data. Ente also offers upload via CLI, but i didn't try it, neither via computer nor phone.

This approach is not optimal, but it leaves room for a better solution. I expect that locally compressing right away might create problems, so a nightly local routine could work?

[notAunty]

Same here, would like to have an offline optimized copy kept on device when I use the "Free up storage" option, just like the iCloud Photos integration on iPhone Photos app. When user revisit the (locally) deleted photos, and try to zoom in on it, the full-sized image would then be loaded.

I've created an initial code merge request here: #9190

[Grosbof]

Spot on Endrll

[notAunty]

I see, thanks for clarifying. Both features is important, in my opinion, given 4k HDR10+ or even 8k videos are coming soon.

[EndrII]

@notAunty Sounds like the Ente Photos already have similar function that you described
see https://ente.io/help/photos/faq/backup-and-sync#optimize-iphone-storage

[notAunty]

@EndrII
That's for people who use iCloud photos. I don't think many have both subscriptions together.

What I'm describing replicates the iCloud Photo feature, where instead of deleting local copies of backed up photos outright, it keeps an optimized version on iOS, Android (Google photos don't have this feature) and others.

In other words, this just brings iCloud photos feature parity to ente-only users on iOS. And improve the Android experience.

PS. Given the long standing of this Discussion, I don't think what I'm describing would see the light of day. I might just fork the project, and implement it myself client-side.

[r3lativo]

I'll share here some of the difficulties I found when I tried to do it locally.

Retaining HDR and motion photos after compression was not feasible for me.

Another thing to keep in mind is (for Android) folder permissions, i.e. in my case saving images to a folder which is not DCIM/Camera inhibits the system to also maintain the actual time and date, and an Ente backup would result in photos with backup time as the associated time. This does not always happen, I had no problem with another smartphone.

[gordielachance]

Same here. That would really make the difference.
I need a cloud space to preview my photos, not to do a full high resolution backup (+ I can't afford it).

My ideal uploader

1. define a watch folder (Ente does already this)
2. add rules to declare which files/folders should be ignored (maybe through a .enteignore file, just like a .gitignore does for git)
3. define preprocess settings for both images and videos (maximum resolution, maximum compression)

It would seems logic that the preprocessor would create a processed subfolder within the watched folder; and that the real sync would be done based on that subfolder.

Then I could finally get rid of Google Photos and not having to code my own tool.

Thanks a lot.

[EndrII]

It's best to avoid creating duplicates. Store the hash or ID of the original in the compressed video or photo, so that the compressed version is stored in the cloud and the original is stored on the device. Duplicates will cause confusion or inconsistency, and they also open the door to logical bugs.

[iadaz]

Regarding being able to ignore certain files/folders (gitignore style) I created a feature request for this here: #2878

[manquetin]

+1 for compression option

[boesemar]

+1 Really needed feature to be able to move from google photos! This saves a lot of storage!

[DavinKaru]

Bump. This is the deal breaker that's keeping me from swapping from Google Photos to Ente!

I take a lot of pictures, but I very rarely need something in full resolution (if I did, they'd be stored on Drive, not photos gallery)..

[PedroC88]

Please!

[PedroC88]

I installed a self hosted instance to test it and only uploaded my most recent photos that I already had on my phone, that took 11GB out of my self-assigned 100Gb. At the original sizes it would be unsustainable to migrate from Google Photos (which is what I want to do).

[SourLemonJuice]

I'm using a Google Pixel phone, the video feature of its camera will always record in 20+ mbps bitrate. A one minute video costs 150MB of storage on my phone.
I know it's not the Ente's fault, but I'm still unclear on which workflow is the best for video backups. As for the Ente, it is hard to copy my existing videos onto the 50+10GB cloud :[

[PedroC88]

Yeah, I have the same issue. I looked at the settings on my phone and, even on the lowest settings, media is just too large to sustain ente uncompressed as my permanent backup.

I really hope ente comes up with a solution.

[PedroC88]

If Ente is reading this, if you guys can provide some architectural guidance on how this should/would be implemented, I can attempt to do it, I just don’t know enough about the code structure to try this without some guidance.

[PedroC88]

Here's a sketch I put together quickly to get this conversation started if possible (also a mock up of what the screen might look like).

The idea is that the client would generate a transcoded/compressed copy of the media and then upload that to the server. The server should accept two hashes for the original and transcoded files just for validation and internal logic but, if the user is pushing transcoded media, only that copy would be uploaded to the storage, effectively losing the original once it's removed from the device (this could be revisited in the future to maybe keep both files, but this would a least make this work as Google Photos).

[gordielachance]

Hi, I won't renew my subscription unless I see this feature. Sorry, not handy enough currently.

[enteio]

Hi,  Thank you for the feedback. I have shared it with our dev team and they have taken it into consideration. If there is anything else you need help with, please reach out. Best, Pratty If you like ente, please consider leaving a review on https://play.google.com/store/apps/details?id=io.ente.photos , https://apps.apple.com/us/app/ente-photos/id1542026904 or https://alternativeto.net/software/ente/about/ .

…

---- on Wed, 13 May 2026 21:27:35 +0530 "Pedro ***@***.***> wrote ---- Here's a sketch I put together quickly to get this conversation started if possible (also a mock up of what the screen might look like). The idea is that the client would generate a transcoded/compressed copy of the media and then upload that to the server. The server should accept two hashes for the original and transcoded files just for validation and internal logic but, if the user is pushing transcoded media, only that copy would be uploaded to the storage, effectively losing the original once it's removed from the device (this could be revisited in the future to maybe keep both files, but this would a least make this work as Google Photos). https://github.com/user-attachments/assets/7f440790-c8cb-499b-a5cb-a7feb1cc5276 https://github.com/user-attachments/assets/4f2c67f8-a86b-4fca-a65a-556ad3d82f58 — Reply to this email directly, #555 (reply in thread) , or https://github.com/notifications/unsubscribe-auth/A4HZ5FQDUILGB7Z5R3A5VUL42SLO7AVCNFSM6AAAAABONIAIT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOJQG4YTONY . Triage notifications on the go with GitHub Mobile for https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned.