Ability to add assets to shared albums

[jgoclawski]

Hi,

Love the tool! I'm in the process of migrating my and my wife's photos from Google Photos to Immich. We had a few shared albums in Google Photos - I was their owner and my wife would add her photos there.
So in Immich I'm trying to have the same structure - an album owned by me, shared with my wife and her photos added there.
My issue is that when import my wife's photos from Takeout, a new album is created in Immich, instead of the shared one being used.

E.g. - Immich has an album "Spain 2018" owned by User A. User B uploads assets using immich-go:

./immich-go -server http://xxx.xxx.xxx.xxx:3001 -key xxx -log-level info \
upload -album "Spain 2018" "/share/UserB/Google Photos/Spain 2018"

And a new album "Spain 2018" is created. I'd love to reuse the existing, shared album.

Looks like it's about getting Albums from Immich -> https://github.com/simulot/immich-go/blob/main/immich/albums.go#L23
Is there a chance to add shared=true to the API call? https://immich.app/docs/api/get-all-albums
Maybe it could be controlled with a flag?

[simulot]

Immich-go place photos in the album with the exact same name. If this album is shared, the photos will be shared.
If the album doesn't exist, immich-go creates it, not shared. you can share it in the application.

[jgoclawski]

Hi, thanks for you reply. Based on my experiments, I don't think that immich-go "sees" the albums that are shared, but owned by another user.

Consider the following scenario:

"User 2" has access to 3 albums:

• Album 2A (owned by "User 2", not shared)
• Album 2B (owned by "User 2", shared with "User 1")
• Album 1B (owned by "User 1", shared with "User 2")

When "User 2" uses immich-go it sees only "Album 2A" and "Album 2B". If I tell it to import assets to "Album 1B", it will not see it and create a new one with that name (owned by "User 2", not shared).

It's about how immich-go calls Immich API.

When "User 2" calls /api/albums, then 2 albums are returned: "Album 2A" and "Album 2B", so a bit like "albums owned by me".
When "User 2" calls /api/albums?shared=true, then 2 different albums are returned "Album 2B" and "Album 1B", so a bit like "only shared albums, no matter who's the owner".

Would you consider adding the shared=true flag to the API call? It's what the web Immich UI does to list albums - it calls the API twice ( /api/albums + /api/albums?shared=true ) to get all the albums.

[simulot]

I'll check it

[Arctize]

I can confirm this. Having the same problem now trying to re-create/fill the shared albums with my partner.

• We have a shared album that my partner owned on Google Photos and we both added photos to it
• My partner's takeout contains the album and all the pictures they added to it, so immich-go re-created this nicely on immich and added all their pictures.
• The takeout on my end however does not seem to contain any information about which of my picture I have added to that shared album. All of my photos are simply in my timeline without any album information.

So, given the lack of this information in the google takeout, I figured I would manually download the album from Google Photos. I get a .zip file containing all photos, no matter who uploaded them. Then I would use immich-go to upload them to my partner's album that they now shared with me again on Immich.

Expectation: Photos that my partner already has in the album are not uploaded to my library. Photos that are missing are uploaded and added to the album.

Outcome: It created a new album with the same name, and uploaded all my partner's photos to my own library too.

I realize that this is maybe a bit of a niche use case. I can try and open a PR for this myself, but that won't happen any time soon I'm afraid. Perhaps in a month or two.

And while I'm already here, thanks for this amazing tool! I don't think I would have made the jump from Google Photos without it. 😊

[simulot]

Thanks for sharing this.

I'm thinking loud here:
Imagine that immich-go has the api key for your partner. It's possible to check partner's database with that key.

Photos have true unique identifier, the SHA1 hash.
The SHA1 hash can be calculated prior the upload. It's possible to check if the SHA1 exists in the partner's database skip that one

The price of this is to force the read each files twice, one for determining the SHA1, the second for the upload.

[Arctize]

Using SHA1 hash could lead to this issue if I'm not wrong: My partner uploads the takeout, then the original quality pictures from the phone and de-duplicates them using immich-go. When I now try and add the pictures from the album .zip file downloaded directly from GPhotos, the hashes will not match and I will uploaded the compressed versions to my own library again.

Would it not make sense to use the already existing duplicate detection? It might be a bit weird to de-duplicate across multiple users' assets. And of course we cannot upgrade assets owned by them without their API key, but I think at that point, we have really arrived at a super niche use case. I don't see myself ever having a higher resolution copy of a photo that someone else shared with me.

Personally, I think for an upload into an album, it would be enough to

• Check if local asset has a duplicate (same filename/date) in the (shared) album
• If duplicate on server is better -> We're good
• If our local version is better:
  • Does server version belong to us? -> Upgrade it
  • Does server version belong to someone else? -> Skip local asset, maybe log a warning