Professional Photo Management with the Power of Open Source

digiKam 5.0.0-beta2 is released

by digiKam


Dear digiKam fans and users,

digiKam team is proud to announce the release of digiKam Software Collection 5.0.0 beta2. This version is the second public release of the new main digiKam version and is a result of the long development process by the team.

This release marks almost complete port of the application to Qt5 and KF5 API. All Qt4/KDE4 code has been removed and many parts have been re-written, reviewed, and tested. Porting to Qt5 required a lot of work, as many important APIs had to be changed or replaced by new ones.

In addition to code porting, we introduced several changes and optimizations, especially regarding dependencies on the KDE project. Although digiKam is still a KDE desktop application, it now uses many Qt dependencies instead of KDE dependencies. This simplifies the porting job on other operating systems, code maintenance, while reducing sensitivity of API changes from KDE project.

The DNG convert tool has been migrated into digiKam Batch Queue Manager. This will simplify the user workflow when performing DNG conversions. Metadata Editor, Geolocator, and tool to import from scanner are now available in the Image editor, Showfoto, and Light table.


As a part of code optimization, an important task was done by Mohamed Anwer, a long-term contributor to digiKam. He worked last summer during “Google Summer of Code” to remove all digiKam KIO-slaves used to query the database. Instead, a robust multi-core/multi-threaded implementation is now used. digiKam had introduced KIO-slaves when the first SQLite database support was implemented. The goal was to perform database-related actions (processing searches, listing albums, tags and dates, storing detected faces, etc) in the background without rendering the graphical interface unresponsive. As the first version of SQLite did not support multi-threading, use of KIO technology was the best solution. Although this worked fine, it became evident that using separate processes was very sensitive with each systems update and was not portable to non-Linux systems. The new solution is also faster because it does not use data serialization shared between digiKam and KIO-Slaves.

Since removing KIO-Slaves was faster than planned, Mohamed also implemented a new important feature: the virtual digiKam trash folder.
Previously, digiKam used the KDE desktop trash, which couldn’t be ported to Mac OS X and Windows. Also, in case of the KDE desktop trash, deleted items were removed permanently from the computer instead of being moved into the desktop trash -- which was not an acceptable solution. Now, like all commercial photo management software, digiKam uses a hidden sub-directory in each main collection (including removable ones) to store deleted items. The trash is accessible from the album tree view, and user can restore or delete items permanently as they wishe. This is a simple, user-friendly, and portable solution.


Last summer, another long-term digiKam contributor, Veaceslav Munteanu, worked to improve the metadata workflow in digiKam, especially for synchronizing photo metadata with the database contents. A typical use case here is to queue all changes to process files when you change metadata in the digiKam interface. The database is patched, but not the metadata. As this last operation can take a while, we delegate pending operations to a new tool named Lazy Synchronization tool, which will do the job when the user decides, or at the end of digiKam session. In the status bar, you can see if pending items need to be processed by the tool.


in addition to a new settings panel, where the user can tune the Exif/Iptc/Xmp tags to handle database population with key image information, like date, comments, keywords, rating, etc., Veaceslav also worked on another part of metadata management. It’s now possible to order tags to parse while items parsing and specify which tags will be updated in the image using the Lazy Synchronization tool.


Shourya Singh Gupta from India worked exclusively on porting export tools to Qt5, factorizing lots of duplicate code everywhere, optimizing the implementations, performing tests, and reviving old plugins which have not had maintainers for a very long time. He helped to quickly have a suitable code working with Qt5. This allowed the team to drop the last Qt4 dependencies.


Although kipi-plugins has come a long way, they are not yet complete, as some tools are not yet fully ported due to some dependencies not available in Qt5. A lot of regression tests to asses the quality of the new code are also remaining. But that’s exactly what beta releases are for.

Another important part on which the team is working for the next 5.0.0 is MySQL/MariaDB interface.
The whole database code has been reviewed, polished, cleaned, and documented. The face recognition database is now integrated into digiKam core and is stored in SQLite or MySQL.

The MySQL interface was written 5 years ago by a contributor who had left the team since then. This code was placed in quarantine due to the lack of support and bugs. But thanks to the new MySQL expert on the team, we are now able to restore, fix, and improve this functionality.

Richard Mortimer has proposed lots of patches to fix and rewrite MySQL database schemas aiming to have a compatible digiKam database with the last MySQL or MariaDB default engine. New database features have been introduced and the database configuration panel has been re-written to ensure safety during database server configuration stage.


It’s now possible to setup a MySQL database at first run, instead of using SQLite first and migrating to MySQL later.
Two Mysql servers are available:

  • Local one to replace local SQLite storage
  • Remote one to use a shared computer through the network.
MySQL offers many advantages for storing digiKam data, especially when collections include more than 100,000 items. With such large collections, SQLite introduces latency which slows down the application. With this new release, you will be able to host MySQL internal server database files at a dedicated place, as with SQLite. Keep in mind that MySQL support is still under development and is not yet fully suitable for production. The database schemas are not yet fully patched, and lots of regression tests are yet to be performed.

Next summer, students will focus on working exclusively on database interface, to improve MySQL support in case of multi-accounts (photo agency use case), or to introduce new database engine support like PostgreSQL for example.

For furher information, take a look into the list of files currently closed in KDE bugzilla.

digiKam software collection tarball can be downloaded from KDE repository

This version is for testing purposes. It’s not currently advised to use it in production.

Thanks in advance for your feedback.

Happy digiKaming!

Note: All screenshots have been done with Linux Mageia Cauldron (next release 6)

Nicely done. Seems like a lot

Nicely done.
Seems like a lot of useful improvement :)

Awesome guys!

Can't wait for the stable version to use it with my Image-Database.

Dark Style

Many congrats to the team for all the hard work done thus far! Is the dark style custom-made for digikam, or was it picked up from the default desktop style? It looks pretty nice.

all from Plasma...

Icons and color schemes come from Plasma desktop...

Looks great

Glad to hear of the progress. Looking great and the "under the hood" stuff is nice.
I'll test on Mac El Cap when you have a version ready for that.

Operating systems

Hi, could anyone tell me if the new release will work with Windows 8.1 operating system (and in a virtual environment?)

yes, but...

...nothing have been tested yet (MAC/WIN).

Nothing to test yet?

Maybe some of the nice people that come here wondering about WIndows versions could be encouraged to test then? Perhaps by asking them in these posts..

Currently there is no 5.0.exe version for windows in the UNstable directory - (it stops at 3.0 rc even though some 4.x have been released) - unless I'm looking at the wrong place?

And as it seems it can it be tested/debugged with Windbg, LibreOffice has a nice installation guide:

Here are the Digikam links I found

That is a good suggestion :-)

That is a good suggestion :-) I'm waiting for the exe.


you can compare with darktable:

Thanks for this comprehensive

Thanks for this comprehensive update on the Digikam project. I'm glad lots of people are interested in it, and are collaborating, ensuring it is top-notch.

But the happiest of the updates, for me, is the decoupling of many of the libs from kdelibs to qtlibs. That, by itself, would mean that the non-Linux ports will become a reality soon.
And it'll also make more non-KDE users happy.

A big thank you to all of you. Digikam rocks!!!

Can you guys, maybe, share a

Can you guys, maybe, share a write-up on the Lazy Synchronization Tool ?

The biggest pain running Digikam was the enormous amount of I/O it could generate, the memory consumption/leak, and Linux's inefficiency under both these scenarios.

Today, as we speak, I've been able to make a usable setup of Digikam + Linux [1], with the help of Control Groups, but I'd be interested to know more about your approach.

[1] http://www.researchut.com/blog/controlling-apps-cgroups

Nice work!

Great work - as always!

I’m especially looking forward to the improved mySQL support and hope it will let me share the same database through 2-3 clients (Ubuntu and Windows). Without having to have the same absolute path to the collection :)

Agreed! Excellent work (as

Agreed! Excellent work (as usual) and I also am excited about being able to share a single database across multiple operating systems. I also like the idea of PostgreSQL support : )

MySQL & multi user / OS support

Being able to catalog photos on multiple computers is the key feature of Digikam for me that separates the application from the rest. Specifying an absolute path to the collection is a show stopper for letting windows clients connect because the absolute path is different.

Either specifying a base path on each client or adding in a client name when connecting could resolve this. Ideally I would like to create users with passwords so that I can restrict access by user. For example the kids can add tags, but not delete photos.

ppa:philip5/extra has 5.0.0-beta2

Philip has published a PPA for Ubuntu, but only for wily. I'm hopeful that he might publish a PPA for trusty as I'm currently using Linux Mint.

It's very unlikely that I

It's very unlikely that I will backport all updates of packages of QT5 and KF5 for Ubuntu trusty that Digikam 5 need as those packages are not that new in that Ubuntu release.

QMYSQL driver not loaded

Thanks for the response. I appreciate the effort to prepare it for trusty, I've installed ubuntu trusty (15.10) and added ppa:philip5/extras.

Unfortunately I've encountered an issue with MySQL support. The following message appears in the terminal window:

QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE
digikam.database: Testing DB connection ( "ConnectionTest" ) with these settings:
digikam.database: Database Parameters:
Type: "QMYSQL"
DB Core Name: "digikam"
DB Thumbs Name: "digikam"
DB Face Name: "digikam"
Connect Options: ""
Host Name: "bluefoot"
Host port: 3306
Internal Server: false
Internal Server Path: ""
Username: "digikam"
Password: "XXXXXXX"

QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.

I've searched for QMYSQL driver not loaded. I found the error mentioned a few times but the results are aimed at a programmer not someone installing the application.

Any thoughts on how to resolve this?

Solved: QMYSQL driver not loaded by installing libqt5sql5-mysql

I was able to solve the QSqlDatabase: QMYSQL driver not loaded error by installing libqt5sql5-mysql using:
sudo apt-get install libqt5sql5-mysql

Importing photos at start is painful

Importing images when starting is a very painful process. If I hadn't started digikam from the command line and/or looked at the database, I would have assumed that the program had crashed because it has paused at the splash screen for several hours.

The second issue I have encountered is that the program appears not to support My%20Pictures appearing in the directory for the AlbumRoot. After entering the Album in settings, I wasn't able to edit the path. I worked around this by creating a symbolic link to the directory and updating the row in the AlbumRoot directory.

Should this be logged in KDE bugzilla?

Planned features

Great progress and good software. The updated handbook is one of the best news since there are so many functions and options. NetPal