Created attachment 131439 [details] Test image with 32Bit floating point precision per channel GIMP 2.10 now can save XCF images with more than 8Bit Precision per channel. Digikam don't show thumbnail images for this files. I attached a test image to the bug report to reproduce this behavior. I tested this with digikam 6.4.0 (openSUSE Leap 15.1 package) and 7.0.0 (appimage). For example this images are created by the following workflow: Open RAW from digikam in GIMP 2.10 -> Rawtherapee plugin starts -> Finish work in Rawtherapee -> GIMP opens the image -> Finish work in GIMP and save as XCF Sure, it is possible to reduce the precision in GIMP but this is not really a solution. I know, I can even send this bug report to the KDE framework or Imagemagick which are used by digikam to load XCF files. It seems none of them can handle XCF files with higher precision. Btw. Is there a way to save a thumbnail as an additional file for the XCF which is than used by digikam?
DigiKam does not have an XCF loader. We use the KImage plugins. You have to report the problem there. Maik
I am having a similar issue, but also another one that is related to the digikam code. When digikam is scanning the album file structure for new images, and comes across one of these 32 bit floating point XCF/GIMP files, it: 1) Throws up a some diagnostic errors 2) It keeps coming back to the same files it could not read and continues to try and process it. For example: digikam.general: Cannot create thumbnail for ".xcf" digikam.general: Thumbnail is null for ".xcf" digikam.metaengine: Cannot load metadata from file .xcf (Error # 11 : .xcf: The file contains data of an unknown image type digikam.metaengine: Error: source file is not HEIF image. digikam.metaengine: Cannot load metadata using Exiv2 (Error # 11 : xcf: The file contains data of an unknown image type digikam.dimg.qimage: Can not load ...xcf" " using DImg::DImgQImageLoader! And will repeat this with the same file over and over and over again until digikam is killed. So issue 1) is rightly fixed somewhere with kimage plugin. But issue 2) is the bigger problem and is blocking digikam from processing the rest of the new files it needs to scan.
@TahomaSoft Which version of digiKam are you using? DigiKam does not get into an endless loop with such files. Of course, if the Icon View Model requests the thumbnail and it does not exist in the database, an attempt is made to reload it. You should then see a generic icon. If you scroll the view, the messages will come again. The Exiv2 messages have nothing to do with the KImageFormats plugin - Exiv2 does not support this format. Maik
Thanks. I am using 7.1.0. And I respectfully disagree; I captured stderr & stdout from Digikam in a typescript; those errors repeat over, and over, and over. The only way I could get digikam to stop trying to read these files and start dealing with the other 3,000 it needed to process was to move them out of my album.
Maik; Rereading your comment; if I had moved my preview timeline to a different era (month, etc) that didn't include those files, are you saying it would then stop trying and retrying to process them? That might be the case. Thanks!
Created attachment 161110 [details] Preview of XCF 32-bit kimageformats support for 32-bit will be added with https://invent.kde.org/frameworks/kimageformats/-/merge_requests/171
So it's targeted for the next KF5 release ?
(In reply to caulier.gilles from comment #7) > So it's targeted for the next KF5 release ? The version for "KF6" should be merged next week. About KF5.... The patch is complex and I wouldn't be surprised if Albert chooses to merge it after the September release (then in the v5.111).
Thanks all for continuing to work on squashing this bug! ~Erik
(In reply to Mirco Miranda from comment #8) > (In reply to caulier.gilles from comment #7) > > So it's targeted for the next KF5 release ? > > The version for "KF6" should be merged next week. > About KF5.... The patch is complex and I wouldn't be surprised if Albert > chooses to merge it after the September release (then in the v5.111). Same issue with KF6 6.2 and 16 bit XCF files created with Gimp 3.0 RC1
> Same issue with KF6 6.2 and 16 bit XCF files created with Gimp 3.0 RC1 Please attach the image.
Created attachment 169935 [details] XCF issue See two attachment 16 [details] bit float XCF files '2_AVR0037-RT-crop.xcf' is not displayed but strangely, it's displayed after cropping it (see '3_AVR0037-RT-crop-2.xcf')
Created attachment 169937 [details] This file is not displayed
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kimageformats/-/merge_requests/220
Git commit 4f61e3912cbc8e467e1a1e59795f13926c331ba8 by Albert Astals Cid, on behalf of Mirco Miranda. Committed on 07/06/2024 at 11:43. Pushed by aacid into branch 'master'. XCF: Increased maximum property size The problem was caused by a check on the maximum size of properties (specifically it failed on PROP_PARASITES). M +3 -1 src/imageformats/xcf.cpp https://invent.kde.org/frameworks/kimageformats/-/commit/4f61e3912cbc8e467e1a1e59795f13926c331ba8
The patch fixes the issue with attached images.