GNOME Bugzilla – Bug 416257
Eye of Gnome can save images with the wrong rotation
Last modified: 2007-04-19 12:54:28 UTC
The bug has been opened on https://launchpad.net/bugs/88248 "Binary package hint: eog Steps to reproduce: 1. Get a jpeg image file that's large enough that EOG isn't going to be able to rotate instantaneously (larger images take more CPU work to rotate). On my XP 3000+ I used a 1920x2560 pixel image. You don't need something that will cause a huge delay, just not instantaneous. A picture taken from even a bad digital camera with highest megapixel setting should work. 2. Open the image in EOG. 3. DOUBLE click the rotate right button. 4. The image in EOG will have only rotated once, despite double clicking. Click save-as and give a name for the new jpg. 5. Open the new jpg in EOG. It will be rotated twice. Presumably EOG is coded to ignore requests to turn left or right when already doing a rotate operation, but still sets a variable indicating the image has been rotated for each click. This is a usability problem for users who naively double click everything, and an annoyance for people who double clicked to really rotate the image twice and save the result but think that hasn't happened yet and rotate it again and get an upside down jpg :)"
Confirming. This appears to be another issue with the old job system where jobs can run in parallel. The problem is that the first job has not updated the pixbuf when the second job starts the transformation process and thus uses the unmodified source pixbuf. As the other parts of the transformation are pretty quick the transformation matrix is then updated correctly (for now) and reloading the image will display it correectly. Trunk is unaffected as the new job system runs only one job at a time.
I just committed a fix to gnome-2-18 branch (rev.3722): 2007-04-19 Felix Riemann <> * libeog/eog-image.c: (eog_image_transform): Lock the image before applying a transformation. Two parallel transformations could produce wrong results otherwise. Fixes bug 416257. It simply uses the present image locking mechanism (wrapping GMutex) to ensure the first transformation is complete before starting the next one. --- This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.