digiKam

Professional Photo Management with the Power of Open Source

digiKam 5.0.0-beta2 is released

by digiKam

digiKam5.0.0-beta2

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.

digiKam5.0.0-beta2-06

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.

digiKam5.0.0-beta2-02

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.

digiKam5.0.0-beta2-03

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.

digiKam5.0.0-beta2-04

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.

digiKam5.0.0-beta2-05

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.

digikam5.0.0-firstrun-mysql

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 further 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)