Version: 1.3.0 (using KDE 4.4.1) OS: Linux Installed from: Debian stable Packages To reproduce 1. Select Picture 2. Select edit 3. Select area to inpaint 4. Click on inpaint Move mouse away from image and it will do the target to Original view. It will say inpainting at the bottom of the screen 0% the app becomes no responsive The cimg filter will say none
Note : new CImg version do not have greystoration code anymore. all code have been move to GMic library : http://gmic.sourceforge.net/ So digiKam greycstoration filter need to be ported to GMic Gilles Caulier
digiKam and Kipi-plugins 1.2.0 are out. Please check if crash is still valid there. Thanks in advance Gilles Caulier
Digikam 1.2.0 locks up on my system (KDE 4.4.2, Kubuntu 9.10) as well when I try "in-painting".
(In reply to comment #2) > digiKam and Kipi-plugins 1.2.0 are out. Please check if crash is still valid > there. > > Thanks in advance > > Gilles Caulier I complied the latest from svn of kdegraphics I complied the latest digikam from svn 1.3.0 And it still hangs Everything works in Digikam, this is the only kink in its armor that I have found. When you first enter into inpainting mode it trys to render the target no matter what even if no cmig filter is selected... Sometimes you can cancel it and other times digikam just freezes when you try to cancel it.
Inpainting use CImg and Greystoration interface/algorithm. It's the same for Restauration tool. Restauration tool loop up also on your computer ? Gilles Caulier
loop-up is not reproducible here. I suspect a wrong settings in your ~/.kde4/share/config/digikamrc file close digiKam and edit this text file. Remove the following section : [inpainting Tool] Alpha=0.800000011920929 Amplitude=20 Anisotropy=1 BTile=4 Da=30 Dl=0.800000011920929 FastApprox=true GaussPrec=2 Interpolation=0 Iteration=30 Preset=1 Sharpness=0.300000011920929 Sigma=2 Tile=256 Settings will be different on your computer of course. Start digiKam and try again Gilles Caulier
Look like computation work fine on my computer : http://farm5.static.flickr.com/4045/4496323427_f48070d321_b.jpg Gilles Caulier
Does not do it when doing restoration.. I sent you a video on face book of the problem. ________________________________ From: Gilles Caulier <caulier.gilles@gmail.com> To: vonwallace@yahoo.com Sent: Tue, April 6, 2010 7:44:45 AM Subject: [Bug 232926] in painting causes digikam to lock up https://bugs.kde.org/show_bug.cgi?id=232926 --- Comment #5 from Gilles Caulier <caulier gilles gmail com> 2010-04-06 14:44:41 --- Inpainting use CImg and Greystoration interface/algorithm. It's the same for Restauration tool. Restauration tool loop up also on your computer ? Gilles Caulier
Do you have tried #6 ? Gilles Caulier
Tried #6 1. The inpainting tool still tries to render when first launched even when cmig is set to none... and and sits there on zero... (restoration tool does not do this) The good news is I can click the cancel icon button next to the progress bar and it stops inpainting, and digikam gives me back control of the form / app. So editing the file helped, but there is still some program logic that needs to be looked at.. as (restoration does not try to automatically render when launched) Thank you.
digiKam 1.6.0 is out: http://www.digikam.org/drupal/node/550 Please update and check if this entry still valid. Thanks in advance Gilles Caulier
For me Inpainting "hangs" when I set all sliders to the right in the "General" tab. But I don't think it actually hangs, it might simply calculate a lot of stuff.
Von, It still valid using digiKam 2.4 ? Gilles Caulier
*** Bug 301528 has been marked as a duplicate of this bug. ***
Problem with CImg is that library is not maintained anymore. Also, the only part that digiKam use is GreyStoration algorithm which have been moved in another lib named Gmic which is complety different. http://gmic.sourceforge.net/ Gilles Caulier
Git commit cf96fce25a846afe8cae287f0a8a6757481be769 by Gilles Caulier. Committed on 28/08/2012 at 14:19. Pushed by cgilles into branch 'master'. do not start Greystoration based tools imediatly because it take a while. User must press Try button explicitly to show preview Related: bug 304002 M +0 -1 imageplugins/enhance/inpaintingtool.cpp M +0 -1 imageplugins/enhance/restorationtool.cpp http://commits.kde.org/digikam/cf96fce25a846afe8cae287f0a8a6757481be769
Marcel, This one is fully reproducible with current implementation. filter cannot be cancelled. It sound like it work in a loop for a while. Can you reproduce ? Gilles Caulier
I just tested this: All sliders moved to right in the "General" tab, start. It takes very long, but reached 1%, 2%, then I cancelled, which had immediate result.
Marcel, I tried to found why Inpainting and Restoration tool start automatically when there are loaded in editor without sucess. Typically, it must not star as well, because tool take a while to run. User must use Try button when all is ready. This is how LocalContrast tool work currently. I suspect something wrong with Greycstoration widget signals emitted which force tool to render preview at startup... This is weird because Greycstoration take wrong settings and go to a very long loop (and hand up) Gilles
Using Digikam 2.8.0 on Kubuntu 12.10 - (KDE 4.9.1): In-painting crashes digikam immediately. However, using showfoto loads in-painnting OK, but stops when reaching about 2% then hangs forever. No response from buttons, menus etc.. - Only way to stop is to kill the application.
Kaj, Code fixed is in 2.9.0, not 2.8.0... Please update and try again Gilles Caulier
On 09/21/2012 12:44 PM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=232926 > > --- Comment #21 from Gilles Caulier <caulier.gilles@gmail.com> --- > Kaj, > > Code fixed is in 2.9.0, not 2.8.0... Please update and try again > OK Gilles, thanks. Digikam 2.9.0 isn't in the repos yet, but I suppose that will change... I don't know how to compile the sources, so I guess I'll have to wait until then. Aside from that a very fine application, I love it! Best regards, Kaj.
Well, now I have updated to 3.0.0-beta3 (comes with Kubuntu 13.04) and in-painting still locks digikam hard. Best regards Kaj.
I confirm this bug. uname -a : Linux athanor 3.5.0-19-generic #30-Ubuntu SMP Tue Nov 13 17:48:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Kubuntu 12.10 digikam 2.8.0 gdb digikam : (gdb) run .... .... (starting the editor) .... (selecting a small area on the picture) .... (clicking in-painting in the Enhance Menu) .... [New Thread 0x7fffa7676700 (LWP 4660)] [New Thread 0x7fff8f087700 (LWP 4661)] [New Thread 0x7fff8e886700 (LWP 4662)] [New Thread 0x7fff8e085700 (LWP 4663)] [New Thread 0x7fff8d884700 (LWP 4664)] [Thread 0x7fff8f087700 (LWP 4661) exited] [Thread 0x7fff8e085700 (LWP 4663) exited] [Thread 0x7fff8d884700 (LWP 4664) exited] [Thread 0x7fff8e886700 (LWP 4662) exited] [Thread 0x7fffa4f69700 (LWP 4656) exited] [Thread 0x7fffa576a700 (LWP 4654) exited] [Thread 0x7fffa5f6b700 (LWP 4655) exited] [Thread 0x7fffa7676700 (LWP 4660) exited] *** glibc detected *** /usr/bin/digikam: malloc(): memory corruption (fast): 0x00007fff74004a10 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7ffff12c6b96] /lib/x86_64-linux-gnu/libc.so.6(+0x813e8)[0x7ffff12c93e8] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x75)[0x7ffff12cafb5] /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x51a)[0x7ffff22251ba] /usr/lib/libdigikamcore.so.2(_ZN7Digikam18DImgThreadedFilter8progressEi+0x46)[0x7ffff53b98c0] /usr/lib/libdigikamcore.so.2(_ZN7Digikam18DImgThreadedFilter12postProgressEi+0x71)[0x7ffff53ba6e1] /usr/lib/libdigikamcore.so.2(_ZN7Digikam20GreycstorationFilter13iterationLoopEj+0xf7)[0x7ffff547fb19] /usr/lib/libdigikamcore.so.2(_ZN7Digikam20GreycstorationFilter10inpaintingEv+0x458)[0x7ffff547f5f8] /usr/lib/libdigikamcore.so.2(_ZN7Digikam20GreycstorationFilter11filterImageEv+0x336)[0x7ffff547ea96] /usr/lib/libdigikamcore.so.2(_ZN7Digikam18DImgThreadedFilter19startFilterDirectlyEv+0x72)[0x7ffff53ba438] /usr/lib/libdigikamcore.so.2(_ZN7Digikam18DImgThreadedFilter3runEv+0x23)[0x7ffff53ba5f3] /usr/lib/libdigikamcore.so.2(_ZN7Digikam13DynamicThread17DynamicThreadPriv3runEv+0x64)[0x7ffff5572c78] /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x6f45d)[0x7ffff210645d] /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x7baec)[0x7ffff2112aec] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fffecc19e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffff133bcbd] Moreover, my PC is a double boot host, Kubuntu and Vista. I have installed digikam-2.9.0 for Windows on the Vista side : same inpainting bug !!!
One more detail : Digikam-2.1.1 on Kubuntu-11.10 work fine on the same machine.
As of yesterday's upgrade of Kubuntu 13.04 the in-painting bug in Digikam 3.0.0-beta3 has been fixed. Thanks to the developers from Kaj Haulrich.
Well... this bug recoiled: after todays upgrade from Digikam 3.0.0-beta3 to Digikam 3.0.0-rc2 in-painting doesn't work anymore. It instantly freezes the entire application, the progress indicator remains at zero and the only (polite, that is) way to close it is by clicking the system-X in the upper right corner - and after a while the system (KDE 4.9.98 - Kubuntu 13.04) offers to terminate the application. Same goes for showfoto.
Hello, I am stll having this bug in Fedora 19, Digikam Version 3.3.0 Using KDE Development Platform 4.10.5 ShowFoto appears to do the same thing. The update for this version just came through, and the inpainting bug was listed as being fixed. I guess it could have been a different inpainting bug..... I didn't get the number during the update. bertman
This bug still exists in Fedora 20, KDE 4.12.15, Digikam 3.5. Inpainting just hangs....
...and it still hangs in Digikam 4..0.0 - using KDE Development Platform 4.13.2
This bug still exists in Fedora 20, KDE 4.14.3, Digikam 4.5 Perhaps it just needs to be removed from the menu as an option? RM
With 5.8.0, in-painting image editor tool was been replaced by a Clone tool. More details here : https://community.kde.org/GSoC/2017/StatusReports/shazaismailkaoud Gilles Caulier