[Digikam-devel] [Bug 144604] New: Rotation causes Exif data corruption

[Isaac Wilcox]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=144604         
           Summary: Rotation causes Exif data corruption
           Product: digikam
           Version: unspecified
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: iwilcox iwilcox me uk


Version:           0.9.1 (Ubuntu package 2:0.9.1-1ubuntu4) (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
OS:                Linux

Hi,

Rotating an image in Digikam (either using [right click] -> Rotate -> Rotate 90 or using Image -> Rotate) causes a subtle corruption of the Exif tag for me.  Some Exif tags relating to the image dimensions get added/rewritten with an invalid type.

I've added the hex ID for each tag in brackets after the exiv2 name, because some programs/Exif descriptions out there seem to use non-standard names for the tags (*sigh*).

The original photo has two tags relevant to this bug:
  Exif.Photo.PixelXDimension (0xA002)
  Exif.Photo.PixelYDimension (0xA003)

According to the Exif spec (2.2, page 26-27), these tags must be of Exif type SHORT or LONG, and before doing the rotate the exiv2 commandline tool tells me they're correct:
  $ exiv2 -p t test.jpg | grep 'Exif.Photo.Pixel[XY]Dimension'
  Exif.Photo.PixelXDimension                   Short       1  2272
  Exif.Photo.PixelYDimension                   Short       1  1704

After doing doing the rotation they've changed to SLONG, which isn't valid:
  $ exiv2 -p t test.jpg | grep 'Exif.Photo.Pixel[XY]Dimension'
  Exif.Photo.PixelXDimension                   SLong       1  1704
  Exif.Photo.PixelYDimension                   SLong       1  2272


Similarly, the rotation adds two tags that the original never had:
  Exif.Image.ImageWidth (0x0100)
  Exif.Image.ImageLength (0x0101)

Again, the Exif spec (2.2, page 17) says these must be SHORT or LONG, not SLONG, but they get written as SLONGs:
  $ exiv2 -p t test.jpg | grep 'Exif.Image.Image.*th'
  Exif.Image.ImageWidth                        SLong       1  1704
  Exif.Image.ImageLength                       SLong       1  2272

This causes at least one tool (exifiron) to declare the Exif tag invalid and (understandably) refuse to touch the file.

I suspect that libexiv2 is being given the wrong type by Digikam/the Kipi Lossless plugin/both, because exiv2 does pick sensible default types, but is happy to let you override them (at least in the commandline program).

Two things that might be worth noting here.  Firstly, I'm on x86-64, which might somehow have a bearing on types Digikam is choosing.  Secondly, exiv2 0.12, the version on my Ubuntu Feisty system, has a bug that prevents tag types from being rewritten unless the tag grows (see http://dev.robotbattle.com/bugs/view.php?id=0000452).  It's fixed in 0.13, but the workaround that'll always fix the tags is to remove them and re-add them, e.g. for each broken one do something like:
  $ # save the dimension somehow into $saveddimension, or your head
  $ exiv2 -M"del Exif.Photo.PixelYDimension" modify IMG_2255.jpg
  $ exiv2 -M"add Exif.Photo.PixelYDimension $saveddimension" modify IMG_2255.jpg
exiv2 will choose a valid default type, but you can override it if you're paranoid.

Cheers,

Zak (Isaac Wilcox)