After an image is cropped the image editor remembers the old width of the image. When you set the zoom at 100% the image is displayed so the width of the image is as wide as the original image. Reproducible: Always Steps to Reproduce: 1.Load an image. 2.Select a tall and narrown portion of the pic and hit control-X to crop it. 3.Set the zoom at 100%. Actual Results: The image is displayed bigger than 100%. This problem also affect the preview window of any tool.
I confirm the bug and it's very frustrating. In order to replicate: - select a photo, - enter the Image Editor select Transform - Resize, - enter Width: like 900 px, - click OK, - the image is blurred like hell and resolution is wrong meaning that scaling (or preview) isn't working). Reproducible - always. I'm using digiKam 4.0.0-beta4 on Linux Mint Petra.
To comment #1 : it's a completly different bug already fixed though bug #335652 Gilles Caulier
To Pochini, about original problem from #1 : A cropped image using full width of original (typically cut as an horizontal band), zoom to 100% work as expected. A cropped image using full height of original (typically cut as a vertical band), zoom to 100% do not work. Can you confirm the dysfunction ? Gilles Caulier
Note : in case 2/ (cut as a vertical band), if i save cropped image in a new file, i close editor and reload image, zoom to 100% work as expected. Conclusion : something is not properly updated internally to editor about image size when crop is done. Gilles Caulier
Yes, I confirm. It "remembers" the original width of the image. A full width crop is fine. A full heigth crop shows the problem. As Kamis says in comment#1 it also happens after the image has been resized. For example: I resize a pic to 25%. When I zoom at 100% it is actually 400%. I have to set the zoom at 25% to see it at 1:1.
I confirm this bug with digikam 4.1.0 on ArchLinux. It's 100% reproducible. I tried with a normal crop and the aspect ratio crop. The issue occurs with both crops.
Still same behaviour with digiKam 4.2.0.
As i connot reproduce the problem on my computer (in debug or final compilation mode), can you take a video of your screen in action to reproduce the problem ? Gilles Caulier
Sent a video on G+ to Gilles!
Created attachment 89084 [details] Video example of bug 335661 This video shows an example of the bug. - First, the about box with version 4.4.0 is shown - The editor is opened with the 'F4' keyboard shortcut - The image is zoomed to 1:1 using the icon at the bottom of the editor window - An area of the image is selected - The menu is used to crop the image Transform -> Crop to selection (Invocation method does not mater) - After the crop, the image has a size of 619x208 (less than half of the video's width) - Clicking on the 1:1 button does not display the image with a 1 pixel to 1 pixel zoom; the image is now bigger than the video (1600x900) - Clicking on the "Fit to window" icon at the bottom of the editor produces the expected result. The video ends with a mess of turning off recordmydesktop that I was too lazy to edit out ;-)
Created attachment 89317 [details] Fix image preview after cropping I believe this might fix the zoom factor after cropping takes place. I'm not really sure if this might cause problems in other places. Waiting for your thoughts on this.
(In reply to Koushik S from comment #11) > Created attachment 89317 [details] > Fix image preview after cropping > > I believe this might fix the zoom factor after cropping takes place. > > I'm not really sure if this might cause problems in other places. Waiting > for your thoughts on this. I applied this to the 4.4.0 sources but I don't see any differencies though. I have tested with "Transform->Resize" and "Crop to selection". Same behaviour as before. /Anders
(In reply to falolaf from comment #12) > (In reply to Koushik S from comment #11) > > Created attachment 89317 [details] > > Fix image preview after cropping > > > > I believe this might fix the zoom factor after cropping takes place. > > > > I'm not really sure if this might cause problems in other places. Waiting > > for your thoughts on this. > > I applied this to the 4.4.0 sources but I don't see any differencies though. > I have tested with "Transform->Resize" and "Crop to selection". Same > behaviour as before. > > /Anders Hi Anders, I tested it out again, and itseems you're right. I thought it worked for a couple of images I was testing. I'll look into it again and figure something out. Thanks for letting me know!
(In reply to Koushik S from comment #13) > (In reply to falolaf from comment #12) > > (In reply to Koushik S from comment #11) > > > Created attachment 89317 [details] > > > Fix image preview after cropping > > > > > > I believe this might fix the zoom factor after cropping takes place. > > > > > > I'm not really sure if this might cause problems in other places. Waiting > > > for your thoughts on this. > > > > I applied this to the 4.4.0 sources but I don't see any differencies though. > > I have tested with "Transform->Resize" and "Crop to selection". Same > > behaviour as before. > > > > /Anders > > Hi Anders, > > I tested it out again, and itseems you're right. I thought it worked for a > couple of images I was testing. I'll look into it again and figure something > out. Thanks for letting me know! Hi Koushik, Looking forward to the next patch! /Anders
(In reply to Koushik S from comment #11) > Created attachment 89317 [details] > Fix image preview after cropping > > I believe this might fix the zoom factor after cropping takes place. > > I'm not really sure if this might cause problems in other places. Waiting > for your thoughts on this. Hi Koushik S, FYI: It did affect the before/after on local contrast tool. /Anders
(In reply to falolaf from comment #15) > (In reply to Koushik S from comment #11) > > Created attachment 89317 [details] > > Fix image preview after cropping > > > > I believe this might fix the zoom factor after cropping takes place. > > > > I'm not really sure if this might cause problems in other places. Waiting > > for your thoughts on this. > > Hi Koushik S, > > FYI: It did affect the before/after on local contrast tool. > > /Anders Hi, Can you specify what effect it had on the contrast tool? I tried it out, and couldn't discern the differences. Also, I'm working on a project for digiKam (as part of Season of KDE), which may take up a majority of my time for a few months. So, I'll try to revisit this bug whenever I can, and hopefully fix it. Thanks for your feedback. I really appreciate it.
Local Contrast tool is this filter : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/filters/lc/localcontrastfilter.h Running through this image editor tool : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/imageplugins/enhance/localcontrasttool.h based on this parent class from editor : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/changes/utilities/imageeditor/editor/editortool.h The tool is loaded in editor canvas with this interface : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/changes/utilities/imageeditor/editor/editortooliface.h To resume, editor canvas is a widget stack. There is a main canvas based on this widget : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/imageeditor/widgets/canvas.h ...and tool loaded pass a dedicated canvas widget. The interface switch between main to tool canvas accordingly with user action. In case of local contrast, the widget loaded by interface is this one : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/imageeditor/widgets/imageregionwidget.h When interface load/unload Canvas/ImageRegionWidget and vis versa, the zoom level and visible region of the canvas must be preserved/restored beofre and after tool session. I think the problem is located in this rules from editor interface, probably due to a race condition somewhere (i never reproduce this problem, excepted in rarely particular conditions) Gilles Caulier
(In reply to Koushik S from comment #16) > (In reply to falolaf from comment #15) > > (In reply to Koushik S from comment #11) > > > Created attachment 89317 [details] > > > Fix image preview after cropping > > > > > > I believe this might fix the zoom factor after cropping takes place. > > > > > > I'm not really sure if this might cause problems in other places. Waiting > > > for your thoughts on this. > > > > Hi Koushik S, > > > > FYI: It did affect the before/after on local contrast tool. > > > > /Anders > > Hi, > > Can you specify what effect it had on the contrast tool? I tried it out, and > couldn't discern the differences. > > Also, I'm working on a project for digiKam (as part of Season of KDE), which > may take up a majority of my time for a few months. So, I'll try to revisit > this bug whenever I can, and hopefully fix it. Thanks for your feedback. I > really appreciate it. Sorry for late answer... I have setup my workflow to show before image when moving mouse over the image. With this setup the after image was "zoomed in" to the uppper left corner of the before image. This only happened on images in portrait format though. /Anders
*** Bug 340855 has been marked as a duplicate of this bug. ***
Created attachment 89683 [details] zoom.patch I have created a patch for this zoom bug. The zoom-variable "m_zoomConst" is created by the image attribute "originalSize". After changes by image processing the image sizes, attribute must be updated.
Git commit 59f9ccedc4d1bd6499e4a088d70f81a7d519beab by Gilles Caulier. Committed on 22/11/2014 at 21:09. Pushed by cgilles into branch 'master'. apply patch #89683 from Maik Qualmann to not lost zoom level between image editor tool session. M +10 -0 utilities/imageeditor/core/editorcore_p.h M +1 -0 utilities/imageeditor/editor/editortooliface.cpp http://commits.kde.org/digikam/59f9ccedc4d1bd6499e4a088d70f81a7d519beab
Hi all, I applied patch from comment #20. Please test and report if all is fine for you before to close this file. Gilles Caulier
(In reply to Gilles Caulier from comment #22) > Hi all, > > I applied patch from comment #20. Please test and report if all is fine for > you before to close this file. > > Gilles Caulier Hi, I have tested the patch on 4.5.0 sources and indeed works! It also solves the problem I have had with before/after on e.g. sharpening and local contrast. This patch seems to be just brilliant!!! /Anders