Summary: | gwenview incorrectly saves rotated images | ||
---|---|---|---|
Product: | [Applications] gwenview | Reporter: | Matěj Laitl <matej> |
Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | a.vanloon, adrien.cordonnier, hamboy95, KaiUweBroulik2, mklapetek, myriam, nate, octavsly, posix.ru, walch.martin |
Priority: | NOR | ||
Version: | 2.7 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Original Image
Rotated Image |
Description
Matěj Laitl
2006-08-13 17:48:25 UTC
Created attachment 17356 [details]
Original Image
Created attachment 17357 [details]
Rotated Image
Note the image only seems to be B/W. Technically it's full RGB.
PS: Like the girls? ;-)
Same problem here with this picture : http://danakil.free.fr/linux/bug_if_rotated.jpg http://danakil.free.fr/linux/right_rotated.jpg -> bug I don't know if this is important but this picture was resized with the "Resize images..." kipi plugin Still occurs with gwenview 1.4.0 using KDE 3.5.5 This is because the JPEG image dimensions are not a multiple of the MCU size see [1] for an explanation). In this case, there are three solutions to perform a rotation: 1: Apply a lossless rotation, keeping the odd pixels around. Rotating the image the other way will give you back the original image. 2: Apply a lossless rotation, but trim the offending pixels, in your case this would reduce the height of the rotated image from 900 to 896. Rotating the image the other way won't give you back the original image. 3: Apply a lossy rotation, which would give a correct image, but would probably loose some details. For now, Gwenview adopts a conservative behavior and use #1. What do you think should be done? let the user choose the solution? select #2 or #3 without asking? If you want to try #2, edit imageutils/jpegcontent.cpp, find the line that says: transformoption.trim = false; and change it to: transformoption.trim = true; [1]: http://www.impulseadventure.com/photo/jpeg-minimum-coded-unit.html Oh, thanks for the nice explanation... Is it possible to apply a lossy rotation only to the partial MCUs on the sides, while keeping lossless for the rest? Looks like a good compromise for me. Trimming an image a little (the worst case would be 15 pixels) is not IMHO transparent for user... It alters composition or user-made margins etc. How often you rotate & save multiple times? I prefer small quality loss to erasing a small part of image. (maybe stupid) idea: If it saved rotated JPEGs with slightly lower compression ratio, would it eliminate the quality loss? Oh, now I know that i can't be only partially lossy. So the best solution IMHO: offer 2 or 3 to an user, and add configuration options: always 2. always 3. ask before each save of rotated odd-sized jpeg. what about the "maybe stupid idea"? Now i will only resize my JPEGs to multiples of 8. Thanks for your suggestions, I will think about it. As of your "maybe stupid idea": I think it could compensate for some quality loss, but it won't eliminate it and would of course result in a larger file. This same bug/issue also occurs for me with .eps files. A bug has been reported on the Ubuntu Bug Tracker (Malone) concerning this as well. https://launchpad.net/distros/ubuntu/+source/gwenview/+bug/29627 Using: Gwenview 1.4.0 KDE 3.5.5 Hi guys,
the same here. KDE 4.5, openSUSE 11.3.
> rpm -qa gwenview
gwenview-4.5.0-170.2.i586
What's about patch or something like this?
I found a solution for myself: Rotating the image, then cutting the out-of-place-part, flipping it (since it is upside down), and attaching it to the top. -> done :D Still annoying. Any news on this? Because I just witnessed this bug occur with Gwenview 2.7.2 on KDE 4.7.3. gwenview 2.6.4 on KDE 4.6.5 is OK With Gwenview 2.7.4 on KDE 4.7.4, I can still reproduce this bug using Matěj Laitl's original pictures. *** Bug 153066 has been marked as a duplicate of this bug. *** *** Bug 273417 has been marked as a duplicate of this bug. *** *** Bug 252693 has been marked as a duplicate of this bug. *** Still present in 4.10.3. I'm not able to reproduce this with Matěj's original image as of Gwenview 16.12.3 or 17.11.70. Looks fixed! |