------- 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)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
