After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0
of its open source digital photo manager.
See below the list of most important features coming with this release.
Bundles packaging improvements
Qt 5.15 LTS used in Windows and macOS bundle
With this release we take care about upgrading the Qt framework with a LTS version. Since Qt 5.15.2, the framework is only
published privately to
the registered clients from the Qt Company. By chance, the KDE project deals with the Qt company to provide a rolling relea
se of the whole Qt framework
including all the most important patches. This is the Qt collection patch used
from now by the digiKam
AppImage bundle. This allows digiKam to benefit from important fixes as to support the most recent version of Mysql and Mar
iadb database in the QtSql plugin.
Even if Qt 5.15.5 is just released as open-source, more than one year later 5.15.2, we will continue to use the Qt Collecti
on Patch,
as the last customer Qt5 release is 5.15.8. So there exists again a serious gap between the open-source and the customer ve
rsions of Qt.
Nice, thank you. But is still crashes for my *.png files at start-up (generated by qlandkartegt / qt5). So it does not start before these are converted to another format. Happens at least since 7.6.
Digikam::DMetadata::load: Loading metadata with "Exiv2" backend from "/home/local/Picture/InArbeit/Neu/test.png"
Digikam::DImg::load: "/home/local/Picture/InArbeit/Neu/test.png" : "PNG" file identified
unknown: Opening file "/home/local/Picture/InArbeit/Neu/test.png"
Digikam::ItemScanner::prepareAddImage: Adding new item "/home/local/Picture/InArbeit/Neu/test.png"
unknown: ASSERT: "!isEmpty()" in file ././/include/QtCore/qlist.h, line 363
Sorry, I was to brief and I do in no case want to be unpolite. The reported (most likely trivial) problem is only a bug example and is more related to release policy. What kind of solid pre-release testing could overlook something like:
convert xxx.jpg -strip xxx.png # make a png without (exif)meta-data
digiKam-7.7.0-x86-64.appimage # and crash on start-up
DigiKam is really a nice open-source program, but a little bit more of testing would make it even better. At least I would be happier with less features, less bugs and a slower release cycle.
In my opinion DigiKam is great, but is releasing too often and should have fewer bugs. Please think about a non-developer user trying out DigiKam, seeing the bug mentioned or one of the many other (trivial and long standing) bugs like bookmark images not being refreshed after renaming, Gmic not handling 16 Bit, Jpeg-2000 bookmarks corrupted, no 16-Bit support for HEIF and so on ⊠Our non-developer user would probably become unhappy and look for another (commercial) software.
Thanks! This is great software and well worth the learning curve. Last year I made a video tutorial on the basics of digiKam here: digiKam Tutorial - YouTube
[Images]$ exiv2 8464801264.jpg
File name : 8464801264.jpg
File size : 8679300 Bytes
MIME type : image/jpeg
Image size : 4032 x 3024
Thumbnail : None
Camera make : Google
Camera model : Pixel 3 XL
Image timestamp : 2018:10:15 17:32:27
File number :
Exposure time : 0.000724 s
Aperture : F1.8
Exposure bias : 0 EV
Flash : No, compulsory
Flash bias :
Focal length : 4.4 mm
Subject distance: 6.06 m
ISO speed : 57
Exposure mode : Auto
Metering mode : Center weighted average
Macro mode :
Image quality :
White balance : Auto
Copyright :
Exif comment :
[Images]$ convert 8464801264.jpg -strip 8464801264.png
[Images]$ exiv2 8464801264.png
File name : 8464801264.png
File size : 27148713 Bytes
MIME type : image/png
Image size : 4032 x 3024
8464801264.png: No Exif data found in the file
[Images]$ digiKam-7.7.0-x86-64.appimage
===> NO CRASH !!!
Jpeg-2000 bookmarks corrupted ==> NOT REPRODUCIBLE HERE using last libjasper codec and libexiv2 0.27-maintenance rolling release (appimage use it).
no 16-Bit support for HEIF ==> HEIF is a container which can use different codec to host image data. As i can see, only 12 bits/color/pixels max is supported from libheif interface. See README from https://github.com/strukturag/libheif
I too canât reproduce the crash with the PNG file without metadata. But I would like to fix it. Can you provide a file from QLandkarteGT or email it to me?
The program is no longer being developed and is no longer available here as an RPM package.
I received the following at the end of the install:
Your locale has changed since this album was last opened.
Old locale: System. new locale: windows-1252
If you have recently changed your locale, you need not be concernedâŠand a bunch more with a click YES if you want to continue otherwise NO and correct your locale settings before restarting digiKam.
What is the signifigance of this? I have not changed anything to my knowledge and 7.6.0 was working just fine last time I opened digiKam. As of yet I have not clicked on either of YES or NO and await someones guidance on this.
thank you very much for your reply. The crash probably happens for all kinds
of png files. But I cannot isolate the problem. Is it something odd in the
database? It all started with 7.6 digikam. Never had such trouble before.
To get a clean setup I created a new User and initialized digikam
accepting all defaults.
I added a copy of pics used locally.
And it does not crash with pngs.
I can even use my digikamrc without a problem.
But still cannot fix the thing for my own user account. I will try the same
procedure as I did for the clean setup. Needless to mention that my data
set has only 4.600 pics (locally) and is using different formats (including
jpeg2000). Color profiles are also used.
I am on Debian Bullseye, using KDE and the digikam app image.
Sorry again, after my last mail a found out that digikam leaves zombies after
the crash. After testing I did âinit 2â to go into minimal console mode. ps
then reported the following:
I got crashes for whenever I added a png. On the other hand I found that a
fresh digikam setup for a new user could not reproduce this.
I was unable to narrow down the problem, may be it was caused by the database
(not digkamrc). Unfortunately it is not so easy for a user to recreate the
database. But I did and the crash problem is gone.
So at some time when switching to digikam 7.6 something got corrupted.
Thanks for the good backtrace. With this commit, the problem will be fixed in digiKam-7.8.0.
However, the cause is incorrect advanced metadata settings for the rating. Go to advanced metadata settings in digiKam setup and select Rating and click Reset Defaults.
