[Digikam-devel] proposal: use tags for album collections & image grouping

Tibor Blenessy tiborb at matfyz.cz
Sun Aug 26 11:44:03 BST 2007


Hi

I'm user of digikam and recently I've to organize quite a lot of photos. 
While using digikam I've thought about some organization principles used 
  in digikam. I've read several bugs (since 2004) and proposals for 
allowing nested album collections, allowing grouping of modified, 
bracketing images, etc. I was thinking about some easy way to implement 
solution to this issues.

This solution is based on creating new tree of tags (I will refer to 
this tree as system tags). This tree of tags will not be available 
directly to the user, but it will be used internally by digikam.

I'm not familiar with digikam code. So sorry, if something is already 
implemented. I've looked at database structure and done some high-level 
code browsing through websvn to get overall look about architecture.

Using tags for album collections

Under system tags tree, there will be tag Albums. Each image will have 
tag from Albums subtree which means, that particular image belongs to 
this album. Image participation to albums will no more be connected 
through image position in filesystem. Albums tags will be created 
automatically by standard ways, that are now used for album creation. 
Images will be placed still in folders, but folders will have no meaning 
to digikam.
To help user organize images in filesystem, there will be some organize 
files dialog (maybe you know it from Amarok). This dialog will enable to 
rearrange filesystem according to Albums tag subtree.
Using this architecture image can belong to multiple albums (this can be 
configurable). Organize files dialog can solve this by copying images, 
symlinking or explicitly asking user where to place image file.
Creating directory structure should be configurable by album name, album 
date, etc. To get inspiration see Amarok's organize files.

Using tags for image grouping

Under image grouping I understand something like micro-albums. In one 
group belongs images taken by bracketing or sequence shots, shots of 
same scene, but different composition, modified images (resized, color 
adjustments,...)

Such group should be displayed by only several representative images. So 
if you have three bracketing photos, you create group and set as 
representative (visible) image one with best exposition. Also in each 
group, there can be several original (source) images, and they derivates 
(for example group representing panorama).

To implement this, I suggest to create new tag tree Groups in system tag 
tree. This tag tree can have following structure:

root: Groups
1. level: group type (bracketing, modifications, sequence, general,...)
2. level: concrete groups
3. level: visible, original

In UI, when user groups images, it is queried for group type and than 
concrete group tag is generated and assigned to all images in group. 
User than can select which image is visible from group, and which images 
  are original.

When showing group in album, only thumbs from visible images are shown. 
But in thumbnail is some clickable icon to expand/collapse this group.

This architecture allows that image can be in multiple groups 
(personally I often have bunch of bracketing images which differ in 
composition, so I would like to have one composition group with all 
images and several bracketing groups)

Creating of groups should be automated as much as possible, so user 
don't get bored with it.
- automatically detect bracketing and sequence groups using EXIF (my 
Minolta Z1 includes this in Exposure Mode, other cameras probably also)
- automatically detect groups, when images are taken in short time interval
- detect groups from images that have same GPS info
- detect groups when images have same filename beginning
- automatically create groups, when changes are done in editor

Concrete group tags should be named automatically (maybe according id of 
visible image, or some unique group name generator)

There should be some UI tools to add/remove images in groups.

In digikam bugs db there were several wishes to create some language to 
apply color changes, and similar on the fly, without modifying original 
image. I think, that this is task for some full featured image editor 
(like gimp) and special image format (mostly this is available in native 
editor formats like XCF in gimp through undo/redo functions). digikam 
should only be able to read such file (what is already done, imho). Such 
file than can be grouped with source file using proposed group feature.

There can be possible problem in performance, because there will be more 
  queries to the db. I'm unable to estimate this, maybe someone with 
more understanding of sqlite. But from my point of view, I have quite a 
lot of tags and loading albums and searches is lighting-fast. Proposed 
features will add only 1 tag to each image (to indicate album) and to 
some images 1 or more tags (to indicate groups), so it should be ok.

I'm willing to help to develop this. I can program in C++, but I have no 
previous experience with Qt (I would like to learn it). Hope this 
wouldn't be too difficult to develop, because it uses already developed 
digikam's tags infrastructure.

So tell what do you think about it. Whether it can be done, etc...

Tibor Blenessy

ps. i'm not native english, so if you didn't understand something email 
me, I'll try to correct myself

























More information about the Digikam-devel mailing list