Paul Verizzo | 27 Jan 01:18 2015

Files won't display and/or open in editor

I have a large TIF file, 145mb.  It shows in the brower view just fine, but it won't open in the editor.  (I think
was a posting a few weeks ago on this or something very similar.)  It shows and opens just fine in Picassa,
and other programs.

I converted it and saved it to a PNG format.  In the digiKam browser view, there's that balloon placeholder
image.  I 
then also converted it to TIF, again, and JPEG.  These show up in the browser view, but just like the original
TIF, they 
won't open in the editor.

Windows running dK 4.5.0.

Paul Verizzo
Ulf Rompe | 26 Jan 23:04 2015

Group by filename

Hi all,

we would like to get some feedback on a patch we have been working on for quite some time now. It introduces a configurable "group by filename" action to the album view which lets you automatically combine files with matching name parts into a group.
A filename based grouping feature is key for our workflow, and we could imagine lots of use cases for other people's workflows. In fact, we found the feature request we attached the patch to after implementing a first version for our own purpose, so it seems there is at least some demand for it.

Find a short screencast of the current functionality here:

As you can see, there are three configuration options:

  1. The default setting is set up to combine RAW and JPEG files. If you have 123.nef and 123.jpg in your current selection, they will be grouped, leaving 123.jpg on top.
  2. The second option configures grouping of files featuring common appendices added by well known image editors. If you have, for example, some of 123.jpg, 123_v1.jpg, 123-Edit.jpg, 123_shotwell.jpg and "123 (edited).jpg" in your current selection, they will be grouped.
  3. The third option is for advanced users, giving you the option to manually tweak the expression used for the matching. The editable pulldown is already populated with the expressions used to realize the two options described above as well as an example that implements our very own grouping logic. Whatever you try here, the previous state will always be remembered and accessible through the pulldown. Just fool around and see what happens.

Technically, this feature is implemented as a patch against digiKam core. While we would have loved to implement it as a plugin, we didn't find a way to hook a plugin into the album view and the context menu. The flexible matching part is based on the popular regular expression syntax. Gilles, we know you are not a fan of regular expressions, but we couldn't think of another way to achieve a flexible matcher like this without overcomplicating things. We just hope that if you would totally hate regular expressions you would have closed the feature request #318357 before someone accepted the challenge to work on it. Of course, the offer I made in my comment to the G+ post above still holds.

While we consider the patch ready for prime time now, we would like to hear:

  1. Is the UI intuitive enough, especially from a KDE point of view?
  2. Could you think of other predefined grouping options than the two introduced above? Of course we would like to serve most users with easy defaults, leaving the manual expression editing to power users.
  3. Would it be realistic to get the feature into digiKam in the near future?

Best regards, Ulf
Digikam-users mailing list
Robert Latest | 25 Jan 12:56 2015

Question about file date / EXIF date

Hello all,

I'm confused about the following: I like to view my photos in
chronological order they were taken. Hoever, it seems that digikam
orders the photos by file modification date. This leads to the
unfortunate situation that whenever I edit the metadata of a picture,
it jumps to the bottom of the view.

People who use only one camera probably don't notice this because their
camera simply names the files by ascending numbers, but I and my family
have several cameras in use. I use a homwgrown importing tool which,
after copying the image file to its assigned place, changes the file's
mtime timestamp to the actual EXIF date of the image contained in the

What I don't understand is this:

1. Why doesn't digikam offer the option to sort by EXIF date rather
than just "date" (which seems to be the file's mtime)?

2. Why is the image file touched at all when in "Configure > Metadata"
none of the options under "Reading and Writing Metadata" is activated?

3. What does the "Update the file timestamp when files are modified"
do? It seems that this would be exactly the option I need; however, it
doesn't make a difference whether I activate it or not. The file
timestamp is always updated.

Thanks for a great piece of software!
Martin (KDE | 24 Jan 18:43 2015

Re: GEO location button is missing in Thumbnails

Hallo Gilles

Thanks for checking this. At least with digikam on fedora 21 the
"button" is missing an the tooltip says that the image has no geo
location data. IS there something I can check why this is the case? Are
there other fedora users seeing the same?


Am 24.01.2015 um 14:30 schrieb Gilles Caulier:
> No problem here. Icon view map icon tool tip show that image _has_
> geolocation info.
> In fact this icon only appear when GPS info are present are fully
> recognized in metadata. This is the case for your image as you can
> seen...
> Gilles Caulier
> 2015-01-24 14:08 GMT+01:00 Martin (KDE) <kde@...>:
>> Hallo Gilles
>> shure I can. Attaches you can find one example image. geo location data
>> was set with geo location tool from digikam, not by camera.
>> regards
>> Martin
>> Am 24.01.2015 um 11:15 schrieb Gilles Caulier:
>>> Geo location info are parsed from image metadata to be registered to
>>> DB. If all info are fine GPS info are stored in DB, else no.
>>> Can you share the image to see if all GPS info are parsed and
>>> registered properly ?
>>> Gilles Caulier
>>> 2015-01-24 11:03 GMT+01:00 Martin (KDE) <kde@...>:
>>>> Hallo
>>>> In thumbnail view there are small round "buttons" on the top. right to
>>>> the rotation buttons there is a free area and if I hover the mouse on
>>>> this space I get the information that this picture has no geo location
>>>> information. But this is not true, as this picture has the location set.
>>>> It is correclty shown in the geo location side panel. Is this a bug or a
>>>> feature?
>>>> In use digikam version (4.6) in Fedora.
>>>> Redards
>>>> Martin
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> Digikam-users@...
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users@...
Martin (KDE | 24 Jan 11:03 2015

GEO location button is missing in Thumbnails


In thumbnail view there are small round "buttons" on the top. right to
the rotation buttons there is a free area and if I hover the mouse on
this space I get the information that this picture has no geo location
information. But this is not true, as this picture has the location set.
It is correclty shown in the geo location side panel. Is this a bug or a

In use digikam version (4.6) in Fedora.

Sergio Belkin | 23 Jan 13:41 2015

Some photos are not shown in thumbnail mail

Hi folks,

I've have some photos that are not shown in digikam through View->Thumbnail.

Photos that cannot be viewed so are "JPEG image data, EXIF standard" taken using a smartphone Samsung GT-i9300 , but "JPEG image data, JFIF standard 1.01" using GT-i8190L can be viewed with no problem.

It's a bit weird that View-Table the thumbail are shown on both kinds of photos.

Please could you say me if is a misconfiguration or a bug?

Thanks in advance!

Sergio Belkin
LPIC-2 Certified -
Digikam-users mailing list
Gerhard Hoogterp | 22 Jan 21:43 2015

TMPDIR issues


Quick question.. Is there a setting or a simple way to use an alternative 
TMPDIR with digikam? 

Where my /tmp is normaly more than adequate, for some (stitching panorama's) 
it's simply to small. As I have partitions with more than enough space I'm 
hoping I overlooked a photoshop or GIMP option to set an TMP and/or swap path 
from within digikam.

(and if there's no such thing, may I suggest it as a feature for a future 



My blog:
Dmitri Popov | 21 Jan 12:08 2015

DLNAExport Kipi plugin

Looks like the DLNAExport Kipi plugin is missing in digiKam 4.6.0
(installed via Philip Johnsson's PPA). Has the plugin been removed
from digiKam? For what reason?

Michael Havens | 20 Jan 02:08 2015


 I thought I once used digiKam to print up a bunch of photos
 The template had a layout of business card sized photos
 I resized the print area and repositioned the area to be printed so that certain points were centered.
 Now it won't do that.... why? Do I need to install a library or plugin? These are what I am installing that I think have anything to do with digiKam:

   digikam kipi-plugins exiv2 gphoto2

Digikam-users mailing list
Gian Paolo Sanino Vattier | 19 Jan 21:12 2015

crazy thumbnail syndrome

Hi all,
This sounds like a total nightmare but I found some hints that could lead to a solution. We can simplify the definition of a syndrome as a set of symptoms that seems to be related by a common cause. My DK is experiencing several symptoms that seems to have a common cause despite their differences.

First the main symptoms of this "crazy thumbnail syndrome":
- when grouping by Album, there are some album/folders that do not show all their content. As an example it shows two thumbnails despite the counter states 10 and using dolphin I confirmed there are indeed 10 photos there. Some of my albums appear completely empty. So, the hidden thumbnails is the first symptom.
- large empty spaces between the albums. This may be just a consequence of the previous symptom because albums that showup with all their thumbnails, have no empty spaces separating from next album.
- the most weird, is that passing the pointer over some thumbnails, they change!!! I mean the thumbnail changes and even the text underneath too corresponding to other photo. It switches from the thumbnail corresponding to the file A to the file B just by passing the mouse on top rendering the thumbnail itself unreliable since I do not really know if it corresponds or not to that album. Funny, when I scroll up or down a bit, these switched thumbnails return to the previously shown thumbnail. Again, mouse-over makes the thumbnail to switch again repeating consistently the behavior.
- the switching thumbnails can occur as a complete change among thumbnails or a partial case as overlapped thumbnails depending on the zoom setting of the Thumbnail view mode.
- when filtering it is the same nightmare showing lesser thumbnails that the real content of the folders.
- this is only happening to some images and not all images, they are always the same with problematic thumbnails and despite their thumbnails show-up perfectly fine when selecting their album directly (not as sub-tree).

Too complex or needing a visual? ok, look this unlisted video and focus on the content of albums 04 and 02...

Now some light over this syndrome...

* I checked the database connecting externally to it, and it is perfect. Data allocated inside is fine, with all the tags perfect etc. Great. So it is just the way DK presents on screen the thumbnails.

* erasing thumbnail.db to force rebuild the thumbnails or using the rebuild tool does not solve the problem.

* Using Table instead of Thumbnail view mode, the thumbnails are all shown and there is no crazy mouse-over nor large black empty spaces. However the "group images by album" does not do anything on Table view (that is another issue anyway). The point is that the problem occur only under Thumbnail view mode and that all these symptoms have a common cause because all of them are solved by simply changing the view mode.

* I tested every visualization combination and all the previous symptoms occur under a specific visualization setting and only to some images (not all). I did not find anything special (yet) to the images whose thumbnails are shown under some settings and those that are shown properly despite the settings.
The combination of terror is when having menu/View/ all the next settings:

a) Thumbnail view mode
b) enable the "include album sub-tree" and "include tag sub-tree"
c) Sort Images set on "by Date"
d) Group Images set on "by Album"

Any other combination is fine, but sadly this is the most useful for me...

Partial solution
just by changing "Sort Images" from "by Date" to "by Name" solves the problem, no more crazy mouse-over behavior changing thumbnails, nor missing thumbnails nor empty spaces. Since the file names from my camera are time correlative, it ends by presenting the Thumbnails in an almost same way to "by Date". Also, by changing "Group Images" from "by Album" to "Flat list" solves the symptoms.

These findings suggest that our files are fine, since DK is able to show their thumbnails properly in most cases but something is weird when combining the "Group Images by Album" with "Sort Images by Date" visualization settings.

Probable related issues:
Some time ago, Audun posted a similar symptom (no thumbnails). Also this link to a post that seems to have similarities as well:
They do not mention the swuitching thumbnail mouse-over behavior but as I mentioned it before, it happens also to some and not all thumbnails.
I cannot confirm my case is in fact related to audun's or others, but maybe these cases can check if changing "sort images" from "by date" to another option, solves their issues of "hidden thumbnails".

Other details:
This is happening to most of our boxes:

BOX1: asus desktop / nvidia / 6 cores / opensuse 13.2 / DK 4.6.0 / KDE 4.14.3 / Linux (x86_64) release 3.16.7-7-desktop.
BOX2: asus 4 cores / all the rest the same except it has DK 4.5.0.
BOX3: notebook HP pavillion / ATI / also with opensuse 13.2 (x86_64)/ DK 4.5.0
BOX4: notebook HP mini / ATI / also with opensuse 13.2 / DK 4.6.0 / KDE 4.14.3 / Linux (x86_64) release 3.16.6-2-default.
BOX5: asus 4 cores quite old / opensuse 13.2 / DK 4.6.0 / KDE 4.14.3 / Linux (x86_64) release 3.16.7-7-desktop.

So the syndrome happens on DK4.5.0 and DK4.6.0 but not always. BOX3 does not have this visualization issue (tested with the same images). All my other boxes have the problem despite they have just being clean-reinstalled and have different hardware. I know BOX3 had a patch recently and BOX2 did not. Both are at the field right now and it is hard for me to perform tests on them. However, in the case a patch solved the problem on BOX3 (which I cannot confirm and do not know if the problem was ever there before the patch neither), why boxes with 4.6.0 (a more recent version) have the issue anyway?

Hope this helps to solve the issue.
Digikam-users mailing list
Piter Dias | 15 Jan 21:28 2015

Problems with "Write Metadata to Image"


I write metadata to side car files to keep original images untouched. It seems that digiKam only creates the side car files after we change some tags or use the option "Write Metadata to Image", what I use today in order to create the files for a lot of old photos that I did not assign any tag.

If I select a bunch of photos some (very few, 0.5%~1%) of side cars are created with just "<?xml version="1.0" encoding="UTF-8"?>" (lets call it "empty"). Most of them are cool.

If the photo with empty side car is selected and I click "Write Metadata to Image", the side car is created as expected (all tags and so on).

Is it a known problem? I use Windows 8.1, digiKam 4.6 and photos are in a samba share (under Ubuntu 14.04.1). If it is a new problem, I already have the DebugView but it is not clear for me, by inspecting it, why it is not working.

Thanks a lot,

Piter Dias

Digikam-users mailing list