SUMMARY Both darktable and digikam use Exiv2 (AFAIK) but only darktable is able to write it into the jxl files, not digikam. NB. digikam reads the xmp metadata written by darktable. STEPS TO REPRODUCE 1. select a jxl file 2. add a tag 3. reread metadata from file OBSERVED RESULT The added tag is no more present. We can also check it through the xmp panel. ADDITIONAL INFORMATION 'Delegate to exiftool backend' parameter is unset (so it is Exiv2 acting).
Sorry, I just checked Exiv2 don't support yet writing xmp to jxl, so darktable found another way to do that, not using Exiv2.
Exiv2-0.27.4 with active BMFF support, supports reading metadata. With active ExifTool support, writing should also be possible. Maik
> Exiv2-0.27.4 with active BMFF support, supports reading metadata. Yes, as I wrote digikam read all xmp data written by darktable. > With active ExifTool support, writing should also be possible. I just tried with exiftool enabled and no writing is done ; worse, all existing xmp metadata is erased.
Oh, also ExifTool can only read JXL. https://exiftool.org/exiftool_pod.html#Writing Well, I wouldn't currently convert my images to JXL... Maik
According to https://exiftool.org/#supported, it should be possible for xmp metadata (I think your link refers to a not updated doc). > Well, I wouldn't currently convert my images to JXL... In this case, it is not a conversion to jxl, it is an export from raw to jxl (with darktable).
I just tried using exiftool command line : it is able to write xmp data (which digikam is able to read). So it seems there is an issue between digikam and exiftool backend in this case.
Git commit 9a13abeb5fccbde511e5d91e4543373e52e0ff8c by Maik Qualmann. Committed on 20/02/2023 at 18:38. Pushed by mqualmann into branch 'master'. changed command to sync EXV container with ExifTool FIXED-IN: 8.0.0 M +3 -1 NEWS M +1 -4 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/commit/9a13abeb5fccbde511e5d91e4543373e52e0ff8c
Git commit 75f648cac5b14b605d2091871465547c3c219f44 by Maik Qualmann. Committed on 20/02/2023 at 20:29. Pushed by mqualmann into branch 'master'. the behavior of ExifTool is not constant when writting EXV container Check for a JXL file. It may be necessary to check for another format. M +0 -1 NEWS M +10 -1 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/commit/75f648cac5b14b605d2091871465547c3c219f44
I don't know if both issues are related but I created an issue about Exiftool : https://exiftool.org/forum/index.php?topic=14515.0
I read your patch and I see that digikam wrote also iptc args. Exiftool don't support iptc for jxl format so may be it was the cause of the problem.
IPTC is ignored by ExifTool on JXL and is not the problem. I also observed your bug report for ExifTool and it is the reason for the current workaround in digiKam. With JXL, ExifTool always seems to start from an "empty" metadata content. Maik
The exiftool bug will be fixed in 12.57 : https://exiftool.org/forum/index.php?topic=14515.0 We will see if that allows to remove the workaround you implemented.
Ok, i will update ExifTool to next version in the bundles when it will be available... Gilles Caulier
(In reply to caulier.gilles from comment #13) > Ok, i will update ExifTool to next version in the bundles when it will be available... Exiftool 12.57 has just been released.
Done. ExifTool updated to 12.57. I rebuild bundles now. Gilles Caulier
The corresponding workaround must also be used with the current version of ExifTool. If we clean up the metadata with "-xmp:all=", then no more XMP metadata from our EXV container will be added to the JXL image. Maik
At the weekend I will prepare files accordingly and test it on the command line level, if it is reproducible then post it in the ExifTool Forum. Maik
(In reply to Maik Qualmann from comment #16) > The corresponding workaround must also be used with the current version of > ExifTool. If we clean up the metadata with "-xmp:all=", then no more XMP > metadata from our EXV container will be added to the JXL image. Ok. Anyway, I just tried the new beta, that seems ok now. Thanks.
From what I understand from this bug report is that exiftool need to be enabled to be able to write metadata to jxl files, right?!? If that's the case, I think that the handling of Digikam of this requirement is not very well done (and I'm happy to open a bug report if needed...) I'm using v8.1 AppImage on Kubuntu. Since a long time, I used to tag jpg files and it is working well **with "Delegate to ExifTool backend all operations to write metadata to files" not enabled** I don't know what is default value of this setting and what is the recommended state but now I have jxl files and I discovered after tagging hundreds of files that the metadata are not stored in the files for jxl files!!! So I think that the current behavior is not good because even if the user explicitly asked that the metadata to be written in the files, that is not done without being informed. I thinks that Digikam should at least inform the user once every working session that metadata are not written because Digikam does not support it and maybe should inform to turn on exiftool option. Or if exiftool is installed fallback using it (maybe also with a message). Tell me if you want me to create a bug report. PS: Is it better to use exiftool as backend? Because the settings UI inform about "write limitations"....
We already have bug reports that we should display an info if, for example, no metadata can be written due to write protection. digiKam has many possibilities to sync the metadata again later. We haven't activated ExifTool by default yet because the backend is still new and a bit slower. But I myself only use the ExifTool backend. But keep in mind that in our ExifTool backend, Exiv2 still plays an important role. But even with ExifTool there are still enough image formats in which we cannot write. Maik