Rotating a not-multiple-of-8 jpg causes image corruption

[Frantret]

Binary package hint: eog

Hi,

I did observe this bug various times, with various jpg files, with or without other "heavy" applications running. I managed to reproduce the bug with the following procedure, I have undergone under Ubuntu 8.10 with Amarok, gPodder, VLC, Gimp, Firefox running at the same time. My version of Eog is 2.24.1-0ubuntu1.

0. prepare a sample of 32 image files in a single folder with Gimp:
 - 2 photos (1st label "a" or "b")
 - 4 sizes (2nd label): 2000x1500 "a", 600x450 "b", 200x150 "c", 60x45 "d"
 - 2 orientations (3rd label): portrait "e", landscape "f"
 - 2 format files: jpg and png
1. open a jpg image with eog
2. rotate "CTRL+R" (4th label): once "x", 3 times "y"
3. save "CTRL+S"
4. forward
5. loop from 2., so that all images of the current folder are treated once
6. the result is 64 new image files

It appeared that:
0. obviously, skipping steps 2 and 3 does not make the bug appear
1. the png files are not affected
2. the 2 sets of jpg files (1st label photo "a" and photo "b") are affected the same way
3. the bug keeps image size unchanged
4. the affected files have rows (resp. columns) of pixels moving from one end of the image to the other end: from the top to the bottom (resp. from the left hand side to the right hand side)
5. the order of these rows (resp. columns) is inversed (mirror effect)
6. rotating the image once moves the pixel columns: from the left hand side to the right hand side, and rotating it 3 times moves the pixel rows: from the top to the bottom
7. globally, the smaller the image size, the higher the number of rows (resp. columns) moved

Not to infer too much, here is a list of the 26 affected files (others remained unchanged), with corresponding number of rows (resp. columns) moved, and new location ("b" for bottom and "r" for right hand side):
aaey.jpg and baey.jpg 12 b
abey.jpg and bbey.jpg 2 b
abfy.jpg and bbfy.jpg 8 b
acey.jpg and bcey.jpg 6 b
acfy.jpg and bcfy.jpg 8 b
adey.jpg and bdey.jpg 13 b
adfy.jpg and bdfy.jpg 12 b
aafx.jpg and bafx.jpg 4 r
abfx.jpg and bbfx.jpg 2 r
acex.jpg and bcex.jpg 8 r
acfx.jpg and bcfx.jpg 6 r
adex.jpg and bdex.jpg 12 r
adfx.jpg and bdfx.jpg 13 r

Attached are the 16 original and 32 bugged jpg image files.

Thanks in advance for the help,
François

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/eog
Package: eog 2.24.1-0ubuntu1
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: eog
Uname: Linux 2.6.27-15-generic i686

[Jakob Unterwurzacher (jakobunt)]

Is there a single image where this happens all the time? This would make reproducing it a lot easier.

[Frantret (frantret)]

Thank you very much for your comment.
As you can see, I tried with various types of jpg images. Among all, a lot seem to reproduce the bug. For example, I've been able to reproduce the bug anytime, with any 200 x 150 pixel jpg image, with any number of "CTRL+R" rotations. I suggest that you use the file "example_eog_ace.jpg" (attached), for instance, to reproduce the bug yourself.

[Frantret (frantret)]

On a single image :
- 0 and 4 rotation causes no bug ;
- 1 and 3 rotations causes 1 bug (resp. columns or rows) ;
- 2 rotations causes 2 bugs (columns and rows moved).
When I load a bugged image, rotating it back to the original orientation causes the bug to disappear.

[Jakob Unterwurzacher (jakobunt)]

I can reproduce this here (see screenshot), confirming.

The issue is that the pixel size of the jpg is not a multiple of 8. This makes lossless jpg rotation impossible, but eog is not smart enough to do something about it. gThumb will give you a warning message and gives you the option to truncate the image to the next multiple of 8.

[Jakob Unterwurzacher (jakobunt)]

Reported the bug to the Gnome developers: https://bugzilla.gnome.org/show_bug.cgi?id=603304

[Oliver Joos (oliver-joos)]

On gnome.org 603304 became a duplicate of 455883.