Bug 148072

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.

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

I agree, unsharp needs a 100% view.
(note also the related bug http://bugs.kde.org/show_bug.cgi?id=147542)

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.).

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)?

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.

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

>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

Ah. Yes, looks like PR got it right :)

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

Created attachment 22276 [details]
dysfunction of preview in Sharpen tool with small picture and x1 zoom

Created attachment 22277 [details]
Patch to test x1 zoom dysfunction with sharpen preview widget

Note : With large images, of course X1 button always work...

The "Patch to test x1 zoom dysfunction with sharpen preview widget" resolves this problem. I would suggest to add it to trunk.

I think the first problem is the slider range, as computed in 
void ImageRegionWidget::resizeEvent(QResizeEvent* e)

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).

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 ....)

*** Bug 147542 has been marked as a duplicate of this bug. ***

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)?

Not yet. It still some regression tests to do.

Gilles Caulier

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.

*** Bug 200041 has been marked as a duplicate of this bug. ***

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.

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.

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