Version: 1.0.0-beta6 (rev.: 1044916) (using 4.3.2 (KDE 4.3.2), 4.3.2-4.fc11 Fedora) Compiler: gcc OS: Linux (i686) release 2.6.30.9-90.fc11.i686.PAE I spotted this when I was converting some old big bmp to png. The result was that the file size difference between output png files was too big. This might not have been cause by the compresion alghorithm. Not easy to reproduce, but try the following: 1. Create some test album 2. Copy one jpg file to this album. 3. Rename the file to test_1.jpg. 4. Copy the same file to this album. 5. Rename to test_2.jpg. 6. Start rename to png with compresion set to 1 in options - if you are lucky you will have different sizes at first atempt 7. If not, renemae again the same two jpgs with "Overwrite mode" combo set to "Rename" 8. And the 7 step again, again, again ... ;) Sounds strange, so I will attach a screen ... ;)
Created attachment 38097 [details] the mentioned proof ;)
One more check. After you have reproduced, check the real file size on hard disk (via e.g. ls). They will be exactly the same ... ;)
Similar problem in editor. Please do the following: 1. F4 on some jpg 2. Save it one with max png compression 3. Edit again and save it once again with min compression The files will have different file size on hard disk (what it is expected), but digikam will show files size different from the really ones.
Created attachment 38105 [details] not reproducible checked in digiKam image editor: this is not reproducible. Sound like a failure from your libpng... Gilles Caulier
Created attachment 38106 [details] not reproducible (2) Same for kipi-plugins Batch Convert image... Gilles Caulier
So is the problem, as the bug title suggests, a problem with PNG encoding, or is the problem that digikam shows a different file size in its album view, while the PNG encoding itself has no problem at all?
Marcel, I'm not sure. perhaps i have a chance. I suspect a problem in Database parser which collect information about image properties. At least, i cannot see a problem with libpng on my computer to generate PNG file with different compression settings. Gilles Caulier
There is one more thing which can bee seen in the screens included by Gilles. Kipi produces 4,4 MB png when max compresion. BQM and the editor can create 3,4 MB png for that test file.
kipi tool use ImageMagick in background (it use libpng ) digiKam editor use a dedicated framework based on libpng and written in digiKam core (DImg). I don't know why ImageMagick file is larger... At least size are different... Gilles Caulier
I've updated the libpng. The problem remains. However, I created a new dir using console and copied the png to this new dir. Digikam found this new dir and display correct values. After selecting "Reread metadata from images" from main menu, I can also see correct values in the old album.
This sounds like digikam reads the size of the new files before the conversion has stopped writing the whole file. So a temporary file size is stored in the database.
Bartek, This file still valid using kipi-plugins 2.4 ? Gilles Caulier
Bartek, This file still valid using kipi-plugins 4.10.0 ? Gilles Caulier
New Kipiplugins 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier
BatchProcessImage is not maintained since a while and is obsolete now. It will be removed with 5.0.0. Use digiKam BQM instead...