Professional Photo Management with the Power of Open Source

digiKam event: KDE Imaging coding sprint planed…

by digiKam

A coding sprint is planed to Genoa - Italy by me and Angelo Naselli. The goal of this event is to improve KDE4 digikam and kipi-plugins code.

The event dates are set from 31 october to 2 november. We will hosted by ALID Association which will provide a room with internet connection. The event will be sponsored by KDE-ev.

Peoples who will contribute to this events are:

I you want to meet us during this event, you are welcome. ALID Association is located at Genoa, Via Giovanni Torti, 35. See the map given below:

View Larger Map

We want to thanks in advance KDE-ev and ALID Association to make this event possible. If you want to help this Italian association, all donations are welcome. Just contact Angelo Nasseli for details.

can't be much closer to a

can't be much closer to a railway station I guess :) quite handy for the travellers :) have fun!

Well you can't see that well

Well you can't see that well from google map, but rail station is really near...
not its entrance thoguh :p


I have something for the coders to sink their teeth into: It took me almost a week but i fiddled around and made a patch that enables digiKam to at least see all my photos. The thumbnails are fine, but it won't show any of them fullsize. I only get "An error is occured with media player..." The actual image viewing code is way above my head so this is all I have. The patch is made against current svn revision 868218. I hope someone can squash this bug for good.

--- graphics.trunk/digikam/libs/database/collectionscanner.h 2008-10-05 20:51:59.000000000 +0200
+++ graphics.patch/digikam/libs/database/collectionscanner.h 2008-10-05 20:20:39.000000000 +0200
@@ -237,7 +237,6 @@
void incrementDeleteRemovedCompleteScanCount();
void resetDeleteRemovedSettings();
bool checkDeleteRemoved();
- void loadNameFilters();
int countItemsInFolder(const QString& directory);
DatabaseItem::Category category(const QFileInfo &info);

--- graphics.trunk/digikam/libs/database/collectionscanner.cpp 2008-10-05 20:51:59.000000000 +0200
+++ graphics.patch/digikam/libs/database/collectionscanner.cpp 2008-10-05 20:20:19.000000000 +0200
@@ -39,6 +39,7 @@
// KDE includes.


// LibKDcraw includes.

@@ -88,10 +89,6 @@
wantSignals = false;

- QStringList nameFilters;
- QSet imageFilterSet;
- QSet videoFilterSet;
- QSet audioFilterSet;
QList scannedAlbums;
bool wantSignals;

@@ -140,25 +137,6 @@

-void CollectionScanner::loadNameFilters()
- QStringList imageFilter, audioFilter, videoFilter;
- DatabaseAccess().db()->getFilterSettings(&imageFilter, &videoFilter, &audioFilter);
- // one list for filtering when listing a dir, with wildcard globbing
- foreach (const QString &suffix, imageFilter)
- d->nameFilters << "*." + suffix;
- foreach (const QString &suffix, audioFilter)
- d->nameFilters << "*." + suffix;
- foreach (const QString &suffix, videoFilter)
- d->nameFilters << "*." + suffix;
- // three sets to find category of a file
- d->imageFilterSet = imageFilter.toSet();
- d->audioFilterSet = audioFilter.toSet();
- d->videoFilterSet = videoFilter.toSet();
void CollectionScanner::completeScan()
emit startCompleteScan();
@@ -166,7 +144,6 @@
// lock database
DatabaseTransaction transaction;

- loadNameFilters();

//TODO: Implement a mechanism to watch for album root changes while we keep this list
@@ -241,7 +218,6 @@

- loadNameFilters();

CollectionLocation location = CollectionManager::instance()->locationForAlbumRootPath(albumRoot);
@@ -287,7 +263,6 @@
int albumId = checkAlbum(location, album);
qlonglong imageId = DatabaseAccess().db()->getImageId(albumId, fileName);

- loadNameFilters();
if (imageId == -1)
scanNewFile(info, albumId);
@@ -460,7 +435,7 @@
itemIdSet << scanInfos[i].id;

- const QFileInfoList list = dir.entryInfoList(d->nameFilters, QDir::AllDirs | QDir::Files | QDir::NoDotAndDotDot /*not CaseSensitive*/);
+ const QFileInfoList list = dir.entryInfoList(QStringList() << "*.*" << "*", QDir::AllDirs | QDir::Files | QDir::NoDotAndDotDot /*not CaseSensitive*/);
QFileInfoList::const_iterator fi;

for (fi = list.constBegin(); fi != list.constEnd(); ++fi)
@@ -592,12 +567,12 @@

DatabaseItem::Category CollectionScanner::category(const QFileInfo &info)
- QString suffix = info.suffix().toLower();
- if (d->imageFilterSet.contains(suffix))
+ KMimeType::Ptr type = KMimeType::findByFileContent( info.filePath() );
+ if ( (*type).is("image") )
return DatabaseItem::Image;
- else if (d->audioFilterSet.contains(suffix))
+ if ( (*type).is("audio") )
return DatabaseItem::Audio;
- else if (d->videoFilterSet.contains(suffix))
+ if ( (*type).is("video") )
return DatabaseItem::Video;
return DatabaseItem::Other;

Re: digikam

Stefan, please open a bug report on bugs.kde.org and describe your problem.
Judging from your patch, you disable the name filtering, so obviously something is wrong with that on your setup. Please tell us which image formats trigger the problem.

I cannot use the bugtracker

I cannot use the bugtracker atm, as I'm behind a transparent proxy which makes it unuseable. This will improve in the nest weeks, i hope.
Yes, the patch removes the filename-based type filtering and uses the mimetype-based one from kdelibs. This has puzzled me for a long time, as every other program like Dolphin, Krusader, Gwenview or the Konqueror gives no trouble. I'm not sure the patch is correct (it most probably is not) but at least it works and all my photos are now found.
There is no problem with any specific image format. The bug apperas with all of them, mostly jpeg or png, but I have a some tiff and an increasing number of raw files too. The reason is in the filename-based detection which won't work if there is no filename extension or an unknown one, like just a numeric suffix.

I doesn't work with raw files.

This is a wrong way. With all raw files format, using KDELibs mime type wrapper, it will never work. Why ? Because Camera makers has used the tiff format to contruct private container.

It's the hell. If you use KDELibs to handle RAW files, a lots will be open as tiff files using libtiff library which will generate a failure of course.

And like you can see at this place, The list of RAW file formats is huge...

Alternative is to parse file content to detect if it's really a RAW file. It's a big puzzle. Perhaps with LibRaw will work, but i'm sure that it will be a slower solution against to check file extension as well.

The slowliness is very true,

The slowliness is very true, DigiKam takes a couple of minutes to scan through even a few thousand photos. And I know my patch is only a crude workaround. The optimum would be somewhere in the middle, first guessing on filename extensions and if it fails on actual file content. DigiKam should already do this if you put "*" in the config dialog, but it does not. That's the bug I tried to fix.

Startup is another problem...

Slow startup is another problem. There is already a file in bugzilla about...

DigiKam is a new discovery for me!

Hi, I just wanted to say thanks for the following:

Using libdcraw and improving upon it, as it's the only thing out there that supports the Foveon X3 sensor in the Sigma SD-14 Digital SLR, a really cool camera I've rented a few times I think I might purchase it...

Being 16-bit...

Being quick enough...

Having this little jewel for me to discover: Inpainting to remove artefacts!!! SWEET!!!
Junk Eradication!

Being even better though different than GIMP and Krita. I say better because the Inpainting feature is a better dustbusting feature than the other two Open Source competitors and puts everything else I've played with out there to shame. Kudos!

Using LittleCMS...

Too bad you're not an Xfce application, but at least I don't have to pull in all of KOffice to use digiKam... I LIKE modularity!

And, last but not least, thanks for making a REAL Photo application guys and gals!