Version: (using KDE 4.3.4) OS: Linux Installed from: Gentoo Packages I loaded the local contrast panel, set things to default and rendered a preview. The image changed, good. I now changed everything, moving the sliders (power, blur) to maximum, minimum, or just around, and updated the preview, no change. No difference in halos, exposure, or anything. I did this many times using different settings and function: power and linear, never made any difference. Not only are the 'general settings' sections cryptic ("stage 1", "stage 2", etc...), changing the settings also makes no apparent difference. ps. also cant zoom to fit nor zoom to 100%, very bad, but that's already filed in a separate bug report.
I can reproduce this bug with >1.0.0 version (rev 1055453). Julien
Same here on two systems, Version 1.0.0 on i386 and amd64.
Gilles, Can you reproduce this bug ? it must be just a small regression, it used to work in betas. Julien
Julien, No, i cannot reproduce the problem here. all work fine : http://farm5.static.flickr.com/4049/4303442856_bee96a5d90_o.png DrSlony, You need to press "Try" button to take effect with last settings change. About zoom to fit and 100%, it's fixed with current svn code. Try it. Gilles Caulier
Gilles, I can reproduce. For me the plugin does something, but always the same, it does not depend on the parameters, it always gives the same result. To reproduce: Click try, Choose the "Target Image" preview mode. Click try. Change a lot the power setting for example. Click on try again. Nothing changed. By the way there is a bug in the preview mode: choose target preview mode click on try choose mouse over preview it does not work if you do not click on try first. Switching between target/mouse over preview modes do not work. Julien
*** Bug 225505 has been marked as a duplicate of this bug. ***
I agree with Julien, I tried changing all the sliders using very different values, I also tried actually processing the image and saving it in case there was a bug in the "try" code, but the results were always identical. I read somewhere that digiKam checks whether there is another enfuse package already installed, if there is it uses that one but if there isn't then it installs and uses its own enfuse implementation. Assuming that what I read is true, maybe the problem is there?
DrSlony, The enfuse tool is used by another tool, which is a kipi plugin to compute tonemapping of hdr images. The local constrast tool is another kind of tonemapping from a single picture. Julien
In the earlier beta the function was o.k., but now it's so on my system (ubuntu karmic) too, as here written from DrSlony and the others.
SVN commit 1101182 by cgilles: move local contrast to coreplugin fix LocalContrastParameter settings management. Do not use a cpnst ref to pass, but pointer, hosted by LocalContrastFloat instance. BUGS: 221992 M +0 -1 imageplugins/CMakeLists.txt M +1 -1 imageplugins/TODO M +1 -0 imageplugins/coreplugin/CMakeLists.txt M +2 -1 imageplugins/coreplugin/digikamimageplugin_core_ui.rc M +16 -0 imageplugins/coreplugin/imageplugin_core.cpp M +2 -1 imageplugins/coreplugin/imageplugin_core.h A imageplugins/coreplugin/localcontrasttool.cpp imageplugins/localcontrast/localcontrasttool.cpp#1101136 [License: GPL (v2+)] A imageplugins/coreplugin/localcontrasttool.h imageplugins/localcontrast/localcontrasttool.h#1101136 [License: GPL (v2+)] D imageplugins/localcontrast/localcontrasttool.cpp D imageplugins/localcontrast/localcontrasttool.h M +9 -18 libs/dimg/filters/lc/localcontrastfilter.cpp M +1 -1 libs/dimg/filters/lc/localcontrastfilter.h M +22 -22 libs/dimg/filters/lc/tonemappingbase.cpp M +33 -33 libs/dimg/filters/lc/tonemappingbase.h M +40 -41 libs/dimg/filters/lc/tonemappingfloat.cpp M +1 -0 utilities/imageeditor/canvas/imagepluginloader.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1101182