Bug 147260

Same occurs for the following in 0.9.2 final:
PEF files (Pentax K10D RAW files)
DNGs generated by running Adobe DNG Converter 4.1 on RAW files generated by a Panasonic Lumix DMC-LX1

It does not occur for the original RAW files generated by the DMC-LX1.

I can provide examples of all three formats upon request.  I am assuming they are too large to attach (8-10MB for PEF, 16MB for Lumix RAW, 7-8MB for Lumix "DNG from RAW"), but will attempt in a second comment.

Created attachment 21003 [details]
output of dcraw -i -v run on a sample K10D image

Created attachment 21004 [details]
output of exiv2 -p t run on a sample K10D image

Created attachment 21005 [details]
output of dcraw -i -v on a DMC-LX1RAW converted to DNG

Conversion was done by Adobe DNG Converter 4.1 running in WINE

Created attachment 21006 [details]
output of exiv2 -p t on a DMC-LX1RAW converted to DNG

Created attachment 21007 [details]
output of dcraw -i -v on a DMC-LX1 RAW image

exiv2 -p t when run on an unconverted DMC-LX1 RAW results in the following error in stderr and no output to stdout:

Exiv2 exception in print action for file P1000317.raw:
P1000317.raw: The file contains data of an unknown image type

These files are rotated correctly in digikam.  My suspicion is that if EXIF rotation information is present in the raw image, rotation is applied twice.  (Once when converted by dcraw, once more by digikam when it sees EXIF rotation information.)

I do not remember the camera orientation for the above samples, but will attempt a test to see if the problem is double rotation (resulting in a total 180 degree rotation) or no rotation later today.

It is not double rotation.  A test image taken with the K10D's grip (right side of camera when oriented normally) oriented upwards results in digikam displaying the "top" of the image at the right side in "view" mode, indicating that either no rotation is being applied, or the net effect of all rotations is that no rotation is applied.

Also, opening the image with "Edit..." results in correct orientation.

Temporary workaround:

In the "Albums" section of "Configure digiKam...", select "Embedded preview load full image size", this will cause RAW images to be rotated correctly, but will slow down browsing through albums significantly.

It appears that within exifRotate in loadsavethread.cpp, if an image is RAW it is not rotated.  For actual images converted with dcraw, this is the correct behavior.

For embedded previews extracted via kdcraw -e, this is not the correct behavior - the embedded preview is an unrotated JPEG that contains an EXIF orientation tag.

The reason the Panasonic DMC-LX1 unconverted-to-DNG raw images behaved correctly was not that they were missing EXIF data, but that they were missing embedded previews.  The Pentax PEFs and LX1 converted-to-DNG images both had embedded previews.

SVN commit 682425 by mwiesweg:

Handle raw embedded preview differently than raw images loaded by dcraw
(either in full or half size mode).
Thanks to Andrew Dodd for bug hunting.

CCBUG: 147260


 M  +2 -1      loadsavethread.cpp  
 M  +23 -9     previewtask.cpp  


--- branches/extragear/kde3/graphics/digikam/libs/threadimageio/loadsavethread.cpp #682424:682425
@@ -211,7 +211,8 @@
     // Raw files are already rotated properlly by dcraw. Only perform auto-rotation with JPEG/PNG/TIFF file.
     // We don't have a feedback from dcraw about auto-rotated RAW file during decoding. Return true anyway.
 
-    if (DImg::fileFormat(filePath) == DImg::RAW)
+    attribute = image.attribute("fromRawEmbeddedPreview");
+    if (DImg::fileFormat(filePath) == DImg::RAW && !(attribute.isValid() && attribute.toBool()) )
     {
         return true;
     }
--- branches/extragear/kde3/graphics/digikam/libs/threadimageio/previewtask.cpp #682424:682425
@@ -138,34 +138,48 @@
 
     DImg img;
     QImage qimage;
+    bool fromEmbeddedPreview = false;
 
     // -- Get the image preview --------------------------------
 
     // First the QImage-dependent loading methods
     // Trying to load with dcraw: RAW files.
-    if ( !KDcrawIface::KDcraw::loadDcrawPreview(qimage, m_loadingDescription.filePath) )
+    if (KDcrawIface::KDcraw::loadEmbeddedPreview(qimage, m_loadingDescription.filePath))
+        fromEmbeddedPreview = true;
+
+    if (qimage.isNull())
     {
-        // Try to extract Exif/Iptc preview.
-        loadImagePreview(qimage, m_loadingDescription.filePath);
+        //TODO: Use DImg based loader instead?
+        KDcrawIface::KDcraw::loadEmbeddedPreview(qimage, m_loadingDescription.filePath);
     }
 
-    // DImg-dependent loading methods
+    // Try to extract Exif/Iptc preview.
     if (qimage.isNull())
     {
-        // Set a hint to try to load a JPEG with the fast scale-before-decoding method
-        img.setAttribute("jpegScaledLoadingSize", size);
-        img.load(m_loadingDescription.filePath, this, m_loadingDescription.rawDecodingSettings);
+        loadImagePreview(qimage, m_loadingDescription.filePath);
     }
-    else
+
+    if (!qimage.isNull())
     {
         // convert from QImage
         img = DImg(qimage);
+        // mark as embedded preview (for exif rotation)
+        if (fromEmbeddedPreview)
+            img.setAttribute("fromRawEmbeddedPreview", true);
         // free memory
-        qimage.reset();
+        qimage = QImage();
     }
 
+    // DImg-dependent loading methods
     if (img.isNull())
     {
+        // Set a hint to try to load a JPEG with the fast scale-before-decoding method
+        img.setAttribute("jpegScaledLoadingSize", size);
+        img.load(m_loadingDescription.filePath, this, m_loadingDescription.rawDecodingSettings);
+    }
+
+    if (img.isNull())
+    {
         DWarning() << "Cannot extract preview for " << m_loadingDescription.filePath << endl;
     }
 

This works now for all raw test images that I have available here.
It's pretty difficult to get it all right...

Note: I cannot confirm the problem of #0, JPEGs are rotated correctly here.

The JPEGs are of course rotated. This was a fatal bug in module brain of unit Roman. :)

I will check the digikam updates as soon as I have time and will close it if CR2s are rotated.

Roman, could you give an update on this bug, 
does it still persist with current svn?

Many thanks in advance, Arnd

Roman, could you give an update on this bug,
it would be nice if we could close this bug before 0.9.3.
is released.

Many thanks in advance, Arnd

Sorry for the delay, but we had been "off shore" during the last school holidays.

I have the problem that I normally do not keep the SVN version of KDE on my system, compiling all the libs and e.g. digikam just takes too long on my old 2x500, so I currently just use the OpenSUSE 10.2 repositories.

I will try to compile KDE+digikam on my companies box at night time. 0.9.3 is planned for september, maybe I can do it.

Another solution would be to send you (or attach) a landscape Canon CR2 so you can test that on your system.

I wrote

> Another solution would be to send you (or attach) a landscape ...

I meant portrait of course, landscape isn't a problem at all.

just a remark:

you don't have to compile KDE itself, just the relevant libs
as described on the homepage.

Due to problems compiling just the digikam libs I took the following approach:

- digikam SUSE SRPMs: digikam-0.9.2-29.4 for OpenSUSE 10.2
- create RPMs with your two modifications in threadimageio
- install RPMs

And it works, the CR2 previews are rotated

great - thanks a lot for the feed-back!