Images that are both in my library and in an iOS shared album appear as duplicate in Immich

[patrontheo]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

When using the Immich iOS app to back up photos from an Apple Photos Shared Album, duplicate uploads can be created for photos that already exist in the main library.

Scenario:

• I take photos during an event, and those original full-resolution photos are already synced to Immich from my iPhone photo library.
• Later, I add some of those same photos to an iOS Shared Album to share with friends.
• Friends also contribute their own photos to that Shared Album.
• I then enable that Shared Album as a source to back up in the Immich iOS app, so friends’ photos can be imported into my Immich library.

Expected behavior:

• Friends’ photos from the Shared Album should be imported.
• My own photos, which already exist in Immich, should be detected as duplicates and skipped.

Actual behavior:

• My own photos from the Shared Album are uploaded again as duplicates.

Suspected cause:
This may happen because Apple Shared Albums store resized versions of photos (for example 1536x2048) rather than the original full-resolution versions (for example 4284x5712). Because the Shared Album copy differs from the original file, Immich deduplication appears not to recognize them as the same photo.

Possible improvement:
Deduplication could potentially account for Shared Album derivatives of already-backed-up originals, perhaps using additional metadata or perceptual similarity rather than relying only on file identity.

The OS that Immich Server is running on

Ubuntu 24.04

Version of Immich Server

v2.7.5

Version of Immich Mobile App

v2.7.5

Platform with the issue

• Server
• Web
• Mobile

Device make and model

iPhone 17 Pro

Your docker-compose.yml content

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    extends:
      file: hwaccel.transcoding.yml
      service: quicksync # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
      - ${FAMILY_PATH}:/usr/src/app/external-family

    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} #-openvino
    # extends: # uncomment this section for hardware acceleration - see https://docs.immich.app/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    mem_limit: 8g # added to prevent oom kills - not sure it works
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:fb8d272e529ea567b9bf1302245796f21a2672b8368ca3fcb938ac334e613c8f
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
      # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
      # DB_STORAGE_TYPE: 'HDD'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always

#  power-tools:
#    container_name: immich_power_tools
#    image: ghcr.io/varun-raj/immich-power-tools:latest
#    ports:
#      - "8001:3000"
#    env_file:
#      - .env

volumes:
  model-cache:

Your .env content

--

Reproduction steps

1. Take photos on an iPhone and let them back up normally to Immich.
2. Create an iOS Shared Album.
3. Add some of those already-backed-up photos to the Shared Album.
4. Have friends add their own photos to the same Shared Album.
5. In the Immich iOS app, enable that Shared Album in the list of albums to back up.
6. Trigger backup/sync.

Result:

Friends’ photos are imported correctly.
Photos I originally took and added to the Shared Album are uploaded again as duplicates (as resized Shared Album versions).

Relevant log output

Additional information

No response

[bo0tzz]

This may happen because Apple Shared Albums store resized versions of photos (for example 1536x2048) rather than the original full-resolution versions (for example 4284x5712).

This is definitely the cause, and I don't think there's really much we can do about it automatically.

[patrontheo]

Thanks for the answer @bo0tzz.

Maybe if we can:

• identify it comes from a shared album
• all metadata are the same except resolution
• both images have high similarity index

Then we flag that as duplicate ?

Cause otherwise when importing a large shared album we sometime end up with a lot of duplicate images :/

[bo0tzz]

The problem is that we don't have all that information (and especially the similarity comparison) until well after the asset has been uploaded to the server. It's also not immediately clear to me whether we can even identify if the source is a shared album.

[patrontheo]

Ok I see ! Thanks for the answer. Indeed I'm not sure how to solve this one :)
But I think it's worth looking into since I'm probably not the only one affected by it.

As of now, they appear in the duplicate detection utility and I can batch remove duplicates when importing new shared albums, so it's not terrible. But this needs to be done each time I import a new shared album.