Version: 10.0 rc2 (using KDE 4.2.0) OS: Linux Installed from: Gentoo Packages I've tried to narrow this down and the error is definitely reproducible on different machines. Here are the steps that will hopefully reproduce the error. Use a RAW image with a portrait orientation...the error does not seem to occur as often with landscape orientation images, but I have had the error with all images. Choose to edit the image. Choose Transform - Resize...use 25% for the resize (the resize value does not seem to be important). Then choose to Enhance - Sharpen, using Refocus. In the new preview the image will be zoomed excessively...maybe 125%, maybe 175%. This obviously is not useful for sharpening which should be your last step in workflow. Using the zoom out buttons, the image cannot be zoomed out even to 100%. This error does not occur 100% of the time, but it does occur very often. I have been able to work around it by zooming out on the original image to a low value, before choosing to sharpen. For example, if I zoom out to maybe just 25%, the zoomed value when I sharpen may only be 75% and I can actually then zoom in on the preview to 100%. At some point the image will always be previewed above 100% in the sharpening preview, and it cannot be zoomed out to a lower value. I don't think this is the intended behavior.
Confirmed that problem occurs regardless of sharpening technique used. Seems to be a preview problem, but it doesn't occur in preview when using some other tools.
I think this can be simplified like this: Edit any photo for opening (for example the good old 0-8bits-photo.png). Choose Enhance->Sharpen. 1)Click once on Zoom Out. => Zoom out is disabled, and the right hand part of the preview disappears 2)Or: change the preview mode, e.g. from horizontal to vertical side-by-side preview, and the second part of the preview disappears. Gilles, any idea?
I noticed this problem is still present in .10.0 final release with KDE 4.2.1. What Marcel said is true, but I think it's more than that. Why would the preview on sharpening immediately go to something greater than 100% by default? Usually as soon as I select sharpen the view goes to something like 160-180% which is not at all helpful for judging the effect of sharpening. After that, as Marcel described, it's not possible to zoom back out. Thanks, Vern
Is this bug being worked on or do I need to resubmit it for .10.0?
Trying to reproduce with 1.0-beta2 (current trunk) the testcase I described in #2, it seems to be solved for me. The Sharpen filter start with fit-to-window zoom now. It feels a bit clumsy as there is no automatic preview creation now but you have to press "Try", otherwise there is white background visible, but this is probably intentional and not the issue here. So please try the latest 1.0 beta to see if there is a problem remaining.
The primary problem that I reported on this ticket is resolved in 1.0 beta2. I noticed other related problems, but I'm not sure if I should report them here or in a separate ticket so I'll try here first. Whether I choose fit to window or not does not affect the resize in 1.0 beta2. I can resize using the zoom in and zoom out buttons and that was my number one concern, mostly because a 100% preview is necessary for the best sharpening. Here are the possible new bugs, although I'm not 100% sure they are bugs. In b2, I cannot click on the percentage for the preview and change it (the down arrow in that box used to be clickable if I remember right). Not a big deal since preview size can be changed with zoom in or zoom out. In b2, I cannot select/deselect 'fit to window' after I choose to sharpen. Whatever was set in the initial preview window when I choose edit is carried over to the window that opens up after I choose enhance/sharpen, but the setting cannot be changed. This is insignificant to me, but I thought I'd report it in case it is a bug. Zoom to 100% (via menu or keyboard shortcut) works fine in the initial edit window, but again it does not work in the window that opens after choosing enhance and sharpen. I thought this might be the expected behavior and not a bug, but wanted to make sure. Those are all insignificant compared to the initial bug reported. Thanks so much for taking care of that one!
vern, all your new remarks are already reported in this bug : https://bugs.kde.org/show_bug.cgi?id=148072 Gilles Caulier
ok, original problem is fixed. for others remarks, see #148072 I close this file now. Gilles Caulier