Bugzilla – Bug 1207371
jpegtran destroys EXIF data when invoked with -rotate
Last modified: 2023-02-10 12:09:06 UTC
When jpegtran is invoked with the -rotate switch, it performs the rotation but destroys all EXIF data. Sample run: [take a photograph holding the camera in portrait mode and download it] bow:2:624> ll IMG_2131.JPG -rw-r--r-- 1 geoff faculty 8534787 Jan 21 06:36 IMG_2131.JPG bow:2:625> exiftool IMG_2131.JPG | wc 303 2004 14758 bow:2:626> jpegtran -rotate 270 -outfile foo.jpg IMG_2131.JPG bow:2:627> exiftool foo foo.jpg foo.sh bow:2:627> exiftool foo.jpg | wc 23 109 1003 In contrast, exiftran doesn't do the same damage:bow:2:628> exiftran -a -o foo.jpg IMG_2131.JPG bow:2:629> exiftool foo.jpg | wc 298 1978 14519 This appears to be a bug in one of the libraries, because I get the same behavior with a version of jpegtran compiled in 2003 that I still have kicking around (and which worked fine up until I upgraded from Leap 15.3 to Leap 15.4).
Isn't this a duplicate of bug 1207150 or at least related to it?
Yes, it's a duplicate. Since the bug is actually in jpegtran (I've verified that fact) I only searched for jpegtran bugs and missed that it was a duplicate. I have separately commented on bug 1204409, which I suspect is the cause of the "invalid characters" message mentioned in bug 1207150. I've added a comment to that one.
(In reply to Geoff Kuenning from comment #2) > Yes, it's a duplicate. Since the bug is actually in jpegtran (I've verified > that fact) I only searched for jpegtran bugs and missed that it was a > duplicate. Closing as a duplicate. *** This bug has been marked as a duplicate of bug 1207150 ***