Summary: | Iptc.Application2.Keywords appends always the 0-byte | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | oongi |
Component: | Metadata-Iptc | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahuggel, anaselli, caulier.gilles |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.5.0 |
Description
oongi
2007-07-25 02:00:08 UTC
I confirm this bug also for digikam 0.9.1 If I import to gallery an image with multiple keywords only the first one is inserted into the database due to the null char. For know I have patched gallery, but I think that is a digikam bug. See https://sourceforge.net/tracker/index.php?func=detail&aid=1785206&group_id=7130&atid=107130 Thanks, gianpaolo Andreas, Are you seen this file ? What do you think about ? Gilles I can't reproduce that with a simple test: ahuggel@mowgli> exiv2 -M'set Iptc.Application2.Keywords DIGIKAM' exiv2-empty.jpg ahuggel@mowgli> ./exiv2 -pi exiv2-empty.jpg | hexdump -C 00000000 49 70 74 63 2e 41 70 70 6c 69 63 61 74 69 6f 6e |Iptc.Application| 00000010 32 2e 4b 65 79 77 6f 72 64 73 20 20 20 20 20 20 |2.Keywords | 00000020 20 20 20 20 20 20 20 20 20 20 20 20 20 53 74 72 | Str| 00000030 69 6e 67 20 20 20 20 20 20 37 20 20 44 49 47 49 |ing 7 DIGI| 00000040 4b 41 4d 0a |KAM.| 00000044 Where is the code in digikam which sets the keywords? -ahu. Andreas, The code is in libkexiv2 : http://websvn.kde.org/branches/extragear/kde3/libs/libkexiv2/libkexiv2/kexiv2.cpp?revision=704515&view=markup Look method "bool KExiv2::setImageKeywords(...)" Gilles @Andreas: in your test, you set the Keywords with exiv2 instead of digikam. Setting keywords with exiv2 works here fine, too. I only used exiv2 to display the NULL-Byte appended by digikam. If you want to reproduce, you have to use digikam to set the keyword. Thanks oongi oongi: yes, my job is to test if the problem is with exiv2 :) -ahu. sorry, didn't understand that... bye oongi Gilles: Use a string value instead of an asciiString. Exiv2::AsciiValue adds a 0-byte (which is required for Exif strings). Just change 'asciiString' to 'string' in the first of these 3 lines in KExiv2::setImageKeywords: Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); val->read(key.latin1()); iptcData.add(iptcTag, val.get()); The same fix is needed in all other places where an IPTC string tag is set. I saw similar code in KExiv2::setImageSubjects and KExiv2::setImageSubCategories. oongi: Sorry, should have elaborated: digikam uses exiv2 (the library) to deal with Exif and IPTC metadata. When there is such a problem, it may be a bug for digikam or for exiv2. Since I'm an exiv2 developer, I need to know whether it is an exiv2 bug and a quick way to test for this is to reproduce the problem with the exiv2 utility. -ahu. Thanks Andreas, I will fix it Gilles oongi, Can you try to patch the code in libKexiv2 (KExiv2::setImageKeywords() method) to validate the fix with digiKam. Thanks in advance Gilles SVN commit 707242 by cgilles: libkexiv2 from KDE3 branch : fix IPTC strings creation with non-zero value at end CCBUGS: 148182 M +3 -3 kexiv2.cpp --- branches/extragear/kde3/libs/libkexiv2/libkexiv2/kexiv2.cpp #707241:707242 @@ -2042,7 +2042,7 @@ QString key = *it; key.truncate(64); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.latin1()); iptcData.add(iptcTag, val.get()); } @@ -2125,7 +2125,7 @@ QString key = *it; key.truncate(236); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.latin1()); iptcData.add(iptcTag, val.get()); } @@ -2209,7 +2209,7 @@ QString key = *it; key.truncate(32); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.latin1()); iptcData.add(iptcTag, val.get()); } Angelo, Patch given on #11 must be backported to Mandriva 2008.0 package... Gilles SVN commit 707247 by cgilles: libkexiv2 from trunk (KDE4) : fix IPTC strings creation with non-zero value at end BUG: 148182 M +3 -3 kexiv2.cpp --- trunk/extragear/libs/libkexiv2/libkexiv2/kexiv2.cpp #707246:707247 @@ -2565,7 +2565,7 @@ QString key = *it; key.truncate(64); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.toLatin1().constData()); iptcData.add(iptcTag, val.get()); } @@ -2648,7 +2648,7 @@ QString key = *it; key.truncate(236); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.toLatin1().constData()); iptcData.add(iptcTag, val.get()); } @@ -2732,7 +2732,7 @@ QString key = *it; key.truncate(32); - Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::asciiString); + Exiv2::Value::AutoPtr val = Exiv2::Value::create(Exiv2::string); val->read(key.toLatin1().constData()); iptcData.add(iptcTag, val.get()); } Gilles, how about releasing a new versione instead? Angelo, Yes, releasing a new version is fine for me. 3 B.K.O files have been fixed + few API improvements. You decide to do it. If you have free time, feel free to do it... Gilles I don't know how to patch the code witch patch, instead I changed in the lines 2022, 2105 and 2189 of kexiv2.cpp (version 0.1.5 of libkexiv2) "Exiv2::asciiString" in "Exiv2::string" and now there isn't the NULL-Byte at the end of the tags: name@linux:~$ exiv2 -pi testimg.jpg | hexdump -C 00000000 49 70 74 63 2e 41 70 70 6c 69 63 61 74 69 6f 6e |Iptc.Application| 00000010 32 2e 4b 65 79 77 6f 72 64 73 20 20 20 20 20 20 |2.Keywords | 00000020 20 20 20 20 20 20 20 20 20 20 20 20 20 53 74 72 | Str| 00000030 69 6e 67 20 20 20 20 20 20 34 20 20 74 65 73 74 |ing 4 test| 00000040 0a 49 70 74 63 2e 41 70 70 6c 69 63 61 74 69 6f |.Iptc.Applicatio| 00000050 6e 32 2e 50 72 6f 67 72 61 6d 20 20 20 20 20 20 |n2.Program | 00000060 20 20 20 20 20 20 20 20 20 20 20 20 20 20 53 74 | St| 00000070 72 69 6e 67 20 20 20 20 20 34 36 20 20 64 69 67 |ring 46 dig| 00000080 69 6b 61 6d 20 28 55 73 69 6e 67 20 4b 69 70 69 |ikam (Using Kipi| 00000090 20 4d 65 74 61 64 61 74 61 45 64 69 74 20 70 6c | MetadataEdit pl| 000000a0 75 67 69 6e 20 30 2e 31 2e 34 29 0a 49 70 74 63 |ugin 0.1.4).Iptc| 000000b0 2e 41 70 70 6c 69 63 61 74 69 6f 6e 32 2e 50 72 |.Application2.Pr| 000000c0 6f 67 72 61 6d 56 65 72 73 69 6f 6e 20 20 20 20 |ogramVersion | 000000d0 20 20 20 20 20 20 20 20 20 53 74 72 69 6e 67 20 | String | 000000e0 20 20 20 20 31 31 20 20 30 2e 39 2e 32 2d 66 69 | 11 0.9.2-fi| 000000f0 6e 61 6c 0a |nal.| Thanks a lot! oongi P.S. and now move on to the next one: https://bugs.kde.org/show_bug.cgi?id=149475 ;-) To apply a patch just do patch < patchfile.patch in the right directory. Sometimes patch -p0 < patchfile.patch is needed (I always forget when, but patch will tell you ... ;-), To provide a patch just do svn diff > patchfile.patch Best, Arnd |