[SOLVED] digiKam doesn't autorotate images anymore

RobF · 2010-02-22 13:47:43

On 2/8/10, I did a full system upgrade (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 pacman.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". pacman - Q kipi-plugins also said ""kipi-plugins" not found". I then installed kipi-plugins from extra 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.

How can this problem be fixed?

Edit: I've also submitted a bug report to KDE's bugzilla
https://bugs.kde.org/show_bug.cgi?id=228056

Last edited by RobF (2010-03-04 19:49:50)

ise · 2010-02-22 14:13:01

I have seen the same problem. Maybe this is related to this bug report: https://bugs.kde.org/show_bug.cgi?id=226838
Can you try to rotate the images in gwenview, started from a shell?

EDIT: You have written a lot of text...

Last edited by ise (2010-02-22 14:14:26)

RobF · 2010-02-22 15:47:28

In my post I referred to the problem of digiKam v.1.1.0 not autorotating images correctly anymore when it's downloading and processing them from the camera, whereas v. 1.0.0 did so correctly (without to my knowledge having any Kipi plugins installed). I.e. v.1.1.0 is configured to autorotate but it doesn't really do it; it doesn't rewrite the EXIF orientation tag. It does display portrait images correctly in its own viewer (and so does Gwenview) but the other programs don't when they access these images in the album directory. They show the wrong orientation but none of them, Gwenview included, has any problem in allowing me to manually rotate the image to the correct orientation that can then be passed on e.g. to Thunderbird.

Of course, I could process all the images taken in portrait orientation manually, e.g. in GIMP, but why do so when digiKam 1.0.0 and earlier used to do it automatically. Besides, the image rotation in digiKam is supposed to be lossless which may not be true if I use other programs.

Again, a short summary: portrait image from camera downloaded with digiKam -> displayed correctly in digiKam (and Gwenview) but not really rotated according to EXIM tags -> can be rotated further (another 90 deg) and saved in digiKam or Gwenview and can then be displayed correctly in GIMP, Firefox and Thunderbird but would not be correctly displayed anymore in digiKam and Gwenview.

I haven't figured out how to rotate images in Gwenview from the CLI, hence can't produce any error messages.

Sorry to be so verbose again.

hcooh · 2010-03-04 00:37:30

I have also the same problem.
Here is the error message when rotating with Gwenview from CLI :

<code>gwenview(12103) Gwenview::JPEGErrorManager::errorExitCallBack: Bogus virtual array access
gwenview(12103): libjpeg error in src
</code>

Does anyone have some feedback about this bug ?

RobF · 2010-03-04 19:48:05

This bug is due to the fact that Digikam 1.1.0 embeds a source file from the old libjpeg-6 that closely accesses parts of libjpeg and silently breaks with libjpeg8, which is the version Arch upgraded to end of January 2010. As a consequence, the rotation fails; it's simply not done. This problem is being worked on by the KDE/digiKam devs, see https://bugs.kde.org/show_bug.cgi?id=228483 ("digikam-1.1.0 with system libjpeg-8 breaks image rotation").

Until this is solved permanently, one can work around it, e.g. by batch processing the images downloaded by digikam 1.1.0 / libjpeg8 with the utility "jhead" which does exactly what digiKam 1.0.0 /libjpeg7 used to do, i.e. lossless rotation of jpeg images that were taken in portrait orientation and setting their exif orientation tag to "normal".

# pacman -S jhead
$ jhead -autorot *.jpg

Last edited by RobF (2010-03-04 19:50:31)

hcooh · 2010-03-06 00:13:43

Hello , thanks for the tip of jhead.
But as my camera don't record this exif orientation tag, is there another way to rotate pictures manually ?
I tried

jpegtran -rotate 90 file.jpg

But it fails !

Last edited by hcooh (2010-03-06 00:14:42)

RobF · 2010-03-06 11:15:25

My understanding is that the currently most widespread jpeg format includes the metainfo of the exif headers, and any program that is able to rotate an image and reset the exif orientation tag to "normal" should be able to permanently upright images that were taken in portrait orientation.

digiKam and some other programs that are part of the KDE program suite (I think that might also include showPhoto) are currently broken, as long as they rely on libjpeg-8: they may be able to upright the images as they display them but they don't permanently reset the orientation tag.

I tried with a couple of programs to rotate portrait orientation photos that I'd downloaded with digiKam. feh wasn't able to rotate these images 90 deg ccw, as needed; it gave me the error "Bogus virtual array access". GIMP was able to do it; it rewrote the orientation tag from "left, bottom" to "left, top" (i.e. normal) and that turned the images upright in all jpg viewers that I tested but I'm not sure it can do this losslessly (perhaps that depends in the "Quality" setting). Make sure you make a copy of your original photos in a separate folder before you try any of these operations.

supercow · 2010-03-29 18:16:57

Hello,

the problem should be solved with digikam 1.2.0.

076 ==> 228483 : digiKam 1.1.0 with system libjpeg-8 breaks image rotation.

.

regards
Olivier

maddojf · 2010-03-31 23:13:27

I just updated to digikam 1.2.0, but I still get the "Failed to Rotate Image" error.

anteater · 2010-04-01 08:06:55

Same here.

jxy · 2010-04-02 15:32:10

maddojf wrote:

I just updated to digikam 1.2.0, but I still get the "Failed to Rotate Image" error.

Same here. Although showfoto can rotate image without problem. So is it an issue related to kipi-plugins?

gartrog · 2010-04-20 20:38:01

Same problem here. Has anyone got some news ?

troncoso · 2010-05-04 16:19:59

hcooh wrote:

I tried
jpegtran -rotate 90 file.jpg
But it fails !

jpegtran sends output to standard output, so you need to capture it into a file like this:

jpegtran -rotate 90 file1.jpg > file2.jpg

As I'm getting frustrated about digikam's rotating image bug, I tried that and it works.
Cheers

Arch Linux

#1 2010-02-22 13:47:43

[SOLVED] digiKam doesn't autorotate images anymore

#2 2010-02-22 14:13:01

Re: [SOLVED] digiKam doesn't autorotate images anymore

#3 2010-02-22 15:47:28

Re: [SOLVED] digiKam doesn't autorotate images anymore

#4 2010-03-04 00:37:30

Re: [SOLVED] digiKam doesn't autorotate images anymore

#5 2010-03-04 19:48:05

Re: [SOLVED] digiKam doesn't autorotate images anymore

#6 2010-03-06 00:13:43

Re: [SOLVED] digiKam doesn't autorotate images anymore

#7 2010-03-06 11:15:25

Re: [SOLVED] digiKam doesn't autorotate images anymore

#8 2010-03-29 18:16:57

Re: [SOLVED] digiKam doesn't autorotate images anymore

#9 2010-03-31 23:13:27

Re: [SOLVED] digiKam doesn't autorotate images anymore

#10 2010-04-01 08:06:55

Re: [SOLVED] digiKam doesn't autorotate images anymore

#11 2010-04-02 15:32:10

Re: [SOLVED] digiKam doesn't autorotate images anymore

#12 2010-04-20 20:38:01

Re: [SOLVED] digiKam doesn't autorotate images anymore

#13 2010-05-04 16:19:59

Re: [SOLVED] digiKam doesn't autorotate images anymore

Board footer