Created attachment 192078 [details] a file with this problem I have a set of pictures where Digikam fails silently to write metadata (caption or title for example) on the file : it set the metadata in the database but not in the file. Running with debug I can see Digikam try to use Exiv2 instead of exiftool (even Check ExifTool availability: true) and exiv2 crashes with "Error # 38 : "Taille du segment JPEG XMP est plus grand que 65535 octets". See debug log below. Digikam is configurated to delegate exiftool all operations to write metadata but it seems it does not do that. > exiftool on these files is ok, no error debut output related to this sequence: digikam.general: No write to baloo +++++++++++++++++++++++++++++++++++++ digikam.metaengine: Check ExifTool availability: true digikam.metaengine: ExifTool "Load Chunks" "-TagsFromFile /home/michel/Images/famille/photo-video/2025/2025-05/2025-05-01_20h16-54.jpg -all:all -icc_profile -o -.exv" digikam.metaengine: ExifToolProcess::readOutput(): ExifTool command completed digikam.metaengine: ExifTool complete command for action "Load Chunks" with elapsed time (ms): 190 digikam.metaengine: EXV chunk size: 83208 digikam.metaengine: ExifTool parsed command for action "Load Chunks" 1 properties decoded digikam.metaengine: ExifTool complete "Load Chunks" for "/home/michel/Images/famille/photo-video/2025/2025-05/2025-05-01_20h16-54.jpg" digikam.metaengine: Metadata chunk loaded with ExifTool digikam.metaengine: Loading metadata with "ExifTool" backend from "/home/michel/Images/famille/photo-video/2025/2025-05/2025-05-01_20h16-54.jpg" digikam.general: Writing tags digikam.metaengine: MetaEngine::metadataWritingMode 0 digikam.metaengine: Will write Metadata to file "/home/michel/Images/famille/photo-video/2025/2025-05/2025-05-01_20h16-54.jpg" digikam.metaengine: Check ExifTool availability: true digikam.metaengine: Cannot export changes with Exiv2 backend: (Error # 38 : "Taille du segment JPEG XMP est plus grand que 65535 octets") digikam.metaengine: Exiv2 error exception for "2025-05-01_20h16-54.jpg" Writing of metadata aborted! digikam.general: Threads Pool "" will use 8 threads digikam.general: Action Thread run 1 new jobs digikam.general: One job is done Digikam::TagsJob(0x5613001f5b40) time: 28 digikam.general: Finish Main Thread
Internally, the metadate byte-array are encoded as Exiv2 containers passed to ExifTool.
This is not a crash, it's a error from Exiv2 because something is wrong in the metadata. In next digiKam 9.1.0 pre-release, we have updated the Exiv2 to the last stable release just published. You can test with the AppImage bundle to see if the problem is reproducible. https://files.kde.org/digikam/ If yes, you must report the problem as UPSTREAM to Exiv2 team: https://github.com/Exiv2/exiv2/issues Gilles Caulier
(In reply to caulier.gilles from comment #2) > This is not a crash, it's a error from Exiv2 because something is wrong in > the metadata. Something is wrong in the metadata and exiftool does not detect that ? I have strong doubts about it. Anyway, Digikam writes the tag in its base without to say to the user it fails to write it into the file. I think it is a serious flaw.
Moreover, not only exiftool read the file without error but it is also able to write the tag without error. I have about 70 files this way.
*** This bug has been marked as a duplicate of bug 468830 ***
When writing or adding metadata, the maximum allowable Exif size of 65,535 bytes is exceeded. This issue arises because we still use Exiv2 to create the metadata container, which is subsequently written by ExifTool. Note that even ExifTool itself can only employ a workaround to bypass this problem: it simply creates two separate Exif segments. The difficulty with this approach is that only ExifTool can properly handle these dual Exif segments; no other tool can. The proper solution would be to purge the Exif metadata of any large, unnecessary binary blobs. Unfortunately, many camera manufacturers already utilize nearly the entire 65,535-byte limit. Maik
> When writing or adding metadata, the maximum allowable Exif size of 65,535 bytes is exceeded. See attached the output of exiftool -G1 -a -s on two photos (let say A and B) made with the same Pixel 8 at a few seconds of interval : ok.txt is the output of the photo A where Digikam can write metadata nok.txt is the output of the photo B where Digikam cannot write metadata I made a diff between both files and I fail to see how your explanation above (> 65,535 bytes) applies here. NB. I don't know if B is still the original one or if it has been altered by previous Digikam metadata writing resulting into the problem.
Created attachment 192298 [details] exiftool output of a ok file
Created attachment 192299 [details] exiftool output of a nok file
Don't forget that Exif host Makernotes (always) as byte array not decodable without reverse engineering (ExifTool is magic here). Preview images (not only thumbnails) can be also present, as XMP too. Exif is a big puzzle : Yys, all these kind of info can be hosted in the single Exif chunk as well, so the limitation arrives quickly. digiKam don't touch Markernotes, and host XMP and IPTC in a separated chunk. JPEG file limitation is one other stuff. Prefers another format without limitation for archiving with lossless compression support (TIFF, PNG, HEIF for ex).
Well I just tried to do exiftool -G1 -a -s -XMP-GCamera:HDRPlusMakerNote= <a nok file> and now it an ok file ! So I have now a workflow to correct the problem for my existing photos (set picklabel on a set of photos, refresh it and filter on no picklabel ; and then apply a script removing XMP-GCamera:HDRPlusMakerNote). To workaround the problem for the future photos, I will need to check them before to tag them since there is not warning from Digikam.
My interrogation about the size explanation is that the attached ok file has a larger makernotes size than the attached nok file.
The main problem in digiKam is the Exiv2 usage to work with Exif (Iptc and XMP) chunks. In case of ExifTool delegate option is turned on, ExifTool is only used to read/write the chunks in the files. All manipulations of tags in chunks is done by Exiv2 API. The chunks are shared with ExifTool for the files IO. Your solution is a workaround using a pure ExifTool usage. Perhaps a script called by digiKam BQM can be used here, but it will be an obscure way for end-users.
> My interrogation about the size explanation is that the attached ok file has a larger makernotes size than the attached nok file. You did not answer to that. Ok, removing the makernotes block avoid the problem but why the file with a larger makernotes size does not have the problem when the file with a smaller makernotes size have it ? It seems to me that may be we miss a piece of the explanation. > Perhaps a script called by digiKam BQM can be used here, but it will be an obscure way for end-users. For sure. But at least a warning would be useful ; it is a major flaw since it is a silent flaw you can discover months or years later rebuilding the db or moving for another DAM.
The maker-notes problematic is certainly due to the non documented tags/formats/structures. A miss-interpreted maker-notes bytes array can break Exiv2 workflow. In digiKam we caught the C++ exceptions when these occurs, but this depend how Exiv2 C++ code deal with dysfunctions. In certain cases, the maker-notes can be miss interpreted in the memory and not really usable (or something like that).
A final comment to inform that I searched all photos with this problem : I found 64. All of them were taken with a Pixel phone (Pixel 5 or Pixel 8). I corrected the problem removing XMP-GCamera:HDRPMakerNote (for the older ones) and XMP-GCamera:HDRPlusMakerNote (for the newer ; it seems that Google renamed HDRP to HDRPlus). This is related to HDDR Ultra mode setting of the Pixel Camera app so I have two choices until the bug will be corrected (into a few years if you wait for an Exiv2 fix...) : 1) to disable this setting 2) to apply a script to remove this metadata before to load them into Digikam. Of course, I cannot ensure that there are not others cases to fall into this Exiv2 problem. Thank you for all the work on Digikam !
Just so you don't regret it later: by deleting this metadata, you will never be able to view the images in HDR again. Currently, digiKam cannot yet process this metadata to generate an HDR image; however, for Gwenview, a feature request for this already exists. Maik
Thank for the the information. Hopefully I kept a copy of these photos with the HDR information in case it would be useful someday.
ideally, moving this information in a XMP sidecar with a script can be a solution, or better, convert to a wavelets compression format which support all metadata.