[Digikam-devel] [Bug 117115] Automatically rotate/flip using camera-provided information (EXIF) modifies image contents

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=117115         




------- Additional Comments From marcel.wiesweg gmx de  2006-04-21 18:38 -------
There is some confusion in this thread.

We have one place in Digikam, one in jpeglossless plugin
- Kipi::JPEGLossLess plugin at jpegtransform.cpp 
- Digikam::exifRotate at exifrotate.cpp
where we use transupp.c from jpegtran to do lossless rotation. The latter is derived from the former and a little bit more simple. Rotation was never meant to be lossy (comments 3, 5, 6, 8, 13), and comment #12 is invalid.
#15 seems to be a completely different problem.

As to the actual problem:
Take a jpeg and jpegtran, and create a losslessly rotated 90° copy. Open both with ImageJ, and rotate either with ImageJ, and subtract them. The result will _not_ be zero.
No go back, and rotate your copy by another 270°. Open both the original and the latest copy in ImageJ, compare them. The result will be zero.

I had the same results with jpeglossless. Camera rotation has the same code as Gilles has checked.

This means: jpegtran rotation (compressed JPEG blocks) and ImageJ rotation (uncompressed data) somehow give different results. If you look at single pixels, there is e.g. 108,122,107 in one image and 109,121,109 at the respective position of the other image. I am no expert on JPEG or jpegtran internals.
However, the rotation is lossless, because you can go back to position 0 and have the same data.

The only remaining question is what "rotating in konqueror" (comment #1) actually means. Is there some other code that is capable of lossless rotation and not derived on jpegtran (dont believe this)? How can I reproduce this?