Summary: | Auto crop does not fully remove black corners created by free rotation | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Gandalf Lechner <gandalflechner> |
Component: | Plugin-Editor-Rotation | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gerhard, michal |
Priority: | NOR | ||
Version: | 0.10.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.0.0 | |
Sentry Crash Report: | |||
Attachments: | screenshot |
Description
Gandalf Lechner
2009-01-05 23:50:48 UTC
I let's black frame as well, or a part is croped ? Image is really rotated ? Gilles Caulier Created attachment 29969 [details]
screenshot
picture showing the result of free rotation without and with auto crop
I confirm this problem with KDE4 and KDE3. It's another side effect of Editor Tool port (i think) Gilles This seems only to be true for portrait oriented images, landscape oriented works fine here. The question is why? The code in this plugin (algorithm) is unchanged since a while. The only way to check is Editor Tool api port. This problem appear since plugin dialog have been removed. Perhaps a slots/signal race condition when plugin widget is raised from widget stack ? Gilles By quickly looking over the filter I ask myself if the auto-crop algorithms were only written for landscape images? Neither WidestArea nor LargestArea are working correctly if used with portrait images. One of algorithm have been written by Gerhard Kulzer. Ask to him... Other one, By Renchi Raju if i remember (not available in team now...) Look comments in code for details Gilles I'll have a look Gerhard Is this auto crop code "borrowed" from Gimp? Because in Gimp auto-cropping portrait images also doesn't work. If you set clipping in Gimp to "crop to result", it works (seems to be what we call "widest area" in our tool. But if you set clipping to "crop with aspect", it just shows a transparent layer, at least on my machine (Gimp 2.6.6). I just installed KDE3 again (what a pain) to test this feature here. I checked out everything from May 2008 till now and compiled it. Even in May last year the crop didn't work so I don't think this is related to the changes of the image editor. If this feature really worked before, it must have been in 2007 or so, because no significant changes where made to imageplugins/freerotation/freerotation.cpp tool in the last 1 1/2 year. I would assume it never worked. Unfortunately I'm not able to go back even more in time, because everything below May 2008 will not compile here anymore. Andi I checked out a VERY old version of the digikamimageplugins package from the SVN repository. Even the version from 2005 doesn't differ from the current one, so I would really assume it never worked for horizontal images. Actually this can't be so hard to fix, I will take a look at it, too. It's been a while since I had math classes, but I will try to analyze the code now. Andi (In reply to comment #11) > ... so I would really assume it never worked for horizontal images. Vertical / Portrait I mean. *** Bug 194660 has been marked as a duplicate of this bug. *** SVN commit 975580 by aclemens: First attempt to fix auto-crop: I played around with the algorithm a little and it seems to work quite well. Can you confirm this? Andi CCBUG:179766 M +50 -28 freerotation.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=975580 I only touched "Largest area" for now... Andi I will close this one now, it should work for others, too :-D "Widest Area"-Crop seems to be ok. Andi There is strange bug: When selecting Largest Area in options image is moved one pixel up and right and along longer border appear black stripe. Looks like this doesn't affect final output. Only preview problem. Yes, I know. Preview bug, because no rotation took place and so no cropping is done. Don't know why... but the final will not be cropped. Hmm maybe we can ignore slotEffect when angle is 0.0. So this bug should be gone. Will try this. |