Version: unknown (using 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)), Kubuntu packages) Compiler: cc OS: Linux (x86_64) release 2.6.27-7-generic When using the free rotation tool, the rotated image is put into an upright rectangle such that the corners are black triangles. The auto crop options of this tool are supposed to crop the picture to the widest or largest upright rectangle selection avoiding these areas. But in the current version, using the auto crop option often leaves parts of the black background triangles in the cut final image, for sure an undesired effect.
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.