This will be great. I only noticed two issues with the mobile app, and one of them had to do with performance - it would get "stuck" uploading an image to the server, and no amount of waiting would let it complete. So I'd have to restart the app, and it would always start over and check every image that was in the library before uploading would begin again.
The second issue is still related to timestamps from iCloud photos. The date that's on the photo in iCloud is not respected when uploading to Immich, meaning photos tagged from 40-90 years ago show up as being taken today.
I really appreciate the work behind Immich and how solid the product already is.
Personally, I don’t want cloud sync/storage, but I understand it’s a need for many users. What I hope is that a fully local mode can be considered in the future. For me, the goal is simply to have a great photo management app. Google Photos, for example, limits functionality if you don’t use their cloud and pushes you toward paid storage. That’s where Immich has a opportunity to shine.
Immich isn't "cloud storage", at least in the sense that the server runs on your own system. We hope to have more improvements in the future to allow it to replace the local gallery app on a device, but it'll always need the server for the full functionality.
I would say if you're looking for a photo management open-source alternative similar to existing solutions like Google Photos, yes.
However, I've been using it for about 6 months and have experienced all sorts of weird bugs/performance issues between the server app and the mobile app. I'm now considering a more barebones solution of using Syncthing + copyparty (as a web UI) to just sync photos from my phone to a RPi, and then running backups to another server with a cron job.
This article just highlights how hard it is to make optional offline applications. I feel like there should be a database-level solution to all this synchronizing.
Postgres can't run on a phone, so that's not a candidate for fully-synced database.
The app needs a search bug fix. If you search by "Description" in the app, it always shows no results. "Context" kind of handles some of the descriptive search features but this should be an easy fix.
Description search does a literal text search by the editable description field on the assets, context search uses the ML/CLIP search to do semantic search. Sounds like you might just have them mixed up?
Eh I think you are right. I don't have any images with a description set. I expected description to use ML and context to also use metadata. But I should RTFM lol
> Having just migrated to Kysely from TypeORM, we were already seeing massive improvements with regard to speed and memory usage in other parts of the application as we migrated queries to use the streaming interface (see #16600, #16666, #16700, #16706, etc.).
I would generally suggest folks look at something like ElectricSQL Postgres Sync Engine. There's a pretty good ShapeStream HTTP API for shipping shape logs across to the client. It can do so much of the heavy lifting for shipping updates for you, & will be reliable!
https://electric-sql.com/docs/api/clients/typescript#shapest...
This will be great. I only noticed two issues with the mobile app, and one of them had to do with performance - it would get "stuck" uploading an image to the server, and no amount of waiting would let it complete. So I'd have to restart the app, and it would always start over and check every image that was in the library before uploading would begin again.
The second issue is still related to timestamps from iCloud photos. The date that's on the photo in iCloud is not respected when uploading to Immich, meaning photos tagged from 40-90 years ago show up as being taken today.
I really appreciate the work behind Immich and how solid the product already is.
Personally, I don’t want cloud sync/storage, but I understand it’s a need for many users. What I hope is that a fully local mode can be considered in the future. For me, the goal is simply to have a great photo management app. Google Photos, for example, limits functionality if you don’t use their cloud and pushes you toward paid storage. That’s where Immich has a opportunity to shine.
Immich isn't "cloud storage", at least in the sense that the server runs on your own system. We hope to have more improvements in the future to allow it to replace the local gallery app on a device, but it'll always need the server for the full functionality.
I was just looking into Immich the other day. Would people recommend it?
[0] https://news.ycombinator.com/item?id=45341121
I would say if you're looking for a photo management open-source alternative similar to existing solutions like Google Photos, yes.
However, I've been using it for about 6 months and have experienced all sorts of weird bugs/performance issues between the server app and the mobile app. I'm now considering a more barebones solution of using Syncthing + copyparty (as a web UI) to just sync photos from my phone to a RPi, and then running backups to another server with a cron job.
Been using it for a year or so. It's great. Have a good backup plan
The discord is also very active and the devs respond well to bugs and feature requests.
Yeah moved from gphotos to self hosted immich. Just edit options and live photos are missing.
Live Photos work for me on iOS.
Yes, works great. Exported everything from Google and uploader to my self hosted immich. Love it.
Yes, it's awesome!
Does Immich support bi-directional synchronization?
Say I deleted a photo from my device, and it gets deleted on the server?
It apparently doesn't support that: https://github.com/immich-app/immich/discussions/4341
This article just highlights how hard it is to make optional offline applications. I feel like there should be a database-level solution to all this synchronizing.
Postgres can't run on a phone, so that's not a candidate for fully-synced database.
Huge win! Excited for better perf
The app needs a search bug fix. If you search by "Description" in the app, it always shows no results. "Context" kind of handles some of the descriptive search features but this should be an easy fix.
Description search does a literal text search by the editable description field on the assets, context search uses the ML/CLIP search to do semantic search. Sounds like you might just have them mixed up?
Eh I think you are right. I don't have any images with a description set. I expected description to use ML and context to also use metadata. But I should RTFM lol
Nice:
> Having just migrated to Kysely from TypeORM, we were already seeing massive improvements with regard to speed and memory usage in other parts of the application as we migrated queries to use the streaming interface (see #16600, #16666, #16700, #16706, etc.).
I would generally suggest folks look at something like ElectricSQL Postgres Sync Engine. There's a pretty good ShapeStream HTTP API for shipping shape logs across to the client. It can do so much of the heavy lifting for shipping updates for you, & will be reliable! https://electric-sql.com/docs/api/clients/typescript#shapest...
ElectricSQL are also authors of pglite, a wasm postgres, for running a sync-ed to mini postgres on the client (via wasm). https://news.ycombinator.com/item?id=37584049 https://news.ycombinator.com/item?id=41224689