Bug 303170

Summary: Auto-rotate should be loss-less while importing
Product: [Applications] digikam Reporter: bugzilla
Component: Import-PostProcessingAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 2.7.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 5.1.0

Description bugzilla 2012-07-07 22:01:57 UTC 
When "Auto-rotate/flip image" is checked on import, photos are rotated automatically according to their EXIV tag which is fine. Unfortunately this seems to be done in a lossy manner, meaning rotating the image and saving it anew. This should be done using a lossless rotation instead.

Reproducible: Always
Comment 1 Marcel Wiesweg 2012-07-08 11:26:54 UTC 
Which image format are you referring to?
Comment 2 caulier.gilles 2012-07-08 15:58:40 UTC 
Autorotation is performed by JPEG Loss Less methods, provided by libjpeg...

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/jpegutils/jpegutils.h#L84

Gilles Caulier
Comment 3 bugzilla 2012-07-08 21:10:34 UTC 
Yes, I'm referring to JPEG. But how do you explain that those pictures are about 20% smaller after the import? I know JPEGs can often be optimized but I cannot explain a change from 900k to 700k...?
Comment 4 bugzilla 2012-07-08 21:38:53 UTC 
BTW: When loading them into GIMP, setting the second image to "difference" and boosting the curves way up, I can actually see, that there's a difference between those two pictures. So it cannot be a lossless rotation imo.
Comment 5 caulier.gilles 2012-07-09 10:10:42 UTC 
Can you share 'before' and 'after' JPEG images to check diff.

I don't know how you compare both image into gimp, but i'm sure that you need to rotate one image to check color channel contents. Rotation can change image color data... This can be not lossless, depending of algorithm used in background.

The file sizes diff can become from metadata where digiKam will record information. This operation do not touch image data !

Gilles Caulier
Comment 6 caulier.gilles 2014-09-01 08:40:02 UTC 
Do you see my previous comment.

Without images samples it will be difficult to investigate.

Gilles Caulier
Comment 7 caulier.gilles 2015-06-28 09:42:36 UTC 
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier
Comment 8 caulier.gilles 2015-08-21 07:06:10 UTC 
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.
Comment 9 caulier.gilles 2016-07-15 16:16:36 UTC 
With digiKam 5.0.0, I cannot reproduce this problem.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier