Bug 456688

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!