rotating with eog does shift (wrap around) image if width or height is not a multiple of 16

Bug #657433 reported by Oliver Joos
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eog (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: eog

I use Ubuntu maverick 10.10 (release candidate) with eog 2.32.0-0ubuntu1.

1. resize an image to 319x479 pixels with gimp
   or scan an image to 1866x1266 pixels with xsane
2. open the image in eog
3. rotate it clockwise
4. save it and close eog
5. check the image in eog or firefox
=> the image got shifted for (width modulo 16) pixels. The area that would be shifted out of the image is mirrored and inserted on the opposite side of the image.

Note for triagers: if this bug is reproducible then please consider to raise its priority! Although (widths modulo 16)!=0 are not that common, this bug might cause quite some damage. Nothing is visible while rotating or saving in eog and nautilus thumbnails are too small to see the shift clearly.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: eog 2.32.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
Date: Sat Oct 9 21:12:32 2010
LiveMediaBuild: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate i386 (20100928)
ProcEnviron:
 LANG=de_CH.utf8
 SHELL=/bin/bash
SourcePackage: eog

Revision history for this message
Oliver Joos (oliver-joos) wrote :
Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :

This is apparently a fundamental problem of lossless rotation. From the JPEG FAQ:
> In particular it is possible to do 90-degree rotations and
> flips losslessly, if the image dimensions are a multiple of the file's
> block size (typically 16x16, 16x8, or 8x8 pixels for color JPEGs).

You see the same result if you use for example the jpegtran tool, so it is not eog specific. Still, I think it is a bug as eog should warn the user and maybe offer to do a lossy rotation (i.e. reencoding) instead. I'll link a (rather old...) upstream bug about the same issue, discussions should best take place there.

BTW, if you rotate the image back, you also get your original image back ̣-- after all the rotation *is* lossless.

Changed in eog (Ubuntu):
status: New → Confirmed
Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :

Actually this bug has already reported in launchpad as bug #486862, I'm therefore marking it as a duplicate.
Feel free to continue to report any other bugs you may find.

Revision history for this message
Oliver Joos (oliver-joos) wrote :

@Marcel: thanks, good to hear that the corruption can be undone.

I saw your comment today on https://bugzilla.gnome.org/show_bug.cgi?id=455883 and understand the problem. The solution of gthumb would be nice for eog too. Nevertheless I resist to use "lossless" rotation whenever possible. I wrote a Nautilus script to rotate images by altering their EXIF Orientation, which is fast and indeed lossless - with any dimensions. I'd prefer if eog had a preference setting to allow this kind of rotation!

> after all the rotation *is* lossless.
True! Every pixel is in the resulting image, somewhere... LOL

Revision history for this message
Marcel Stimberg (marcelstimberg) wrote :

I added your commend about EXIF rotation to the upstream bug, discussion should best continue there (https://bugzilla.gnome.org/show_bug.cgi?id=455883).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.