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...
forgot: When rotating in konqueror and doing the same analyze. The result WILL be all zero!
Created attachment 13656 [details] 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...)
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)
*** Bug 115168 has been marked as a duplicate of this bug. ***
Op zondag 5 februari 2006 00:24, schreef Thorsten Schnebeck: > > Le Samedi 4 F
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
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
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
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
Ok, Toma, let's me any time to check the code. I will trying to do it... But don't remove this option (:=)))... Gilles
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
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...
Created attachment 15370 [details] 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
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
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.
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
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?
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.
Hi Roger, this was discussed long ago. At the end: o not all popular image viewers or all OS honour EXIF orientation o it's very confusing for 'newbie' users when image is once roated once not. o Play save and rotate contents Please add a wishlist (if it does not exists) about a mode where digikam consitently uses/modifies exif orientation instead of rotating the images. I'll add my vote. Achim
I take back everything (almost) since I noted that it is not konqueror that honors EXIF but rather the camera (Canon) that stored a rotated thumbnail in the file. My new camera stores a thumbnail as taken orientation. My new camera can also save original RAW (NEF) at the same time as it stores high quality JPEGs. I could settle with the following: When first entering download dialog digikam starts a wizard that asks the user if (s)he wants convenience or uncompromised quality. convenience: autorotate images, create a new directory uncompromised: no autorotate, the camera file is unmodified. Then add a note about that individual selections can be made in the advanced settings.
Please close this file and re-open a new one. The subject can be confuse with the title. When developpers check B.K.O, they read titles in first, not the all the files content (:=)))... Thanks in advance. Gilles Caulier
About lossles vs. not lossless: Lossless rotation is lossless in a way that there is no recompression. But the resulting image looks (very!!) slightly different to a image rotated within an image viewer. Calculating the difference between both is *not* the right thing to do! You should rotate the auto-rotated image by 270 degrees (e.g. with jpegtran, which is lossless) and compare the result with the not-rotated version. There will be no difference. => Digikam's autorotation makes the image slightly different to the non-rotated (original) version but neither version is better (or worse) than the other. That's just an effect of the Jpeg color subsampling and things like that. So please do not remove this feature!
If noone objects I would like to close this bug. What Matthias pointed out (#22) is what I tried to say, that is, there is no information loss. The last wish of Roger (#20) comes down to UI changes if I understand correctly. There are too much different problems discussed here.
Yes Roger, I'm agree with the explaination of Marcel. Please close this file and open new one about gui improvements. Thanks in advance Gilles Caulier
#22 Is correct. Read up a bit on jpegtran and noted that if the result is rotated back you get the same image again - I have verified this too. => this bug report is now INVALID (provided that digikam uses jpegtran routines for all operations), remaining is not even the wished UI modifications. Well maybe a tooltip explaining this...