fix(graphicsmagick): apply EXIF auto-orient so portrait images don't convert sideways (#590) - #637
Open
thejdubb02 wants to merge 1 commit into
Open
Conversation
…convert sideways A phone portrait photo is stored as landscape pixels plus an EXIF Orientation tag (e.g. Orientation 6, rotate 90). The GraphicsMagick converter called `gm convert <in> <out>` without -auto-orient, so converting to a format that drops the tag (PDF) produced a landscape result. C4illin#577 added -auto-orient to the ImageMagick converter for the same reason; this does the same for GraphicsMagick. -auto-orient is a no-op on images with no orientation tag. Fixes C4illin#590.
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
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.
Fixes #590.
A phone portrait photo is stored as landscape pixels plus an EXIF Orientation tag (for example Orientation 6, rotate 90). Converting it with the GraphicsMagick converter produced a landscape result, because
gm convertwas called without-auto-orientand the target format (PDF here) drops the orientation tag.#577 fixed this for the ImageMagick converter by adding
-auto-orient. This does the same for the GraphicsMagick converter, which is one of the paths the reporter mentions ("ImageMagick or others").Reproduced with the exact command the converter runs, on a 600x400 JPEG tagged EXIF Orientation 6:
gm convert in.jpg out.pdfproduced a 600x400 (landscape) PDF pagegm convert in.jpg -auto-orient out.pdfproduced a 400x600 (portrait) PDF pageA genuinely portrait-pixel image (400x600, no EXIF) already converted to a portrait PDF, so this is specifically EXIF orientation, not page geometry.
-auto-orientis a no-op on images with no orientation tag.Test: mirrors the imagemagick test added in #577, asserting the
gm convertargs are["convert", filePath, "-auto-orient", targetPath]. It fails without the change.One note: like #577, this applies
-auto-orientto every GraphicsMagick conversion. If you would rather scope it (some formats and targets can carry the orientation tag themselves, so they may not need it), I am happy to adjust.Summary by cubic
Fixes #590 by adding
-auto-orientto the GraphicsMagick converter. Phone portrait photos (landscape pixels plus an EXIF orientation tag) previously converted to landscape when the target format dropped the tag; now they keep their orientation.-auto-orientis a no-op on images without an orientation tag.Written for commit 567c585. Summary will update on new commits.