** Changed in: eog (Ubuntu)
Status: New = Confirmed
--
rotating a jpg photo (eg CTRL+R), then saving it (eg CTRL+S), moves a few
lines or columns of pixels from one end to the opposite
https://bugs.launchpad.net/bugs/486862
You received this bug notification because you are a member of
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
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
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.
--
rotating a jpg photo
** Description changed:
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,
Is there a single image where this happens all the time? This would make
reproducing it a lot easier.
--
rotating a jpg photo (eg CTRL+R), then saving it (eg CTRL+S), moves a few
lines or columns of pixels from one end to the opposite
https://bugs.launchpad.net/bugs/486862
You received this bug
** Attachment added: original and bugged jpg files
http://launchpadlibrarian.net/35956275/example_eog.tar.gz
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/35956276/Dependencies.txt
** Attachment added: ProcMaps.txt
