Version: 1.9.0 (using KDE 4.6.3) OS: Linux I setted up a batch process to add exif/xmpp/other tags in my photos. I also setted up a template. After running the queue, the photos halved in file size. Although they keep their original resolution, something must have happened. AFAIU, I have not setted up any type of convertion for this to happen. The photos were taken with a Canon T2i (550D). Reproducible: Always Steps to Reproduce: Process the photo as described in Details. Expected Results: Maybe keep the size of the files? Except there is a good technical reason that says the quality is not lost. OS: Linux (x86_64) release 2.6.39+echo Compiler: gcc
What do you mean exactly ? Can you provide files before and after processing ? What's your workflow in BQM ? Do you have more than one tool assigned to a list ? Gilles Caulier
What I do mean: - Take a photo - Get it on digikam - Right click on the photo and add it to the BQM, add to current queue - Select only Metadata → Apply Metadata Template - Choose the template - Run the queue The photo is now half the size. The two cases will be available in http://perezmeyer.com.ar/test_digikam/ in a few minutes (still uploading).
Interresting : [gilles@localhost Download]$ identify IMG_1928.JPG IMG_1928.JPG JPEG 5184x3456 5184x3456+0+0 8-bit DirectClass 3.446MB 0.000u 0:00.009 [gilles@localhost Download]$ identify IMG_1928_orig.JPG IMG_1928_orig.JPG JPEG 5184x3456 5184x3456+0+0 8-bit DirectClass 7.105MB 0.000u 0:00.000
Created attachment 61640 [details] original metadata
Created attachment 61641 [details] target metadata
Created attachment 61642 [details] diff metadata
Look like some metadata have been dropped between original and target image, but this cannot not explain why file size have been reduce a lots. Andreas, i need your expertise here. Thanks in advance Gilles Caulier
Lisandro, Which Exiv2 version you use ? Go to Help/Components Info for details Gilles Caulier
(In reply to comment #8) > Lisandro, > > Which Exiv2 version you use ? Go to Help/Components Info for details > > Gilles Caulier digiKam version 1.9.0 Eliminación de mosaico parallelizada: Sí Exiv2 admite metadatos XMP: Sí Exiv2 puede guardarse en JP2: Sí Exiv2 puede guardarse en Jpeg: Sí Exiv2 puede guardarse en PGF: Sí Exiv2 puede guardarse en PNG: Sí Exiv2 puede guardarse en TIFF: Sí LibCImg: 130 LibClapack: Biblioteca interna LibExiv2: 0.20 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.6.4 (4.6.4) LibKExiv2: 1.2.0 LibKdcraw: 1.2.0 LibLCMS: 118 LibLensFun: biblioteca dinámica externa LibLqr: Biblioteca interna LibPGF: 6.09.44 - Biblioteca interna LibPNG: 1.2.44 LibQt: 4.7.3 LibRaw: 0.11.3 LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Widget Marble: 0.11.2 (Stable Release) Infraestructura de la base de datos: QSQLITE LibGphoto2: 2.4.11 LibKipi: 1.2.0 Apt says: exiv2/libexiv2-9: 0.20-2.1 libkexiv2-9: 4:4.6.3-1
It's possible to try to update Exiv2 to 0.21 ? Gilles Caulier
(In reply to comment #7) > Look like some metadata have been dropped between original and target image, > but this cannot not explain why file size have been reduce a lots. (In reply to comment #7) > Look like some metadata have been dropped between original and target image, > but this cannot not explain why file size have been reduce a lots. There is more new metadata in the modified file thought. Look at this: < Thumbnail Offset : 8506 < Thumbnail Length : 4416 --- > Thumbnail Offset : 8470 > Thumbnail Length : 15159 Maybe the original photo had a big thumbnail attached?
(In reply to comment #10) > It's possible to try to update Exiv2 to 0.21 ? I'll try to grab it from experimental and check.
(In reply to comment #12) > (In reply to comment #10) > > It's possible to try to update Exiv2 to 0.21 ? > > I'll try to grab it from experimental and check. Same behaviour.
Are you sure that digiKam is linked to Exiv2 0.21 instead 0.20. Take a look again into Help/Components info... when you update Exiv2, libkexiv2 interface used with digiKAm need to be updated too. Gilles Caulier
(In reply to comment #14) > Are you sure that digiKam is linked to Exiv2 0.21 instead 0.20. Take a look > again into Help/Components info... > > when you update Exiv2, libkexiv2 interface used with digiKAm need to be updated > too. Point. Will try recompiling.
(In reply to comment #15) [snip] > Point. Will try recompiling. digikam in Debian depends on libkexiv2 and not libexiv, and I can't get a newer libkexiv. So no, i can not try with that for the moment. Regards, Lisandro.
digiKam needs libkexiv2 needs Exiv2... libkexiv2 is a KDE/Qt interface to Exiv2 for digiKam Gilles Caulier
(In reply to comment #17) > digiKam needs libkexiv2 needs Exiv2... > > libkexiv2 is a KDE/Qt interface to Exiv2 for digiKam > > Gilles Caulier libkexiv depends on libexiv: http://packages.debian.org/sid/libkexiv2-9 So in order to use digikam with libexiv 0.21 I should also upgrade libkexiv. According to digikam's control file, there is no other dependence on exiv.
Lisandro, Some progress in this file ? Gilles Caulier
I'll check asap.
Still no KDE update, so I still need to wait.
I recompiled digikam 1.9.0 against libkexiv2 4.7.2. But this time I noticed it depends on libexiv libexiv2-9 (0.20-2.1). I'll try recompiling agains a newer libexiv.
Tested against libexiv 0.21.1, same behaviour.
Tested against libexiv 0.22, the bug is still there :-(
Ok, now, it's time to test with digiKam 2.x release. 2.3 is out since one month. 2.4, since few days... Gilles Caulier
Tested with 2.3, the bug is still there.
Official digiKam 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier
This bug is still valid.
Lisandro, I still cannot reproduce your problem in my computer. Here i use 3.0.0-RC. Can you try again with last 2.9.0 stable release please ? Gilles Caulier
(In reply to comment #29) > Lisandro, > > I still cannot reproduce your problem in my computer. Here i use 3.0.0-RC. > > Can you try again with last 2.9.0 stable release please ? Debian is freezed and I only have 2.6.0 at hand. I'm currently busy fixing RC bugs to make the release, I may be able to compile 2.9.0 at some point on January. Lisandro.
Lisandro, This file still valid using last digiKam 4.2.0 ? Gilles Caulier
Yes, but now I think it's half a bug, half a feature. Since not so long the ¿exif? properties of the original images say something like "JPEG (old compression method" while the processed files don't. So I *guess* the problem is that the compression format is changed when the files are being processed, thus reducing the size of the images. While it's a feature if the data is not lost, it's a bug to do so without asking.
Forget my last comment: the bug is still there but both files have "old style jpeg compression"
And you have tested with 4.2.0 ? Gilles Caulier
Mm, sorry, indeed I tested with 4.1.0. Will test with 4.2.0 as soon as is lands in unstable. Once again, sorry for that :-/
Maik, your last changes in BQM solve this issue ? Gilles
Gilles, Yes. For example, the JPEG compression of the queue to the value can be set, which is also used otherwise for storing the images. Maik