After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 632290 - eog does not save changes if image is rotated and flipped once
eog does not save changes if image is rotated and flipped once
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
2.32.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-16 10:27 UTC by Oliver Joos
Modified: 2010-10-16 21:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Oliver Joos 2010-10-16 10:27:20 UTC
I use eog 2.32.0 in Ubuntu 10.10. To reproduce:
1. open a local jpeg image in eog
2. rotate it once (left or right)
3. flip it (vertically or horizontally)
4. save it explicitly or close eog and answer yes to save it
=> the image file is rewritten (nautilus thumbnail is redrawn), but the image content did not change!

Further I saw:
- if rotating TWICE left or right and flipping once, it works as expected
- if rotating three times and then flipping is buggy like rotating once

Hint: Bug 629960 reports similar problems with eog 2.30.
Comment 1 Felix Riemann 2010-10-16 17:43:54 UTC
Confirming. Could be also be related to bug 615376.
Comment 2 Felix Riemann 2010-10-16 18:44:02 UTC
Oookay, it looks like our lossless JPEG saving code practically does no transformation (instead of falling back to reencoding) if the transformations don't accumulate to a single flip/rotation.

We should checkout the lossless transpose/transverse operations offered by 
libjpeg. Maybe they can help too.

(In reply to comment #0)
> Further I saw:
> - if rotating TWICE left or right and flipping once, it works as expected

This is because a 180° rotation and a H/V‐flip accumulate to a single V/H‐flip operation on save.
Comment 3 Felix Riemann 2010-10-16 21:11:50 UTC
(In reply to comment #2)
> Oookay, it looks like our lossless JPEG saving code practically does no
> transformation (instead of falling back to reencoding) if the transformations
> don't accumulate to a single flip/rotation.
> 
> We should checkout the lossless transpose/transverse operations offered by 
> libjpeg. Maybe they can help too.

Indeed. These ones were not supported as JPEG transformation yet and represent the case you describe. Changed that and fixed the recognition in gnome-2-32 and master:

commit 21639caabe2ad4993f97bc8fe90eb8ca5a6de20f
Author: Felix Riemann <>
Date:   Sat Oct 16 22:50:50 2010 +0200

    Support transpose/transverse as lossless JPEG transformations
    
    Also implement a warning message if unsupported transformations
    are used to easier discover such cases in the future. Fixes bug 632290.

commit 0aafa6cf28c38aa3d72c98d0651e89919b3348a3
Author: Felix Riemann <>
Date:   Sat Oct 16 22:41:56 2010 +0200

    Fix calculation of reference matrices for transpose/transverse
    
    The flip matrices were applied as if the source matrix were an identity
    matrix instead of properly multiplicating them.

From my understanding eog should now be able to map any transformation possible to produce using its built-in tools to a JPEG transformation.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.