Summary: | Gwenview "Crop" Corrupts Resulting Image | ||
---|---|---|---|
Product: | [Applications] gwenview | Reporter: | David Rankin <drankinatty> |
Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | finex, mat69 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
full image
cropped image gwenview-crop-save-01.png gwenview-crop-save-02.png Two files, same crop from gwenview, 1 corrupt, 1 not. Needs investigation |
Description
David Rankin
2009-08-08 19:29:25 UTC
Please, remember to *attach* files to bugzilla. Don't link to external website where them could be deleted. Created attachment 35997 [details]
full image
Created attachment 35998 [details]
cropped image
I've tried to crop that image with gwenview from current trunk, but the resulting image is correct :-) This is evidently an intermittent problem and may be a bug in qwenview's saving to smb shares or in qwenview's "save as" behavior after cropping. I have asked others to confirm the crop issue and a simple crop and saving to the same file works. However, I can reproduce the bug when I attempt a crop and then a "Save As". The corruption occurs using a "Save As" after a crop. When the first corruption occurred I had taken a screenshot of the taskbar with ksnapshot and then used "open with" to open gwenview. The crop was performed by choosing "crop" and then grabbing the right-hand bounding box handles and dragging leftward to size the view I wanted and choosing "crop" from the pop-up below the selection. I then chose file "save as" and saved the file to a samba share. I don't know where the corruption was introduced, but I performed it twice to confirm - corrupted both times. I believe the "save as" corruption occurred because the original file was saved in /tmp/kde-david on the local machine and my "Save As" was to a smb share mounted under /mnt I just took another screenshot of this bug report and cropped it and the smb save bug occurred again. I went through the same procedure outlined above and chose "save as" after the crop and entered "gwenview-bugreport.png" as the file name. To my surprise, the file was NOT saved under the name "gwenview-bugreport.png" but was saved under the name quicklaunch-zephyr-newksnapfull1.png (prior save name) in /tmp/kde-david -- WTF?? After selecting crop, you are presented with the black banner under the toolbar saying: "Current image modified [Undo] [Redo] [Save][Save All]" see: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/gwenview-crop-save-01.png Since I want to "Save As", I simply used "save as" from the file menu. I don't know whether that it where the bug is, but not saving in the name I specified is certainly not expected behavior. For example if I now open gwenview-crop-save-01.png and just go to crop the text in the center and save it, then choose "crop", set the bounding box, choose "crop" to complete and then choose "save as" and save as gwenview-crop-save-02.png, the image is completely corrupted. See: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/gwenview-crop-save-02.png I agree gwenview will correctly crop an image if saving back to the same file. This bug occurs when you crop then "Save As". Further, I don't know if it matters whether the save as "target" is on a smb share, but that was the case here. Let me know if you need more info. At least now we know how to reproduce it so it can be fixed. Created attachment 35999 [details]
gwenview-crop-save-01.png
Sorry, attaching the new corrupt image examples.
(P.S.: The linked files would be deleted, they're on my server and I am the only one with write access -- then again, I could have that careless moment of stupidity at the command line...)
Created attachment 36000 [details]
gwenview-crop-save-02.png
File corrupted after:
(1) original image opened in gwenview
(2) crop -> set box -> crop -> choose "Save As"
(3) resulting png is corrupt.
FWIW
Computer Running Gwenview:
Toshiba 205D (4G)
OpenSuSE 11.0
kdebase4-4.3.0-103.6.x86_64.rpm
gwenview-4.3.0-111.1.x86_64.rpm
Fileserver:
OpenSuSE 10.3
Tyan S2865 w/Opteron 9850 (4G)
Linux 2.6.22.19-0.3-default #1 SMP 2009-05-27 x86_64 GNU/Linux
samba-3.4.0-13.1
*Zero* MCE or other hardware errors on either machine
(In reply to comment #6) > Created an attachment (id=35999) [details] > gwenview-crop-save-01.png > > Sorry, attaching the new corrupt image examples. > > (P.S.: The linked files would be deleted, they're on my server and I am the > only one with write access -- then again, I could have that careless moment of > stupidity at the command line...) Should read "The linked files would NOT be deleted.." Created attachment 36002 [details] Two files, same crop from gwenview, 1 corrupt, 1 not. Needs investigation Gwenview has been completely reinstalled and the corruption still occurs. In fact, I have produced 3 corrupt files in a row using this scenario. The latest: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/gwenview-crop-save-03.png Try this scenario and see if you still get a good crop: (1) Grab a screenshot of a window in ksnapshot (2) Choose "Open with" -> Gwenview (3) Crop the image, after pressing the final "crop", choose "File" -> "Save As" (4) Save to a smb share I tried saving the file with gwenview to my local disk and also saving it to the smb share. Both using the "File" -> "Save As" after a crop. When I save to the smb share, the corrupt image is about 250 bytes bigger than the good file: -rw-r--r-- 1 david dcr 37489 2009-08-08 20:23 gwenview-crop-save-03.png (corrupt) -rw-r--r-- 1 david dcr 37231 2009-08-08 20:37 gwenview-crop-save-03.scp2server.png (good) The file I saved locally and then scp'ed to the server is fine: http://www.3111skyline.com/download/openSUSE_bugs/kde4/screenshots/gwenview-crop-save-03.scp2server.png This makes no sense at all. I have used the same server and same setup for years and saved thousands, if not tens of thousands, of files to the server without a single instance of corruption until this gwenview "Crop"; "File" -> "Save As" issue. Let me know. Thanks. Alright, I give up. It will take one of the coding masters to figure out what is going on here. I can reproduce the corruption every time by using the crop and file "save as" as described above. Others don't have this problem. I have captured this behavior with strace for gwenview and all child processes with: strace -ff -o gwen.strace.txt gwenview I have compressed the file with xz to save space. The xz file is just a bit over 1M and contains: gwen.strace.txt.23568 gwen.strace.txt.23569 gwen.strace.txt.23584 gwen.strace.txt.23585 gwen.strace.txt.23586 gwen.strace.txt.23587 gwen.strace.txt.23588 gwen.strace.txt.23589 gwen.strace.txt.23590 gwen.strace.txt.23591 gwen.strace.txt.23592 gwen.strace.txt.23594 gwen.strace.txt.23597 gwen.strace.txt.23611 gwen.strace.txt.23612 gwen.strace.txt.23613 gwen.strace.txt.23614 gwen.strace.txt.23615 gwen.strace.txt.23616 gwen.strace.txt.23617 gwen.strace.txt.23618 gwen.strace.txt.23622 gwen.strace.txt.23623 gwen.strace.txt.23654 WARNING: gwen.strace.txt.23568 will expand to > 400M, the remaining files are small. A URL will have to do this time since bugs.kde.org won't allow attachments > 1024K. This one is 1241K: http://www.3111skyline.com/download/openSUSE_bugs/kde4/data/gwenview.strace.tar.xz I hope this helps Just FYI, I have confirmed this behavior on two separate openSuSE 11.0 installs. One i586 and one x86_64. I'll test with Archlinux and report back tomorrow. We need to determine whether it's cropping which cause a problem or save as or save as on smb. Can you try these: 1. Open an image from your hard disk, crop it, save it with "save", is it corrupted? 2. Open an image from your hard disk, do not modify it, save it with "save as" on your hard disk, is it corrupted? 3. Open an image from your hard disk, do not modify it, save it with "save as" on your smb share, is it corrupted? Thanks for the time you spent on that bug. SVN commit 1217378 by mfuchs: Cropping pictures that use a small palette (e.g. 256 entries) works now. QImage::copy(QRect) also preserves the EXIF-Tag. BUG:257590 BUG:236318 BUG:250473 CCBUG:203109 M +2 -7 cropimageoperation.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1217378 I think the above commit fixes this bug. If this is not the case i.e. this is not working in 4.6.1+ then please reopen this report. SVN commit 1217379 by mfuchs: Backport r1217378 Cropping pictures that use a small palette (e.g. 256 entries) works now. QImage::copy(QRect) also preserves the EXIF-Tag. CCBUG:257590 CCBUG:236318 CCBUG:250473 CCBUG:203109 M +2 -7 cropimageoperation.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1217379 |