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

------- 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         
           Summary: Automatically rotate/flip using camera-provided
                    information (EXIF) modifies image contents
           Product: digikam
           Version: 0.7.4
          Platform: unspecified
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: roger.larsson norran net


Version:           0.7.4 (using KDE 3.4.2 Level "b" , SUSE 10.0)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.13-15-default

Camera -> <specific camera> -> Advanced
"Automatically rotate/flip using camera-provided information (EXIF)"
Will modify your images actual contents due to an lossy recompression (I will add difference image later)

Doing this should NEVER be the default!

You can test this with ImageJ
1. Download to a directory without automatic rotation.
  [digikams view of this directory will be with
   some images in wrong direction]
2. Download to another directory with automatic rotation.
Take a look in both directories using konqueror - they
will be oriented the same.

Use ImageJ to open the files (one will not be rotated).
Use Image->Rotate
Use Process->Image Calculator
 Image1: select the first image
 Operation: subtract
 Image2: select the second image
 Create New Window
 32-bit Result
The resulting image is not all zero...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 roger.larsson norran net  2005-11-26 21:36 -------
forgot: When rotating in konqueror and doing the same analyze.
The result WILL be all zero!
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 roger.larsson norran net  2005-11-26 21:50 -------
Created an attachment (id=13656)
 --> (http://bugs.kde.org/attachment.cgi?id=13656&action=view)
Difference output from ImageJ (first saved as tiff then converted to png)

Changing the compression level to 100% does not help much
(or it was not used in this operation, since image sizes
are the same...)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 roger.larsson norran net  2005-11-26 21:53 -------
A much better handling of this would be to do it the same way as konqueror does. Use the rotation information on display only!
With an non default option to do the lossy permanent rotate (including resetting the EXIF)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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         
tomalbers kde nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ach mpe mpg de



------- Additional Comments From tomalbers kde nl  2006-02-04 21:16 -------
*** Bug 115168 has been marked as a duplicate of this bug. ***
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 tomalbers kde nl  2006-02-05 01:14 -------
Op zondag 5 februari 2006 00:24, schreef Thorsten Schnebeck:

> > Le Samedi 4 F�vrier 2006 22:20, Sebastian R�der a �crit :
> > > Issues like described in this bug report are from my point of view an
> > > SERIOUS PROBLEM!
>
> I would like to second Gilles.
>
> First a comment to rotation and JPG: Every better photoviewer supports the
> EXIF rotation flag. So if you use or can correct the rotation flag there is
> no need to have an active rotation or a special jpeg lossless rotation
> (that digiKam also supports, when it knows the filetype) at all.
>
> The only thing you have to know when working with digiKam is, that when you
> use the IE you work with raw picture data like in every other graphic
> editor (e.g. gimp, krita, cinepaint, photoshop) The problem is not a
> limitation of the IE - its the other way round. If the IE could only
> manipulate JPGs I would not use digiKam any longer.
>
> You use the wrong format - its simple as that. You have to understand that
> JPG is an im- & export format. Do not use it in a complex workflow if you
> have high quality demands. JPG as a lossy format is designed for transport
> - that why you can find it in every camera and every photo web service. Its
> minimize the level of storage and bandwidth. These are  expense factors for
> digicams and web services. But when it come to quality you will not find
> jpeg any longer, then RAW, Tiff and PNG rules.
>
> But you really see a visual difference when watching JPEGs written with 99%
> quality settings from the IE?
>
> I also think there is one limitation with JPEG and IE: The quality setting
> should be visible and adjustable in the "save as" dialog when using a lossy
> file format. The simple save comand is dangerous. I hear too often that
> people lose image details cause they used to use a 65%-75% default JPEG
> quality setting for web and slideshows.
>

Hi Thorsten,

I think we all agree. Now my proposal for this problem:

        Remove the auto-rotate feature from the camera download dialog.

We can display them rotated, so the auto-rotate feature is not needed and
looses data.

Viewpoints?

Toma

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 thorsten.schnebeck gmx net  2006-02-05 01:38 -------
As this option limits the quality during download I vote to remove this option. Users who work with digicam that do not support the rotation flag have still two options in the album view: lossless rotation or a forced rotation flag correction. Options attached to downloading should never reduce quality.

HTH

  Thorsten
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-02-05 10:40 -------
I'm not favorable to remove this option.

There is an lossless JPEG rotation technic that we can used. Its used by jpegLossLess kipi plugin. You need to backport any code to do it properly.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Oliver Dörr]

------- 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 oliver doerr-privat de  2006-02-05 10:48 -------
I'm using this option and to be honest i can't see any reason why to remove it! Ok, it seems not to be losless, but that could be documented. On the other side it  is very comfortable that the images are orientaed in the right way.

Personally i'm willing to accept the loose of image quality. Perhaps the option should not be selected b y default (if it is?), but it's a really good option and the user should decide by it's own if he uses it!

Oliver
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 tomalbers kde nl  2006-02-05 15:54 -------
Op zondag 5 februari 2006 10:40, schreef Gilles Caulier:
> There is an lossless JPEG rotation technic that we can used. Its used by
> jpegLossLess kipi plugin. You need to backport any code to do it properly.


I failed in that earlier.

Toma
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-02-05 17:48 -------
Ok, Toma, let's me any time to check the code. I will trying to do it...

But don't remove this option (:=)))...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-02-09 16:00 -------
I have checked the code provide by Renchi between

- Kipi::JPEGLossLess plugin at jpegtransform.cpp
- Digikam::exifRotate at exifrotate.cpp

... about lossless transformations operated on JPEG. The codes are similar.

Roger, can you test kipi jpeglossless on your downloaded jpeg file from camera (without process auto-rotate during download) and look if you find the same problem

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 roger.larsson norran net  2006-02-09 23:32 -------
I do not really think I need to test. I will explain why

Digikam::exifRotate - the name of this function indicates that the image is
rotated by modifying the rotation exif information tag.

Decompressing one such image happens in two steps.
1) Identical code is decompressed to the same image matrix
2) The image matrix is rotated to the direction indicated by the exif tag.
The first step is identical for ALL rotation directions, compare with negative
film. The second step will not destroy any image data.

What Digikam does/did when downloading is/was the following.
(When finding rotation)
1) Decompress to image matrix
2) Roatate to direction indicated by exif tag
3) Reencode this new image matrix
4) Save this reencoded image
5) Optionally reset the exif tag - should never have been an option. If the
   image is rotated to the correct direction, exif have to be reset.
Trying to use Digikam::exifRotate will fail. Why? Jpeg from camera indicates
that camera was rotated right 90 degrees when taking the picture.
Rotating the picture right by using exifRotate will only result in an exif indicating rotated right by 180 degrees.
When viewed from a viewer that uses exif the picture will be upside down and
when viewed from a viewer that does not use exif it will look like no rotation
at all (as the camera sees it).

Having a destructive rotate by exif has some uses (but it should never EVER be
a hidden default!)
* If you do not care about the possible quality loss (you will never get it
  back)
* If your tools do not support exif
* If you use your tools in batch mode (many images at the same time, if only
  one image at the time it is easy to use that tools image rotate)
The only tools that I run into with this problem is the Windows explorer and
image viewer (but I am sure they will be fixed) and Digicam icon view...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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         
gilles vonet lu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gilles vonet lu
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 martinrehn hotpop com  2006-03-30 10:44 -------
Created an attachment (id=15370)
 --> (http://bugs.kde.org/attachment.cgi?id=15370&action=view)
Script to rotate images with no loss of information (as it appears in the
Debian libjpeg-progs package)

The script exifautotran (attached) does exactly the right thing;

1) Rotates losslessly, using jpegtran
2) Preserves all metadata, using the switch "-copy all" to jpegtran
3) Resets orientation, using jpegexiforient -1
4) Includes error handling
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-04-03 14:12 -------
No need script here. we working using C++...

In digiKam core, we use digikam/libs/jpegutils/transupp.c to tranform lossless a JPEG file. This implementation come from  jpegtran application.

http://linux.about.com/library/cmd/blcmdl1_jpegtran.htm

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerrit Hannaert]

------- 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 degerrit web de  2006-04-19 21:18 -------
Sorry for the Bugzilla spam but I am an end-user and was bitten by this just today. I was surprised Digikam was rotating images upon download and destroying EXIF information, since I was used to Digikam lossless rotate plugin :-(
In my opinion this should either be a default and lossless operation, or it shouldn't be default and should be described as lossless in the Advanced section.

I am using Digikam 0.8.1 on Ubuntu Dapper beta.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 ach mpe mpg de  2006-04-19 21:47 -------
Hi, the loss of exif infos should be fixed AFAIR.  If you have time
can you try:

http://www.mpe.mpg.de/~ach/tmp/digikam_0.8.1+0.8.2-beta1-0_i386.deb

Note this is an unofficial build of the beta1 tarball I'm
preparing (final beta1 tarball will be slightly modified).

I hope to get beta1 into dapper, despite the version freeze.

Achim
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[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?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 roger.larsson norran net  2006-04-21 21:05 -------
Konqueror makes use of EXIF Image Orientation information.
It only affects how Konqueror DISPLAYS the image.
If this tag is changed the image will be rotated accordingly
(when viewed in Konqueror).
Since konqueror does rotate the images according to this tag
when viewed. The only thing konqueror has to do to rotate
an image is to change the value of this tag!

The name Digikam::exifRotate has confused me. I thought it ment
"rotate by modifying exif info" when it really meant
"rotate image according to exif".

To solve most problems digikam should honor the EXIF Image Orientation
tag, it can be read by using libexif.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel