SUMMARY Digikam cannot save images in heic/heif format. STEPS TO REPRODUCE 1. Try to save as, or export an open image in Digikam in the heic/heif format. OBSERVED RESULT Error: "Failed to save [input file] to [output path]." EXPECTED RESULT File would save normally like it does from any other format. SOFTWARE/OS VERSIONS Windows: 10 x64, v. 1909. macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: Digikam 7.0.0-beta 1 x64 (Dec 27 build) ADDITIONAL INFORMATION I have tested on my Win10 machine, I can open, and save, heic/heif files normally in other applications. There are two applications on my machine that can OPEN heic/heif files normally, but throw an error when you try to save in heic/heif format: 1. GIMP 2.10.14 2. Digikam 7.0.0-beta 1
Under Linux, no problem. I used a JPEG file and exported to HEIC with image editor "save as..". Which is the kind of input image format to convert in HEIF ? Can you post the DebugView M$ tool text trace while digiKam is running and try to generate the HEIF file ? https://www.digikam.org/contribute/ Gilles Caulier
yes fully reproducible under Windows: [3844] digikam.geoiface: ---- [3844] digikam.metaengine: Exiv2 ( 2 ) : Directory Minolta, entry 0x0088: Data area exceeds data buffer, ignoring it. [3844] [3844] digikam.general: startSavingAs called [3844] digikam.general: Writing file to QUrl("file:///C:/Users/gilles/Pictures/METADATA/digiKam/photo-000048.heic") [3844] digikam.widgets: Trying to discover format based on filename ' "photo-000048.heic" ', fallback = 0 [3844] digikam.widgets: Discovered format: 6 [3844] digikam.widgets: Format selected: "photo-000048.heic" [3844] digikam.widgets: Trying to discover format based on filename ' "photo-000048.heic" ', fallback = 0 [3844] digikam.widgets: Discovered format: 6 [3844] digikam.general: Trying to find a saving format from targetUrl = QUrl("file:///C:/Users/gilles/Pictures/METADATA/digiKam/photo-000048.heic") [3844] digikam.general: Qt Offered types: "*.bmp *.bw *.cur *.icns *.ico *.pbm *.pcx *.pgm *.pic *.png *.ppm *.rgb *.rgba *.sgi *.tga *.wbmp *.webp *.xbm *.xpm *.tiff *.tif *.jpg *.jpeg *.jpe *.jp2 *.j2k *.jpx *.pgx *.pgf *.heic *.heif" [3844] digikam.general: Writable formats: ("bmp", "bw", "cur", "icns", "ico", "pbm", "pcx", "pgm", "pic", "png", "ppm", "rgb", "rgba", "sgi", "tga", "wbmp", "webp", "xbm", "xpm", "tiff", "tif", "jpg", "jpeg", "jpe", "jp2", "j2k", "jpx", "pgx", "pgf", "heic", "heif") [3844] digikam.general: Possible format from local file: "heic" [3844] digikam.general: Using format from target url "heic" [3844] digikam.geoiface: ---- [3844] digikam.general: Saving to : "C:/Users/gilles/Pictures/METADATA/digiKam/EditorWindow-jYaqPR.digikamtempfile.heic" ( "heic" ) [3844] digikam.general: Saving file "C:/Users/gilles/Pictures/METADATA/digiKam/EditorWindow-jYaqPR.digikamtempfile.heic" at -1 [3844] digikam.dimg: Prepare Metadata to save for "C:/Users/gilles/Pictures/METADATA/digiKam/photo-000048.heic" [3844] digikam.metaengine: JPEG image preview size: ( 1280 x 852 ) pixels - 65683 bytes [3844] digikam.dimg: Saving to "C:/Users/gilles/Pictures/METADATA/digiKam/EditorWindow-jYaqPR.digikamtempfile.heic" with format: "heic" [3844] Check HEVC encoder for 16 bits encoding... [3844] Check HEVC encoder for 14 bits encoding... [3844] Check HEVC encoder for 12 bits encoding... [3844] HEVC encoder max bits depth: 12 [3844] HEVC encoder setup... [3844] HEIF set color profile... [3844] Stored HEIF color profile size: 6924 [3844] HEIF setup data plane... [3844] HEIF data container: 0x29b35bbe040 [3844] HEIF bytes per line: 18096 [3844] HEIF output bytes per color: 6 [3844] HEIF 16 to 8 bits coeff. : 4 [3844] HEIF 8 to 16 bits coeff. : 4 [3844] HEIF master image encoding... [3844] Error while processing HEIF image: Encoder plugin generated an error: Unsupported bit depth: Bit depth not supported by x265 [3844] digikam.general: error saving image ' C:/Users/gilles/Pictures/METADATA/digiKam/EditorWindow-jYaqPR.digikamtempfile.heic [3844] digikam.general: "C:/Users/gilles/Pictures/METADATA/digiKam/EditorWindow-jYaqPR.digikamtempfile.heic" false true Gilles Caulier
I have the same error message here on Linux too. Maik
The AppImage works. In my native digiKam version is libx265-3.2.1 installed from a non-free repository. Maik
The error come from this loop : https://invent.kde.org/kde/digikam/blob/master/core/dplugins/dimg/heif/dimgheifloader_save.cpp#L69 ... where the max bit depth available to encode to x265 try to be detected. Mostly deployed, the 8 bits color depth is supported. By compilation option, a 10 or 12 bits color depth can be enabled. This must generate extra .so using bit depth in file name. So, loop report an higher bit depth than 8 but fail to found the relevant .so or .dll on the system. But must starnge thing is the Windows version: MXE compile a 8 bits version and no more, but the loop return a 12 bits color depth supported. Why ??? Probably a bug in x265 API. There is an alternative to this loop, using this API : https://github.com/videolan/x265/blob/master/source/x265.h#L1908 ...which must return the X265 max depth available. Gilles
This value (x265_max_bit_depth) returns 8 bits for me, instead of the loop - then saving heic works. Maik
Git commit ca0034a9fde054ec65fa144607fbe38083b6c8ad by Gilles Caulier. Committed on 31/12/2019 at 15:52. Pushed by cgilles into branch 'master'. use max bit depth returned by x265 API instead to loop over possible value. FIXED-IN: 7.0.0 M +6 -11 core/dplugins/dimg/heif/dimgheifloader_save.cpp https://invent.kde.org/kde/digikam/commit/ca0034a9fde054ec65fa144607fbe38083b6c8ad
Daily bundle are published in this repository: https://files.kde.org/digikam/ digiKam and Gimp must certainly use the same HEIF codec : libx265. In digiKam the error come from this libray that we use to check the max color depth in a specific way which return a wrong value, certainly due a bug in this library. For Gimp i don't know how the export plugin deal with the library, but there is a chance to see a similar dysfunction. Gilles Caulier
Hi, the issue still repros on today's build of the 7.0 beta. I tried to save several different images in heic format, same error on all. Tried reducing 16-bit source images in .tif format to 8-bit, then save, same result.
The build for Win64 cannot contain the change yet, wait for tomorrow. Maik
Unfortunately does not work under Windows, x265 returns a negative value as bit depth. Maik
Maik, How this is possible : https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/x265.h?at=default#lines-1965 8 (default), or 10... Gilles
Maik, The code to tune max bit depth at configuration time is this one : https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/common/version.cpp#lines-98 Something like X265_DEPTH must be defined somewhere. Gilles
Maik, This is the cmake rule for bit depth : https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/CMakeLists.txt#lines-369 As you can see the top level cmake option is HIGH_BIT_DEPTH. If this option is not turned on, well 8 bits is used as default. As look well the comment in cmake file about 64 bits only architecture. It's very interresting. Again, i don't understand how x265 can return a negative value for max bit depth... Gilles
Maik, Which negative value do you see exactly on debugview about max bit depth ? -1, -2, -3 ? Gilles
MAik, Look like how MXE build libx265: https://github.com/mxe/mxe/blob/master/src/x265.mk#L19 There is plenty of versions, with different bit depth and also HDR support. Incredible... So, libx265_main12.a, libx265_main10.a, libx265.a are typically generated Gilles
It was a very large negative number, I will start the VM again right away. It also looks to me as if the variable is not being initialized. If I understand the doc correctly it happens at compile time. Maik
[5332] Check HEVC encoder for -2071058945 bits encoding... [5332] Cannot get max supported HEVC encoder bits depth! Maik
Git commit 9c13bc8a534a99772d63122115c75e76302c3645 by Gilles Caulier. Committed on 01/01/2020 at 15:56. Pushed by cgilles into branch 'master'. fail back to default 8 bits encoding if max byte depth is not valid M +12 -2 core/dplugins/dimg/heif/dimgheifloader_save.cpp https://invent.kde.org/kde/digikam/commit/9c13bc8a534a99772d63122115c75e76302c3645
Windows bundles will be updated in one hour at usual place : https://files.kde.org/digikam/ Gilles Caulier
Thank you for the discussion and work on this bug! Just ran the latest bits, same steps as before. Result: * The heic image does save to the file system without an error, in spite of the next item. * The Digikam editor freezes saying it is "Saving" and showing a 69% progress bar. It never leaves this state, and I have to click close on the editor which then crashes Digikam too. I have two follow-up questions for you guys doing dev work on this item: 1. Should you (or I??) notify whoever does the dev work on this library that contains the heic/heif functionality about what is going on? So that the issue is ultimately getting fixed at the source, versus as a workaround in Digikam? Sorry if I'm misunderstanding the discussion below, just raising the question to make sure we are letting folks know if needed. 2. Same question with regard to Gimp. Should we be filing an issue with the Gimp devs since Gimp essentially has identical behavior on the production bits 2.10.14? Thanks, Tim
Tim, My failback to 8 bits color depth under Windows 10 work as expected here. I just tested with the Windows installer generated today. I just created an HEIC from a JPEG file : https://i.imgur.com/1TuUbku.png The DebugView trace : [3020] digikam.general: >>>>>>>>>face rect before: 1659 830 678 680 [3020] digikam.general: startSavingAs called [3020] digikam.general: Writing file to QUrl("file:///C:/Users/gilles/Pictures/METADATA/pict0149 with photoshop metada.heic") [3020] digikam.widgets: Trying to discover format based on filename ' "pict0149 with photoshop metada.heic" ', fallback = 0 [3020] digikam.widgets: Discovered format: 6 [3020] digikam.widgets: Format selected: "pict0149 with photoshop metada.heic" [3020] digikam.widgets: Trying to discover format based on filename ' "pict0149 with photoshop metada.heic" ', fallback = 0 [3020] digikam.widgets: Discovered format: 6 [3020] digikam.general: Trying to find a saving format from targetUrl = QUrl("file:///C:/Users/gilles/Pictures/METADATA/pict0149 with photoshop metada.heic") [3020] digikam.general: Qt Offered types: "*.bmp *.bw *.cur *.icns *.ico *.pbm *.pcx *.pgm *.pic *.png *.ppm *.rgb *.rgba *.sgi *.tga *.wbmp *.webp *.xbm *.xpm *.tiff *.tif *.jpg *.jpeg *.jpe *.jp2 *.j2k *.jpx *.pgx *.pgf *.heic *.heif" [3020] digikam.general: Writable formats: ("bmp", "bw", "cur", "icns", "ico", "pbm", "pcx", "pgm", "pic", "png", "ppm", "rgb", "rgba", "sgi", "tga", "wbmp", "webp", "xbm", "xpm", "tiff", "tif", "jpg", "jpeg", "jpe", "jp2", "j2k", "jpx", "pgx", "pgf", "heic", "heif") [3020] digikam.general: Possible format from local file: "heic" [3020] digikam.general: Using format from target url "heic" [3020] digikam.geoiface: ---- [3020] digikam.general: Saving to : "C:/Users/gilles/Pictures/METADATA/EditorWindow-rTewTZ.digikamtempfile.heic" ( "heic" ) [3020] digikam.general: Saving file "C:/Users/gilles/Pictures/METADATA/EditorWindow-rTewTZ.digikamtempfile.heic" at -1 [3020] digikam.dimg: Prepare Metadata to save for "C:/Users/gilles/Pictures/METADATA/pict0149 with photoshop metada.heic" [3020] digikam.metaengine: JPEG image preview size: ( 1280 x 852 ) pixels - 104767 bytes [3020] digikam.dimg: Saving to "C:/Users/gilles/Pictures/METADATA/EditorWindow-rTewTZ.digikamtempfile.heic" with format: "heic" [3020] HEVC encoder max bit depth: -2076301825 [3020] HEVC encoder max bits depth: 8 (default failback value) [3020] HEVC encoder setup... [3020] HEIF set color profile... [3020] Stored HEIF color profile size: 6924 [3020] HEIF setup data plane... [3020] HEIF data container: 0x2229f070040 [3020] HEIF bytes per line: 9056 [3020] HEIF output bytes per color: 3 [3020] HEIF 16 to 8 bits coeff. : 8 [3020] HEIF 8 to 16 bits coeff. : 0 [3020] HEIF master image encoding... [3020] HEIF preview storage in thumbnail chunk... [3020] HEIF metadata storage... [3020] Stored HEIF Exif data size: 4148 [3020] Stored HEIF Iptc data size: 105334 [3020] Stored HEIF Xmp data size: 146931 [3020] HEIF flush to file... No crash, no dysfunction, target HEIC image can be open as well... As you can see, with this line : [3020] HEVC encoder max bit depth: -2076301825 The max bit depth reported by libx265 is a mess, but forcing to use the default 8 bits color depth work like a charm... Note: i tried to export as HEIC in lossless mode or in lossy mode, and in both i generate a valid HEIC file. Please try again with this installer version: https://files.kde.org/digikam/digiKam-7.0.0-beta1-20200102T060110-Win64.exe.mirrorlist Note2: I agree that something wrong as not expected with libx265 library under Windows about the max bit depth supported. Reporting this problem to libx265 project can be a good idea. About Gimp, i don't know how it work to export HEIC files. So, if you can reproduce the problem on your windows 10 with the pointed DK windows installer, please share on the cloud the original image that you try to export. Gilles Caulier
Tim, Windows bundles will be updated this morning at usual place : https://files.kde.org/digikam/ Please let's me hear if the problem remain. Thanks in advance... Gilles Caulier
On today's build, I get the same behavior as yesterday. No error message, and file does save as .heic format. But Digikam editor is frozen in mode saying "Saving....74%". And I am unable to close the editor or do anything else, I have to terminate the program. Another possible helpful data point: I noticed on Win 10 x64, latest 1909 build, they've upgraded the build-in MS Paint program to save in .heic format. I tested, this works normally and saves .heic files without an issue. I believe there is still an issue within Digikam/Gimp, or the libraries they use, in saving .heic files. Thanks, Tim
How long did you wait to save? It is significantly slower under Windows until the encoder is finished, but it will be finished. Another thing, Gimp works here on a Windows 7 machine even when saving a HEIC file. Maik Am Freitag, 3. Januar 2020, 22:14:10 CET schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=415719 > > --- Comment #24 from tlteebken-reg@outlook.com --- > On today's build, I get the same behavior as yesterday. No error message, > and file does save as .heic format. But Digikam editor is frozen in mode > saying "Saving....74%". And I am unable to close the editor or do > anything else, I have to terminate the program. > > Another possible helpful data point: I noticed on Win 10 x64, latest 1909 > build, they've upgraded the build-in MS Paint program to save in .heic > format. I tested, this works normally and saves .heic files without an > issue. > > I believe there is still an issue within Digikam/Gimp, or the libraries they > use, in saving .heic files. > > Thanks, > > Tim
I waited 5 minutes.
Can you share the original image that you try to export to HEIC. I would to try to reproduce the dysfunction here. Gilles Caulier
I can't (it was a CR3 file that I had just 'imported' using the RAW editor, the source file is over 35MB). Possibly helpful additional details to know: * Tested with several other CR3 RAW files, same behavior on all. * Tested with the open Adobe DNG files, the saving is VERY slow, but if you wait long enough, it does finally save without error and works. Save time was 30-45 seconds. * Tested with non-raw ordinary JPG/TIF files, works great and saves instantaneously, no problem! So it seems we are almost there. Something funky going on with the large, RAW file formats and especially with CR3.
I also noticed that the Windows packages load and save images very slowly. This could be due to the option set to teach MinGW C++11. At the company today, I was also amazed at how long it took to save a small HEIC file, so I am almost certain that it would work for you too. Another thing is compilation in debug mode, which slows down digiKam considerably. Gilles, my suggestion is to build the Windows packages without debug, we hardly get any useful backtraces anyway. Maik Am Freitag, 3. Januar 2020, 23:00:22 CET schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=415719 > > --- Comment #28 from tlteebken-reg@outlook.com --- > I can't (it was a CR3 file that I had just 'imported' using the RAW editor, > the source file is over 35MB). > > Possibly helpful additional details to know: > * Tested with several other CR3 RAW files, same behavior on all. > * Tested with the open Adobe DNG files, the saving is VERY slow, but if you > wait long enough, it does finally save without error and works. Save time > was 30-45 seconds. > * Tested with non-raw ordinary JPG/TIF files, works great and saves > instantaneously, no problem! > > So it seems we are almost there. Something funky going on with the large, > RAW file formats and especially with CR3.
To follow up on an earlier comment in this thread from Gilles: * Would one of you guys please report this bug to the developers of the library that is involved with saving Heic? I would do it, but I'm not sure I understand all the background info that should be added to the bug. * I will report the end user issue to Gimp as well, which is that it does not save .heic format at all in 2.10.14. And will cross reference this bug. Thanks, Tim
Ah it's insterresting. Same here, HEIC encoding is slow. I never tested with CR3. I will do it tomorrow. About to drop debug symbols, i can do it easily as it just an option to turn off in bundle configuration. So a lots of stuff to do tomorrow... Gilles
Q: the CR3 file imported to image editor is decoded in 8 bits or 16 bits color depth ? Also, which kind of Canon camera do you use exactly ? Gilles Caulier
My input files that repro this behavior are 16-bit, whether in CR3 or DNG format. Canon Camera: EOS M6 Mark II (support just added in libraw, including CR3) Here's the cross-reference bug I submitted to Gimp: https://gitlab.gnome.org/GNOME/gimp/issues/4453
Git commit 36746afbad134a47524ff9ad70c611c1b2c488fa by Gilles Caulier. Committed on 04/01/2020 at 05:55. Pushed by cgilles into branch 'master'. add debug trace to print elapsed time to encode as HEIF M +8 -1 core/dplugins/dimg/heif/dimgheifloader_save.cpp https://invent.kde.org/kde/digikam/commit/36746afbad134a47524ff9ad70c611c1b2c488fa
Well some more good news: I did a fresh uninstall/reinstall of the Gimp 2.10.14 bits and the Microsoft codecs. Now Gimp is working perfectly, I can save images in heic format with no error. So the only remaining issue in Digikam 7.0 Beta 2, for me, is the fact that large input files save extremely slowly in .heic format. I'd say that CR3 input files save so slowly, that in effect it is broken, it's taking so long most users like I did, will not realize it's still functioning, will think the app has frozen, and shut it down. Because you stop getting any feedback or indication that it is still working. It'll just say something like "Saving...70%" and you'll have no indication that it's making further progress. If there is no way to speed up the saving behavior (due to the external library dependency), maybe it would at least by possible to give user a prompt indicating this save could take a long time, and give them the option to cancel out of the operation gracefully rather than forcibly terminate the program. Thanks, Tim
In fact the libheif API do not provide any progress info while encoding. Only the loop for pixels formatting to be encoded as x265 is handle in DK code and has progress info of course. This is what you see until 70% of the job. The 30% remaining is the real x265 encoding. So, if a improvement must be done, it's in libheif: https://github.com/strukturag/libheif/issues/161 ==> look like this bug is reported by... me few month ago (:=)))... So please comment on this files directly... About the performance, x265 is really a high computation stage. It's done by another library which is called in fact by the top-level library libheif : libx265 https://bitbucket.org/multicoreware/x265/wiki/Home Gilles Caulier
Ok that makes sense. It's fine with me then if you want to close this bug, I'm not sure what else you can do in Digikam. Like I said, only suggestion I have--as a general alert to users--is just let them know with a dialog this is a very large file and encoding/saving in .heic format may take a long time, up to several minutes or more. Thanks again for all your help debugging this issue! Tim
My last comment: Under My Windows 10 64bits running on VirtualBox with 4 cores, HEIC encoding use only... one core... Encoding is not parallelized. This is why it's so slow. Encoding a Canon EOS-R (30 Mpx) CR3 raw file (16 bits color depth) to HEIC (lossy compression) took... 45 seconds. But it work... Voilà. So for optimisation and improvement, all must be delegate to UPSTREAM libraries as said in comment #36. I close this file now. Gilles Caulier
Maik, Just a note: I build a 64 bits version without debug symbols of Windows Installer. Of course, this reduce the file size a lots, but this have not effect of execution speed. why ? this is simple : libx265 is a standard MXE package which is already compiled without debug symbols. My option to turn off debug symbols in Windows installer force to drop all symbols everywhere. If the option is turn on, debug sumbols is preserved in all digiKam binaries. As libx265 is an external dll, this has no effect. I check the libx265 code and assembly code is used to run faster the encoding, but there is no multi-core support (no open-mp support). I suspect that optimizations exists with special hardwares and turned on with Microsoft compiler only. Here we cross compile under Linux because M$ devel env. is just a shame... So the OpenMP support wish must be reported as UPSTREAM to libx265 project. Gilles
In fact libx265 use WPP not OpenMP to parallelize : https://x265.readthedocs.io/en/default/threading.html I never hear about WPP before. Another brick on the wall... Gilles
Tim, In fact, I found the problem. libx265 must be compiled with "-pmode" option to enable parallelism computation. And with MXE x265 package, this option is not present : https://github.com/mxe/mxe/blob/master/src/x265.mk So, an UPSTREAM bug must be reported to MXE project under github about this problem : https://github.com/mxe/mxe/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen Gilles Caulier
Yes, I had a test last night with the AppImage and my native version, which is compiled with release. I was amazed that the times were the same. Other functions are much faster with my release version... Maik Am Samstag, 4. Januar 2020, 17:44:03 CET schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=415719 > > --- Comment #40 from caulier.gilles@gmail.com --- > In fact libx265 use WPP not OpenMP to parallelize : > > https://x265.readthedocs.io/en/default/threading.html > > > I never hear about WPP before. Another brick on the wall... > > Gilles