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 11 Packages Projects Releases 10 Wiki Activity

[BUG] Metadata extraction from EXIF needs to support all groups #1112

New Issue
Closed
opened 2026-02-05 00:30:43 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-05 00:30:43 +03:00
Owner
Copy Link

Originally created by @alex-phillips on GitHub (Jul 15, 2023).

The bug

Currently, the exiftool library defaults to the metadata output that exiftool returns with its default settings. In some cases of assets, the values return for specific fields is incorrect. Given the attached XMP file, exiftool (the library used in Immich as well as the direct CLI tool) return the incorrect tags for geolocation data. The file contains the same fields in 2 different groups: XMP-video:GPS * and XMP-exif:GPS *. Exiftool defaults to XMP-video with its extraction but the valid data exists in the XMP-exif group.

The library can be modified to instead of returning the default values for each field in a flat data structure:

GPSLatitude: ...
GPsLongitude: ...

it can return all metadata fields by their groups:

XMP-video:
    GPSLatitude: ...
    GPsLongitude: ...
XMP-exif:
    GPSLatitude: ...
    GPsLongitude: ...

We should modify the library to return this data structure, but it will require some modifications to the getter method getExifProperty. Instead of pulling out the requested key from the exif data structure, we would have to iterate over each known group for they key and if multiple values are found, we can do some checking for if they are identical or if one is potentially invalid.

This issue should likely be addressed before merging in https://github.com/immich-app/immich/pull/2908 as part of the PR contains removing the getter function entirely and assuming all correct exif data is returned from the library, which in this case is incorrect.

Test XMP file that exhibits the above issue:
VID_20190111_135851.mp4.xmp.zip

The OS that Immich Server is running on

Ubuntu 23.04

Version of Immich Server

1.67.2

Version of Immich Mobile App

1.67.2

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

default dev compose file

Your .env content

default dev .env file

Reproduction steps

1. Import any media file using the above sidecar to see incorrect GPS location (0,0)
2. Use exiftool to see output of default (incorrect) GPS data: `exiftool VID_20190111_135851.mp4.xmp`
3. Use exiftool to return all metadata by group to see that the correct GPS data does exist: `exiftool -a -g1 VID_20190111_135851.mp4.xmp`

Additional information

No response

Originally created by @alex-phillips on GitHub (Jul 15, 2023). ### The bug Currently, the exiftool library defaults to the metadata output that exiftool returns with its default settings. In some cases of assets, the values return for specific fields is incorrect. Given the attached XMP file, exiftool (the library used in Immich as well as the direct CLI tool) return the incorrect tags for geolocation data. The file contains the same fields in 2 different groups: `XMP-video:GPS *` and `XMP-exif:GPS *`. Exiftool defaults to `XMP-video` with its extraction but the valid data exists in the `XMP-exif` group. The library can be modified to instead of returning the default values for each field in a flat data structure: ```yaml GPSLatitude: ... GPsLongitude: ... ``` it can return all metadata fields by their groups: ```yaml XMP-video: GPSLatitude: ... GPsLongitude: ... XMP-exif: GPSLatitude: ... GPsLongitude: ... ``` We should modify the library to return this data structure, but it will require some modifications to the getter method `getExifProperty`. Instead of pulling out the requested key from the exif data structure, we would have to iterate over each known group for they key and if multiple values are found, we can do some checking for if they are identical or if one is potentially invalid. This issue should likely be addressed before merging in https://github.com/immich-app/immich/pull/2908 as part of the PR contains removing the getter function entirely and assuming all correct exif data is returned from the library, which in this case is incorrect. Test XMP file that exhibits the above issue: [VID_20190111_135851.mp4.xmp.zip](https://github.com/immich-app/immich/files/12062316/VID_20190111_135851.mp4.xmp.zip) ### The OS that Immich Server is running on Ubuntu 23.04 ### Version of Immich Server 1.67.2 ### Version of Immich Mobile App 1.67.2 ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML default dev compose file ``` ### Your .env content ```Shell default dev .env file ``` ### Reproduction steps ```bash 1. Import any media file using the above sidecar to see incorrect GPS location (0,0) 2. Use exiftool to see output of default (incorrect) GPS data: `exiftool VID_20190111_135851.mp4.xmp` 3. Use exiftool to return all metadata by group to see that the correct GPS data does exist: `exiftool -a -g1 VID_20190111_135851.mp4.xmp` ``` ### Additional information _No response_
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#1112
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?