Bug 213172

Summary:	Convert images to png conversion not deterministic
Product:	[Applications] digikam	Reporter:	Bartek Pietrasiak <pietras.sp>
Component:	Plugin-Bqm-Convert	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	caulier.gilles, languitar, marcel.wiesweg
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:	5.0.0
Sentry Crash Report:
Attachments:	the mentioned proof ;) not reproducible not reproducible (2)

Description Bartek Pietrasiak 2009-11-05 00:35:42 UTC

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 ... ;)

Comment 1 Bartek Pietrasiak 2009-11-05 00:38:21 UTC

Created attachment 38097 [details]
the mentioned proof ;)

Comment 2 Bartek Pietrasiak 2009-11-05 00:46:38 UTC

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 ... ;)

Comment 3 Bartek Pietrasiak 2009-11-05 02:56:25 UTC

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.

Comment 4 caulier.gilles 2009-11-05 10:43:19 UTC

Created attachment 38105 [details]
not reproducible

checked in digiKam image editor: this is not reproducible. Sound like a failure from your libpng...

Gilles Caulier

Comment 5 caulier.gilles 2009-11-05 10:48:31 UTC

Created attachment 38106 [details]
not reproducible (2)

Same for kipi-plugins Batch Convert image...

Gilles Caulier

Comment 6 Marcel Wiesweg 2009-11-05 11:03:44 UTC

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?

Comment 7 caulier.gilles 2009-11-05 12:24:28 UTC

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

Comment 8 Bartek Pietrasiak 2009-11-05 13:24:08 UTC

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.

Comment 9 caulier.gilles 2009-11-05 13:32:08 UTC

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

Comment 10 Bartek Pietrasiak 2009-11-05 13:52:55 UTC

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.

Comment 11 Johannes Wienke 2009-11-05 13:58:55 UTC

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.

Comment 12 caulier.gilles 2011-12-21 09:55:06 UTC

Bartek,

This file still valid using kipi-plugins 2.4 ?

Gilles Caulier

Comment 13 caulier.gilles 2015-05-19 09:22:58 UTC

Bartek,

This file still valid using kipi-plugins 4.10.0 ?

Gilles Caulier

Comment 14 caulier.gilles 2015-06-29 17:52:17 UTC

New Kipiplugins 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier

Comment 15 caulier.gilles 2015-07-04 10:11:35 UTC

BatchProcessImage is not maintained since a while and is obsolete now. It will
be removed with 5.0.0.

Use digiKam BQM instead...