I tried to use batch queue Manager to do some modifications to about 40 jpgs / 12mpx size. After the jobs runs completely without errors the Digikam Browser shows an empty Image and the size was 0 byte. I tried that with a new workflow... ( besides editing a workflow leads to a crash of digikam ) and with fewer pics and its always the same: 0byte sized pics ... Reproducible: Always Steps to Reproduce: 1. mark some pictures in Digikam browser 2. Click Batch Queue Manager 3. Assign Actions "color Auto correction - exposure" 4. assign action "sharpen image - simple sharp" 5. User "original album" as target - Rename File to file+"sometext" 6. run the queue Actual Results: All modified files have the correct name and exist but they have 0 Byte size...so they are useless. Expected Results: Files should have a similar size then the original files with modifications from the batch.
This only apply to JPEG ? What's about PNG or TIFF ? Which libjpeg you use on your system. here, it's libjpeg 8, and there is no problem. Do you use libjpeg-turbo ? What do you see as debug trace on the console. Open a console run kdebugdialog and turn on digikam, KExiv2 space. After that, start digiKam. Gilles Caulier
Look like all is fine here : http://www.flickr.com/photos/digikam/8470323584/sizes/l/in/photostream/ Gilles Caulier
(In reply to comment #1) > This only apply to JPEG ? What's about PNG or TIFF ? > > Which libjpeg you use on your system. here, it's libjpeg 8, and there is no > problem. > > Do you use libjpeg-turbo ? > > What do you see as debug trace on the console. Open a console run > kdebugdialog and turn on digikam, KExiv2 space. After that, start digiKam. > > Gilles Caulier Hi Gilles, I use following components - sorry that I forgot them to include in my initial post. Furthermore it works if I add a convert job to png or tiff. First here my components: digiKam version 3.0.0-rc Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.22 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.10.00 LibKExiv2: 2.3.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.2.0 LibLCMS: 119 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.12.27 - internal library LibPNG: 1.2.46 LibQt: 4.8.2 LibRaw: 0.15.0-Beta1 LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.12.2 (stable release) Parallelized PGF codec: No Parallelized demosaicing: No RawSpeed codec support: No Database backend: QSQLITE Kipi-Plugins: 3.0.0-rc LibGphoto2: 2.4.14 LibKface: 2.0.0 LibKipi: 2.0.0 LibOpenCV: 2.4.2 Libface: 0.2 heredigiKam version 3.0.0-rc Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.22 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.10.00 LibKExiv2: 2.3.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.2.0 LibLCMS: 119 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.12.27 - internal library LibPNG: 1.2.46 LibQt: 4.8.2 LibRaw: 0.15.0-Beta1 LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.12.2 (stable release) Parallelized PGF codec: No Parallelized demosaicing: No RawSpeed codec support: No Database backend: QSQLITE Kipi-Plugins: 3.0.0-rc LibGphoto2: 2.4.14 LibKface: 2.0.0 LibKipi: 2.0.0 LibOpenCV: 2.4.2 Libface: 0.2 Second here the output of kdebugdialog after activating "digikam" & "Kexiv2" : SqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. digikam(4537) Phonon::KdePlatformPlugin::createBackend: using backend: "GStreamer" ..thats all..!? Michael
Sound like the problem is outside. Can you share some original JPEG files that you try to process in BQM, to see if i can reproduce the problem here ? Gilles Caulier
I would love to do so but the pics are above 4 Megs in size...(12Mp) maybe I can try to load them up somewhere...
Hi Gilles, finally I managed to provide three pics on my webspace who all have problems. Here are the links: http://scholzmike.net/IMGP1368.JPG http://scholzmike.net/IMGP1374.JPG http://scholzmike.net/IMGP1382.JPG Hope that helps :-) Best regards, Michael
Mike, Please look here : https://bugs.kde.org/show_bug.cgi?id=314822#c6 ... and let's me here if the analyse of the problem is reproducible for you... Gilles Caulier
Update: like i wrote in 314822: the solution with adding a "convert to jpg" job solved the problem. A bit strange because the picture already is jpg but it seems a "write" job is needed in any case. Knowing that the BQM works nearly perfect :-) Thank you Gilles ! Michael
Mike, it's abnormal. Here, i play with JPEG WITHOUT to assign convert to JPEG tool, and it work perfectly. It sound like a missing test case that i don't see, relevant your settings. Gilles Caulier
Mike, I think the lead problem is fixed now following this report : https://bugs.kde.org/show_bug.cgi?id=313938 Please checkout current code from git/master (next 3.2.0), and test. Thanks in advance Gilles Caulier
Git commit dd3dc1cdd2292f2c12b2927250619ae4781f3a61 by Gilles Caulier. Committed on 27/07/2013 at 09:10. Pushed by cgilles into branch 'master'. Batch Queue Manager : add new option to turn on/off multi-core support. This option is now turn off by default due to some dysfunctions under Windows, until it will be hack and fixed. Note that problem are not reproducible under OSX and Linux here. Options is implemnted for digiKam 3.3.0 release. Related: bug 318198, bug 318577, bug 320358 M +13 -1 utilities/queuemanager/manager/actionthread.cpp M +1 -1 utilities/queuemanager/manager/actionthread.h M +4 -1 utilities/queuemanager/manager/queuesettings.h M +9 -1 utilities/queuemanager/manager/workflowmanager.cpp M +14 -2 utilities/queuemanager/views/queuesettingsview.cpp http://commits.kde.org/digikam/dd3dc1cdd2292f2c12b2927250619ae4781f3a61
digiKam 3.5.0 is out. Can you give a fresh feedback about your report ? Problem still reproducible ? Thanks in advance Gilles Caulier
*** This bug has been marked as a duplicate of bug 318577 ***
Couldn test it with 3.x since I changed my distro. Now I have 4.2 in use and this problem is solved definitely ! Thanks to all great people involved ! :-)