fix(images): use EXIF-oriented dimensions in metadata refresh#475
Merged
Conversation
The metadata-refresh task read image dimensions via sharp(buffer).metadata() without accounting for EXIF orientation. For orientation 5-8 (rotate 90/270/transpose/transverse — common on phone photos) sharp reports the stored, pre-rotation width/height, so the task persisted swapped dimensions to images.width/height. Because the gallery (and the new variant pipeline) treat those as displayed dimensions, rotated photos were laid out as landscape-when-portrait, and the bad values would also overwrite the correct browser-reported dimensions stored on upload. Extract the orientation-swap logic introduced in the variant generator into a shared getOrientedDimensions() helper and use it in both image-variants.ts (behavior-preserving refactor) and metadata-refresh.ts (the fix). Verified against sharp 0.34.5 across EXIF orientation 1-8: helper output matches the actual .rotate() pixel dimensions (1-4 unchanged, 5-8 swapped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix: EXIF-oriented dimensions in the metadata-refresh task
A pre-existing correctness bug surfaced during the image-performance work (parent task #1, raised by @Picimpact-Review during BE-2 review).
Problem
server/tasks/metadata-refresh.tsread image dimensions viasharp(buffer).metadata()without accounting for EXIF orientation. sharp reports the stored (pre-rotation) width/height, so for orientation 5–8 (rotate 90/270/transpose/transverse — common on phone photos) the task persisted swappedimages.width/images.height. The gallery (and the new variant pipeline) treat those as displayed dimensions, so rotated photos laid out as landscape-when-portrait, and the bad values would also overwrite the correct browser-reported dimensions stored at upload time.This is the same orientation issue fixed inline in the BE-2 variant generator; this PR makes the handling consistent so the two code paths that write
images.width/heightagree.Change
getOrientedDimensions(metadata)helper inserver/lib/image-variants.ts, and use it ingenerateImageVariants(behavior-preserving refactor).metadata-refresh.ts(the actual fix).Verification
.rotate()pixel dimensions (1–4 unchanged, 5–8 swapped) — see below.tsc --noEmit: no errors in changed files.eslint --fix: clean.Independent of the BE-3 queue work; safe to review/merge on its own.
🤖 Generated with Claude Code