Version: 1.1.0-1 (using KDE 4.3.4) Compiler: gcc 4.4.3-1? Binary packages compiled by Arch Linux devs OS: Linux Installed from: Archlinux Packages On 2/8/10, I did a full system upgrade of my Arch Linux install (pacman -Syu) which among many other things upgraded digiKam 1.0.0-1 -> 1.1.0-1. I'm using kernel 2.6.32.7 SMP with KDE 4.3.4. Before this upgrade: * digiKam appeared to have automatically rotated images taken in portrait orientation when it downloaded them from the camera and had displayed them in the correct orientation within digiKam. * Other programs (Gwenview, GQView, GIMP, photoShow, KolourPaint, Okular, Firefox, Thunderbird) also display them in the correct orientation, including Thunderbird when I attach them to emails, to be displayed inline. * When I look at the EXIF metadata of these images, under "Orientation" it says "top, left" for all of them, and they are all correctly displayed in the proper orientation by all of these programs, regardless of whether they were taken in landscape or portrait orientation. * In digiKam's Config Settings>EXIF Actions, both "Show images/thumbnails rotated according to orientation tag" and "Set orientation tag to normal after rotate/flip" are checkmarked. * The only files that were ever written by digiKam to the album directory were files with the names IMG_xxxx.JPG. * According to my install log file, the currently installed version of libkipi is v. 0.1.6-2 (installed in 08/2008 and never upgraded). There is no record of kipi-plugins ever having been installed (before the upgrade). After this upgrade: * digiKam still seems to flash a message "EXIF rotated ..." every time it downloads an image taken in portrait orientation from the camera, and it also displays them correctly. * Gwenview and ShowPhoto also display images taken in portrait format after this upgrade correctly. However, GQView, KolourPaint, Okular, Firefox and Thunderbird display these images incorrectly, i.e. in landscape format, 90 deg cw rotated from the way they should be. * GIMP also displays them in the same incorrect way, and for these images it says "According to the EXIF data, this image is rotated" and "Would you like GIMP to rotate it into the standard orientation?" When I then click on "Rotate", GIMP does rotate it and shows it in the correct orientation. * When I look at the EXIF metadata of images taken and downloaded after the upgrade, under "Orientation" it says "left, bottom" for the images taken in portrait orientation and "top, left" for those taken in landscape orientation. Portrait images saved in GIMP after I'd clicked on "Rotate", are now displayed correctly by all programs and the EXIF orientation tag now reads "top, left". * In digiKam's Config Settings>EXIF Actions, both "Show images/thumbnails rotated according to orientation tag" and "Set orientation tag to normal after rotate/flip" are still checkmarked. * digiKam now also writes a file .digikam-exifrotate-xxxx.jpg of 4-12 KB size to the album directory for every image downloaded that was taken in portrait format (and supposedly rotated). The numbers xxxx in these .digikam-exifrotate-xxxx.jpg files do not match the numbers xxxx of the corresponding IMG_xxxx.JPG image files. * When I looked at Settings>Configure digiKam>Kipi Plugins in the new version 1.1.0-1, it said "No Kipi plugins found". The Arch program for listing installed packages (pacman - Q kipi-plugins) also said ""kipi-plugins" not found". I then installed kipi-plugins from the mainstream extra repo without any apparent problems which installed the following four targets: libusb1-1.0.6-1, libdc1394-2.1.0-1, opencv-2.0.0-4, kipi-plugins-1.1.0-1. * When I then looked at Kipi Plugins in Settings, I now find 25 of them installed and accessible from the main interface, all of them checkmarked, incl. one called "JPEGLossless (A tool to rotate/flip images without losing quality)". Yet after installing all these plugins, the behavior of digiKam did not change in the slightest from what I described in the preceding paragraphs ("after the upgrade"). In sum, it looks to me as though digiKam v. 1.1.0-1, when it downloads photos taken in portrait orientation, rewrites EXIF metadata saying the image has been rotated (at least that's what GIMP diagnoses) but it doesn't set the orientation tag to normal ("top, left") after the rotation. digiKam, showPhoto and Gwenview are still able to rotate such images and display them correctly but the other programs seem to go by the unaltered EXIF orientation tag and hence display these images incorrectly. Since this retagging appears to be the job of the Kipi JPEGLossless plugin, one would conclude that there is something wrong with this plugin. How I managed to have digiKam v. <1.1.0 handle all of this correctly without having a Kipi plugin installed I don't understand. Many thanks for your wonderful work on KDE which I have enjoyed in Linux since 2003. This is my first KDE bug report.
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