Bug 146635

Summary: ratio crop doesn't remember orientation
Product: [Applications] digikam Reporter: Daniel Bauer <linux>
Component: Plugin-Editor-CropAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: roberto.castagnola
Priority: NOR    
Version: 4.9.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 0.9.4
Sentry Crash Report:
Attachments: ratiocrop-start-values.patch

Description Daniel Bauer 2007-06-10 15:45:54 UTC
Version:           0.9.2 svn (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs
OS:                Linux

ratio crop tool doesn't remember orientation settings of previously cropped photo when a new picture is loaded (cropping orientation is always set to orientation of the picture, no matter whether "automatic orientation" is selected or not).

To reproduce:
use some portrait oriented images. Do a "landscape oriented" ratio crop on the first one, say ok, save it, load ratio crop for the next picture: the tool is oriented "portrait" again.
Comment 1 Roberto Castagnola 2008-01-22 00:18:14 UTC
Created attachment 23186 [details]
ratiocrop-start-values.patch

The problem is that the values are stored after the image is cropped: if you
start with a portrait image ad crop it with landscape orientation, width/height
values of cropped image are used to choice it's orientation so all values are
stored as the original image was a landscape image.
This patch fixes it + it fixes an undocumented bug for which the plugin doesn't
correctly start with stored values.
Comment 2 caulier.gilles 2008-01-22 06:25:52 UTC
Thanks for the patch Roberto.

Arnd, this is another patch for you (:=)))

Gilles
Comment 3 Arnd Baecker 2008-01-22 09:14:54 UTC
I have tested the patch in a couple of cases and everything seems fine!

Before I commit this patch to svn, there is maybe one related issue:
It seems that size and position are not saved properly.
The question is: should we do that? 
If the image dimensions are the same, this would make sense.
But otherwise this would cause different problems.
So presumably the best is to just leave it as is, right?

Comment 4 Roberto Castagnola 2008-01-29 16:06:21 UTC
> The question is: should we do that?
If I have several images with the same dimensions and I want to crop them all in the same way, restoring previous region selection is usefull. This will work correctly as soon as bug 128293 is fixed.
When image dimensions differ, we can change how it restore the values: suppose to crop an image 3200x2400 where selection rect is (x,y,width,height) = (100,100,2400,1800). If new image dimensions are 1600x1200 (same aspect ratio), we may start with a proportional selection rect (50,50,1200,900). If aspect ratio changes too, we can think something else.
I think a discussion about this may be started somewhere.
Comment 5 Arnd Baecker 2008-01-29 17:23:35 UTC
SVN commit 768240 by abaecker:

Remember orientation setting of a previously cropped photo (patch by Roberto Castagnola)

CCBUGS: 146635
TODO:KDE4PORT



 M  +2 -1      NEWS  
 M  +15 -33    imageplugins/coreplugin/ratiocrop/imageeffect_ratiocrop.cpp  
 M  +2 -0      imageplugins/coreplugin/ratiocrop/imageeffect_ratiocrop.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=768240
Comment 6 Arnd Baecker 2008-01-29 17:29:49 UTC
About the remaining issue: 
a) changing image dimension (but with same aspect ratio)
b)  changing image dimension, different aspect ratio
I am not sure if it is worth the effort.
If yes, it might make sense to discuss this in a new wish,
and close this one here after the port to the KDE4 branch.
Comment 7 caulier.gilles 2008-01-30 16:32:27 UTC
SVN commit 768752 by cgilles:

digiKam from KDE4 : backport commit #768240
BUG: 146635


 M  +18 -35    imageeffect_ratiocrop.cpp  
 M  +6 -3      imageeffect_ratiocrop.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=768752
Comment 8 caulier.gilles 2008-01-30 16:34:52 UTC
Following comment #6, this file is now closed.

Additional remaining issues must be reported into new files.

Thanks Roberto for the patch. you is credited in source file now...

Gilles Caulier