GNOME Bugzilla – Bug 329129
Rotating garbles image irrecoverably
Last modified: 2007-02-11 19:37:01 UTC
Steps: 1. Open the attached image in gThumb. 2. Rotate 90 degrees counterclockwise. Actual results: The image rotates. However, the 4 left-most lines of the original image are garbled in the end result. Meaning data loss and therefore a critical bug. Expected results: A perfectly rotated image. Version: gThumb 2.7.2
Created attachment 58355 [details] Original image
Created attachment 58356 [details] Rotated image (magnified)
Still the same in 2.7.3.
And also in 2.7.5.1.
I'm not sure there is data loss here, if you rotate back the image seems to be restored correctly.
You're right, the original image can be recovered this way. However, my intent is to print rotated images ... Still a major bug because gThumb prevents me from doing so.
Version 2.7.7 still exhibits the bug.
I don't think this is a gthumb bug, exactly. Running: jpegtran -rot 270 nano_4514.jpg > rot.jpg produces the same problem (garbled edge), so I think the problem is either: 1) There is something wrong with the sample file. 2) There is something wrong with the libjpeg / jpegtran code. Can you reproduce this on any other images?
OK, after a little research: truly lossless jpeg rotation is only possible if the vertical and horizontal dimensions are both multiples of 8 (jpeg MCU = minimum coded unit = 8). For details, see the jpegtran man page, http://www.impulseadventure.com/photo/rotation-partial-mcu.html, and http://www.impulseadventure.com/photo/lossless-rotation.html. If the dimensions are not multiples of 8, the program has three basic options: 1) Crop the photo to the nearest multiple of 8 (jpegtran -trim option), or, 2) Garble the edges slightly, or, 3) Use the "generic" rotate options (swap x and y and save, with re-compression) All approaches result in data loss! Currently gthumb opts for #2. In contrast, xnview opts for #1 (cropping), with a warning. I think that images with 8x8 multiples should use the jpeg lossless rotate, but all other images should use the generic rotate routine (#3), to keep it simple for normal users. What do other people think?
Maybe gthumb should offer the choice of a "lossless" cropped rotate for odd-size jpeg images, or "lossy" rotate with a compression-quality slider (and just use the lossless rotate automatically for 8x8 jpegs).
*** Bug 141588 has been marked as a duplicate of this bug. ***
This is fixed in CVS (head). If the image has an Exif orientation tag, and the image dimensions are not multiples of 8, then Tools>Rotate will change the orientation tag to accomplish the rotation (overriding the selected rotation mode, if necessary). The sample image above does have an Exif orientation tag, so it can be losslessly rotated by changing the tag. If the image does not have an Exif orientation tag, and the image dimensions are not multiples of 8, then data loss is unavoidable.
*** Bug 406794 has been marked as a duplicate of this bug. ***