Bug 148072 - zoom tool for sharpen tool is ankward
Summary: zoom tool for sharpen tool is ankward
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Editor-Sharpen (show other bugs)
Version: 0.9.2
Platform: Ubuntu Linux
: HI wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-21 01:02 UTC by Laurent COOPER
Modified: 2016-06-29 20:09 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.1.0


Attachments
dysfunction of preview in Sharpen tool with small picture and x1 zoom (902.31 KB, image/png)
2007-12-02 10:34 UTC, caulier.gilles
Details
Patch to test x1 zoom dysfunction with sharpen preview widget (5.40 KB, patch)
2007-12-02 10:42 UTC, caulier.gilles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent COOPER 2007-07-21 01:02:39 UTC
Version:           0.9.2-final (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages

In previous digikam version, when using the sharpen tool, there was an easy zoom chooser : 1x 2x 0.5x ...

Now, there is a slider with an apparently continuous choice.

But the result is much difficult to see. With a sharpen tool, I like to "a priori" have a 100% view, to see the real effect. Are fringes appearing? Is there a real improve?

With this slider, it's particulary complex to set zoom to 100%. And the question arise : are the effect dissolved into resizing? Specialy important for pictures who are to be sent to a labo for printing.

A simple button zoom choice should be an option at least. And 100% should be the default (not the full size of the picture height)

BTW, it's no more possible to save the unsharp mask parameters? (another bug to be opened or I'm just lost?)
Comment 1 Dik Takken 2007-07-26 22:18:58 UTC
I agree on this one. Before deciding if your settings are producing the desired result, you MUST be sure that you are looking at the original pixels. Unscaled, unprocessed in any way. A 100% zoom setting is really needed here.
Comment 2 vern 2007-09-25 16:51:12 UTC
I agree this is a high priority.  I don't care how it is done, but a simple and quick way to choose 100% view in the edit preview would be a great help.

Thanks,
Vern
Comment 3 Arnd Baecker 2007-11-05 11:02:43 UTC
I agree, unsharp needs a 100% view.
(note also the related bug http://bugs.kde.org/show_bug.cgi?id=147542)
Comment 4 Mikolaj Machowski 2007-11-13 09:22:38 UTC
Probably simplest solution would be make +- buttons jump to predefined
values, not change by some random(?) value. Eg. always jump to x0% (10,
20, 30, 40, 50, 60, 70, 80, etc.).
Comment 5 Arnd Baecker 2007-11-13 09:30:05 UTC
Zooming is in a non-linear way because
going from 10% to 20% is a huge step, while going from 100% to 110% 
is only a small one.

Wouldn't a [100%] button at the side just do the job
(+ keyboard shortcut)?
Comment 6 Mikolaj Machowski 2007-11-13 11:38:07 UTC
Not additional button - it is cluttering of interface.

Maybe creating some smarter chain of predefined zoom factors. I remember
in old Photoshop 4 in navigation tool, zoom buttons where giving steps
like: 16%, 33%, 50%, 75%(?), 100%, 130%, more I don't remember.
Comment 7 caulier.gilles 2007-11-13 11:50:19 UTC
Mik,

This is my reference (:=))):

http://www.powerretouche.com/Windows_plugins/sharpness_plugin.jpg

Look on the bottom/left : you have a slider (like 0.9.3) and buttons (like 0.9.2)...

We just need to have both at the same time... When i have used the zoom slider in image plugins, i have thinking this will be enough, without buttons. This is a wrong judgment from me...

Gilles
Comment 8 caulier.gilles 2007-11-13 11:53:33 UTC
>Look on the bottom/left : you have a slider (like 0.9.3) and buttons (like 0.9.2)...

Oups, "and buttons (like 0.9.1)" i want mean...

Gilles
Comment 9 Mikolaj Machowski 2007-11-13 12:06:01 UTC
Ah. Yes, looks like PR got it right :)
Comment 10 caulier.gilles 2007-12-02 10:31:33 UTC
To original post from Laurent :

>In previous digikam version, when using the sharpen tool, there was an easy >zoom chooser : 1x 2x 0.5x ...

>Now, there is a slider with an apparently continuous choice.

>But the result is much difficult to see. With a sharpen tool, I like to "a >priori" have a 100% view, to see the real effect. Are fringes appearing? Is >there a real improve?

Oh yes ! Zoom is performed imediatly in memory without to allocate more memory space. Previous implementation recompute the whole image to scale it. This way is definitivly wrong !!!

>With this slider, it's particulary complex to set zoom to 100%. And the >question arise : are the effect dissolved into resizing? Specialy important for >pictures who are to be sent to a labo for printing.

>A simple button zoom choice should be an option at least. And 100% should be >the default (not the full size of the picture height)

Yes, a 100% button can be done, but for small image (with a size smaller than screen size), 100% zoom value will not work properlly in preview. Something is wrong in preview widget implementation (indeep)

Look screenshot from my computer...


>BTW, it's no more possible to save the unsharp mask parameters? (another bug to >be opened or I'm just lost?) 

Use Load and SaveAs button on the bottom of dialog...

Gilles
Comment 11 caulier.gilles 2007-12-02 10:34:41 UTC
Created attachment 22276 [details]
dysfunction of preview in Sharpen tool with small picture and x1 zoom
Comment 12 caulier.gilles 2007-12-02 10:42:45 UTC
Created attachment 22277 [details]
Patch to test x1 zoom dysfunction with sharpen preview widget

Note : With large images, of course X1 button always work...
Comment 13 Markus Spring 2007-12-18 12:15:33 UTC
The "Patch to test x1 zoom dysfunction with sharpen preview widget" resolves this problem. I would suggest to add it to trunk.

Comment 14 Arnd Baecker 2007-12-19 21:21:24 UTC
I think the first problem is the slider range, as computed in 
void ImageRegionWidget::resizeEvent(QResizeEvent* e)

Comment 15 Arnd Baecker 2007-12-20 11:02:35 UTC
The slider range issue could be overcome by this:
--- libs/widgets/imageplugins/imageregionwidget.cpp     (revision 750612)
+++ libs/widgets/imageplugins/imageregionwidget.cpp     (working copy)
@@ -118,6 +118,10 @@
     double dstWidth  = contentsRect().width();
     double dstHeight = contentsRect().height();
     double zoom      = QMAX(dstWidth/srcWidth, dstHeight/srcHeight);
+
+    // For small images we start with 100% zoom, i.e. smaller than contentsRect.
+    if (zoom>1.0)
+        zoom = 1.0;

     setZoomMin(zoom);
     setZoomMax(zoom*12.0);

------------

But this (of course) addresses non of the problems one gets.

Gilles, I think Markus suggestion #c13 to apply your patch 
is a good one: for normal images everything is ok (and that is really the majority I would guess), while for small images we have
to find the origin of the problem (seems not an easy one at first glance).
Comment 16 Arnd Baecker 2008-04-24 09:49:31 UTC
Gilles, I just came across
http://bugs.kde.org/show_bug.cgi?id=148234
"Small images cause zoom slider crazyness"
Most likely the dysfunction you show in #c11
is related to that bug.
(So let me repeat my suggestion: let's get your patch  #c12 in,
maybe also #c15, and solve the remaining issue for small images in the other
bug ....)
Comment 17 caulier.gilles 2008-07-23 23:10:14 UTC
*** Bug 147542 has been marked as a duplicate of this bug. ***
Comment 18 Roman Fietze 2008-12-24 14:31:46 UTC
It seems, that the zoom functionality has moved to the toolbar with 0.10.x

It now offers zoom in/out as well as zoom levels 25% * 2^n, which of course also includes 100%.

Should we close that bug (I'm not the reporter)?
Comment 19 caulier.gilles 2008-12-24 14:45:34 UTC
Not yet. It still some regression tests to do.

Gilles Caulier

Comment 20 Droebbel Melta 2009-04-19 23:34:19 UTC
The zoom level currently (0.10.0 from ubuntu jaunty) defaults to "fit window". It should rather default to 100%.

Also zooming is only possible step by step via + or - or the corresponding buttons. Selecting a particular zoom level is neither possible in the toolbar nor via menu or keyboard, as these ways are deactivated.
Comment 21 caulier.gilles 2009-07-14 06:38:59 UTC
*** Bug 200041 has been marked as a duplicate of this bug. ***
Comment 22 DrSlony 2009-07-14 12:37:07 UTC
I vote for additional 100% & 200% and possibly 400% buttons, of which 100% is most important. I don't see how these tiny but very useful buttons would clutter the interface. Also, global "100%/zoom to fit" shortcuts should work in showFoto and Light Table.
Comment 23 vern 2009-07-15 13:51:31 UTC
Just a comment about the zoom buttons cluttering the interface...they wouldn't.  A great feature in digikam is that you can choose which buttons are displayed. There are a lot more to choose from than those displayed by default, and the defaults can be removed.  I always add a delete permanently and download all button.
Comment 24 caulier.gilles 2010-01-20 12:20:39 UTC
SVN commit 1077548 by cgilles:

Editor Tool Preview factoring : Important change here
- Now editor tool based on image region widget preview can be zommed to 100% all time. there is no zomming 
restriction based on image size to always fit contents to preview size.
- When user select a zommable editor tool, canvas zoom is applied to preview.
- All preview mode are available with image region widget tools based (NR, refocus, etc...)

Warnings: this commit do not finalize preview factoring and regressions tests need to be done again. 
I can see preview dysfunctions in some cases.

TODO : port progressively all editor tools based on image guide widget (not zommable) to image region widget (zommable) as WB, curves, levels, etc...

BUGS: 221987
BUGS: 163284
BUGS: 148072
BUGS: 222975
CCBUGS: 197316
CCBUGS: 148235
CCBUGS: 220567
CCBUGS: 196469
CCBUGS: 221988



 M  +5 -0      canvas/canvas.cpp  
 M  +1 -0      canvas/canvas.h  
 M  +7 -4      editor/editortooliface.cpp  
 M  +24 -54    widgets/imageregionwidget.cpp  
 M  +4 -7      widgets/imageregionwidget.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1077548