A picture's XMP answers four properties, where upstream asks it first for all of them #222

New issue

Closed

opened 2026-09-15 23:30:07 +02:00 by Claude · 1 comment

Claude commented

2026-09-15 23:30:07 +02:00

Collaborator

A picture's XMP block is consulted for four properties only: title, comment, rating and keywords. Upstream reads the others through the same combined tag.

Both sides

upstream/Emby.Photos/PhotoProvider.cs reads everything off TagLib's CombinedImageTag, which asks each of the file's tag blocks in turn with XMP first. That covers make, model, software, date taken, orientation, exposure, ISO and focal length as well as the four text fields.

Ours (crates/ephyra-images/src/exif.rs) lets XMP answer first for title, comment, rating and keywords. It reads the camera, date and exposure fields from the EXIF/TIFF block only.

What a client sees

Take a PNG or WebP exported with an XMP packet and no eXIf chunk, which several editors write. Upstream files its camera, date taken and exposure. We file none of them.

Before fixing

TagLib's source is not on disk, so the order it uses for each property is inferred rather than read. Start by giving the library-kinds fixture a picture whose XMP carries the camera and date fields and whose EXIF carries different values or none. Regenerate with cargo xtask reference gen-library-kinds and let the read block show which one upstream takes. The comparison test in xtask/src/reference/kinds.rs then holds it.

Found reviewing #209.

A picture's XMP block is consulted for four properties only: title, comment, rating and keywords. Upstream reads the others through the same combined tag. ## Both sides `upstream/Emby.Photos/PhotoProvider.cs` reads everything off TagLib's `CombinedImageTag`, which asks each of the file's tag blocks in turn with XMP first. That covers make, model, software, date taken, orientation, exposure, ISO and focal length as well as the four text fields. Ours (`crates/ephyra-images/src/exif.rs`) lets XMP answer first for title, comment, rating and keywords. It reads the camera, date and exposure fields from the EXIF/TIFF block only. ## What a client sees Take a PNG or WebP exported with an XMP packet and no `eXIf` chunk, which several editors write. Upstream files its camera, date taken and exposure. We file none of them. ## Before fixing TagLib's source is not on disk, so the order it uses for each property is inferred rather than read. Start by giving the library-kinds fixture a picture whose XMP carries the camera and date fields and whose EXIF carries different values or none. Regenerate with `cargo xtask reference gen-library-kinds` and let the `read` block show which one upstream takes. The comparison test in `xtask/src/reference/kinds.rs` then holds it. Found reviewing #209.

Claude referenced this issue

2026-09-15 23:52:56 +02:00

Nothing reads a photo's EXIF, so every column upstream fills is empty #209

Claude referenced this issue

2026-09-16 01:50:24 +02:00

A picture's XMP GPS is never read, and which block answers for it is unmeasured #233

Claude commented

2026-09-16 02:25:47 +02:00

Author

Collaborator

Fixed, and landed on main at 76f368b8.

Measured, not inferred. A new built asset, /kinds/homevideos/Holiday/Contested.jpg, carries an XMP packet and an Exif block that disagree about every property both can hold. The regenerated answer key records what upstream filed:

the packet's make, model, orientation, exposure time, focal length, ISO, title and comment;
the block's aperture, shutter speed, software and date, although the packet names a date too;
no rating at all, although the block carries one.

crates/ephyra-images/src/exif.rs now matches that: read_xmp answers for make, model, orientation, exposure time, focal length and ISO as well, and the block's rating tag is read by nothing. every_picture_reads_as_upstream_read_it holds it.

Left unmeasured and now said so in the module's own documentation: the packet carries no GPS, so which block answers for latitude, longitude and altitude is still read from TagLib's shape rather than from upstream. Filed as #233.

Fixed, and landed on `main` at `76f368b8`. **Measured, not inferred.** A new built asset, `/kinds/homevideos/Holiday/Contested.jpg`, carries an XMP packet and an Exif block that disagree about every property both can hold. The regenerated answer key records what upstream filed: - the **packet's** make, model, orientation, exposure time, focal length, ISO, title and comment; - the **block's** aperture, shutter speed, software and date, although the packet names a date too; - **no rating at all**, although the block carries one. `crates/ephyra-images/src/exif.rs` now matches that: `read_xmp` answers for make, model, orientation, exposure time, focal length and ISO as well, and the block's rating tag is read by nothing. `every_picture_reads_as_upstream_read_it` holds it. Left unmeasured and now said so in the module's own documentation: the packet carries no GPS, so which block answers for latitude, longitude and altitude is still read from TagLib's shape rather than from upstream. Filed as #233.

Claude closed this issue

2026-09-16 02:25:48 +02:00