eog rotate&save moves small strip of pixels to other side of image

[Scott Cowles Jacobs]

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))

------------------------------------------------------------------------
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

-------------------------------------------------------------------------

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: eog 3.26.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
Uname: Linux 4.13.0-32-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CurrentDesktop: LXQt
Date: Mon Jan 29 20:54:14 2018
InstallationDate: Installed on 2017-11-06 (85 days ago)
InstallationMedia: Lubuntu-Next 17.10 "Artful Aardvark" - Beta amd64 (20171014)
SourcePackage: eog
UpgradeStatus: No upgrade log present (probably fresh install)

[Rafael Gattringer (rafael.gattringer)]

Please describe the problem:
Rotate a jpg photo left and save it. The last line of the new picture will display incorrect pixels.

Steps to reproduce:
1. Rotate a (jpeg) file once left.
2. Save the picture.

Actual results:
The last line of the new image displays incorrect pixels.

Expected results:
Same output as rotating and saving the image with GIMP.

Does this happen every time?
Yes.

Other information:
- Seems not to occur after rotating right.
- Ok with other jpg files.

[Rafael Gattringer (rafael.gattringer)]

Created attachment 91616
Original JPG Image

[Rafael Gattringer (rafael.gattringer)]

Created attachment 91617
Image showing error at the last line

[Rafael Gattringer (rafael.gattringer)]

Bug noticed on Ubuntu Feisty 7.04 / EOG 2.18.1 and also replicated on Ubuntu Dapper 6.06 / EOG 2.14.3.

[Felix Riemann (friemann)]

Indeed.
This appears to be related to the lossless JPG transformations as it is reproducible with jpegtran.

I don't know if there is anything against it we can do inside EOG.

A workaround would be to save the rotated image in PNG-format (lossless) and then save the PNG-File as a JPG again.

[Claudio Saavedra (csaavedra)]

I can reproduce it as well. These pixels are not really wrong, but they correspond to the opposite row (or column). If this is inside libjpeg we should report it against it.

[Felix Riemann (friemann)]

Hmm, I don't think this is a problem with libjpeg but with lossless jpeg transformations in general. It could be what Alan Horkan talks about in bug 338138 comment 9 (first paragraph). Rotating the image would apparently require trimming the image to a multiple of 16.
The question is: Can we detect this and warn the user (and possibly let him decide what to do)?

[Claudio Saavedra (csaavedra)]

*** Bug 577142 has been marked as a duplicate of this bug. ***

[Marcel Stimberg (marcelstimberg)]

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).

In contrast to eog, gthumb does detect this situation and displays a dialog with the following text:

This transformation may introduce small image distortions along one or more edges, because the image dimensions are not multiples of 8.

The distortion is reversible, however. If the resulting image is unacceptable, simply apply the reverse transformation to return to the original image.

You can also choose to discard (or trim) any untransformable edge pixels. For practical use, this mode gives the best looking results, but the transformation is not strictly lossless anymore.

It then gives the options: "Trim", "Cancel" and "Accept distortions".

[Oliver Joos (oliver-joos)]

Created attachment 172489
original and padded (200% zoomed)

I would like such a behavior like in gthumb. But why trimming?? I'd prefer padding, namely adding a border (in background color or in black if none is specified). With trimming the rotation is definitely not lossless anymore, with padding it is!

After my tests, I guess that perhaps only the width must be rounded up, but to a multiple of 16 (and not 8 as written above). The border should be added on the right edge. On the other hand this might only be correct for JPEGs created by GIMP. I did not consult the specs of JPEG or "lossless rotation"!

Further I think that padding should be the default answer in the dialog. Not many people will want distortions. The dialog should have a checkbox "remember my decision and don't ask again". And afterwards the chosen "rotation method" should be changeable in the preferences of eof.

[Felix Riemann (friemann)]

Marcel, such a dialog might indeed be a solution. Not sure yet, if we should act proactively (width%8 != 0 -> not lossless) or whether we should still try to save and check if libjpeg complains (it can be configured to do so since v7) until showing the dialog. We likely need to change how saving works to implement either variant though.

Oliver, padding won't necessarily make the rotation lossless since it will trigger the recompression of the image which is normally what you want to avoid when talking about "lossless JPEG transformations". While trimming isn't really lossless either it works without recompressing the remainder of the picture.

[Felix Riemann (friemann)]

*** Bug 603304 has been marked as a duplicate of this bug. ***

[Marcel Stimberg (marcelstimberg)]

One more thing that came up in the downstream discussion: Most users don't care about a physical rotation of the image, just changing the orientation flag in the EXIF data and thereby changing how the image is displayed would be enough. This "rotation" is obviously always lossless and does not depend on the image size. The only problem here is that some applications (e.g. the gnome desktop background) ignore this flag...

[Jsaipakoimetr (jsaipakoimetr)]

Issue still existing with eog 3.26.1.

[Scott Cowles Jacobs (scott092707)]

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...

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Scott Cowles Jacobs (scott092707)]

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 Cowles Jacobs (scott092707)]

Filed upstream as: https://bugzilla.gnome.org/show_bug.cgi?id=793049

Added above as bug watch (as described in comment #4's link).

[Sorry about comment #5 - my page only showed the text in the comment-entry box,
not yet as a confirmed comment - if someone can delete the duplicate comment,
my face can stop turning red with embarrassment...]

[Sebastien Bacher (seb128)]

Thanks for forwarding to GNOME

[Felix Riemann (friemann)]

*** Bug 793049 has been marked as a duplicate of this bug. ***

[Paul White (paulw2u)]

Upstream bug is a duplicate of 455883 so changing

[Paul White (paulw2u)]

https://bugzilla.gnome.org/show_bug.cgi?id=455883

[Andre Klapper (a9016009)]

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/eog/-/issues/

Thank you for your understanding and your help.