Summary: | digiKam doesn't autorotate images anymore | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | robf <rglk1> |
Component: | Thumbs-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, marcel.wiesweg |
Priority: | NOR | ||
Version: | 1.1.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 6.3.0 | |
Sentry Crash Report: | |||
Attachments: |
Debug output
File written by digiKam |
Description
robf
2010-02-22 15:29:37 UTC
There are some misconceptions here, so quickly what happens is: Your camera sets the exif tag. Applications that know how to deal with Exif flags will display your photos correctly, others will not. For these, there is a function to rotate the actual image data according to the Exif flag (and in due course reset the exif flag to normal). This is embedded into digikam, it's not the kipi plugin (which also can do that). Now, something is wrong in this operation, it does not complete. There is normally debug output on the console while downloading photos from the Camera, some lines starting with Digikam::exifTransform. Could you please check this. Be sure to enable 50003 in kdebugdialog. Created attachment 41198 [details] Debug output See comment #2 Created attachment 41200 [details] File written by digiKam See comment #4 In the meantime, I've done a full system upgrade of my Arch linux install which included upgrading digiKam 1.1.0-1 -> 1.1.0-2. The problem remains exactly the same. I took two photos of the same scene, #5142 in portrait orientation and #5143 in landscape orientation, and downloaded them into digiKam. The exif orientation tag after the import of #5142 says "left, bottom". The pertinent debug output for the download is attached as RFDigiKamDebugOutput.txt. I've also attached the file .digikam-exifrotate-7305.jpg that digiKam wrote for #5142. Which version of libjpeg are you running? 6 or 8? (In reply to comment #5) > Which version of libjpeg are you running? 6 or 8? I'm using libjpeg 8-2. Before 02/08/10, I ran digiKam 1.0.0 and libjpeg 7 and everything was fine, then I upgraded to digiKam 1.1.0 and libjpeg 8 and the autorotate problem materialized. [2010-02-08 15:54] upgraded libjpeg (7-1 -> 8-2) [2010-02-08 15:57] upgraded digikam (1.0.0-1 -> 1.1.0-1) On 2010-01-30, the Arch devs posted a note saying that "the new versions of libjpeg and libpng required a rebuild of all dependent packages" and that a large number of rebuilds was required. Subsequent to this, there was a lengthy thread (41 posts) in the Arch Linux forum (http://bbs.archlinux.org/viewtopic.php?id=90067) of people writing in and complimenting the devs for an excellent job done in rebuilding all these packages and causing essentially no problems. However, a little later, someone wrote in soliciting reports and descriptions of problems caused by this major upgrade (http://bbs.archlinux.org/viewtopic.php?id=90457). He had a number of takers (13 posts) but nobody among them reported problems with digiKam. If you think the problem is likely to lie downstream, i.e. with the Arch rebuild of the digiKam package, then I will submit this bug to the Arch bug tracker. For now, I can work around this (minor) problem using jhead in batch mode. Another thing I noticed yesterday when I ran digiKam to download 60 photos from my camera: for EVERY photo downloaded, digiKam flashed the message "exif-rotate file IMG_....." in the status bar, including for all those taken in standard orientation. I'm pretty sure this didn't happen with v. 1.0.0. Digikam embeds a source file from libjpeg-6 which closely accesses parts of libjpeg and silently breaks with libjpeg8. This problem is not yet solved, see the other bug. It clearly explains your problems though - the rotation fails and is simply not done. *** This bug has been marked as a duplicate of bug 228483 *** (In reply to comment #7) > Digikam embeds a source file from libjpeg-6 which closely accesses parts of > ... Thanks for your help, Marcel. Until this is fixed, I'll get by with jhead. Fixed with bug #228483 |