Bug 148621

Could you please try 0.9.2 and report back.
If I remember correctly, some images rotation issues 
were fixed with that release
(see http://www.digikam.org/?q=download/binary/).

thank you, arnd. it's working fine in 0.9.2; i guess you can close the ticket.

Thanks a lot for the feedback! Closing this bug as fixed.

I am using the newest digikam version of the openSUSE backports repository (0.9.2-29.1) and I still have a similar problem. Rotating left or right always rotates the images 180°. When I do it a second time, though, it rotates 90° or 270° as it is supposed to.

So this bug doesn't seem to be resolved.

Jens,

Rotation is handle using Exif informations. Try to use the last stable release of Exiv2 library on your computer.

Gilles

I am having the same problem.  Using 0.9.3-svn(yesterday) and libs from svn also.  exiv2 is 0.14.

If I rotate 'right' it goes 180 degrees.  If I rotate 'left' it rotates 90 degress counterclockwise as expected (but usually only on the second click). After a few clicks on the photo, rotation then behaves as expected.

This may have something to do with the original orientation since it is different for portrait and landscape. 

If rotate normal landscape orientation to right:  rotates 90 clockwise (as expected)
If rotate portrait/vertical orientation to right: rotates 180 degrees.
If rotate portrait/vertical orientation to left: rotates 90 degrees counterclockwise as expected, but have to click twice.

It seems to happen only on pictures from my Canon SD450.  I have done limited testing of other cameras (Canon S45 and Canon Rebel XT plus various other files) and they seem okay.

Some examples from the SD450 camera can be found here..
http://bacon.no-ip.info/digikam/

Geoff

As a followup - 
It does happen with photos from other cameras (my 2 other Canons). 
This problem appears limited to pictures with initial portrait/vertical orientation.

Also tried exiv2 0.15 and still same problem.

A .diff of the output from 2 files is also on the website which might provide some insight. The one labeled rotated was rotated a few times and put back to the initial layout.

Hope this helps.

Created attachment 21520 [details]
Removing some code that might break rotation

I remember I had some similar problems a long time ago, and I have found this
changes here in my KDE3 svn version. Please try if it fixes your problem. I
cannot remember the details of the problem anymore.

Forgot to mention, the directory to apply this patch is kipi-plugins/jpeglossless

Your patch solved the problem. It is working as expected now. Thanks.  

Thanks for the feedback - I re-open this bug until the
patch is commited (and backported to KDE4).

SVN commit 707626 by mwiesweg:

If the image had already an exif rotation flag set, this code part would cause
this taken into account twice, add the JPEG specific code does its own
sophisticated checking with matrix multiplication.

BUG: 148621


 M  +8 -0      actionthread.cpp  


--- branches/extragear/kde3/libs/kipi-plugins/jpeglossless/actionthread.cpp #707625:707626
@@ -77,6 +77,13 @@
     {
         KIPI::ImageInfo info = m_interface->info( *it );
 
+        /*
+        Removing this code:
+         - for JPEGs, jpegtransform is using the Exiv2Iface and matrix multiplication
+           to compute the mathematically correct rotation (taking flip operations into account,
+           the code below only angles). Metadata tag is reset.
+         - For ImageMagick, no metadata is taken into account, and no metadata is changed!
+           Angle from host application still applies.
         // Don't use the host angle in case of auto-rotation (Rot0)
         if (val != Rot0)
         {
@@ -105,6 +112,7 @@
             else
                 val = Rot0;
         }
+        */
 
         Task *t      = new Task;
         t->filePath  = QDeepCopy<QString>((*it).path()); //deep copy