Bug 1207371

Summary: jpegtran destroys EXIF data when invoked with -rotate
Product: [openSUSE] openSUSE Distribution Reporter: Geoff Kuenning <geoff>
Component: OtherAssignee: Petr Gajdos <pgajdos>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: pgajdos
Version: Leap 15.4   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE Leap 15.4   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Geoff Kuenning 2023-01-22 01:57:01 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).
Comment 1 hui 2023-01-22 07:07:27 UTC
Isn't this a duplicate of bug 1207150 or at least related to it?
Comment 2 Geoff Kuenning 2023-01-22 08:41:09 UTC
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.
Comment 3 Petr Gajdos 2023-02-10 12:09:06 UTC
(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 ***