Created attachment 128919 [details] Screenshot of description as "binarycaption" SUMMARY I use the Description field in the Captions panel to write some notes about the picture, or just write whatever is in the back of a scanned photo. For some reason, some of the pictures, after writing a description, and then change some other metadata (Tags, date), or moving the picture to another folder, the Description appears as "binary comment" (see attachment). Sometimes re-reading the picture metadata solves it and the description reappears. Sometimes it doesn't. It seems that restarting digikam does the trick, though. STEPS TO REPRODUCE 1. Go to Captions panel, Description tab, Captions field. 2. Write some text. Save changes (Apply). 3. Move the picture to another album within digikam, and re-scan that album so you see the picture. 4. Select the picture and check the contents of the Description. OBSERVED RESULT "binary comment" EXPECTED RESULT The original caption that was written before. SOFTWARE/OS VERSIONS digikam-7.0.0-rc-20200526T141006-x86-64.appimage in ubuntu 20.04LTS
*** This bug has been marked as a duplicate of bug 374012 ***
Exiv2 cannot decode the field because some program wrote there wrong data. Also possible that it is an audio file or the like. What does Exiftool decode? Maik
Reading the metadata again fixes it ??? Maik
Is that the collection about the bad network connection? Exiv2 probably had read errors from the file. I've never seen this problem before. Maik
The string "binary comment" does not come from digiKam. So Exiv2 decoded this. Maik
I see. The metadata was only edited in digikam. Prior to that, this is what I did: I scanned the picture (using Xsane) to png, straightened and cropped the picture using gimp and saved to jpg, copied to a folder in my library, let Digikam refresh the folder, and write the metadata. After that, I tagged the picture, entered the date, and moved the picture to its definitive location. That's when I noticed the "binary comment". It happened to three or four of my pictures today (all of them were just scanned). Re-reading the metadata worked for most cases except one, in which I had to restart digikam to see the correct caption once again. The library is stored in a network folder, but I have not had any (noticeable) network issues for a long time.
Hmm, PNG files were very problematic before Exiv2-0.27.1. Exiv2 saved the color profile / name incorrectly and calculated an incorrect checksum. Maik
Oh, but these were all JPG pictures. I only use PNG during the scan process so I don't lose quality when editing the picture. But digikam only used the jpg version.
The bug also affects Gimp... The problem may have arisen during the conversion. https://gitlab.gnome.org/GNOME/gimp/-/issues/2111 Maik
For interest only, that was the bug report for Exiv2: https://github.com/Exiv2/exiv2/issues/597 Maik
Just to provide more information, even if it's not caused by digikam, some of the files are still affected after restarting digikam. I ran "exiv2 -pa" on the affected file, this is what I see. As a reference, the contents of the description should be: DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 user@TM1703:/media/sshfs/FOTOS$ exiv2 -pa 0091.jpg Exif.Image.ImageDescription Ascii 61 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Image.XResolution Rational 1 236 Exif.Image.YResolution Rational 1 236 Exif.Image.ResolutionUnit Short 1 cm Exif.Image.Software Ascii 13 GIMP 2.10.18 Exif.Image.ExifTag Long 1 178 Exif.Photo.DateTimeOriginal Ascii 20 2001:10:20 00:00:00 Exif.Photo.DateTimeDigitized Ascii 20 2020:05:30 01:08:07 Exif.Photo.UserComment Undefined 68 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Photo.ColorSpace Short 1 sRGB Exif.Thumbnail.ImageWidth Long 1 170 Exif.Thumbnail.ImageLength Long 1 256 Exif.Thumbnail.BitsPerSample Short 3 8 8 8 Exif.Thumbnail.Compression Short 1 JPEG (old-style) Exif.Thumbnail.PhotometricInterpretation Short 1 YCbCr Exif.Thumbnail.SamplesPerPixel Short 1 3 Exif.Thumbnail.JPEGInterchangeFormat Long 1 448 Exif.Thumbnail.JPEGInterchangeFormatLength Long 1 8976 Iptc.Envelope.CharacterSet String 3 Iptc.Application2.Caption String 60 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Xmp.xmpMM.DocumentID XmpText 52 gimp:docid:gimp:18aaf1c6-fe6d-49aa-853b-194f48a5cea5 Xmp.xmpMM.InstanceID XmpText 44 xmp.iid:dc3ccc3d-dc53-46e7-8305-db515a011d77 Xmp.xmpMM.OriginalDocumentID XmpText 44 xmp.did:14811b95-e952-4553-94db-859a96fe210a Xmp.xmpMM.History XmpText 0 type="Seq" Xmp.xmpMM.History[1] XmpText 0 type="Struct" Xmp.xmpMM.History[1]/stEvt:action XmpText 5 saved Xmp.xmpMM.History[1]/stEvt:changed XmpText 1 / Xmp.xmpMM.History[1]/stEvt:instanceID XmpText 44 xmp.iid:5dc9d00c-39fe-4ff3-942e-6080bbf4d8d3 Xmp.xmpMM.History[1]/stEvt:softwareAgent XmpText 17 Gimp 2.10 (Linux) Xmp.xmpMM.History[1]/stEvt:when XmpText 6 +02:00 Xmp.GIMP.API XmpText 3 2.0 Xmp.GIMP.Platform XmpText 5 Linux Xmp.GIMP.TimeStamp XmpText 16 1590793689630645 Xmp.GIMP.Version XmpText 7 2.10.18 Xmp.dc.Format XmpText 10 image/jpeg Xmp.dc.description LangAlt 1 lang="x-default" binary comment Xmp.xmp.CreatorTool XmpText 9 GIMP 2.10 Xmp.acdsee.notes XmpText 60 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Xmp.iptcExt.LocationCreated XmpBag 0 Xmp.iptcExt.LocationShown XmpBag 0 Xmp.iptcExt.ArtworkOrObject XmpBag 0 Xmp.iptcExt.RegistryId XmpBag 0 Xmp.plus.ImageSupplier XmpSeq 0 Xmp.plus.ImageCreator XmpSeq 0 Xmp.plus.CopyrightOwner XmpSeq 0 Xmp.plus.Licensor XmpSeq 0 Xmp.digiKam.CaptionsDateTimeStamps LangAlt 1 lang="x-default" 2020-05-30T01:10:06 Xmp.tiff.ImageDescription LangAlt 1 lang="x-default" DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Xmp.exif.UserComment LangAlt 1 lang="x-default" binary comment
Update: I tagged that picture with a face, and ran the same command again. After re-reading the metadata, now the caption appears, but it seems that the XMP metadata is corrupted somehow. This is the output (I redacted the name of the face): marc@marc-TM1703:/media/sshfs/box_ext/mnt/md0/Personal/Victoria/FOTOS$ exiv2 -pa 0091.jpg Error: XMP Toolkit error 201: XML parsing failure Warning: Failed to decode XMP metadata. Exif.Image.ImageDescription Ascii 61 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Image.XResolution Rational 1 236 Exif.Image.YResolution Rational 1 236 Exif.Image.ResolutionUnit Short 1 cm Exif.Image.Software Ascii 13 GIMP 2.10.18 Exif.Image.ExifTag Long 1 178 Exif.Photo.DateTimeOriginal Ascii 20 2001:10:20 00:00:00 Exif.Photo.DateTimeDigitized Ascii 20 2020:05:30 01:08:07 Exif.Photo.UserComment Undefined 68 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Photo.ColorSpace Short 1 sRGB Exif.Thumbnail.ImageWidth Long 1 170 Exif.Thumbnail.ImageLength Long 1 256 Exif.Thumbnail.BitsPerSample Short 3 8 8 8 Exif.Thumbnail.Compression Short 1 JPEG (old-style) Exif.Thumbnail.PhotometricInterpretation Short 1 YCbCr Exif.Thumbnail.SamplesPerPixel Short 1 3 Exif.Thumbnail.JPEGInterchangeFormat Long 1 448 Exif.Thumbnail.JPEGInterchangeFormatLength Long 1 8976 Iptc.Envelope.CharacterSet String 3 Iptc.Application2.Caption String 60 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Iptc.Application2.Keywords String 21 Firstname Lastname
And finally, since the XMP seemed to be corrupted, I tagged the face once again, and checked the exiv2 output. This time it seems that the XMP metadata could be repaired and everything looks fine: user@TM1703:/media/sshfs/FOTOS$ exiv2 -pa 0091.jpg Exif.Image.ImageDescription Ascii 61 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Image.XResolution Rational 1 236 Exif.Image.YResolution Rational 1 236 Exif.Image.ResolutionUnit Short 1 cm Exif.Image.Software Ascii 13 GIMP 2.10.18 Exif.Image.ExifTag Long 1 178 Exif.Photo.DateTimeOriginal Ascii 20 2001:10:20 00:00:00 Exif.Photo.DateTimeDigitized Ascii 20 2020:05:30 01:08:07 Exif.Photo.UserComment Undefined 68 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Exif.Photo.ColorSpace Short 1 sRGB Exif.Thumbnail.ImageWidth Long 1 170 Exif.Thumbnail.ImageLength Long 1 256 Exif.Thumbnail.BitsPerSample Short 3 8 8 8 Exif.Thumbnail.Compression Short 1 JPEG (old-style) Exif.Thumbnail.PhotometricInterpretation Short 1 YCbCr Exif.Thumbnail.SamplesPerPixel Short 1 3 Exif.Thumbnail.JPEGInterchangeFormat Long 1 448 Exif.Thumbnail.JPEGInterchangeFormatLength Long 1 8976 Iptc.Envelope.CharacterSet String 3 Iptc.Application2.Caption String 60 DIGI 3 26.10.2001 000626540 neg. 25A No.Neg. 25A, 000626540 Iptc.Application2.Keywords String 21 Firstname Lastname Xmp.acdsee.categories XmpText 122 <Categories><Category Assigned="0">Persones<Category Assigned="1">Firstname Lastname</Category></Category></Categories> Xmp.mwg-rs.Regions XmpText 0 type="Struct" Xmp.mwg-rs.Regions/mwg-rs:RegionList XmpText 0 type="Bag" Xmp.mwg-rs.Regions/mwg-rs:RegionList[1] XmpText 0 type="Struct" Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Name XmpText 21 Firstname Lastname Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Type XmpText 4 Face Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area XmpText 0 type="Struct" Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area/stArea:x XmpText 8 0.525102 Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area/stArea:y XmpText 8 0.295021 Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area/stArea:w XmpText 8 0.135366 Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area/stArea:h XmpText 8 0.109983 Xmp.mwg-rs.Regions/mwg-rs:RegionList[1]/mwg-rs:Area/stArea:unit XmpText 10 normalized Xmp.MP.RegionInfo XmpText 0 type="Struct" Xmp.MP.RegionInfo/MPRI:Regions XmpText 0 type="Bag" Xmp.MP.RegionInfo/MPRI:Regions[1] XmpText 0 type="Struct" Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:Rectangle XmpText 37 0.457419, 0.24003, 0.135366, 0.109983 Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName XmpText 21 Firstname Lastname Xmp.digiKam.TagsList XmpSeq 1 Persones/Firstname Lastname Xmp.MicrosoftPhoto.LastKeywordXMP XmpBag 1 Persones/Firstname Lastname Xmp.lr.hierarchicalSubject XmpBag 1 Persones|Firstname Lastname Xmp.mediapro.CatalogSets XmpBag 1 Persones|Firstname Lastname Xmp.dc.subject XmpBag 1 Firstname Lastname
fixed with bug #374012
Git commit 3b9b6615fd7b6a9711a5aa8986d143429bb31909 by Maik Qualmann. Committed on 23/08/2020 at 07:02. Pushed by mqualmann into branch 'master'. filter "binary comment" from the comment fields Since Exiv2-0.27.3 empty comment fields are output as "binary comment". Related: bug 374012, bug 425125 M +11 -6 core/libs/metadataengine/engine/metaengine_exif.cpp https://invent.kde.org/graphics/digikam/commit/3b9b6615fd7b6a9711a5aa8986d143429bb31909
Upgraded from 7.0.0 to 7.1.0, still seeing "binary comment" under the photos, any idea?
Perform a "Read-read metadat from image to database"... Gilles Caulier
In a few cases, the words "binary comment" were saved into the picture as the comment when I saved the metadata overwriting the actual comment. If re-reading the metadata doesn't change it, that might be this case.
Another case, is the Exiv2 shared library version which deal with the "comment contents" In face Exiv2 must detect and decode the binary form automatically. If you have a older Exiv2 version, Exiv2 will return the string "binary comment", else the real data decoded. If you use the digiKam AppImage, we use the last Exiv2 version which much do the job... Gilles Caulier
An existing comment is not deleted from the DB when the metadata is re-read unless the option to clean up the database is temporarily activated in the digiKam metadata setup. Maik
(In reply to MarcP from comment #18) > In a few cases, the words "binary comment" were saved into the picture as > the comment when I saved the metadata overwriting the actual comment. If > re-reading the metadata doesn't change it, that might be this case. If it's the case, any simple method to remove them? Just tested, newly imported images are fine, but re-reading existing images yielded no changes. Cheers.
(In reply to Maik Qualmann from comment #20) > An existing comment is not deleted from the DB when the metadata is re-read > unless the option to clean up the database is temporarily activated in the > digiKam metadata setup. > > Maik Thanks! Exactly what I need. Cheers.
It only happened once to me, but I was just saying that it was a possibility. Using an external tool (e.g. http://exif.regex.info/exif.cgi ) you can make sure if the text "binary comment" has actually been written to the file, or if it's just a bug in the Exiv2.
Created attachment 132088 [details] Example photo which results in "binary comment" appearing as the caption in Digikam
I have uploaded an example photo from a Canon EOS 550D which results in "binary comment" appearing as the caption. This is not resolved in Digikam 7.1.0 (tested with x86-64 AppImage). This could cause data loss in the following scenario: 1. Set Digikam to write metadata to sidecar file only. 2. Overwrite "binary comment" by typing in a new caption in Digikam. 3. Select Reread Metadata From File from Item menu. Result: new caption is overwritten with "binary comment". I understand that the "Reread Metadata From File" function already has the potential to lose the user's data if it conflicts with the metadata in the file (in fact, perhaps the function should be renamed "Reset Metadata to File Metadata"?), but this is a scenario where a user wouldn't expect their data to be overwritten as there is no comment in the file.
Exiftool user comment decoded in RAW mode. Your Canon: UserComment = Tag 0x9286 (264 bytes, undef[264]): 2098: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................] My Nikon: UserComment = ASCII Tag 0x9286 (44 bytes, undef[44]): 033c: 41 53 43 49 49 00 00 00 20 20 20 20 20 20 20 20 [ASCII... ] As you can see, your Canon does not encode a charset in the user comment, even if the comment is empty. Therefore Exiv2 decodes your user comments as "binary comment". You could of course now say that Exiv2 should also interpret this as an empty comment. But we can also say that Canon writes incorrect metadata in the images. I think that it has to be solved at Exiv2 level, we can't add more workarounds. You can disable reading the XMP user comment in the advanced metadata settings to avoid the problem with sidecar. Maik
Maik, From your comment #26, how did you print the raw data values from tags with ExifTool ? Gilles
Fixed with bug #425125
I think it was the output of 3 x verbose from ExifTool (-v3) and I grabbed the UserComment from it. Maik