[Kde-imaging] [Bug 146381] Image rotation splits the image with a small strip appearing on the wrong side.

[Martin Rehn]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=146381         




------- Additional Comments From martinrehn hotpop com  2008-07-21 21:29 -------
Sorry for spamming this bug report, but for completeness, there is a fourth option: instead of trimming the picture dimensions to a multiple of 8 pixels, you can *extend* them to such a multiple [1, 2]. This introduces some "ghost" pictures along the edge, but it is a lossless operation, as far as the information in the image is concerned, and the ghost pixels will likely be less conspicuous than are the misplaced pixels currently. The operation is not reversible, though, since the image dimensions are changed.

So, in the spirit of besting GNOME when it comes to options, here are the possible ways to deal with failing lossless rotation (as stated above jpegtran has code to detect the failure):

a) Lossless rotation, leaving pixels in the wrong location (as today; reversible; very ugly; no information loss).

b) Lossless rotation, introducing ghost pixels (non-reversible; possibly less ugly; no information loss).

c) Trimming, followed by lossless rotation (looks good; information loss)

d) Lossy rotation (preserves image size; quality loss; more quality loss if rotated again since we are still not at a multiple of the code block size)

Trimming (c) is probably the best choice for large-size pictures, where the lost pixels are not important. But in some cases those pixels may matter, so the user should be allowed to choose what to do, I think. Maybe we could even offer to remember the choice on an image-size basis, so that the user can go ahead and use trimming for his photos without confirmation, but then get asked again when trying to rotate some other image.

[1] http://www.impulseadventure.com/photo/rotation-partial-mcu.html
[2] Not always a multiple of eight; can also be a multiple of 16, depending on the size of the code blocks in the jpeg.