Created attachment 146651 [details] A jpg with Exifdata readable with exiftools, but not usabel in Digikam SUMMARY On some of my JPEG Files produced by scanning with Silverfast there are no Exif Data (tab Exif) in the Metadata Information tab, although in the same Metadata tab in information is available in the Exiftool tab. On these JPGs also the tool to set date and time does not work (as no data can be written into the metadata) SOFTWARE/OS VERSIONS Windows: Win10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Which version of digiKam did you use ?
The Exiv2 backend has a problem with the ICC profile in the image: digikam.metaengine: Cannot load metadata from file with Exiv2 backend: /daten/Bilder/Test/AgfaXRG16.jpg (Error # 53 : "Not a valid ICC Profile" Maik
(In reply to caulier.gilles from comment #1) > Which version of digiKam did you use ? actually 7.5.0, but the problem also occured in the previous version 7.4.0
(In reply to Maik Qualmann from comment #2) > The Exiv2 backend has a problem with the ICC profile in the image: > > digikam.metaengine: Cannot load metadata from file with Exiv2 backend: > /daten/Bilder/Test/AgfaXRG16.jpg (Error # 53 : "Not a valid ICC Profile" > > Maik I See. Loooking at the different ICC Profiles it seem, that all ICC Profiles written as XML and not as Binary gives this problem. Exiftool also says "Warning: Bad length ICC_Profile" The Problem is using wsRGB (a Windows color profile) in Silverfast, as this writes the wsRGB as XML. Changing this to normal srgb Profile does not chang colors visually and Exiv2 Backend then can read it. So to not scan each picture again: exiftool.exe "-icc_profile<=srgb.icc" AgfaXRG16.jpg solves the Problem. (It is now only some work finding all these files and changing them; but usally I am usinf adobe or srgb, so it shouldn't be to much files).
I do have a similar problem, but it seems to be independant from ICC (as far as I can tell). Just after upgrading to digikam 7.6.0 running within current tumbleweed linux now for many (not all!) newly added jpegs from my Sony A77 camera seem to have missing exif information. But exiftool can display their exif without any error message. Around 50% of all new jpegs are affected. To me this is a showstopper in using digikam. But when trying to load those jpegs using showfoto, I encounter ICC errors like digikam.metaengine: Cannot load metadata from file with Exiv2 backend: /run/media/sdcard/disk/DCIM/100MSDCF/DSC07881.JPG (Error # 59 : "corrupted image metadata" The standalone exiftool can't see ICC at all (within working jpegs): exiftool -icc_profile -b -w icc dsc07875.jpg --> 0 output files created But why are only some of my new jpegs affected? I'd guess that some binary part within exif is triggering this problem. I don't believe that my camera will include buggy ICC profiles only "sometimes". Sadly I couldn't upload a sample jpeg due to the 4MB limit. Regards, Michael
Hi, I also use a Sony A77 camera here, and no problem to show Exif info from Exiv2. Use cloud web service to share your JPEG files and past the url here. Best Gilles Caulier
Created attachment 147759 [details] missing exif within digikam Lucky me - this foto is smaller than 4MB AND is failing to display exif within digikam
I could uplaod a jpeg with my problem being small enough. Regards, Michael
This problem will only be fixed in > Exiv2-0.27.5. See Bug 446403 and Exiv2 bug report: https://github.com/Exiv2/exiv2/issues/2001 Maik
In our pre-release digiKam-7.7.0 AppImage from here: https://files.kde.org/digikam/ Let's use a git/master version of Exiv2 and it will show all Exif metadata. Not with the version from openSUSE Tumbleweed. Maik
(In reply to Maik Qualmann from comment #10) > In our pre-release digiKam-7.7.0 AppImage from here: > > https://files.kde.org/digikam/ > > Let's use a git/master version of Exiv2 and it will show all Exif metadata. > Not with the version from openSUSE Tumbleweed. > > Maik Thanks for your hint. I fetched the current pre-release exiv 1.0.0.9 from git (both source code and precompiled version). But I couldn't "convince" digikam 7.6.0 to use the updated library (neither the precompiled nor my compiled version). After copying the new library into /lib64, I tried to "fool" digikam by linking the new version ln -s libexiv2.so.1.0.0.9 libexiv2.so.27 Sadly digikam fails to start with undefined symbol. Then I tried your prerelease 7.7.0 - it resolves my issue. But for my working digikam workflow I'd prefer to stay with the stable 7.6.0. Do you have any suggestion which exiv2 version would work with digikam 7.6.0? Maybe I've missed one step when I replaced the current libexiv2.so.0.27.5? Regards (and thanks for your fast solution!), Michael
Sorry - but I've forgotten to include the error message from digikam when trying to use the updated exiv2 library: digikam: symbol lookup error: /lib64/libdigikamcore.so.7.6.0: undefined symbol: _ZTIN5Exiv28AnyErrorE Regards, Michael
Do not recompile and install the Exiv2 git/main branch from github. Use branch 0.27-maintenance instead : https://github.com/Exiv2/exiv2/tree/0.27-maintenance Gilles Caulier
Thank you very much - the library from the maintenance branch works within digikam 7.6.0 and resolves my exif issue. That was ultrafast support!! Regards, Michael
But there is still a problem - not within digikam, but within kodi. If I take a portrait photo with my Sony A77 which is automatically rotated by digikam 7.6.0 it can't be displayed by current kodi 19.4 running on raspberry. If trying to display such pictures within kodi no exif information is shown and the jpeg can't be rendered. I don't have problems with portrait photos taken e.g. last year (being rotated by some older releases of digikam). The "problematic" new portrait jpegs are nevertheless rendered perfectly by digikam. And even (to my surprise) by kodi 19.4. under tumbleweed linux. Only kodi 19.4 (osmc) running on a raspberry pi3 fails to render new portraits. Conclusion: Something seems to be "different" within digikam for portrait photos as compared with older digikam versions preventing "some" kodi installations to render them (because probably exif data is not accessible). Since this problem only affects my "new" portrait photos rotated by 7.6.0 digikam it might be an issue within digikam, maybe again exiv2? See my appended portrait photo. Regards, Michael
Created attachment 147810 [details] portrait photo unable to render under kodi
When I validate the file with ExifTool, there are warnings. The first of which could be the cause. I'll examine it further tonight. Warning = [minor] Error reading PreviewImage from file Warning = [minor] IFD0 tag 0x0100 ImageWidth is not allowed in JPEG Warning = [minor] IFD0 tag 0x0101 ImageHeight is not allowed in JPEG Maik
Thank you for looking into my issue. I've done some testing myself with freshly taken jpegs using the same (low) resolution. If I rotate a new portrait photo using jhead it is displayed properly within kodi on a raspberry. I've seen one major difference between exif data from jhead vs. digikam use. The jhead version does NOT adjust the tags 'Exif Image Width' and 'Exif Image Height' despite fixing the orientation. The other dimensions were swapped by jhead as to be expected when rotating the image. I even tried to drop any metainfo (even all previews; exiftool -All= ...) from my broken portrait photo (the one uploaded here). But even then it will not be displayed by kodi on a raspberry. Hope that my additional information is helpful, Michael
I've looked again into my problem. I tried to fix all warnings reported by exiftool - without success. Kodi under linux reports these additional two errors IptcParse: Unrecognised IPTC tag: 0x41 IptcParse: Unrecognised IPTC tag: 0x46 Deleting all IPTC tags using exiftool fixed those error messages, but the jpg is still not visible within kodi under osmc on a raspberry. Thus I assumed that maybe the picture dimension triggers a memory problem within raspberry. But I can prove the contrary. I've converted the buggy jpg into tiff and back again into jpeg using imagemagick's convert. Now all EXIF metadata are really gone, and the jpg is visible within kodi on my raspberry. If I finally copy all exif information back using exiftool that jpg works fine within kodi on raspberry including exif metadata. I don't understand why my buggy jpg fails on kodi@raspberry (osmc based upon kodi 19.4) while working fine on kodi@linux (also kodi 19.4) and digikam 7.6.0. But I'm quite sure that my problem is triggered by digikam 7.6.0 if it does an automatic rotation. These seem to be the differences between the fixed and the buggy jpgs as reported by exiftool 12.39: fixed jpg: Validate : 1 Warning (minor) Warning : [minor] Non-standard IFD0 tag 0x000b ProcessingSoftware buggy jpg (the one uploaded): Validate : 4 Warnings (all minor) Warning : [minor] Non-standard IFD0 tag 0x000b ProcessingSoftware Warning : [minor] Fixed incorrect URI for xmlns:MicrosoftPhoto Warning : [minor] IFD0 tag 0x0100 ImageWidth is not allowed in JPEG Warning : [minor] IFD0 tag 0x0101 ImageHeight is not allowed in JPEG Additionall the preview images and the makernotes are dropped within the fixed jpg. Hope that you might discover the change within digikam. Regards, Michael
Sorry, me again. But now I guess that my problem is related with Sony's previewimage IF the jpeg is autorotated either by jhead or digikam. Even if the jpg has been rotated by digikam 7.2.0 there is something wrong with the preview. exiftool -b -previewimage can never extract the previewimage if being rotated by digikam or jhead. If the jpeg is directly from the camera (i.e. not rotated by a tool) exiftool can extract the preview. Starting with digikam 7.6.0 thus something is broken even worse IF the jpg is autorotated. Sadly I'm unable to drop the previewimage (exiftool -PreviewImage= ... fails). Only workaround for me seems to be by converting buggy jpg into tiff and back into jpg. Thus I will disable autorotate from now on within digikam... Regards, Michael
"Sony's previewimage IF the jpeg is autorotated either by jhead or digikam" --> 1/ digiKam do not touch this metadata. Preview is stored by digiKam in IPTC or XMP. --> 2/ JPEG file are not changed about preview. Only all other writable format, as PNG, TIFF, JPEG2000, HEIF, etc, and only in IPTC or XMP. So this metadata corruption problem is not relevant of digiKam. Note : Exiv2 has also a problem with the JPEG section largest than 64Kb. Typically Exif, Iptc, or XMP are stored in on JPEG section, and large section are dispatched on more than one entry in JPEG. EXIV2 only deal with one section, not more. There are a file in Exiv2 bugzilla about this problem. Gilles Caulier
I can only report what I have noticed after upgrading towards digikam 7.6.0 (and even some earlier releases) - there is something mysterious if jpegs are autorotated by digikam during upload. But I do not need to enable autorotation within digikam any more (I did that some years ago when many viewers were unable to repect EXIF's orientation) - anyhow it's better not to modify jpegs directly during upload into digikam. Thus from my perspective I have a solution for this problem. Thanks for your patience, Michael
Git commit 802d92a3ec46e2ca1b60aa0e2e9bdb8516d4f041 by Maik Qualmann. Committed on 24/04/2022 at 14:58. Pushed by mqualmann into branch 'master'. add read Exiv2 warnings and errors to then read the metadata with ExifTool Related: bug 452567, bug 432265, bug 446363, bug 449637 M +6 -0 core/libs/metadataengine/engine/metaengine_fileio.cpp M +8 -0 core/libs/metadataengine/engine/metaengine_p.cpp M +1 -0 core/libs/metadataengine/engine/metaengine_p.h https://invent.kde.org/graphics/digikam/commit/802d92a3ec46e2ca1b60aa0e2e9bdb8516d4f041
Comment on attachment 146651 [details] A jpg with Exifdata readable with exiftools, but not usabel in Digikam I also experience this. Both on Windows 10 DigiKam 7.6.0 & Kubuntu 22.04 DigiKam 7.5.0. (example using [meta:File.File.Image.FileModifyDate] to rename an image.) I have several pictures that have data visible only in the ExifTools tab. However I cannot use this data to rename files. However the above renaming issue still exists even when the image does have other metadata already writen, and viewable with the other available metadata tabs.
We already know the image. It has an invalid ICC profile for Exiv2 that throws an exception. Here in the development version of digiKam-8.0.0 I still have Exif metadata in the tab. Since we recognize the exception, we then read the metadata with ExifTool and then pass it back to Exiv2 as a container. Maik
The bug (within libexiv2) is back within tumbleweed / digikam 7.6.0 as installed on 2022-06-04. I did re-compile the current exiv2-0.27-maintenance and exchanged /lib64/libexiv2.so.0.27.5 which resolved that issue. Originally tumbleweed did provide 0.27.5 (working fine till some days ago), but probably NOT its current maintenance release. Regards, Michael
Sadly this bug again re-appeared on Linux tumbleweed with current updates (from 2022-09-12): digikam 7.8.0 libexiv2-0.27.5 I could solve the problem for myself in replacing /lib64/libexiv2.so.0.27.5. Sadly, some automagic security routine within tumbleweed will undo my changes within /lib64 (don't know how to avoid that). Thus I have to check for the correct library after each reboot:-( From my understanding the new digikam 7.7.0 should already contain a workaround for buggy libexiv2, maybe this workaround was not forwarded into 7.8.0? Anyhow, the root cause for the problem is that the tumbleweed maintainer from libexiv2 does not use the maintenance version from libeviv2. Regards, Michael
All bundles of digiKam are build with the rolling release of Exiv2 based on maintenance branch of the library. So the 7.8.0 Windows/MacOS/AppImage version use a recent code of Exiv2 including the famous fix. The solution for you is to use the AppImage Linux bundle on your system, not the official package. Best Gilles Caulier
Reading the metadata with ExifTool if Exiv2 reports a warning or error from Comment 23 will only be available in digiKam-8.0.0. Maik
@JH digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
@JH 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
Created attachment 160620 [details] This image is the original image generated by Stable Diffusion, UserComment is displayed as garbled in Exif and normal in ExifTool. And Digikam gets stuck after displaying the metadata! The images generated by stable diffusion come with a message that is prompted at the time of generation, which is stored in the image's metadata. When I use it to view the information about the images generated by stable diffusion, the UserComment under Exit is garbled, while in ExitTool it is displayed normally, and the software becomes very laggy and can only be recovered by restarting. I set different options but none of them work. I hope you guys can fix this bug or tell me how to set it up. More and more people are using Stable diffusion and many need to manage the large number of images generated, which I think is important.
@Rex Lee, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer 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
To Rex from Comment 32, With your sample image attached, digiKam 8.2.0 for Windows (including Exiv2 0.28.1) show a very limited of Exif metadata, similar of ExifTool (this one show more info from file properties, not metadata. Exif from Exiv2: https://i.imgur.com/IgG1GFV.png ExifTool view: https://i.imgur.com/JcXG7mX.png So for me the Exiv2 behavior is normal. Gilles Caulier
Hi Gilles, I fixed the issue with the user comment by supporting UTF16. But the condition is Qt >= 5.15. Maik
Hi Maik, So the condition is fine i think as Windows build switch to Qt6 definitively... Gilles