| Summary: | After running a batch process to change metadata, the files halved in size. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Lisandro Damián Nicanor Pérez Meyer <perezmeyer> |
| Component: | Plugin-Bqm-AssignTemplate | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | ahuggel, caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 4.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.11.0 | |
| Sentry Crash Report: | |||
| Attachments: |
original metadata
target metadata diff metadata |
||
|
Description
Lisandro Damián Nicanor Pérez Meyer
2011-07-03 20:01:55 UTC
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 |