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. Images on NAS 2. Open image from thumbnail 3. OBSERVED RESULT Loading of HEIC-images takes very long time EXPECTED RESULT I expect it to open close to instant. Video files .MOV opens instantly for playback. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Which operating system did you use ? Note : HEIF decoding is delegate to libheif (https://github.com/strukturag/libheif) Can you share a sample file to test here ? Gilles Caulier
Well, if you look into libheif's bug reports and search for "slow", you'll find it. The loading time of digiKam does not differ from the implementations of other projects using libheif. We don't currently have an alternative to libheif on Linux. Maik
I was using windows 10, but tried on Linux and found it to be faster. Does DK use multi-thread or single-thread on windows?
DK use multi-thread everywhere. For HEIF loading, it use a separated thread to load image data (so to run the codec) Is the libheif/libde265 codec optimized under Windows ? Codec must use multi-thread to parallelize computations. Perhaps it's not the case under Windows. Again I suspect this problem located in libheif/libde265, not digiKam code. Gilles
In my win 11 installation 12MP HEIC images take up to 15s. I do not believe that this is better than on the Linux systems
@dajomu UPSTREAM bugs from libheif: https://github.com/strukturag/libheif/issues/645 https://github.com/strukturag/libheif/issues/552 https://github.com/strukturag/libheif/issues/472 https://github.com/strukturag/libheif/issues/133 Select right one and continue this discussion on github bugzilla from libheif. Nothing can be done in digiKam code to improve the performances. Gilles Caulier
*** Bug 441648 has been marked as a duplicate of this bug. ***
*** Bug 473356 has been marked as a duplicate of this bug. ***
Hi Maik, Outside the fact that HEIF codec is slow to load image data, libheif team has implemented a progress report usable in client application: https://github.com/strukturag/libheif/issues/161 I think if we patch the digiKam HEIF image loader to handle this information and forward progress value to the GUI, this will at least end-users to know that something is working in the background. Best Gilles
Hi Gilles, if I see it correctly, it is available from version V1.19.7? Maik
yes exactly
Ok, OpenSUSE is currently on V1.19.5. Maik
Dear Maik and Gilles, thank you for your great work - I love digikam! I am using the most recent weekly build (8.6.0 03.03.2025 14:02) on Windows 11. An older 12 mpixel HEIC images still takes 3-4 seconds until the preview is shown (on an 8-core AMD Ryzen, JPEG displays instantly). But new HEIC images made on iOS 18 take 15 to 30 seconds to show as preview. Are there any news in speeding HEIC processing up? I've uploaded three of the images: https://www.jff2k.de/upload/images/2025/20190224_153422.HEIC (takes 3 seconds) https://www.jff2k.de/upload/images/2025/20250802_124011.HEIC (takes 30 seconds if the next one was previewed first) https://www.jff2k.de/upload/images/2025/20250802_133208.HEIC (takes 15 seconds)
Well, I really have an old AMD dual core computer, I know I really need to upgrade. But for the image where you need 30 seconds, it took me maybe a little over 1 second, here under Linux. I'll test it tomorrow under Windows 11, on a current computer. Maik
I have just tested the three images on my 4 year old Win 11 4-core laptop with the 8.6.0 build of 06.02.25. In general, these heic images seem to be more of the faster ones to load. I could not identify a negative experience here. The image preview is more or less instantaneous. Switching fast preview on and off does not make a difference. Comparing with Windows Photos, digikam seems to be a bit faster. 20190224_153422.HEIC is loaded probably in half the time what the other two requires (<1s).
Thank you for your answer. There seems to be a bug in yesterdays release... Took the new Windows build 04.03.2025 06:02 and now it takes only 3 seconds to open on first try, next time in >1 second... Strange. But if I browse through my albums and open several albums with HEIC images, digikam seems to slow down after some minutes, now I again wait up to 30 seconds to open a HEIC image as preview in an album with 140 HEIC images...
I have updated to the last version as well. I cannot confirm your behavior but let Maik check it again. My heic images are still displayed directly. In a folder of ~800 heic, there is a small delay from time to time if I switch from one image to the next one very fast. However, in my fast try I have never got read times over 2 seconds. BG Mik
I've made some more testing. It seems to be related to network access on Windows. When I use a local Album, accessing HEIC images is as fast as Mik says. But when I access the HEIC images on a SMB share (connected as drive S: via Gbit-LAN, 110MB/s throughput), opening a HEIC preview takes 30 seconds or more. With JPEG images there is nearly no speed difference between network access or local access. I've made a short screen recording to show the effect: https://www.jff2k.de/upload/images/2025/20250304_180038.MP4
Confirming. I think that is even slower than before. One of the reasons here is that the image is loaded six times if you are in preview mode and switch from one image to the next one. Two times as a preload and then 4 times again in case of an actual switch to the next image. If the preload is finished the next image can be shown directly. However, it is starting the loading process again. There seems to be no preload for jpg and jpg is only loaded twice. Probably, it would be good to load the file once, keep it in tmp storage (maybe in total 5) and first ask the local storage before requesting it from the original path again. Maybe this is a topic to address together with the face recognition process discussed a month ago. https://drive.google.com/file/d/1UAjBfxe64lxlhIkSNnoMCFppTU7FnokU/view?usp=sharing BG Mik
The image is definitely not loaded 4 times, I just checked this here using the debug output. We are of course using an image cache, the size of which depends on the main memory. How big is your main memory? How many can be kept in memory also depends on the image size, of course. I have 8GB of main memory here and with the reserved image cache from digiKam I can scroll back and forth exactly 9 images (HEIF 4032x3032) without reloading, without digiKam having to reload an image. Maik
In your log you can see that an attempt is made to load a preview image first and then the full image. There are two possibilities for this, either the thumbnails are created first. Or you have set the "fast" preview in the digiKam view settings. This attempts to load a preview image, which for your images is only (512x384). This image is discarded because it is too small for the current view and the full image is loaded. For a better image experience you should generally set the preview view to full image automatically. Maik
I have to correct my previous comment. Sorry for the confusion. I have double checked it with network traffic. 1) jpg preload exists and is working well. Compared to heic (smb) there is no additional action on the image when moving to the next one 2) The images all seem to be loaded only once. Sometimes I see two spikes for heics but I think that there is still only one request. 3) Local heic images behave similar to jpg (whether local or smb). However heic images on SMB have the additional four calls of "digikam.metaengine: Loading metadata with "Exiv2" backend from" which are the steps consuming the time. As there is the SMB address mentioned, I previously thought the image is reloaded again. Thanks. I will change the preview setting. BG Mik
(In reply to Maik Qualmann from comment #20) > The image is definitely not loaded 4 times, I just checked this here using > the debug output. We are of course using an image cache, the size of which > depends on the main memory. How big is your main memory? > > How many can be kept in memory also depends on the image size, of course. > > I have 8GB of main memory here and with the reserved image cache from > digiKam I can scroll back and forth exactly 9 images (HEIF 4032x3032) > without reloading, without digiKam having to reload an image. > > Maik I have 32GB of memory, this should not be the show stopper in this case. What can I do to help resolving the issue?
Additional remark: The four additional calls only happen if the preloading is not finished. Two of the calls seem to be because of my activated fast preview.