Created attachment 150592 [details] This is one of the heic files that DK cannot handle. SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. The attached picture can be imported in tot he database of Digicam 7.7 but no thumbnail can be created nor can DK view or edit this picture. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
The heic file works here on Linux without any problem. I am using the libheif from the system and it is not on git/master level. Please post the debug output from the terminal as described here for macOS: https://www.digikam.org/contribute/ Maik
Created attachment 150593 [details] This is a screenshot of the debug window
Which version is shown for libHEIF in the component information in the Help menu? Maik
Hi Maik, The screenshot come from my Macbook pro, as i'm in contact previously by mail with Sebastian: digikam version 7.8.0 Manifests: ... HEIF Snapshoot 2022-07-04: heif: 64d9ab99ce7ea8876700c034b19bbc8dd773ae0b ... Libraries: ... LibHEIF: 1.12.0 The problem is fully reproducible here. Gilles
There was this problem before on Windows, it will probably be something similar for macOS now. I think a bug report needs to be opened for libheif. https://github.com/strukturag/libheif/issues/71 Maik
Hi Maik, I agree, the bug is not in digiKam code, but in libheif. Sebastian, A new upstream bug in github heif project must be reported with a ref to this downstream bug, and the older one for Windows target given by Maik. https://github.com/strukturag/libheif/issues Thanks in advance Gilles Caulier
Same for me with Windows Version and on Version 7.8 from 29/07/22
The problem is that libheif has not released a new version for a year. Since we no longer have libheif within digiKam and most distributions rely on the latest stable version, this problem exists. There is already a bug report at libheif with the wish to release a new version. Maik
Maik, is this fixed with the new version of Digicam released today? Sebastian
No, it is not fixed on Windows, the problem is still there. Maik
Even though we are talking about macOS here, the problem also exists on Windows. The image can only be loaded under Linux. The problem should be reported to libheif with the sample image. Maik
Maik, For testing, i cleaned my sqlite database and rescan the whole collection with my HEIF files (Iphone 7). For each item, it crash. Kunbutu 22.04 is used here, with libheif 1.12.0 (offcial package). Thread 4 "Digikam::ScanCo" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffc4e4a640 (LWP 799234)] __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736496707136) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736496707136) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140736496707136) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140736496707136, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007ffff45e8476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007ffff45ce7f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007ffff45ce71b in __assert_fail_base (fmt=0x7ffff4783150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fffefdea89c "success", file=0x7fffefde569a "box.cc", line=1114, function=<optimized out>) at ./assert/assert.c:92 #6 0x00007ffff45dfe96 in __GI___assert_fail (assertion=0x7fffefdea89c "success", file=0x7fffefde569a "box.cc", line=1114, function=0x7fffefdea4a8 "heif::Error heif::Box_iloc::read_data(const heif::Box_iloc::Item&, std::shared_ptr<heif::StreamReader>, const std::shared_ptr<heif::Box_idat>&, std::vector<unsigned char>*) const") at ./assert/assert.c:101 #7 0x00007fffefddfa8a in () at /lib/x86_64-linux-gnu/libheif.so.1 #8 0x00007fffefdb1b57 in () at /lib/x86_64-linux-gnu/libheif.so.1 #9 0x00007fffefdc206f in () at /lib/x86_64-linux-gnu/libheif.so.1 #10 0x00007fffefdb5860 in heif_context_read_from_reader () at /lib/x86_64-linux-gnu/libheif.so.1 #11 0x00007fffd0035ecd in Digikam::DImgHEIFLoader::load(QString const&, Digikam::DImgLoaderObserver*) (this=0x7fffb80beef0, filePath=..., observer=0x0) at /home/gilles/Devel/8.x/core/dplugins/dimg/heif/dimgheifloader_load.cpp:146 #12 0x00007ffff63b3f79 in Digikam::DImg::load(QString const&, int, Digikam::DImgLoaderObserver*, Digikam::DRawDecoding const&) (this=0x7fffb8112c28, filePath=..., loadFlagsInt=1, observer=0x0, rawDecodingSettings=...) at /home/gilles/Devel/8.x/core/libs/dimg/dimg_fileio.cpp:132 #13 0x00007ffff63b3912 in Digikam::DImg::loadItemInfo(QString const&, bool, bool, bool, bool) (this=0x7fffb8112c28, filePath=..., loadMetadata=false, loadICCData=false, loadUniqueHash=false, loadImageHistory=false) at /home/gilles/Devel/8.x/core/libs/dimg/dimg_fileio.cpp:55 #14 0x00007ffff7343ea0 in Digikam::ItemScanner::loadFromDisk() (this=0x7fffc4e476a0) at /home/gilles/Devel/8.x/core/libs/database/item/scanner/itemscanner.cpp:135 #15 0x00007ffff734af9f in Digikam::ItemScanner::newFile(int) (this=0x7fffc4e476a0, albumId=1) --Type <RET> for more, q to quit, c to continue without paging--q Quit (gdb) y If i use 7.8.0 appimage, there is no crash (we use libheif from git/master, so 1.12.0++) Gilles
Git commit 1c1092438da32def814cae76abb2702fcaa96e63 by Maik Qualmann. Committed on 04/09/2022 at 07:54. Pushed by mqualmann into branch 'qt5-maintenance'. define int64_t M +4 -0 core/dplugins/dimg/heif/dimgheifloader_load.cpp https://invent.kde.org/graphics/digikam/commit/1c1092438da32def814cae76abb2702fcaa96e63
libheif 1.12: bool success = istr->seek(extent.offset + item.base_offset); assert(success); This calls the new QIODevice seek function, which returns false. Either the requested position is out of range or it is related to the undefined int64_t variable. Maik
Git commit 082c4c54c9a57cd3750fcd2f11f8344b19dd4f02 by Maik Qualmann. Committed on 04/09/2022 at 09:44. Pushed by mqualmann into branch 'qt5-maintenance'. fix return from QIODevice::seek() function The libheif inverted again in bitstream.h. Related: bug 458690 M +2 -1 core/dplugins/dimg/heif/dimgheifloader_load.cpp https://invent.kde.org/graphics/digikam/commit/082c4c54c9a57cd3750fcd2f11f8344b19dd4f02
(In reply to Maik Qualmann from comment #15) > Git commit 082c4c54c9a57cd3750fcd2f11f8344b19dd4f02 by Maik Qualmann. > Committed on 04/09/2022 at 09:44. > Pushed by mqualmann into branch 'qt5-maintenance'. > > fix return from QIODevice::seek() function > The libheif inverted again in bitstream.h. > Related: bug 458690 > > M +2 -1 core/dplugins/dimg/heif/dimgheifloader_load.cpp > > https://invent.kde.org/graphics/digikam/commit/ > 082c4c54c9a57cd3750fcd2f11f8344b19dd4f02 May I kindly ask for an update? Is the problem meanwhile solved or a solution visible at the horizon? BR, Sebastian
From a digiKam view, no... All future improvements must come from libheif and libde265 codec libraries used to decode HEVC containers. Typically, the way to use GPU devices to speed-up computations. Link where to report as UPSTREAM the whishes : libheif : https://github.com/strukturag/libheif/issues libde265 : https://github.com/strukturag/libde265/issues Gilles
Some issues reported : https://github.com/strukturag/libheif/issues/645 https://github.com/strukturag/libheif/issues/552 https://github.com/strukturag/libheif/issues/472 Gilles
(In reply to caulier.gilles from comment #18) > Some issues reported : > > https://github.com/strukturag/libheif/issues/645 > > https://github.com/strukturag/libheif/issues/552 > > https://github.com/strukturag/libheif/issues/472 > > Gilles Dear Gilles, Did you check if the problem still exists with DigiKam 8.0? Sebastian
Hi, Not at all, but we update plenty of heif dependencies in the bundles. So there is a chance to see this problem fixed definitively. Best Gilles Caulier
@Sebastian digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
I‘m hesitating to update to version 8. In case the problem is still existing in version 8 it will be difficult for me to downgrade.
No problem to preview or to open the sample HEIC image from this entry under digiKam 8.1.0 for macOS. I close this file now. https://i.imgur.com/bWhuVXt.png https://i.imgur.com/eATvGF9.png
Thank you for testing and your confirmation!