convert -scale makes file with EXIF in a place that exifautotran can't read

Bug #1893289 reported by Akkana Peck
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
graphicsmagick (Ubuntu)
New
Undecided
Unassigned

Bug Description

This comes from Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/libjpeg9/+bug/1842116
which references Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947182

Start with a JPEG image, say from a camera, that has an Orientation tag other than 0:

$ jhead dsc00902.jpg | grep Orientation
Orientation : rotate 90

Scale it smaller:

$ convert dsc00902.jpg -scale 1024 dsc00902sm.jpg

The scaled file still has an Orientation tag:

$ jhead dsc00902sm.jpg | grep Orientation
Orientation : rotate 90

Now try to use exifautotran to rotate it and set the orientation to 0:

$ exifautotran dsc00902sm.jpg

$ jhead dsc00902sm.jpg | grep Orientation
Orientation : rotate 90

The orientation still specifies rotation.

This is apparently because convert put the APP1 marker in a place that libjpeg-turbo-progs considers invalid (see the Debian bug linked at the top of this report).

Indeed, if I use hexdump to look at the beginning of dsc00902sm.jpg:

0000000 d8ff e0ff 1000 464a 4649 0100 0101 5e01
0000010 5e01 0000 e1ff cbbb 7845 6669 0000 4949

The e1ff that specifies the APP1 (EXIF) doesn't occur until 20 bytes in. If I use hexdump on the original image from the camera:

0000000 d8ff e1ff cbbb 7845 6669 0000 4949 002a

APP1 is right after the SOI, where exifautotran wants it (and exifautotran works on that file).

I'm not conversant enough with the JPEG standard to have an opinion whether the libjpeg-turbo-progs maintainer is right to insist on APP1 being immediately after SOI. I think this may be a newly introduced requirement from exifautotran. But it's frustrating not to be able to use convert and exifautotran together in a script.

THis applies to both graphicsmagick and imagemagick. I'm not sure if I should file a duplicate bug for imagemagick.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: graphicsmagick 1.4+really1.3.35-1
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Aug 27 19:03:24 2020
InstallationDate: Installed on 2020-04-29 (120 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: graphicsmagick
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Akkana Peck (akkzilla) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.