[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #36 from [email protected] --- Here is a workaround : 1) Enable write metadata to sidecar files in digikam 2) Apply your changes 3) Run this command `exiftool -tagsFromFile image.jpg.xmp -all:all -overwrite_original image.jpg` -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #35 from FeikeEU --- (In reply to caulier.gilles from comment #34) > >Why not to bypass exiv2 when it fails ? (only if user set "delegate to > >Exiftool writing operations"). Of course, I have no idea whether such a fix > >is reasonably feasible, it is just a suggestion. > > Because actually we cannot. > Thanks for you continued feedback and efforts!! I appreciate the effort it would cost to rebuild digiMam's metadata engine, so I'm more hoping that exiv2 will fix the issue at their end, at some point. Still, until (if 'ever') that happens, it is still unfortunate that people are carefully managing their tags (face tags, in my personal situation), while they don't always get added to the actual image file. In some sense, the work gets lost, without the user realizing it! (That's how I, at some point, came across this issue. In another application (GeoSetter) I did not see some face tags, that I was sure I added to the image. And now I don't know which other tags did not get written, in the tens-of-thousands of images I tagged in the last years) So I would still (humbly :)) ask for an error message to be shown: "file xyz was not updated", so that I can (try to) fix the issue when it occurs. (E.g. 'clean/fix' the JPG file and try again.) (While the face tags I set are still in the digiKam database, I only 'really rely' on the metadata that is stored in the actual image files, as that is (in my opinion) the only way to be 'future proof', and not be 'forever' dependent on the (continued existence) of the database of one application or the other.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #34 from [email protected] --- >Why not to bypass exiv2 when it fails ? (only if user set "delegate to >Exiftool writing operations"). Of course, I have no idea whether such a fix is >reasonably feasible, it is just a suggestion. Because actually we cannot. Internally digiKam use the Exiv2 container to host metadata chunk as Exif. It's due to the story as Exiv2 is a prior solution used by digiKam to deal with metadata. The ExifTool support is a work around to enable extra IO files support that Exiv2 fail. We pass the Exiv2 container to ExifTool and this one flush the chunks to the files. The same mechanism is used to read. There are possible solutions to this problem: 1 - Exiv2 must be fixed to support large Exif chunk. There is an old report in Exiv2 bugzilla about this problem. See comment 6 for details. 2 - Port whole digiKam metadata engine to pure ExifTool. This require a large code to rewrite and test. We don't plan to do it. Also the performance of ExifTool due to Perl usage will be lower than a native C++ library as Exiv2. 3 - Use a work around with ExifTool to patch and merge the Exif large Exif chunk. I don't know if this way already exists. Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #33 from mahikeulbody <[email protected]> --- (In reply to caulier.gilles from comment #31) > The bug is located in Exiv2, and already reported since a while and not yet > fixed: > > https://github.com/Exiv2/exiv2/issues/1549 Meanwhile, users are tagging photos without realizing that some of them aren’t actually tagged. I think it is a real problem, even if the % of concerned photos is low. Why not to bypass exiv2 when it fails ? (only if user set "delegate to exiftool writing operations"). Of course, I have no idea whether such a fix is reasonably feasible, it is just a suggestion. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Maik Qualmann changed: What|Removed |Added CC||[email protected] --- Comment #32 from Maik Qualmann --- *** Bug 519841 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #31 from [email protected] --- The bug is located in Exiv2, and already reported since a while and not yet fixed: https://github.com/Exiv2/exiv2/issues/1549 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Maik Qualmann changed: What|Removed |Added CC||[email protected] --- Comment #30 from Maik Qualmann --- *** Bug 517665 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Dmitry Nezhevenko changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added Version|8.3.0 |8.7.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #29 from Chris --- Reproduce error. 1: Download https://bugsfiles.kde.org/attachment.cgi?id=176930 and save as test-large-metadata.jpg 2: Copy to one of your digikam albums 3: Let digikam scan the file, 4: Add a tag 5: Write metadata to file (might happen automatically, depending on your settings) 6: Select the image (with the tag) 7: Item menu -> Reread metadata form file 8: Observe your tag disappear -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #28 from Chris --- (In reply to caulier.gilles from comment #26) > Hi, > > The digiKam 8.7.0 pre-release for Windows have been rebuild from scratch > today with many improvements and updates. Please test with this version to > see if the problem is reproducible. > > Link to download: https://files.kde.org/digikam/ > > Thanks in advance > > Gilles Caulier Still present in digiKam-8.7.0-20250411T170124-Qt6-Win64 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #27 from Chris --- (In reply to caulier.gilles from comment #25) > Hi, > > digiKam 8.6.0 is just released: > > https://www.digikam.org/news/2025-03-15-8.6.0_release_announcement/ > > Problem still exists with this version? > > Thanks in advance > > Gilles Caulier Still present in 8.6.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #26 from [email protected] --- Hi, The digiKam 8.7.0 pre-release for Windows have been rebuild from scratch today with many improvements and updates. Please test with this version to see if the problem is reproducible. Link to download: https://files.kde.org/digikam/ Thanks in advance Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #25 from [email protected] --- Hi, digiKam 8.6.0 is just released: https://www.digikam.org/news/2025-03-15-8.6.0_release_announcement/ Problem still exists with this version? Thanks in advance Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #24 from Chris --- A work-around for the bug of HdrPlusMakernotes from Pixel phones: *** #store metadata in sidecar (extract embedded): exiftool -ee -o %d%f.xmp filename.jpg #remove -HdrPlusMakernotes from the original file: exiftool -HdrPlusMakernotes= filename.jpg #reestablish data from xmp file: exiftool -tagsfromfile filename.xmp "-xmp:all>all:all" filename.jpg *** For me, this makes digikam 8.5.0 able to save metadata to the jpg-file and sync from database to file. This is only necessary on files where HdrPlusMakernotes are "visible" for exiftool without the -ee parameter. After the above operation the HdrPlusMakernotes can only be extracted with exiftool -ee, which apparently helps on the way the embedded Exiv2 handles the files in digikam. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #23 from Chris --- Created attachment 176930 --> https://bugs.kde.org/attachment.cgi?id=176930&action=edit Test file with over 64K metadata from Google Pixel 7a Another test-file that shows the problem with large metadata. It was established that that the issue in digikam is due to a limitation in Exiv2 handling metadata over 64KB (KiB). Will this bug be addressed with an optional ability to enable exiftool (slower) as the metadata "engine"? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #22 from Chris --- @Maik Thanks for the explanation. I will attach the file to the correct bug report ;) Best regards, Chris -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #21 from Maik Qualmann --- In your test file, the problem is not the namespace "GCamera" as in the other bug reports, but the size of the XMP JPEG segment. Exiv2 does not support more than 65535 bytes. Even though we do a lot with ExifTool, digiKam is based internally on Exiv2 for preparing the metadata. At the moment, I do not see this limitation in Exiv2 being fixed in the near future. For us, the only solution is to write completely natively with ExifTool, with all its advantages and disadvantages (slow). Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #20 from Chris --- Attached this attachment to another bug that was marked resolved, but described the problem more precisely: https://bugsfiles.kde.org/attachment.cgi?id=176922 Digikam 8.5.0 (Windows) is unable to save tags or face regions to the file. The attached file is constructed with metadata from a Pixel 7a (the metadata of photo I really had problems with). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #19 from Chris --- Bug 481268 seems to be related or maybe the exact same: https://bugs.kde.org/show_bug.cgi?id=481268 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added Version|8.1.0 |8.3.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Chris changed: What|Removed |Added CC||[email protected] --- Comment #18 from Chris --- I tried today with digiKam-8.3.0-20240120T105916-Win64.exe Metadata is no longer deleted, but keywords added (tags from the tags tree) are not longer written to the file. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #17 from José Oliver-Didier --- Created attachment 164495 --> https://bugs.kde.org/attachment.cgi?id=164495&action=edit Test Image File with large XMP -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #16 from José Oliver-Didier --- (In reply to caulier.gilles from comment #15) > José, > > The 8.3.0 pre-release installer is updated online with the last changes from > Maik. > > Please install file and report: https://files.kde.org/digikam/ > > Best > Gilles caulier I tested this with 8.3.3 and observed that the metadata is not being erased as before (which is good), however any caption (description) text added is not written back to the file. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #15 from [email protected] --- José, The 8.3.0 pre-release installer is updated online with the last changes from Maik. Please install file and report: https://files.kde.org/digikam/ Best Gilles caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #14 from Maik Qualmann --- Git commit 9e46012e63e5ebf6292d5798b6b197228971d2d1 by Maik Qualmann. Committed on 03/12/2023 at 10:16. Pushed by mqualmann into branch 'master'. abort writing with ExifTool if Exiv2 has an error exception M +7-1core/libs/metadataengine/engine/metaengine_p.cpp https://invent.kde.org/graphics/digikam/-/commit/9e46012e63e5ebf6292d5798b6b197228971d2d1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #13 from Darek Kay --- @Maik Thank you for looking into this. I should have been more specific: it is not the XMP file that is destroyed (here digiKam always works). It's the JPG file for which the sidecar exists that is destroyed. This is the setup: - 468830-small.jpg + 468830-small.xmp - 468830-big.jpg + 468830-big.xmp Here are the settings you've requested - ☑ Read from sidecar files - ☑ Write to sidecar files; Write to XMP sidecar for read-only item only - ☑ Sidecar file names are compatible with commercial programs I also use: ☑ Behavior: Delegate to ExifTool backend all operations to write metadata to files After changing the rating to "2" for both files, digiKam displays values from the sidecar file (rating 5). Inspect the JPG files manually to verify the problem: $ exiftool -Rating 468830-big.jpg $ exiftool -Rating 468830-small.jpg Rating : 2 And it's not only the rating that is missing for "big.jpg", it's the entire EXIF/XMP/IPTC metadata. Some further notes: - I've installed 8.2.0 after my comment yesterday and the issue is still reproducible. - I'm on Windows 10. As the workaround from José is not practicable for my use case (I would have to remove information from the XMP file), I will probably adjust my workflow. Right now I'm using "file.jpg" + "file.raf" + "file.xmp" (and hence the settings I've listed above), but I really only want to use XMP for the RAW file. As the (from my perspective) unintended JPG<>XMP connection causes the problem, I might use "file.jpg" + "file.raw.raf" + "file.raw.xmp" as a workaround, for which this bug does not occur. I hope this helps others with a similar setup. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #12 from Maik Qualmann --- I have worked intensively with your example files and cannot reproduce any problems here with the current digiKam-8.3.0 developer version on Linux. A test on Windows will follow later. The "big" XMP file is not destroyed and metadata is added or changed. The crs:Table data remains unchanged. Please post a screenshot of your current sidecar settings. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830
--- Comment #11 from Darek Kay ---
I have encountered the same issue (digiKam deletes all metadata) and the core
issue is the same (XMP segment is big), BUT the use case is slightly different
and I feel like this is a problem with digiKam itself. I have attached 3 files:
- A minimal jpg file
- A "small" XMP sidecar file
- A "big" XMP sidecar with 240Kb of data (minimal example of a file coming
from Lightroom)
To reproduce the problem:
- Save XMP sidecar files as "468830-small.xmp" and "468830-big.xmp"
- Duplicate the jpg file into "468830-small.jpg" and "468830-big.jpg" to
match both sidecar files.
- Open both images in digiKam.
- Change the rating (or any other metadata) for both files.
- Synchronize/save the metadata.
What you will notice is that the "small" JPG file is fine (the metadata is
stored), while the "big" JPG file is broken (metadata lost).
The interesting part is that the field that causes the problem
("crs:Table_...") is never actually stored within JPG by digiKam. This is fine,
as the field does not make much sense in a JPG file, but despite not being
saved it causes the metadata loss. My guess is that DigiKam passes all XMP data
- including the sidecar file - to the backend, even if some data won't be
stored in the JPG file.
If you think it's worth handling my use case separately from the initial bug, I
can open a new ticket.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #10 from Darek Kay --- Created attachment 163762 --> https://bugs.kde.org/attachment.cgi?id=163762&action=edit Example XMP sidecar file (small) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #9 from Darek Kay --- Created attachment 163761 --> https://bugs.kde.org/attachment.cgi?id=163761&action=edit Example XMP sidecar file (big) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #8 from Darek Kay --- Created attachment 163760 --> https://bugs.kde.org/attachment.cgi?id=163760&action=edit Example image file -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Darek Kay changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #7 from [email protected] --- @José, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer + ExifTool backend available at usual place: https://files.kde.org/digikam/ This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added Version|8.0.0 |8.1.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #6 from José Oliver-Didier --- I was still able to reproduce the issue on digiKam 8.1.0 pre-release. :( Seems I forgot to attach the sample file to this bug. I used the one from the original Bug 448729 Looking in the Exiv2 GitHub thread I could not find any indication to the 64K limit issue being finally fixed. https://github.com/Exiv2/exiv2/issues/1549 https://github.com/Exiv2/exiv2/issues/2150 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #5 from [email protected] --- @José Olivier-didier, digiKam 8.1.0 pre-release Windows bundle is now ported to Exiv2 0.28 which come with a huge list of bugfixes : https://github.com/Exiv2/exiv2/issues/2406#issuecomment-1529139799 Installer file is available here : https://files.kde.org/digikam/ In case of Exiv2 bug fixed with this version, please give us a feedback. Thanks in advance Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #4 from [email protected] --- Git commit 3d71acc72593534c2a1398d2945992fbbf45935a by Gilles Caulier. Committed on 16/05/2023 at 03:00. Pushed by cgilles into branch 'master'. Switch bundles from Exiv2 0.27 maintenance branch to new 0.28 release Related: bug 386291, bug 386291, bug 452567 M +11 -8project/bundles/3rdparty/ext_exiv2/CMakeLists.txt https://invent.kde.org/graphics/digikam/commit/3d71acc72593534c2a1398d2945992fbbf45935a -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 Maik Qualmann changed: What|Removed |Added CC||[email protected] --- Comment #3 from Maik Qualmann --- Writing with ExifTool is not native writing in digiKam-8.0.0 at the moment. We create a temporary EXV container with Exiv2 that is applied to the metadata with ExifTool. The problem occurs because Exiv2 does not yet support Exif metadata greater than 65535. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added OS|Other |Microsoft Windows Platform|Other |Microsoft Windows -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 [email protected] changed: What|Removed |Added CC||[email protected] Component|Metadata-Engine |Metadata-ExifTool -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #2 from José Oliver-Didier --- Another workaround is to use exiftool itself to "re-build" the XMP metadata. If I "fix" the XMP using exiftool using: exiftool test_before.jpg -xmp:all= -tagsfromfile @ "-all:all
[digikam] [Bug 468830] Metadata is lost after write operation when the size of XMP JPEG segment is larger than 65535 bytes when using Exiftool backend
https://bugs.kde.org/show_bug.cgi?id=468830 --- Comment #1 from José Oliver-Didier --- Created attachment 158334 --> https://bugs.kde.org/attachment.cgi?id=158334&action=edit Display error message until exiftool can be used for all read/write operations? What I am surmising here is that Digikam uses exiv2 to read the metadata and build a "tag file" which is then used by exiftool to write to the file. Prior to writing the tags, exiv2 is failing, hence the "Error #37", writes an empty tag file and as such exiftool erases the metadata and replaces it with the empty file. I believe that if there is no immediate fix for this issue because of the exiv2 dependency this should produce an error to the user and not apply the changes to the files. Similar behavior can be observed in Microsoft Windows Photos app which displays the error message: "Description can't be saved." However, Exiftool is able to read and write to the file. -- You are receiving this mail because: You are watching all bug changes.
