immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 12 Packages Projects Releases 10 Wiki Activity

[Feature]: Add option to optimize uploaded images automatically #523

New Issue
Closed
opened 2026-02-04 21:04:32 +03:00 by OVERLORD · 52 comments
OVERLORD commented 2026-02-04 21:04:32 +03:00
Owner
Copy Link

Originally created by @DVerdeV on GitHub (Dec 28, 2022).

Feature detail

The vast majority of home users don't notice if any compression is applied to the image.

I have tested this with the ImageMagick tool on Linux and by changing the quality. Personally, I've started to notice it when I lower it to 35%. I think it is a good idea to add an option to compress images when uploading, as this would allow storing many, many more in the same space using a negligible amount of server usage.

According to tests I have done, a 5.8 MB image can be reduced to 350 KB (35% quality).

Platform

Server

Originally created by @DVerdeV on GitHub (Dec 28, 2022). ### Feature detail The vast majority of home users don't notice if any compression is applied to the image. I have tested this with the ImageMagick tool on Linux and by changing the quality. Personally, I've started to notice it when I lower it to 35%. I think it is a good idea to add an option to compress images when uploading, as this would allow storing many, many more in the same space using a negligible amount of server usage. According to tests I have done, a 5.8 MB image can be reduced to 350 KB (35% quality). ### Platform Server
OVERLORD commented 2026-02-04 21:04:41 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Dec 28, 2022):

Then if you want to retrieve the original file to print, you cannot do it anymore

@alextran1502 commented on GitHub (Dec 28, 2022): Then if you want to retrieve the original file to print, you cannot do it anymore
OVERLORD commented 2026-02-04 21:04:53 +03:00
Author
Owner
Copy Link

@DVerdeV commented on GitHub (Dec 28, 2022):

Then if you want to retrieve the original file to print, you cannot do it anymore

A small section could be added in the settings to adjust this compression and enable/disable it. Obviously, there are people who then print some stored photos, but for a user who takes a lot of photos, it might be better to be able to store a lot of them using less storage space.

Google Photos did this with their “high quality/storage saver” backup option. Find here what they have on their help page about that:
image

I think those are good dimensions for a print of a photograph and enough for albums, gifts, etc…

@DVerdeV commented on GitHub (Dec 28, 2022): > Then if you want to retrieve the original file to print, you cannot do it anymore A small section could be added in the settings to adjust this compression and enable/disable it. Obviously, there are people who then print some stored photos, but for a user who takes a lot of photos, it might be better to be able to store a lot of them using less storage space. Google Photos did this with their “high quality/storage saver” backup option. Find here what they have on their help page about that: ![image](https://user-images.githubusercontent.com/99612385/209868282-8ba15149-5c8e-4cfd-a142-a3daf50a6df3.png) I think those are good dimensions for a print of a photograph and enough for albums, gifts, etc…
OVERLORD commented 2026-02-04 21:04:58 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jan 15, 2023):

Closing this issue as it is not in scope of the project

@alextran1502 commented on GitHub (Jan 15, 2023): Closing this issue as it is not in scope of the project
OVERLORD commented 2026-02-04 21:05:10 +03:00
Author
Owner
Copy Link

@lpryszcz commented on GitHub (Oct 18, 2023):

Hi, I find this feature useful as well. But this can be done manually directly on the library.
Does immich store file size/md5 in the database? If image is compressed, this would change its size and hash, possibly breaking things.
Thank you!

btw, immich is amazing!

@lpryszcz commented on GitHub (Oct 18, 2023): Hi, I find this feature useful as well. But this can be done manually directly on the library. Does immich store file size/md5 in the database? If image is compressed, this would change its size and hash, possibly breaking things. Thank you! btw, immich is amazing!
OVERLORD commented 2026-02-04 21:05:17 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Oct 18, 2023):

@lpryszcz Immich stores file size and md5 in the database and use md5 to check for duplication.

@alextran1502 commented on GitHub (Oct 18, 2023): @lpryszcz Immich stores file size and md5 in the database and use md5 to check for duplication.
OVERLORD commented 2026-02-04 21:05:20 +03:00
Author
Owner
Copy Link

@WinnerOK commented on GitHub (Oct 21, 2023):

@lpryszcz would you be interested to collaborate and find a way to compressed already stored images at least manually server-side ?

I see the following possible options:

  1. (extremely hacky) - run a script that will compress existing images in-place and recalculate hash
  2. (better but more difficult) - implement an endpoint in server to compress input images or manually compress old images. Although this feature is somewhat requested in https://github.com/immich-app/immich/issues/165#issuecomment-1138042361 it might fall the same failth as the original issue: https://github.com/immich-app/immich/issues/165#issuecomment-1575164317

I suggest for us to try hacky ways to optimize a file storage and only after to try and create more or less stable PR to immich

Useful links: DB queries

@WinnerOK commented on GitHub (Oct 21, 2023): @lpryszcz would you be interested to collaborate and find a way to compressed already stored images at least manually server-side ? I see the following possible options: 1. (extremely hacky) - run a script that will compress existing images in-place and recalculate hash 2. (better but more difficult) - implement an endpoint in server to compress input images or manually compress old images. Although this feature is somewhat requested in https://github.com/immich-app/immich/issues/165#issuecomment-1138042361 it might fall the same failth as the original issue: https://github.com/immich-app/immich/issues/165#issuecomment-1575164317 I suggest for us to try hacky ways to optimize a file storage and only after to try and create more or less stable PR to immich Useful links: [DB queries](https://immich.app/docs/guides/database-queries)
OVERLORD commented 2026-02-04 21:05:34 +03:00
Author
Owner
Copy Link

@lpryszcz commented on GitHub (Oct 21, 2023):

I like the idea @WinnerOK .

I see the following possible options:

  1. (extremely hacky) - run a script that will compress existing images in-place and recalculate hash

This is also my favourite (at least for now).
The problem I see it that if we compress and update the db, it'll cause mobile client to upload the same photos again if they are not removed already.

  1. We could play directly with the client (app) so it uploads compressed/reduced images (similar to "the other" app).

The main question is, how stable is DB design? It makes little sense to develop something that will be broken with future releases (this is why #165 is on hold as far as I understand, right?).

@lpryszcz commented on GitHub (Oct 21, 2023): I like the idea @WinnerOK . > I see the following possible options: > 1. (extremely hacky) - run a script that will compress existing images in-place and recalculate hash This is also my favourite (at least for now). The problem I see it that if we compress and update the db, it'll cause mobile client to upload the same photos again if they are not removed already. 3. We could play directly with the client (app) so it uploads compressed/reduced images (similar to "the other" app). The main question is, how stable is DB design? It makes little sense to develop something that will be broken with future releases (this is why #165 is on hold as far as I understand, right?).
OVERLORD commented 2026-02-04 21:05:37 +03:00
Author
Owner
Copy Link

@WinnerOK commented on GitHub (Oct 21, 2023):

We could play directly with the client (app) so it uploads compressed/reduced images (similar to "the other" app).

If we do client-side compression and use hash of compressed file for dedup, then client will have to repeat compression to properly check for duplicates. This seems like a lot of work for client.

The original image in high-quality should still be available on user's device. Therefore, we should check for duplicates based on the original hash. (Keep in mind that current hashing is server sided, but it could become client sided at one time: https://github.com/immich-app/immich/issues/2567)

If we have to consider original file hash, then we have to make sure that hash in the DB is only used for deduplication and does not actually get verified afterwards (otherwise we have to store 2 hashes in the DB) then we could just store the original hash. @alextran1502 could you tell us if immich uses file hash anywhere except deduplication during upload?

If we would dive into server, we could also somewhat address the issue mentioned above (https://github.com/immich-app/immich/issues/1202#issuecomment-1366894485 ) by adding 2 configurations:
1. Upload quality: compressed or original. This speaks for itself.
2. If upload quality is original we can show a slider compress photos older than X days/years/never and also add a checkmark never compress favourite media

This way people who have limited storage can give up on quality, but still preserve their favourite moments as is

@WinnerOK commented on GitHub (Oct 21, 2023): > We could play directly with the client (app) so it uploads compressed/reduced images (similar to "the other" app). If we do client-side compression and use hash of compressed file for dedup, then client will have to repeat compression to properly check for duplicates. This seems like a lot of work for client. The original image in high-quality should still be available on user's device. Therefore, we should check for duplicates based on the original hash. (Keep in mind that current hashing is server sided, but it could become client sided at one time: https://github.com/immich-app/immich/issues/2567) If we have to consider original file hash, then we have to make sure that hash in the DB is only used for deduplication and does not actually get verified afterwards (otherwise we have to store 2 hashes in the DB) then we could just store the original hash. @alextran1502 could you tell us if immich uses file hash anywhere except deduplication during upload? --- If we would dive into server, we could also somewhat address the issue mentioned above (https://github.com/immich-app/immich/issues/1202#issuecomment-1366894485 ) by adding 2 configurations: 1. Upload quality: `compressed` or `original`. This speaks for itself. 2. If upload quality is `original` we can show a slider `compress photos older than X days/years/never` and also add a checkmark `never compress favourite media` This way people who have limited storage can give up on quality, but still preserve their favourite moments as is
OVERLORD commented 2026-02-04 21:05:44 +03:00
Author
Owner
Copy Link

@aviv926 commented on GitHub (Oct 23, 2023):

I see someone started something about it here #1242

also someone made something that already work with immich

https://gist.github.com/JamesCullum/6604e504318dd326a507108f59ca7dcd

@aviv926 commented on GitHub (Oct 23, 2023): I see someone started something about it here #1242 also someone made something that already work with immich [https://gist.github.com/JamesCullum/6604e504318dd326a507108f59ca7dcd](https://gist.github.com/JamesCullum/6604e504318dd326a507108f59ca7dcd)
OVERLORD commented 2026-02-04 21:05:54 +03:00
Author
Owner
Copy Link

@athornfam2 commented on GitHub (Nov 8, 2023):

I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I

@athornfam2 commented on GitHub (Nov 8, 2023): I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I
OVERLORD commented 2026-02-04 21:05:58 +03:00
Author
Owner
Copy Link

@aviv926 commented on GitHub (Nov 14, 2023):

I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I

Unfortunately according to the developer of the project this is not a feature that will be added in the near future or at all

In my reply above, I showed how it is possible to still apply compression to details, but it seems that this is something that affects the entire library and cannot be selected per user

@aviv926 commented on GitHub (Nov 14, 2023): > I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I Unfortunately [according to the developer](https://github.com/immich-app/immich/pull/1242#issuecomment-1368285255) of the project this is not a feature that will be added in the near future or at all In my reply above, I showed how it is possible to still apply compression to details, but it seems that this is something that affects the entire library and cannot be selected per user
OVERLORD commented 2026-02-04 21:06:01 +03:00
Author
Owner
Copy Link

@athornfam2 commented on GitHub (Nov 14, 2023):

I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I

Unfortunately according to the developer of the project this is not a feature that will be added in the near future or at all

In my reply above, I showed how it is possible to still apply compression to details, but it seems that this is something that affects the entire library and cannot be selected per user

it's unfortunate as it could save a tremendous amount of space for those of us that don't need original quality on a remote server especially if the photo is cached locally. I guess I'll have to look into a solution for that. Do you know of any that have been created by other users?

@athornfam2 commented on GitHub (Nov 14, 2023): > > I'm interested in an on/off switch as well. My family and I don't particularly see the point in anything larger than 8MP or 12MP anyways. I > > Unfortunately [according to the developer](https://github.com/immich-app/immich/pull/1242#issuecomment-1368285255) of the project this is not a feature that will be added in the near future or at all > > In my reply above, I showed how it is possible to still apply compression to details, but it seems that this is something that affects the entire library and cannot be selected per user it's unfortunate as it could save a tremendous amount of space for those of us that don't need original quality on a remote server especially if the photo is cached locally. I guess I'll have to look into a solution for that. Do you know of any that have been created by other users?
OVERLORD commented 2026-02-04 21:06:04 +03:00
Author
Owner
Copy Link

@AngelaDMerkel commented on GitHub (Sep 16, 2024):

My issue #8907 was recently closed as a duplicate of this unfortunately (also) closed issue. I think this makes it pretty clear that the team won't work on this issue. It would be a great solution to be able to toggle with users even if only for video. Images occupy a miniscule amount of space relatively speaking, but a lot of my users are uploading giant 4K videos don't really benefit from their inflated bitrates and my machine is already doing the work to convert to proxies for viewing. I understand it's a against the spirit of Immich as the developers see it, but it would go a very long way to making this a much more versatile solution

@AngelaDMerkel commented on GitHub (Sep 16, 2024): My issue [#8907](https://github.com/immich-app/immich/discussions/8907) was recently closed as a duplicate of this unfortunately (also) closed issue. I think this makes it pretty clear that the team won't work on this issue. It would be a great solution to be able to toggle with users even if only for video. Images occupy a miniscule amount of space relatively speaking, but a lot of my users are uploading giant 4K videos don't really benefit from their inflated bitrates and my machine is already doing the work to convert to proxies for viewing. I understand it's a against the spirit of Immich as the developers see it, but it would go a very long way to making this a much more versatile solution
OVERLORD commented 2026-02-04 21:06:18 +03:00
Author
Owner
Copy Link

@Chuckame commented on GitHub (Nov 13, 2024):

@alextran1502 finally, does the incoming new feature of workflows could fit this need, as we could be able to apply a pipeline over the imported photos?

@Chuckame commented on GitHub (Nov 13, 2024): @alextran1502 finally, does the incoming new feature of workflows could fit this need, as we could be able to apply a pipeline over the imported photos?
OVERLORD commented 2026-02-04 21:06:24 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Nov 13, 2024):

Potentially, I think it will fir with custom plug in

@alextran1502 commented on GitHub (Nov 13, 2024): Potentially, I think it will fir with custom plug in
OVERLORD commented 2026-02-04 21:06:27 +03:00
Author
Owner
Copy Link

@bverkron commented on GitHub (Dec 2, 2024):

I think this feature is very viable for certain use-cases and workflows, but it may not be a good fit for the core of what Immich is. This is said as someone who really wants this feature!

Immich has grown immensely in popularity and functionality (and for good reason!) and with that comes more and more use-cases and workflows. Personally I would love this feature since currently I'm trying to use Immich as a photo / video sharing platform for close family members. I have 80,000 photos / videos in my Lighroom catalog and need a good way to share those with the family, but I am not expecting Immich to take over all that content as the main storage / organization system. Rather it's a glorified web gallery so my family can gain access to our family photos and they're not "locked" into my LR catalog and I don't have to eat up all my cloud storage and rely on Adobe.

Thus, I don't want / need Immich to hold the original files, backup, etc just "web copies" that family can easily access. Some of my original video files are massive as well as they are shot in 4K 60 on a Canon mirrorless. So 15 second clip can be around 0.5 of a GB.

Would love to see a workflow that would allow for this kind of thing and I think workflows would open up a huge amount of possibility for all kinds of cases without bugging down or diluting the core development and making the whole product a spaghetti mess trying to accommodate everyones specific use cases.

@bverkron commented on GitHub (Dec 2, 2024): I think this feature is very viable for certain use-cases and workflows, but it may not be a good fit for the core of what Immich is. This is said as someone who really wants this feature! Immich has grown immensely in popularity and functionality (and for good reason!) and with that comes more and more use-cases and workflows. Personally I would _love_ this feature since currently I'm trying to use Immich as a photo / video sharing platform for close family members. I have 80,000 photos / videos in my Lighroom catalog and need a good way to share those with the family, but I am not expecting Immich to take over all that content as the main storage / organization system. Rather it's a glorified web gallery so my family can gain access to our family photos and they're not "locked" into my LR catalog and I don't have to eat up all my cloud storage and rely on Adobe. Thus, I don't want / need Immich to hold the original files, backup, etc just "web copies" that family can easily access. Some of my original video files are massive as well as they are shot in 4K 60 on a Canon mirrorless. So 15 second clip can be around 0.5 of a GB. Would love to see a workflow that would allow for this kind of thing and I think workflows would open up a huge amount of possibility for all kinds of cases without bugging down or diluting the core development and making the whole product a spaghetti mess trying to accommodate everyones specific use cases.
OVERLORD commented 2026-02-04 21:06:37 +03:00
Author
Owner
Copy Link

@lpryszcz commented on GitHub (Dec 2, 2024):

I'd second to that! In addition, my phone camera saves "lowly" compressed photos in jpeg (~8 MB each) which could be easily compressed to reduce their size 10x. So for me, having option to "reduce" file size before sending it to the server would be a great benefit.

@lpryszcz commented on GitHub (Dec 2, 2024): I'd second to that! In addition, my phone camera saves "lowly" compressed photos in jpeg (~8 MB each) which could be easily compressed to reduce their size 10x. So for me, having option to "reduce" file size before sending it to the server would be a great benefit.
OVERLORD commented 2026-02-04 21:06:42 +03:00
Author
Owner
Copy Link

@rdymade commented on GitHub (Dec 10, 2024):

Thus, I don't want / need Immich to hold the original files, backup, etc just "web copies" that family can easily access. Some of my original video files are massive as well as they are shot in 4K 60 on a Canon mirrorless. So 15 second clip can be around 0.5 of a GB.

If i undetstand this correctly you could just link your originals to immich via an external library. This way it is not the main storage but still does the video/image transcoding. Basically exactly what you want it to do really.

@rdymade commented on GitHub (Dec 10, 2024): > Thus, I don't want / need Immich to hold the original files, backup, etc just "web copies" that family can easily access. Some of my original video files are massive as well as they are shot in 4K 60 on a Canon mirrorless. So 15 second clip can be around 0.5 of a GB. If i undetstand this correctly you could just link your originals to immich via an external library. This way it is not the main storage but still does the video/image transcoding. Basically exactly what you want it to do really.
OVERLORD commented 2026-02-04 21:06:55 +03:00
Author
Owner
Copy Link

@bverkron commented on GitHub (Dec 11, 2024):

That could work for some workflows but mine is to publish from Lightroom to Immich using a plugin. The main reason for this is that I have thousands of videos in my collection and don't want all of them in Immich and cannot use the current file structure to filter them out on disk. I have smart collections in Lightroom that filter down to just specific videos automatically (say 2 star and above only with specific people or other keywords) and only publishes those to Immich.

Lightroom can technically do conversions first before sending to Immich (instead of sending the full size original) but it can only do a max of 1080p (I want 1440p) and only h.264 non-HDR (I want HDR video in Immich). So I'm forced to send the full size video file which can sometimes be massive.

@bverkron commented on GitHub (Dec 11, 2024): That could work for some workflows but mine is to publish from Lightroom to Immich using a plugin. The main reason for this is that I have thousands of videos in my collection and don't want all of them in Immich and cannot use the current file structure to filter them out on disk. I have smart collections in Lightroom that filter down to just specific videos automatically (say 2 star and above only with specific people or other keywords) and only publishes those to Immich. Lightroom can technically do conversions first before sending to Immich (instead of sending the full size original) but it can only do a max of 1080p (I want 1440p) and only h.264 non-HDR (I want HDR video in Immich). So I'm forced to send the full size video file which can sometimes be massive.
OVERLORD commented 2026-02-04 21:07:07 +03:00
Author
Owner
Copy Link

@happyTonakai commented on GitHub (Jan 20, 2025):

I need that feature because my iPhone gives me a 10MB file for a screenshot!

@happyTonakai commented on GitHub (Jan 20, 2025): I need that feature because my iPhone gives me a 10MB file for a screenshot!
OVERLORD commented 2026-02-04 21:07:12 +03:00
Author
Owner
Copy Link

@miguelangel-nubla commented on GitHub (Jan 20, 2025):

Made this to solve the problem:
https://github.com/miguelangel-nubla/immich-upload-optimizer.

@miguelangel-nubla commented on GitHub (Jan 20, 2025): Made this to solve the problem: https://github.com/miguelangel-nubla/immich-upload-optimizer.
OVERLORD commented 2026-02-04 21:07:24 +03:00
Author
Owner
Copy Link

@rodrigoGA commented on GitHub (Feb 5, 2025):

I am very interested in this feature. I haven't fully familiarized myself with Immich, but I believe that every version generated of an image should be stored along with additional metadata (hash, dimensions, size, etc.). If not, it would require a change in the backend without needing modifications to the clients. This approach is flexible, even for an architecture that handles different sizes for various devices.

I’ve been reviewing the issues and noticed that this feature is requested multiple times—possibly the most requested one. Moreover, in most cases this application is used on a home server shared by several family members, where managing storage space is a crucial aspect of any image storage software.

In my view, this functionality should be a core part of the system rather than an add-on like AI features. Although I haven't contributed to Immich yet, I'd be happy to collaborate on developing this feature.

Considering that, as @alextran1502 mentioned, this idea was closed because it was deemed out of scope for the project, I’d like to ask if it might be reconsidered or if you believe it could be useful, especially given that some progress has already been made (@miguelangel-nubla ). Also, I noticed that Workflows are on your roadmap; is that the planned solution for this case?

@rodrigoGA commented on GitHub (Feb 5, 2025): I am very interested in this feature. I haven't fully familiarized myself with Immich, but I believe that every version generated of an image should be stored along with additional metadata (hash, dimensions, size, etc.). If not, it would require a change in the backend without needing modifications to the clients. This approach is flexible, even for an architecture that handles different sizes for various devices. I’ve been reviewing the issues and noticed that this feature is requested multiple times—possibly the most requested one. Moreover, in most cases this application is used on a home server shared by several family members, where managing storage space is a crucial aspect of any image storage software. In my view, this functionality should be a core part of the system rather than an add-on like AI features. Although I haven't contributed to Immich yet, I'd be happy to collaborate on developing this feature. Considering that, as @alextran1502 mentioned, this idea was closed because it was deemed out of scope for the project, I’d like to ask if it might be reconsidered or if you believe it could be useful, especially given that some progress has already been made (@miguelangel-nubla ). Also, I noticed that Workflows are on your roadmap; is that the planned solution for this case?
OVERLORD commented 2026-02-04 21:07:31 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Feb 5, 2025):

We have a fundamental 'rule' to not change the original file ever, in order to significantly minimize the chance of data corruption bugs. The workflows feature will eventually also involve plugin support, and then this can be implemented with a third party plugin, but we won't be adding support for it to the Immich core.

@bo0tzz commented on GitHub (Feb 5, 2025): We have a fundamental 'rule' to not change the original file ever, in order to significantly minimize the chance of data corruption bugs. The workflows feature will eventually also involve plugin support, and then this can be implemented with a third party plugin, but we won't be adding support for it to the Immich core.
OVERLORD commented 2026-02-04 21:07:45 +03:00
Author
Owner
Copy Link

@aviv926 commented on GitHub (Feb 5, 2025):

You can check out this project, it's not official by the immich developers but it does the job. I'm sure the developer would be happy to get help with the development from other people.

https://github.com/miguelangel-nubla/immich-upload-optimizer

@aviv926 commented on GitHub (Feb 5, 2025): You can check out this project, it's not official by the immich developers but it does the job. I'm sure the developer would be happy to get help with the development from other people. https://github.com/miguelangel-nubla/immich-upload-optimizer
OVERLORD commented 2026-02-04 21:07:52 +03:00
Author
Owner
Copy Link

@djbel63 commented on GitHub (Feb 18, 2025):

You can check out this project, it's not official by the immich developers but it does the job. I'm sure the developer would be happy to get help with the development from other people.

https://github.com/miguelangel-nubla/immich-upload-optimizer

I just taked it as base for me.

`tasks:

  • name: jpeg-resize-compress
    command: convert {{.folder}}/{{.name}}.{{.extension}} -resize 1920x1920> -quality 50 {{.folder}}/{{.name}}-new.jpg && mv {{.folder}}/{{.name}}-new.jpg {{.folder}}/{{.name}}.{{.extension}}
    extensions:
    • jpeg
    • jpg
      `

With that, i can compress from 10mb jpeg (DSLR) to 200kb foto.

@djbel63 commented on GitHub (Feb 18, 2025): > You can check out this project, it's not official by the immich developers but it does the job. I'm sure the developer would be happy to get help with the development from other people. > > https://github.com/miguelangel-nubla/immich-upload-optimizer I just taked it as base for me. `tasks: - name: jpeg-resize-compress command: convert {{.folder}}/{{.name}}.{{.extension}} -resize 1920x1920\> -quality 50 {{.folder}}/{{.name}}-new.jpg && mv {{.folder}}/{{.name}}-new.jpg {{.folder}}/{{.name}}.{{.extension}} extensions: - jpeg - jpg ` With that, i can compress from 10mb jpeg (DSLR) to 200kb foto.
OVERLORD commented 2026-02-04 21:08:04 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Mar 24, 2025):

I wish immich implements this, 90%+ users don't need original size (50mp) photos at all.

@jorgeEF commented on GitHub (Mar 24, 2025): I wish immich implements this, 90%+ users don't need original size (50mp) photos at all.
OVERLORD commented 2026-02-04 21:08:08 +03:00
Author
Owner
Copy Link

@nijahplays commented on GitHub (Mar 29, 2025):

Even lossless compression would be nice. I like full quality images and having a bit of extra space as well.

@nijahplays commented on GitHub (Mar 29, 2025): Even lossless compression would be nice. I like full quality images and having a bit of extra space as well.
OVERLORD commented 2026-02-04 21:08:17 +03:00
Author
Owner
Copy Link

@AngelaDMerkel commented on GitHub (Mar 29, 2025):

@nijahplays I requested lossless JXL in a previous FR. It's against developer ethos but will be possible in a plugin down the line, which seems like a fair decision.

@AngelaDMerkel commented on GitHub (Mar 29, 2025): @nijahplays I requested lossless JXL in a previous FR. It's against developer ethos but will be possible in a plugin down the line, which seems like a fair decision.
OVERLORD commented 2026-02-04 21:08:24 +03:00
Author
Owner
Copy Link

@evanpacini commented on GitHub (Apr 26, 2025):

@nijahplays

Even lossless compression would be nice. I like full quality images and having a bit of extra space as well.

This. I have tons of PNGs that weren't compressed as much as they could. Would be handy if PNGs were losslessly compressed upon upload.

@evanpacini commented on GitHub (Apr 26, 2025): @nijahplays > Even lossless compression would be nice. I like full quality images and having a bit of extra space as well. This. I have tons of PNGs that weren't compressed as much as they could. Would be handy if PNGs were losslessly compressed upon upload.
OVERLORD commented 2026-02-04 21:08:32 +03:00
Author
Owner
Copy Link

@mcpeixoto commented on GitHub (May 26, 2025):

This totally makes sense to have as an option. 90% of users don’t need full-res originals on a home server, especially when most photos are never printed. Just having a toggle like “Storage Saver” with adjustable compression (or max resolution) would let people store way more without touching the original on the device.

@mcpeixoto commented on GitHub (May 26, 2025): This totally makes sense to have as an option. 90% of users don’t need full-res originals on a home server, especially when most photos are never printed. Just having a toggle like “Storage Saver” with adjustable compression (or max resolution) would let people store way more without touching the original on the device.
OVERLORD commented 2026-02-04 21:08:35 +03:00
Author
Owner
Copy Link

@szszl0 commented on GitHub (Jun 20, 2025):

@alextran1502 Most people dont print photos.. Why not let people decide if they want their photos compressed or not?

@szszl0 commented on GitHub (Jun 20, 2025): @alextran1502 Most people dont print photos.. Why not let people decide if they want their photos compressed or not?
OVERLORD commented 2026-02-04 21:08:38 +03:00
Author
Owner
Copy Link

@athornfam2 commented on GitHub (Jun 20, 2025):

@alextran1502 Most people dont print photos.. Why not let people decide if they want their photos compressed or not?

It's interesting this topic is still being discussed 3 years later! Thankfully someone in the thread created an optimizer for our photos. I wish it would go back to existing ones though.

@athornfam2 commented on GitHub (Jun 20, 2025): > @alextran1502 Most people dont print photos.. Why not let people decide if they want their photos compressed or not? It's interesting this topic is still being discussed 3 years later! Thankfully someone in the thread created an optimizer for our photos. I wish it would go back to existing ones though.
OVERLORD commented 2026-02-04 21:08:41 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Jun 20, 2025):

I just use an external album in immich and compress the photos/videos in the folder with a bash script using ffmpeg. I sync the photos to that folder with smbsync and that's it.. Still waiting till immich implements image resizing.

@jorgeEF commented on GitHub (Jun 20, 2025): I just use an external album in immich and compress the photos/videos in the folder with a bash script using ffmpeg. I sync the photos to that folder with smbsync and that's it.. Still waiting till immich implements image resizing.
OVERLORD commented 2026-02-04 21:08:53 +03:00
Author
Owner
Copy Link

@szszl0 commented on GitHub (Jun 20, 2025):

It's interesting this topic is still being discussed 3 years later! Thankfully someone in the thread created an optimizer for our photos. I wish it would go back to existing ones though.

Yeah, I have seen it, didnt use it yet. But it doest work for photos that are already in our library right? Also using third party software for that increases number of places where something could break. I need the user experience to be as smooth as possible becouse my wife is my main customer..

I just use an external album in immich and compress the photos/videos in the folder with a bash script using ffmpeg. I sync the photos to that folder with smbsync and that's it.. Still waiting till immich implements image resizing.

Yeah, I guess it would be doable for me but I'd prefer something simpler for my wife

@szszl0 commented on GitHub (Jun 20, 2025): > It's interesting this topic is still being discussed 3 years later! Thankfully someone in the thread created an optimizer for our photos. I wish it would go back to existing ones though. Yeah, I have seen it, didnt use it yet. But it doest work for photos that are already in our library right? Also using third party software for that increases number of places where something could break. I need the user experience to be as smooth as possible becouse my wife is my main customer.. > I just use an external album in immich and compress the photos/videos in the folder with a bash script using ffmpeg. I sync the photos to that folder with smbsync and that's it.. Still waiting till immich implements image resizing. Yeah, I guess it would be doable for me but I'd prefer something simpler for my wife
OVERLORD commented 2026-02-04 21:09:08 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Jun 20, 2025):

Yeah, I guess it would be doable for me but I'd prefer something simpler for my wife

It's simple and she doesn't have to do anything:
Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all.

@jorgeEF commented on GitHub (Jun 20, 2025): > Yeah, I guess it would be doable for me but I'd prefer something simpler for my wife It's simple and she doesn't have to do anything: Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all.
OVERLORD commented 2026-02-04 21:09:14 +03:00
Author
Owner
Copy Link

@rodrigoGA commented on GitHub (Jun 20, 2025):

It's simple and she doesn't have to do anything:
Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all.

These doubts arise if the script runs directly in the Immich folder:

  • How does Immich know an image is already on the server and avoid reuploading it?
  • If I have the mobile app installed, will it resync photos I’ve already uploaded?
  • What happens if I connect two different mobile apps to the same server, will photos get duplicated or deduplicated correctly?
  • Does deduplication rely on MD5, file size, timestamp, or some EXIF metadata?
  • If I edit a photo locally after it’s uploaded, how does Immich handle that ?
@rodrigoGA commented on GitHub (Jun 20, 2025): > It's simple and she doesn't have to do anything: > Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all. These doubts arise if the script runs directly in the Immich folder: - How does Immich know an image is already on the server and avoid reuploading it? - If I have the mobile app installed, will it resync photos I’ve already uploaded? - What happens if I connect two different mobile apps to the same server, will photos get duplicated or deduplicated correctly? - Does deduplication rely on MD5, file size, timestamp, or some EXIF metadata? - If I edit a photo locally after it’s uploaded, how does Immich handle that ?
OVERLORD commented 2026-02-04 21:09:18 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Jun 20, 2025):

It's simple and she doesn't have to do anything:
Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all.

These doubts arise if the script runs directly in the Immich folder:

  • How does Immich know an image is already on the server and avoid reuploading it?
  • If I have the mobile app installed, will it resync photos I’ve already uploaded?
  • What happens if I connect two different mobile apps to the same server, will photos get duplicated or deduplicated correctly?
  • Does deduplication rely on MD5, file size, timestamp, or some EXIF metadata?
  • If I edit a photo locally after it’s uploaded, how does Immich handle that ?

Immich handles external albums in a different way than its internal albums. It scans new files in the external album periodically and adds the new files to the database, you can set read-only for immich in that external album so it works just as a read only gallery.

This is useful if you want to access your photos from any other app or just a file browser as immich isn't the one managing your album. Everything else you should handle it manually.

Immich won't sync new photos to the external album, it only sync photos to its internal albums so if you choose to use an external album you shouldn't sync photos within immich or you'll end up with you album splitted in different locations.

Resumed: I only use immich as a photo gallery viewer and that's all I need from it. I keep managing my photos/videos through other apps.

@jorgeEF commented on GitHub (Jun 20, 2025): > > It's simple and she doesn't have to do anything: > > Automate the sync from her phone to the folder and that's it.. set the bash script to run every hour or so and you won't miss immich integrated sync at all. > > These doubts arise if the script runs directly in the Immich folder: > - How does Immich know an image is already on the server and avoid reuploading it? > - If I have the mobile app installed, will it resync photos I’ve already uploaded? > - What happens if I connect two different mobile apps to the same server, will photos get duplicated or deduplicated correctly? > - Does deduplication rely on MD5, file size, timestamp, or some EXIF metadata? > - If I edit a photo locally after it’s uploaded, how does Immich handle that ? Immich handles external albums in a different way than its internal albums. It scans new files in the external album periodically and adds the new files to the database, you can set read-only for immich in that external album so it works just as a read only gallery. This is useful if you want to access your photos from any other app or just a file browser as immich isn't the one managing your album. Everything else you should handle it manually. Immich won't sync new photos to the external album, it only sync photos to its internal albums so if you choose to use an external album you shouldn't sync photos within immich or you'll end up with you album splitted in different locations. Resumed: I only use immich as a photo gallery viewer and that's all I need from it. I keep managing my photos/videos through other apps.
OVERLORD commented 2026-02-04 21:09:21 +03:00
Author
Owner
Copy Link

@AngelaDMerkel commented on GitHub (Jun 23, 2025):

Resumed: I only use immich as a photo gallery viewer and that's all I need from it. I keep managing my photos/videos through other apps.

immich is so much more than that and already does a massive amount of background work to make it possible to view, manage and store images. The smaller versions being transcoded for actually serving to devices are effectively what this FR is about. I would love everything to be transcoded losslessly into an easier storage format, but in lieu of that I'd love to transcode a copy of my family's 100s of gigabytes of videos and photos they never see again into something smaller. I am easily storing over 1TB of images for them which could be 100GB without them noticing a difference.

@AngelaDMerkel commented on GitHub (Jun 23, 2025): > Resumed: I only use immich as a photo gallery viewer and that's all I need from it. I keep managing my photos/videos through other apps. immich is so much more than that and already does a massive amount of background work to make it possible to view, manage and store images. The smaller versions being transcoded for actually serving to devices are effectively what this FR is about. I would love everything to be transcoded losslessly into an easier storage format, but in lieu of that I'd love to transcode a copy of my family's 100s of gigabytes of videos and photos they never see again into something smaller. I am easily storing over 1TB of images for them which could be 100GB without them noticing a difference.
OVERLORD commented 2026-02-04 21:09:29 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Jun 23, 2025):

I would love everything to be transcoded losslessly into an easier storage format, but in lieu of that I'd love to transcode a copy of my family's 100s of gigabytes of videos and photos they never see again into something smaller. I am easily storing over 1TB of images for them which could be 100GB without them noticing a difference.

That's fine if that's your salsa, but I don't think anybody here is asking to transcode/optimize every immich user galleries without being asked to do so, this should be clearly an optional feature that we're sure most people will use.

For me the thing goes this way: If I can't secure backups of a pretty large photos/videos gallery it's like having no gallery at all, so I prioritize something that I can handle knowing that I will always have those valuable photos/videos even if they aren't the best quality possible.

Cheers.

@jorgeEF commented on GitHub (Jun 23, 2025): > > I would love everything to be transcoded losslessly into an easier storage format, but in lieu of that I'd love to transcode a copy of my family's 100s of gigabytes of videos and photos they never see again into something smaller. I am easily storing over 1TB of images for them which could be 100GB without them noticing a difference. That's fine if that's your salsa, but I don't think anybody here is asking to transcode/optimize every immich user galleries without being asked to do so, this should be clearly an optional feature that we're sure most people will use. For me the thing goes this way: If I can't secure backups of a pretty large photos/videos gallery it's like having no gallery at all, so I prioritize something that I can handle knowing that I will always have those valuable photos/videos even if they aren't the best quality possible. Cheers.
OVERLORD commented 2026-02-04 21:09:33 +03:00
Author
Owner
Copy Link

@zolakt commented on GitHub (Jul 2, 2025):

Personally, I'd like all my images to be compressed, since I never print them. But I get that some people don't want that.

So why not make this a one-time job, instead of intercepting all uploads? You select the pictures you want, click a compress button, and that is it. It overwrites existing images, recalculates the hash and updates the db. Yes, you would possibly need to store both hashes in the db, but why is that a big deal? I don't get why is this shot down by the devs, when clearly a huge section of user base asks for this feature.

The plugin approach mentioned here, and Miguel's proxy are fine, but they don't offer granularity. It's all or nothing. And you will find people on both ends on the spectrum that have a problem with this.

99% of users storing family photos need maybe 10% of them to be printable, at most. Others are either poor photos, poor cameras, gazillion almost the same pictures of the cat... No one needs all of those to be printable. On the other end of the spectrum you have the pros, with an inverse ratio, but even they have at least 10% of cat pictures they never mean to print. A one-time job would offer granularity and solve all use cases.

Btw. for the "storage is cheap" argument: Yeah it is, but if you want to do a proper 3-2-1 backup strategy (and you definetly should since you are going the self-hosting route), that is two disks and a cloud bucket subscription... it adds up. On the other hand you could be using 10x less space without any visual difference.

And don't get me wrong, I'm not trying to vent here or belittle the effort. This is a fantastic project, one of the best self-hosted ones out there. I just think you are being too opinionated about this particual feature, that would solve a lot of things for a lot of users.

On another note: does anyone have a suggestion on how to deal with photos that have already been imported? How to manually compress them without breaking anything? I really can't spare the amount of time it would take me to reupload and retag everything.

Btw. I won't be switching back to it, but just for reference, Google Photos has this as a one-shot action, for each photo. You have that option in the context menu. And that is clearly the project you are trying to compete with. So I don't really get this strongly oppinionated NO. Your users are asking for it, your competitors already have it...

@zolakt commented on GitHub (Jul 2, 2025): Personally, I'd like all my images to be compressed, since I never print them. But I get that some people don't want that. So why not make this a one-time job, instead of intercepting all uploads? You select the pictures you want, click a compress button, and that is it. It overwrites existing images, recalculates the hash and updates the db. Yes, you would possibly need to store both hashes in the db, but why is that a big deal? I don't get why is this shot down by the devs, when clearly a huge section of user base asks for this feature. The plugin approach mentioned here, and Miguel's proxy are fine, but they don't offer granularity. It's all or nothing. And you will find people on both ends on the spectrum that have a problem with this. 99% of users storing family photos need maybe 10% of them to be printable, at most. Others are either poor photos, poor cameras, gazillion almost the same pictures of the cat... No one needs all of those to be printable. On the other end of the spectrum you have the pros, with an inverse ratio, but even they have at least 10% of cat pictures they never mean to print. A one-time job would offer granularity and solve all use cases. Btw. for the "storage is cheap" argument: Yeah it is, but if you want to do a proper 3-2-1 backup strategy (and you definetly should since you are going the self-hosting route), that is two disks and a cloud bucket subscription... it adds up. On the other hand you could be using 10x less space without any visual difference. And don't get me wrong, I'm not trying to vent here or belittle the effort. This is a fantastic project, one of the best self-hosted ones out there. I just think you are being too opinionated about this particual feature, that would solve a lot of things for a lot of users. On another note: does anyone have a suggestion on how to deal with photos that have already been imported? How to manually compress them without breaking anything? I really can't spare the amount of time it would take me to reupload and retag everything. Btw. I won't be switching back to it, but just for reference, Google Photos has this as a one-shot action, for each photo. You have that option in the context menu. And that is clearly the project you are trying to compete with. So I don't really get this strongly oppinionated NO. Your users are asking for it, your competitors already have it...
OVERLORD commented 2026-02-04 21:09:36 +03:00
Author
Owner
Copy Link

@Red007Master commented on GitHub (Aug 16, 2025):

Look, I can "kinda" understand photos argument (while it is still wrong).

But it makes absolutely no sense when we talk abut video.

I have 4min 600mb full-HD video in shitty quality, I can easily drop it to 50mbs, without any (perceivable) quality loss, and believe me or not - I will nor anybody else will be printing video.

Disappointing decision driven not by inability, hardness or lack of resourced but by inflated ego and "I know better".

Unfortunately I will need to come-up with some hacky solution for this problem.

Edit: If somebody will need it:
Here FFmpeg command that I use on my videos, -map_metadata 0 lets you transfer metadata from original video to it's compressed version.

ffmpeg -i INPUT_FILE -c:v libx264 -crf 32 -preset medium -map_metadata 0 -c:a aac -b:a 128k -movflags +faststart -profile:v baseline -level 3.0 OUTPUT_FILE

@Red007Master commented on GitHub (Aug 16, 2025): Look, I can "kinda" understand photos argument (while it is still wrong). But it makes absolutely no sense when we talk abut video. I have 4min 600mb full-HD video in shitty quality, I can easily drop it to 50mbs, without any (perceivable) quality loss, and believe me or not - I will nor anybody else will be printing video. Disappointing decision driven not by inability, hardness or lack of resourced but by inflated ego and "I know better". Unfortunately I will need to come-up with some hacky solution for this problem. Edit: If somebody will need it: Here FFmpeg command that I use on my videos, `-map_metadata 0` lets you transfer metadata from original video to it's compressed version. `ffmpeg -i INPUT_FILE -c:v libx264 -crf 32 -preset medium -map_metadata 0 -c:a aac -b:a 128k -movflags +faststart -profile:v baseline -level 3.0 OUTPUT_FILE`
OVERLORD commented 2026-02-04 21:09:41 +03:00
Author
Owner
Copy Link

@szszl0 commented on GitHub (Aug 20, 2025):

@alextran1502 do you have any valid reason to ignore this crucial feature request?

@szszl0 commented on GitHub (Aug 20, 2025): @alextran1502 do you have any valid reason to ignore this crucial feature request?
OVERLORD commented 2026-02-04 21:09:52 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 20, 2025):

@szszl0 Yes I do, the design philosophy of Immich is to not touch and alter the original files.

@alextran1502 commented on GitHub (Aug 20, 2025): @szszl0 Yes I do, the design philosophy of Immich is to not touch and alter the original files.
OVERLORD commented 2026-02-04 21:09:57 +03:00
Author
Owner
Copy Link

@rodrigoGA commented on GitHub (Aug 26, 2025):

Totally with you @alextran1502 . A photo manager whose philosophy is “never touch photos” is so pure that, taken to the extreme, we should probably not store them at all....problem solved 😅.
Also, by that logic, Immich already does touch things, there’s an image editor on the roadmap (and today we already allow basic edits like crop/rotate), plus derivatives and metadata....etc.

What’s being asked is opt-in, a per-user, album ...Storage Saver, with exclusions (e.g., favorites), dedupe by the original file hash (also store the optimized hash), and run it as a one-off job, not an upload interceptor.

I respect code cleanliness, but when a request repeats for years with lots of +1s, it’s not noise, it’s a signal. Being open to that signal isn’t weakness, it’s good engineering.

@rodrigoGA commented on GitHub (Aug 26, 2025): Totally with you @alextran1502 . A photo manager whose philosophy is “never touch photos” is so pure that, taken to the extreme, we should probably not store them at all....problem solved 😅. Also, by that logic, Immich already does touch things, there’s an image editor on the roadmap (and today we already allow basic edits like crop/rotate), plus derivatives and metadata....etc. What’s being asked is opt-in, a per-user, album ...Storage Saver, with exclusions (e.g., favorites), dedupe by the original file hash (also store the optimized hash), and run it as a one-off job, not an upload interceptor. I respect code cleanliness, but when a request repeats for years with lots of +1s, it’s not noise, it’s a signal. Being open to that signal isn’t weakness, it’s good engineering.
OVERLORD commented 2026-02-04 21:10:07 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Aug 26, 2025):

Immich already does touch things

No, Immich doesn't touch the original file like Alex mentioned. Any edits are done through EXIF metadata in an XMP sidecar file.

@bo0tzz commented on GitHub (Aug 26, 2025): > Immich already does touch things No, Immich doesn't touch the original file like Alex mentioned. Any edits are done through EXIF metadata in an XMP sidecar file.
OVERLORD commented 2026-02-04 21:10:18 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 26, 2025):

Thanks for the comment, for image editing, we are not planning to touch the original file either.

Besides the design philosophy. There are more technical nuisance of supporting such system, especially for detecting which files have been uploaded, or not. Or matching duplicate when ingesting from different source.

I think that more people regretted using the optimized storage option when upload to services like Gphotos than being happy about it. As the cost of hard-drive will only reduce in the future. I hope that not implementing this feature will make you one day say "thanks gosh, Immich doesn't give me the option to mess with my original files, because I need that for x,y,z reasons."

I think the cons outweigh the pros for this feature. We often say yes to most thing, but for this specific feature it is in a no-list in the foreseeable future

@alextran1502 commented on GitHub (Aug 26, 2025): Thanks for the comment, for image editing, we are not planning to touch the original file either. Besides the design philosophy. There are more technical nuisance of supporting such system, especially for detecting which files have been uploaded, or not. Or matching duplicate when ingesting from different source. I think that more people regretted using the optimized storage option when upload to services like Gphotos than being happy about it. As the cost of hard-drive will only reduce in the future. I hope that not implementing this feature will make you one day say "thanks gosh, Immich doesn't give me the option to mess with my original files, because I need that for x,y,z reasons." I think the cons outweigh the pros for this feature. We often say yes to most thing, but for this specific feature it is in a no-list in the foreseeable future
OVERLORD commented 2026-02-04 21:10:28 +03:00
Author
Owner
Copy Link

@jorgeEF commented on GitHub (Aug 26, 2025):

I don't think anybody here is asking for a mandatory optimization to all the media of every immich user, It's clearly an optional feature to be used by those that want to use it and that's it. As I see it, immich currently takes control of users media and forbids users to do whatever they want with their own photos/videos. This is why I just stoped using it: it was too much hustle to do whatever I want with my own media on immich...

@jorgeEF commented on GitHub (Aug 26, 2025): I don't think anybody here is asking for a mandatory optimization to all the media of every immich user, It's clearly an optional feature to be used by those that want to use it and that's it. As I see it, immich currently takes control of users media and forbids users to do whatever they want with their own photos/videos. This is why I just stoped using it: it was too much hustle to do whatever I want with my own media on immich...
OVERLORD commented 2026-02-04 21:10:33 +03:00
Author
Owner
Copy Link

@Red007Master commented on GitHub (Aug 27, 2025):

I think that more people regretted using the optimized storage option when upload to services like Gphotos than being happy about it.

This is first time EVER I have heard something like this.

Having your opinion and vision of the project is absolutely ok.
You have every right, and it's OUR problem, not yours.

But gaslighting people (yourself included) that your position/opinion/decision/vision is objectively right is wrong on many levels.

@Red007Master commented on GitHub (Aug 27, 2025): > I think that more people regretted using the optimized storage option when upload to services like Gphotos than being happy about it. This is first time EVER I have heard something like this. Having your opinion and vision of the project is absolutely ok. You have every right, and it's OUR problem, not yours. But gaslighting people (yourself included) that your position/opinion/decision/vision is objectively right is wrong on many levels.
OVERLORD commented 2026-02-04 21:10:36 +03:00
Author
Owner
Copy Link

@Red007Master commented on GitHub (Aug 27, 2025):

If you want to use something like "people regretted using the optimized storage option when upload to services like Gphotos than being happy about it" as justification of something - do actual PULL an ask people what they actually think and not "what you believe people thinking".

But we perfectly know what result of pull like this will be, ain't we?

@Red007Master commented on GitHub (Aug 27, 2025): If you want to use something like **"people regretted using the optimized storage option when upload to services like Gphotos than being happy about it"** as justification of something - do actual PULL an ask people what they actually think and not "what you believe people thinking". But we perfectly know what result of pull like this will be, ain't we?
OVERLORD commented 2026-02-04 21:10:44 +03:00
Author
Owner
Copy Link

@rodrigoGA commented on GitHub (Aug 27, 2025):

It still reads more like a (valid) preference than a pros-cons balance for common cases.

Still, on the points @alextran1502:

  • Immutability. Philosophically, there are ways not to break it. Think of it like this: the user intentionally opts in and confirms; they run a job, accept the change, and from that moment the optimized version becomes the “official,” immutable file. Same philosophy, only which file is canonical changes and that’s the user’s decision.
  • Duplicates. I’m not fully aware of the internals, but my understanding is that storing the original file’s hash should be enough to detect possible duplicates of the original
  • GPhotos. Regret typically comes from default, irreversible settings, not from optional tools. If the feature is optional and configurable per user/album, with dry-run + savings preview and exclusions (favorites), the risk drops a lot. (In my case, GPhotos’ Storage Saver actually helped consolidate a lot of family albums.)
  • Storage cost. I’m not convinced that storage gets cheaper is a strong argument for an app where most installs are small local servers, and expanding them isn’t trivial. Also, I’m not sure the rate of storage cost reduction outpaces the growth of photos and videos.

Please don’t take this negatively, quite the opposite. We’re very satisfied with Immich and genuinely grateful for the amazing work. This suggestion comes from that appreciation and from wanting to make an already great project even more flexible.
I hope you’ll reconsider this as an advanced optional feature those who don’t use it keep the philosophy intact

@rodrigoGA commented on GitHub (Aug 27, 2025): It still reads more like a (valid) preference than a pros-cons balance for common cases. Still, on the points @alextran1502: * Immutability. Philosophically, there are ways not to break it. Think of it like this: the user intentionally opts in and confirms; they run a job, accept the change, and from that moment the optimized version becomes the “official,” immutable file. Same philosophy, only which file is canonical changes and that’s the user’s decision. * Duplicates. I’m not fully aware of the internals, but my understanding is that storing the original file’s hash should be enough to detect possible duplicates of the original * GPhotos. Regret typically comes from default, irreversible settings, not from optional tools. If the feature is optional and configurable per user/album, with dry-run + savings preview and exclusions (favorites), the risk drops a lot. (In my case, GPhotos’ Storage Saver actually helped consolidate a lot of family albums.) * Storage cost. I’m not convinced that storage gets cheaper is a strong argument for an app where most installs are small local servers, and expanding them isn’t trivial. Also, I’m not sure the rate of storage cost reduction outpaces the growth of photos and videos. Please don’t take this negatively, quite the opposite. We’re very satisfied with Immich and genuinely grateful for the amazing work. This suggestion comes from that appreciation and from wanting to make an already great project even more flexible. I hope you’ll reconsider this as an advanced optional feature those who don’t use it keep the philosophy intact
OVERLORD commented 2026-02-04 21:10:53 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 27, 2025):

No negative feelings taken 😄 I know you guys have good intentions. I think it is okay to disagree on the direction, and that is perfectly okay. From both viewpoints, we have reasons to believe what is best for the use case, and it is normal when they are not aligned.

I stand my point of not going to implement this feature. My suggested workaround is to optimize the library before importing it into Immich if the use case really needs to save space on the hard drive.

@alextran1502 commented on GitHub (Aug 27, 2025): No negative feelings taken 😄 I know you guys have good intentions. I think it is okay to disagree on the direction, and that is perfectly okay. From both viewpoints, we have reasons to believe what is best for the use case, and it is normal when they are not aligned. I stand my point of not going to implement this feature. My suggested workaround is to optimize the library before importing it into Immich if the use case really needs to save space on the hard drive.
OVERLORD commented 2026-02-04 21:11:02 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 27, 2025):

I will yield the BDFL stick this time and lock this discussion. Thank you for participating in discussing this feature request 😃

@alextran1502 commented on GitHub (Aug 27, 2025): I will yield the BDFL stick this time and lock this discussion. Thank you for participating in discussing this feature request 😃
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#523
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?