GPS Coordinates Are Not Correct If Coordinate Direction Is In Separate Field when using external XMP file #2041

Closed
opened 2026-02-05 04:49:47 +03:00 by OVERLORD · 11 comments
Owner

Originally created by @BigCheeZ on GitHub (Jan 22, 2024).

The bug

This is the same issue as reported in issue 3540 except that I'm reporting it for when external XMP files are used with media (eg: image0.jpg and image0.jpg.xmp) using External Libraries. The linked ticket is fixed, but it seems it was only fixed for when the data is embedded in the media file.

I've attached a zip file with a JPG and XMP file that show the issue. The JPG actually has the accurate EXIF data inside the file. The XMP files does too, but when it is parsed by Immich it results in the location being shown as Nepal (see below) instead of Orlando, FL USA because GPSLongitudeRef is not being handled appropriately.

Birendranagar
Surkhet, Karnali Pradesh
Nepal

immich-xmp-test.zip

I understand that if I did not use the external XMP file then the location would be properly extracted from the JPG. I have other data in the XMP file from previous applications I've used that I do not want to lose.

I have tried:

  • Syncing Sidecar Metadata in Jobs tab
  • Extract Metadata (All) in Jobs tab
  • Force re-scan all Library files from Settings >> Libraries

The OS that Immich Server is running on

Docker on NixOS 23.05

Version of Immich Server

v1.93.3

Version of Immich Mobile App

v1.93.0 build.134

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

---
version: "3.8"

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${IMMICH_ROOT}/uploads:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - <my_external_library_mount>:/mnt/media/icloud:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always
    networks:
      - luna-compose_caddynet
      - immich-net
    labels:
      caddy: "photos.${MY_DOMAIN}"
      caddy.reverse_proxy: "{{upstreams 3001}}"
      caddy.tls.dns: "cloudflare ${CLOUDFLARE_API_TOKEN}"

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${IMMICH_ROOT}/uploads:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - <my_external_library_mount>:/mnt/media/icloud:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always
    networks:
      - immich-net

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - ${IMMICH_ROOT}/model-cache:/cache
    env_file:
      - .env
    restart: always
    networks:
      - immich-net

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:70a7a5b641117670beae0d80658430853896b5ef269ccf00d1827427e3263fa3
    env_file:
      - .env
    restart: always
    networks:
      - immich-net

  database:
    container_name: immich_postgres
    image: tensorchord/pgvecto-rs:pg14-v0.1.11
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - ${IMMICH_ROOT}/pgdata:/var/lib/postgresql/data
    restart: always
    networks:
      - immich-net

networks:
  luna-compose_caddynet:
    external: true
  immich-net:
    attachable: true
    driver: bridge

Your .env content

IMMICH_VERSION=v1.93.3

Reproduction steps

1. Create an External Library using the JPG and associated XMP in the zip file linked in the ticket
2. After image is added to Immich open it in web view and see that GPS is incorrect

Additional information

No response

Originally created by @BigCheeZ on GitHub (Jan 22, 2024). ### The bug This is the same issue as reported in issue [3540](https://github.com/immich-app/immich/issues/3540) except that I'm reporting it for when external XMP files are used with media (eg: image0.jpg and image0.jpg.xmp) using External Libraries. The linked ticket is fixed, but it seems it was only fixed for when the data is embedded in the media file. I've attached a zip file with a JPG and XMP file that show the issue. The JPG actually has the accurate EXIF data inside the file. The XMP files does too, but when it is parsed by Immich it results in the location being shown as Nepal (see below) instead of Orlando, FL USA because GPSLongitudeRef is not being handled appropriately. Birendranagar Surkhet, Karnali Pradesh Nepal [immich-xmp-test.zip](https://github.com/immich-app/immich/files/14002230/immich-xmp-test.zip) I understand that if I did not use the external XMP file then the location would be properly extracted from the JPG. I have other data in the XMP file from previous applications I've used that I do not want to lose. I have tried: * Syncing Sidecar Metadata in Jobs tab * Extract Metadata (All) in Jobs tab * Force re-scan all Library files from Settings >> Libraries ### The OS that Immich Server is running on Docker on NixOS 23.05 ### Version of Immich Server v1.93.3 ### Version of Immich Mobile App v1.93.0 build.134 ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML --- version: "3.8" services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} command: [ "start.sh", "immich" ] volumes: - ${IMMICH_ROOT}/uploads:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro - <my_external_library_mount>:/mnt/media/icloud:ro env_file: - .env depends_on: - redis - database restart: always networks: - luna-compose_caddynet - immich-net labels: caddy: "photos.${MY_DOMAIN}" caddy.reverse_proxy: "{{upstreams 3001}}" caddy.tls.dns: "cloudflare ${CLOUDFLARE_API_TOKEN}" immich-microservices: container_name: immich_microservices image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} command: [ "start.sh", "microservices" ] volumes: - ${IMMICH_ROOT}/uploads:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro - <my_external_library_mount>:/mnt/media/icloud:ro env_file: - .env depends_on: - redis - database restart: always networks: - immich-net immich-machine-learning: container_name: immich_machine_learning image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} volumes: - ${IMMICH_ROOT}/model-cache:/cache env_file: - .env restart: always networks: - immich-net redis: container_name: immich_redis image: redis:6.2-alpine@sha256:70a7a5b641117670beae0d80658430853896b5ef269ccf00d1827427e3263fa3 env_file: - .env restart: always networks: - immich-net database: container_name: immich_postgres image: tensorchord/pgvecto-rs:pg14-v0.1.11 env_file: - .env environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} volumes: - ${IMMICH_ROOT}/pgdata:/var/lib/postgresql/data restart: always networks: - immich-net networks: luna-compose_caddynet: external: true immich-net: attachable: true driver: bridge ``` ### Your .env content ```Shell IMMICH_VERSION=v1.93.3 ``` ### Reproduction steps ```bash 1. Create an External Library using the JPG and associated XMP in the zip file linked in the ticket 2. After image is added to Immich open it in web view and see that GPS is incorrect ``` ### Additional information _No response_
Author
Owner

@Kia0ra commented on GitHub (Jan 22, 2024):

Hello,

I seem to have the same problem with sidecar data not loading or loading incorrectly with an external gallery and XMP files.

Example :
exif:PixelXDimension="4368" exif:PixelYDimension="2912" exif:GPSLatitude="42,6.51768S" exif:GPSLongitude="171,20.16774E" exif:GPSVersionID="2.2.0.0" exif:GPSAltitude="200000/10000"

image

Wrong file resolution and no GPS data are shown
immich_xmp_fail_to_import.zip

@Kia0ra commented on GitHub (Jan 22, 2024): Hello, I seem to have the same problem with sidecar data not loading or loading incorrectly with an external gallery and XMP files. Example : ` exif:PixelXDimension="4368" exif:PixelYDimension="2912" exif:GPSLatitude="42,6.51768S" exif:GPSLongitude="171,20.16774E" exif:GPSVersionID="2.2.0.0" exif:GPSAltitude="200000/10000"` <img width="292" alt="image" src="https://github.com/immich-app/immich/assets/15661585/580148fa-3609-4ce4-af6e-2addaad5107a"> Wrong file resolution and no GPS data are shown [immich_xmp_fail_to_import.zip](https://github.com/immich-app/immich/files/14014698/immich_xmp_fail_to_import.zip)
Author
Owner

@BigCheeZ commented on GitHub (Jan 22, 2024):

@Kia0ra your issue looks to be a naming issue.

See https://immich.app/docs/features/xmp-sidecars/

When importing files via the CLI bulk uploader, Immich will automatically detect XMP sidecar files as files that exist next to the original media file and have the exact same name with an additional .xmp file extension (i.e., PXL_20230401_203352928.MP.jpg and PXL_20230401_203352928.MP.jpg.xmp).

In the zip you attached you have:

  • IMG_5090.CR2
  • IMG_5090.JPG
  • IMG_5090.xmp
@BigCheeZ commented on GitHub (Jan 22, 2024): @Kia0ra your issue looks to be a naming issue. See https://immich.app/docs/features/xmp-sidecars/ > When importing files via the CLI bulk uploader, Immich will automatically detect XMP sidecar files as files that exist next to the original media file and have the exact same name with an additional .xmp file extension (i.e., PXL_20230401_203352928.MP.jpg and PXL_20230401_203352928.MP.jpg.xmp). In the zip you attached you have: * IMG_5090.CR2 * IMG_5090.JPG * IMG_5090.xmp
Author
Owner

@Kia0ra commented on GitHub (Jan 23, 2024):

Ok I see but this is Lightroom's default behavior, I imagined it could also be taken into account in Immich.
It doesn't explain why the resolution of the RAW file isn't extracted correctly.

@Kia0ra commented on GitHub (Jan 23, 2024): Ok I see but this is Lightroom's default behavior, I imagined it could also be taken into account in Immich. It doesn't explain why the resolution of the RAW file isn't extracted correctly.
Author
Owner

@waclaw66 commented on GitHub (Jan 23, 2024):

I have checked your issue and there's nothing to blame Immich. Seems to be the similar issue as https://github.com/photostructure/exiftool-vendored.js/issues/165 of upstream library.

@waclaw66 commented on GitHub (Jan 23, 2024): I have checked your issue and there's nothing to blame Immich. Seems to be the similar issue as https://github.com/photostructure/exiftool-vendored.js/issues/165 of upstream library.
Author
Owner

@waclaw66 commented on GitHub (Jan 24, 2024):

It turned out it's an issue of exiftool itself. Opened an issue...
https://exiftool.org/forum/index.php?topic=15622.0

@waclaw66 commented on GitHub (Jan 24, 2024): It turned out it's an issue of `exiftool` itself. Opened an issue... https://exiftool.org/forum/index.php?topic=15622.0
Author
Owner

@BigCheeZ commented on GitHub (Jan 24, 2024):

@waclaw66 thanks for the effort! From looking at the comments on the forum post it seems I will need to modify my existing XMP files. That's not a big problem for me since I am not syncing them back upstream anywhere. FYI, I did use the Apple Photos app for creating the XMP files.

I am a little confused about how the embedded-XMP issue, https://github.com/immich-app/immich/issues/3540, was fixed. If embedded-XMP data is read by exiftool then would it not have the same issue since it seems the Ref fields are not being used per the spec?

@BigCheeZ commented on GitHub (Jan 24, 2024): @waclaw66 thanks for the effort! From looking at the comments on the forum post it seems I will need to modify my existing XMP files. That's not a big problem for me since I am not syncing them back upstream anywhere. FYI, I did use the Apple Photos app for creating the XMP files. I am a little confused about how the embedded-XMP issue, https://github.com/immich-app/immich/issues/3540, was fixed. If embedded-XMP data is read by exiftool then would it not have the same issue since it seems the Ref fields are not being used per the spec?
Author
Owner

@MrColumbo commented on GitHub (Feb 4, 2024):

I once opened this one Wrong location on map #4340 ...not sure if that is related but at least even with the latest version immich is still showing the wrong map location.
I never as able to see the XMP data by using exiftool in the example of the lizzeard picture ..I once thought i might do a batch thing to just remove the XMP data ...

@MrColumbo commented on GitHub (Feb 4, 2024): I once opened this one Wrong location on map #4340 ...not sure if that is related but at least even with the latest version immich is still showing the wrong map location. I never as able to see the XMP data by using exiftool in the example of the lizzeard picture ..I once thought i might do a batch thing to just remove the XMP data ...
Author
Owner

@Bluish9428 commented on GitHub (May 31, 2024):

I'm having the exact same issue. Just tried to migrate my library from Apple Photos with GPS stored in XMP and all my photos are mapped to very incorrect places.

@Bluish9428 commented on GitHub (May 31, 2024): I'm having the exact same issue. Just tried to migrate my library from Apple Photos with GPS stored in XMP and all my photos are mapped to very incorrect places.
Author
Owner

@BigCheeZ commented on GitHub (May 31, 2024):

@Bluish9428 there is a command provided from the https://exiftool.org/forum/index.php?topic=15622.0 post that fixed the issue for me. It will modify your XMP files to match the standard and work with Immich. If you're exporting from Apple Photos once, then this will likely work for you.

Specifically, it is this post: https://exiftool.org/forum/index.php?msg=83953

@BigCheeZ commented on GitHub (May 31, 2024): @Bluish9428 there is a command provided from the https://exiftool.org/forum/index.php?topic=15622.0 post that fixed the issue for me. It will modify your XMP files to match the standard and work with Immich. If you're exporting from Apple Photos once, then this will likely work for you. Specifically, it is this post: https://exiftool.org/forum/index.php?msg=83953
Author
Owner

@Bluish9428 commented on GitHub (May 31, 2024):

Thanks, I'll give that a try! It would be nice if this was built in for less technical people in the future, but glad there is a workaround.

@Bluish9428 commented on GitHub (May 31, 2024): Thanks, I'll give that a try! It would be nice if this was built in for less technical people in the future, but glad there is a workaround.
Author
Owner

@jrasm91 commented on GitHub (Sep 6, 2024):

It seems the source of this bug is 3rd party programs incorrectly writing GPS tags to XMP, and subsequent programs naturally read them "incorrectly". Since this isn't an immich bug and there doesn't seem like much we can do about it, I'm going to go ahead and close this. The recommended solution is to correct the invalid XMP metadata.

@jrasm91 commented on GitHub (Sep 6, 2024): It seems the source of this bug is 3rd party programs incorrectly writing GPS tags to XMP, and subsequent programs naturally read them "incorrectly". Since this isn't an immich bug and there doesn't seem like much we can do about it, I'm going to go ahead and close this. The recommended solution is to correct the invalid XMP metadata.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#2041