Dear digiKam fans and users,
After five months of active maintenance and long bugs triage, the digiKam team is proud to present version 8.2.0 of its open source digital photo manager.
See below the list of most important features coming with this release.
Libraw : Updated to snapshot 2023-11-21 Bundles : Updated Exiv2 to last 0.28.1 release Bundles : Updated ExifTool to last 12.70 release. Bundles : Linux and macOS uses KF5 framework to last 5.
This is a companion discussion topic for the original entry at https://www.digikam.org/news/2023-12-03-8.2.0_release_announcement/
2 Likes
Hi all!
My environment:
OS Ubuntu 20
ldd (Ubuntu GLIBC 2.31-0ubuntu9.12) 2.31
digikam 8.2.1 appimage installed and running ok.
I downloaded appimage ver.8.2.0 as usual, but cannot run this version.
I also checked glibc version (>2.27 needed) but I have ver.2.31.
What can I do?
Thank you!
Is source code available somewhere please? I haven’t seen it published yet on GitHub - LibRaw/LibRaw: LibRaw is a library for reading RAW files from digital cameras ?
Hello,
I have the same problem with Antonio.A.
The error messages are:
digikam: /lib/x86_64-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /tmp/.mount_digiKayhwRxj/usr/lib/libMagick++-7.Q16.so.5) : digikam: /lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.13’ not found (required by /tmp/.mount_digiKayhwRxj/usr/lib/libopencv_core.so.408)
Like Antonio.A, my glibc is “Ubuntu GLIBC 2.31-0ubuntu9.12” and seems to meet the requirements of digiKam 8.2.0’s requirement ( glibc >= 2.27).
The Libraw code have been taken from the gihub repository to be hosted in digiKam core at this place:
The problem is not the GLIBC, but the GLIBC++ ABI, required by ImageMagick codecs.
The AppImage is compiled under Ubuntu 18.04. I’m surprised by the non compatibility with th more recent Ubuntu/Debian distro.
Did you have libstdc++ package installed ?
WDYMB “native Windows 10 build”? Microsoft have discontinued Windows 10, haven’t they?
Yes, libstdc++ package 10.5.0-1ubuntu1~20.04 is installed. But, “strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6|grep GLIBCXX_3.4.29” shows nothing (last one is GLIBCXX_3.4.28).
FYI, my system is Linux Mint 20.3 (based on Ubuntu 20.04 LTS).
No they haven’t. I believe there may still be some minor feature updates, and in any case it will be supported for some years to come.
I’m having issues on MacOS Sonoma? (14.1.2 (23B92)) MacBook Pro M2
Digikam fails to launch and no window is displayed.
Turning on logging shows the following:
➜ export QT_LOGGING_RULES="digikam*=true"
➜ /Applications/digiKam.org/digikam.app/Contents/MacOS/digikam
digikam.qtav: Register QtAV Renderers:
digikam.qtav: Qt have no OpenGL support.
digikam.qtav: register QtAV::OpenGLWidget Renderer: true
digikam.qtav: QtAV have OpenGL support.
digikam.qtav: register QtAV::QGLWidget Renderer: true
digikam.qtav: register QtAV::QGLWidget2 Renderer: true
digikam.qtav: register QtAV::Widget Renderer: true
digikam.qtav: register QtAV::GraphicsItem Renderer: true
digikam.widgets: Breeze icons resource file found
digikam.widgets: Breeze-dark icons resource file found
digikam.general: Qt standard translations removed: 0
digikam.general: Qt standard translations path: "/Applications/digiKam.org/digikam.app/Contents/Resources/translations"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qt"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtbase"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qt_help"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtdeclarative"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtquickcontrols"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtquickcontrols2"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtmultimedia"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtwebengine"
digikam.general: Loaded Qt standard translations "en_US" from catalog "qtxmlpatterns"
digikam.general: Loaded Qt ECM translations "en" from catalog "kcoreaddons5_qt"
digikam.general: Loaded Qt ECM translations "en" from catalog "kwidgetsaddons5_qt"
At this point the app freezes and I have to force-quit or kill.
Is there a way to turn on deeper levels of logging?
Thanks for the clarification.
So, in fact, this is not a new “snapshot” in LibRaw parlance (which implies new cameras/raw format support and is followed by an internal version bump and an announcement like this), but just a collection of bug and security fixes on top of the last published one. AFAIK, no new “snapshot” has been published since the 0.21.1 version. Could you please keep this in mind for future release notes?
Having been a loyal and happy digiKam user for many years, I updated to this version as it came out (on MS Windows 11 Home, 64-bit, v23H2 with latest updates) on a i7 Intel, 32 GB RAM, and 2 NVME’s (1 for OS, 1 for DB). digiKam is running on a separate DB and the collection consists of about 250k photo’s, with about half in RAW (NEF) format.
The new version works, but…:
It is super-slow to start at about 5 minutes before it’s beyond the splash screen and reread the whole DB, where in the previous version this used to be about 1 minute.
Also when photo’s are edited (outside digiKam), and stored in a catalogued folder, digiKam becomes unresponsive for some time and then returns to usable/responsive.
It feels like the new MS Windows version is not nearly as efficient as previously and this currently impairs my joy with the otherwise fantastic tool.
Wanted to share this here for the community.
Have you seen this (solved) thread? Digikam 8.2 scanning for new entries very slow Might be the same issue.
No I did not yet - thank you for pointing out. That does significantly improve startup times.
Yet responsiveness after edits and requiring rescan remains sluggish in comparison to prior to v8.2.0.
Maik Qualmann provided a fix for the issue and recommends to test appimage of V8.3 as soon as a new build is available.
“The AppImage date must be greater than December 17, 2023.”
Thanks for that advice.
So I downloaded and installed digiKam 8.3.0, dated 19-dec-2023.
The launch of the app takes as long as with 8.2.0 with 4 minutes.
On the splash screen the loading tools part takes 4+ minutes. Is that normal?
The read of “new items” is now (with the “fast scan” setting down to below 1 minute - so that is as good as it was before 8.2.0.
Upon launch, digiKam prompts “Download required files” (face detection, aestetic Detection and Auto tags) and asks for a restart post the install of those components.
After restart, digiKam still freezes, seemingly randomly. It becomes totally unresponsive for about 30 seconds, whereafter the interface becomes responsive again.
I have uninstalled 8.2 and went back to 8.1 because I could not get it to run. Same as @Casper_Blom. Running Windows 10 with 8 gig ram. I will try the new build
I’m on Windows 10 and 8 gig ram. Installed 8.2, it stops loading at random. Sometimes “Loading Tools”, sometimes “Loading images”. Anything from 150 to 500 mb usage. Made the changes suggested in this thread, including installing 8.3 and waiting for an hour. I deleted the db and pointed it to a folder with no images. It will not run. Any suggestions will ne appreciated.
Feeding back here that I am reverting to digiKam 8.1.0 :
Tried the latest app images suggested by Gerd (thank you!) but no change in the behaviour:
digiKam starts up more or less at normal speed, yet thereafter on random action such as adding a directory, clicking to change to another folder, it freezes completely for a couple of minutes and then becomes operable for another couple of minutes, and then the same thing again.
digiKam runs on Windows 11 Home 23H2, build 22631.2861 and is installed on a Dell XPS 9510 laptop with 1+4 TB SSD’s and 32GB ram. Prior to the upgrade to 8.2.0 never experienced such issues with digiKam.
I am seeing the same behavior on Windows 10 (22H2) and have also reverted to digiKam 8.1.0.