I use the batch queue manager to add a watermark and metadata to PNG images created in DK's own image editor. I just switched to DK 3.0.0-rc (in the kubuntu-backports PPA with KDE 4.10) and now zero size PNG files are created. I've tried various other tools in BQM and it's always the same, zero size PNG files. If I add a 'convert to PNG' tool on the end then everything is fine. Reproducible: Always Steps to Reproduce: 1. Create a PNG file in the image editor (save as new version, save in format PNG) 2. Add that to the current queue 3. Go to batch queue manager 4. Add a tool (e.g. border, watermark, metadata, flip, ) 5. Run 6. Look at the results, a file with suffix '.PNG' and size 0. 7. Add a 'convert to PNG' tool 8. Run 9. Look at the results, a file with suffix '.png' and a reasonable size Actual Results: A file with suffix '.PNG' and size 0 Expected Results: A file with suffix .PNG and size non-zero. Here's the components information in case this is something off with kubuntu-backports 4.10. 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.14.90 (0.15 RC 1) Parallelised demosaicing: No Parallelized PGF codec: 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.3.1 Libface: 0.2
Also happening on my system, but with default jpgs, too. The Batch Manager reports successful creation, and files are there, but they are 0KB, empty, and digikam will not show a preview, saying could not load image.
Run kdebugdialog, turn on digiKam, KExiv2, and KDcraw debug space, and start digiKam on a console. What do you see as debug trace when you try to reproduce the problem ? Gilles Caulier
Created attachment 77450 [details] digikam-konsole-trace Attached per your instructions, Gilles. Thank you.
There is no libjpeg error to see. Only Exiv2 print that metadata cannot be loaded from 0 bytes files. It's normal. To try to reproduce here the problem, please : - share your original JPEG files. - List me tools applied on JPEG, with settings and order. Gilles Caulier
I can't access the computer until this evening (CET) but my normal workflow showed this problem. 1. Start with a tiff image (in my case from a film scanner) 2. Tidy up the image with the DK image editor 3. Save as new version - in PNG format 4. Add to current queue 5. Add watermark tool (text watermark) 6. Add metadata tool 7. Run I tried various other combinations of tools as well and all resulted in a zero size output file unless I added the 'convert to png' tool on the end.
AHA!!!! I have discovered the potential issue!!! Read on please! First to answer Gilles, for me I tried to simplify the recreation... I edited a RAW file and saved changes (to JPG), then added that JPG to BQM. I just ran one tool (resize - default medium 800px). Still same, digikam says everything went good, and in preview pane there is no image, only generic icon with 0B size. So I noticed Jon has an issue with png, and I with jpg. I never had this problem before. But I noticed since I started working with RAW I changed some preferences to accomodate such as "checkmark on- Read from Side Car file"...ever since I did this, if I try to open any file directly from digikam in gimp, gimp will give errors regarding thumbnail, etc everytime. Now, so this time in BQM I tried using a RAW file instead of JPG and it works correctly! It does not affect RAW. Next, from my comment about the Side Car preference, I "disable- read from Side Car", and now try again with JPG, and IT WORKS! :) I wonder/hope this helps you, Gilles to find the problem. Let me know if you need any more information, or more testing from me. Thank you for your hard work! Very much appreciated. P.S. Jon, try that, check your preferences and turn off all Side Car file stuff. See if that works.
Umm. I can't reproduce it now. Although since I filed the bug, I got upgraded from DK 3.0.0-rc (in the KDE-backports PPA) to DK 3.0.0 (in the Philip5 PPA) so it's not the same build of DK as was showing the bug.
AJ, Very important : Which libkexiv2 and Exiv2 version you use. All about XMP sidecar is managed through these libraries. Go to Help/Components Info for details. Gilles Caulier
Gilles, Ok, firstly, I still am using 3.0.0-rc. Maybe I should use Philip5 PPA too? In the components info shows: 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.14.90 (0.15 RC 1) Parallelized PGF codec: No Parallelized demosaicing: No RawSpeed codec support: No Database backend: QSQLITE Kipi-Plugins: 3.0.0-rc LibGphoto2: 2.4.13 LibKface: 2.0.0 LibKipi: 2.0.0 LibOpenCV: 2.3.1 Libface: 0.2 in muon package manager, shows I have both libkexiv2-10 and libkexiv2-11 installed, and regular exiv2 package.
Hi Gilles, I have the same problem with 0Byte sized files but I dont use sidear files so I dont have it enabled. The problem is there regardless if enabled or not in "Metadata".
Sorry forgot the reference : I mean my filed Bug 314822
The bug is back. Now same as Mike. It is not working for RAW or anything again. Haven't changed any settings.
OK did further testing in BQM. Mike try this: make sure you assign a "Convert To JPEG" tool. I trieed that and now it works. I remember I did that last time as well. So maybe unless you convert to something, it won't work.
To all, take a care to use official 3.0.0. RC release has bug in BQM that have been fixed in public release. If you work to RAW and you don't set a convert file tool to a write format (JPEG, PNG, TIF, etc...) as RAW is read only, no output can be generated. BQM don't have yet a check to bring user about this problem... Gilles Caulier
OK AJ you are right :-) I veryfied your solution with adding a "convert to jpg" job at the end of the queue and then it works. But my input format is jpg also... dont use RAW. So it's a general "problem" or effect that a convert job is a "must do". I can live perfect with that - thanks Gilles :-)
Mike, I'm not sure to understand. When you said that it's a general problem, do you mean that JPG input file require JPEG converter tool assigned. Typically no. All writable format as supported as well. Typically, input file format is parsed and if is writable source is overwritten, or a new file is created, if you set relevant queue settings (renaming, target file and folder, etc...) But i'm agree that RAW workflow need a new warning if no output format convert is not assigned in workflow. Gilles Caulier
Gilles, yes even jpgs require to use a "convert" tool. It is affecting raw and jpg (and most likely any image) in the bqm queue.
Look carrefully my screenshot, file name, tools list, processed files, etc : http://www.flickr.com/photos/digikam/8470323584/in/photostream/lightbox/ I can process JPEG files in BQM without to asssign a "Convert To" tool in my workflow. Why i cannot reproduce the dysfunction here ? What's the difference ? Gilles Caulier
Is is true we can build a queue, add RAW files and let them be processed, and no output is written unless a converter is added in the end? That should be fixed then ;-)
Yes, Marcel, it's a bug that we must fix. In fact, a parse of workflow list must be done before to run queue, and check this special case and report an error in GUI... But, as it's said in this thread, the dysfunction exist too with JPEG file as input. There is no reason because JPEG is writtable and i cannot reproduce it here... I suspect another bug here, which appear in certain condition that i don't found yet... Gilles
When this bug hit me, it was with tiff files from my film scanner that had been saved as PNG from DK's image editor. Not a raw file in sight.
@ Marcel #19 : Relevant report is here : https://bugs.kde.org/show_bug.cgi?id=316948 Gilles Caulier
jon33040, This file still valid using last digiKam 4.2.0 ? Gilles Caulier
I tried it with digikam 4.2.0 on Manjaro Linux and I couldn't reproduce the problem I had in a similar Bug with jpeg files modified in different ways and then saved as jpeg as well. Tried it also saving as png..no problems.