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 793049 - eog rotate&save moves small strip of pixels to other side of image
eog rotate&save moves small strip of pixels to other side of image
Status: RESOLVED DUPLICATE of bug 455883
Product: eog
Classification: Core
Component: image viewer
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-01-31 04:20 UTC by scott092707
Modified: 2018-05-31 12:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
After roate&save (83.51 KB, image/jpeg)
2018-01-31 04:32 UTC, scott092707
Details
Before rotate&save (181.57 KB, image/jpeg)
2018-01-31 04:42 UTC, scott092707
Details

Description scott092707 2018-01-31 04:20:13 UTC
[ see https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1746146 ]

I have been using Hugin to assemble panoramas, but until this one, they were all horizontal (all photos to be assembled right to left).

This one contained four images vertically oriented, so to line them up, I copied them and rotated them 90 degrees counterclockwise with eog and saved through eog, and then pointed Hugin at the rotated images (Possibly Hugin could make a vertical panorama without my doing this, but I didn't try...)

After the panorama image was complete, I copied it and rotated it into a vertical orientation again (90 degrees clockwise) and saved through eog.

Imagine my surprise, when I looked at the final image, and saw a strip of pixels on the right that didn't look right.

Upon closer inspection, I found that they seemed to match the pixels on the left edge.

When rotating, the image appears correct. It is only after saving, and re-invoking eog on the image that the problem is visible.

It is not a display problem, as the copied/moved pixel columns show up when the image is shown with ImageMagick, and GIMP.

With GIMP, by blowing up the display to 400%, and watching the pixel coordinates as I move my mouse from the left to the right over the false pixel columns, it appears that the number of pixel columns copied or moved is 7.

Upon further research, When I have GIMP blow up both images equally, it seems clear that the pixel columns are being cut off from the left side of the image, and attached to the right side.
(In the attached images, if you look at the "C" on the left (about 75% of the way down, at the edge), you will see that it lines up almost exactly with the edge of the image, yet in the horizontal image, there is a gap between the edge and the "C" (that appears also to be about 7 pixels wide))

Also:
If you look at the right edge of the image, opposite to the "C", the rest of the "C" as it fades out can be seen - but the dark area is to the left, not the right.

This appears to indicate that the columns of pixels that are transferred are brought over in reversed order (mirrored).

(If the chopped-off gap-leading-to-"C" were not reversed, the dark area would be on the right fading to the left as it leads from the "C" into the gap).

I hope that I have described clearly enough, what I am seeing...
------------------------------------------------------------------------
scott@scott-Asus-M2N68-AM-PLUS:~$ uname -a
Linux scott-Asus-M2N68-AM-PLUS 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:13:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
scott@scott-Asus-M2N68-AM-PLUS:~$ lsb_release -dsc
Ubuntu 17.10
artful
scott@scott-Asus-M2N68-AM-PLUS:~$ echo $DESKTOP_SESSION
QLubuntu
scott@scott-Asus-M2N68-AM-PLUS:~$ eog --version
GNOME Image Viewer 3.26.1
Comment 1 scott092707 2018-01-31 04:32:48 UTC
Created attachment 367673 [details]
After roate&save

[for some reason, even though both the Before and After photos were
the same size (6.4MB -  well above the "File size limit: 3600 KB" text
above) the Before photo was able to be attached, and the After was not...
I had to make a screenshot of the After to get it to attach here.]

If you look at the right edge of the photo, you can see the displaced pixel columns.
Comment 2 scott092707 2018-01-31 04:42:57 UTC
Created attachment 367674 [details]
Before rotate&save

[I guess my original attachment was too big, although there was no complaining red screen to alert me to that fact that I got with the original After photo - both attachments are now screenshots, and thus not so useful to you for analysis.]
Comment 3 Felix Riemann 2018-05-31 11:05:05 UTC
This likely a limitation of the JPEG rotation code, which tries to rotate the image losslessly/without recompression). It requires the image dimensions (especially the "new" width" to be a multiple of 8 or 16 (depends on the image).

If the dimensions are not in the required dimensions (at 550x1147px neither width nor height are multiples of 16) the options is to have that little artifact strip or to trim the picture. eog currently chooses the artifact strip. See bug 338138.

Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 338138 ***
Comment 4 Felix Riemann 2018-05-31 12:53:04 UTC
Oops, that actualy meant bug 455883

*** This bug has been marked as a duplicate of bug 455883 ***