Milestone Report 2: GSoC’17 Tasks Implementation


The second coding period is completed and here is the report blog. Hope you’ll find it detailed enough!

Task 3: Create a new schema for similarity features.


This task involved creating a new schema for similarity database.

  • ImageHaarMatrix table (as mentioned in last post) moved from Core DB to Similarity DB.
  • Creating a new ImageSimilarity table. As compared to previous post, ImageSimilarity schema has been updated to accommodate use of various algorithms:

 imageID1(int) | imageID2(int) | algorithm(int) | value(double)

  • “Dbconfig.xml” file updated with a couple of other Similarity DB queries, along with above CREATE TABLE statements.

Task 4: Create a new database access interface inspired of Faces Management database interface.


Extracting  the rules from main DB interface and writing code for a entirely new interface dedicated to fingerprints management, similar to Thumbnails or Faces Management. Code has been written for the following:

  • Similarity DB Access Wrapper
  • Similarity DB Backend
  • Similarity DB Schema Update
  • Similarity DB Interface

These files contain separate SQL queries and rules to create and update similarity DB respectively.

I’ll upload next blog post with the final set of tasks!

Thank you for reading. 


Milestone Report I: GSoC’17 Tasks Implementation


The first coding period is completed and this is the first coding period report blog. Hope you’ll find it detailed enough!

Task 1: Review current whole database implementation including database schema hosted as XML.


Since I’ve worked previously with DB, things seemed pretty clear this time. Among the three DB, my main focus was on understanding:

  • Understanding to create a new DB from scratch
  • Understanding to write the common code fragments for MySQL/SQLite
  • Thorough reading of DB Config file ( to understand how database schema is set up.
  • Analyzing the implementation of Thumbnails DB, especially, to create a similar one for similarity feature.

Task 2: Isolate tables and schemas relevant of similarity fingerprints.


This task involved isolating existing tables and figuring out the new tables to be created, relevant to the similarity DB.

  • ImageHaarMatrix needs to exactly moved to the new database, without any change. I think it’s not required in the core DB. (Haar Algorithm is used to generate image fingerprints in DigiKam).
  • A new ImageSimilarity table is required to store the similarity value of pair of images. Schema would be:

imageID1(int) | imageID2(int) | value(double)

No other tables are required currently to be moved from Core DB.

Thank you for reading. I’ll keep you updated with my next tasks in upcoming blogs!

GSoC’17 : First Blog

Hello readers

I’m glad to share this opportunity to be selected 2 times for Google Summer of Code project under KDE. It’s my second consecutive year working with DigiKam team.

DigiKam is an advanced digital photo management  application which enables user to view, manage, edit, organise, tag and share photographs under Linux systems. DigiKam has a feature to search items by similarity. This require to compute image fingerprints stored in main database. These data can take space on disk especially with huge collection and bloat the main database a lots and increase complexity to backup main database which include all main information for each item registered, as tags, label, comments, etc.

The goal of this proposal is to store the similarity fingerprints must be stored in a dedicated database. This would be a big relief for the end users as image fingerprints are around few KB of raw data for each image. And storing all of them takes huge disk space, increases time latency for huge collections.

Thus, to overcome all the above issues, a new DB interface would be created. {This work has already been done for thumbnail and face fingerprints}. Also, from backup point of view, it’s easy to have separate files to optimise.

I’ll add keep you guys updated with my work in upcoming posts.

Till then, I encourage you to use the software. It’s easy to install and use. (You can find cheat sheet to build DigiKam in my previous post! 😀 )

Happy DigiKaming! 🙂

DBUS dropped for digiKam under Linux


You might all be familiar with the popular message bus system i.e. DBus. It is an inter-process communication (IPC) and remote procedure call (RPC) mechanism that allows communication between multiple computer programs concurrently running on the same machine.

DigiKam earlier used DBus under Linux system, but its support under Windows and OS X made digiKam unstable. The database core implementation based on DBUS was only used with old KIOSalve which is now removed.

In the current version, DBus is now optional for Linux and completely removed for Windows and OS X. It is now a thread, not a separate process.

After more than 1 year of development, digiKam 5.0.0 release plan updated and finalized… Do take a look!

Bonne Journée!

digiKam: My SQL/MariaDB support

Being a Google Summer of Code’16 student, this is my first milestone report blog. Hope you’ll find it detailed enough!

Task 1: Review current whole database implementation including database schema hosted as XML.


  • Understand all three parts of Core DB:
  1.  CoreDB- hosts all albums, items, search data…
  2. ThumbsDB – host image Thumbnails.
  3.  FaceDB – host image histogram for face recognition.
  • Analyzing the ‘databaseserver’ code in core (which rely on DBUS. Actions are ongoing to minimize DBUS dependency, to improve digiKam stability for non Linux systems).
  • Understand how common code fragments work for both MySQL/SQLite (DB settings extracted from config file and later functions accordingly).
  • Understanding how SQL queries are being used in the source and implemented.
  • Thorough reading of file to understand how database schema is set up. (Create table/indexes/triggers statements for both SQLite/MySQL).
  • Understanding database version update through schemaupdater files (of all 3 DB).



I faced many doubts while reading the source code, plus several concept related queries. But all of them were resolved with Mentors’ help and guidance throughout.    




Cheat sheet to build digiKam for Newbies

Salut people!

This blog post is for all those yearning to manage photographs like professionals. This is a quick guide to build an advance photo management software digiKam, for all shutterbugs!

Required Installations:

  • Qt Creator, a cross platform C++, JavaScript and QML Integrated Development Internment. Download link and then follow these steps to install. (Using Qt Creator is highly recommended, but other IDE like KDevelop or Eclipse could be used.)

  • Maria DB, a community developed fork of the MySQL Relational Database System. Follow these guidelines step by step to install. Remember: DO NOT put any password for root user. 

Get digiKam from KDE Git/Master Repository

Enter these commands in a new terminal:

  • git clone git://  (Remember if you are in a University with crappy firewalls, use git clone )

  • cd digikam-software-compilation/

  • export GITSLAVE=.gitslave.devel

  • ./download-repos

Read well the README file and install all the dependencies before executing further commands. (Tip: use apt-file search <package_name> to easily install dev packages)

To compile the source code under Linux you have to give these commands in the source code folder. You should use a separate build folder to help cleaning up sources if something goes wrong.

  • ./bootstrap.linux   (All configuration tasks can be performed by bootstrap.linux script.)

Make sure it runs successfully without errors. Check the console to correct errors, if any.

  • cd build

  • make -j8

  • sudo su

  • make install

Open a new terminal and run [digikam], and Voila! You’re all set to use it.


QMutex: An impressive breakthrough

Hello Readers.

If you’ve looked into source codes, you will often come across term like mutex. This post unravels its purpose and advantages.

There have been many issues to multi thread programming. The most prominent one being the atomicity (An illusion that a section of code either executes completely, or doesn’t execute at all).

mutex meets the atomicity requirement. Officially: “Mutex are typically used to serialize access to a section of  code that cannot be executed concurrently by more than one thread. A mutex object only allows one thread into a controlled section, forcing other threads which attempt to gain access to that section to wait until the first thread has exited from that section.”

You might be amazed to know that we have a class in Qt, known as QMutex, that provides access serialization between threads. QMutex is optimized to be fast. It is constructed and destroyed with almost no overhead, which means it is fine to have many mutexes as part of other classes.

QMutexLocker is like an icing on the cake. It’s best to use both as this makes it easy to ensure that locking and unlocking are performed consistently.

Many software use mutex protection to manage multi threads. One such is digiKam, an advanced digital photo management application for Linux, Windows, and Mac-OS X which manages it’s huge source code using QMutex class.

For more advanced information, take a tour of official Qt Documentation!