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

[Marcel Wiesweg]

> 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.

Some time ago I have collected some proposals:
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion
Currently we are working on storing more image fields in the db, which still 
needs discussion on this list in the next days.
The multiple collection paths feature is also in the working.

>
> 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.

It's a historic feature of digikam that Albums represent file system 
locations. I have found that there is no sufficient benefit of removing and 
replacing this system, it is simple and easy. "Organize files" features dont 
work with this of course.
To have images in multiple albums: use Tags ;-)

>
> 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,...)

I agree that tags are the right choice for this.

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

Be aware that this quickly becomes complex!

For database storage, it would be better to break it down to one-to-one 
relations for derived images, tags for grouping, a visibility flag per image 
for visibility.
For creating a panorama D from A,B,C:
A -> D
B -> D
C -> D

I need to think a bit about grouping, no aswer to that yet.

>
> 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.

Yes certainly. All this UI is a lot of work though ;-)


>
> 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 is definitely need for such a feature, at least to provide 
never-edit-the-original which is required for a proper image manager IMO.

>
> 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.

We need to have a sane database schema, the rest is the task of the db we are 
using. And not our problem.

>
> 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.

You are very welcome if you want to help with digikam development.
Qt4 is really a great piece of software, and it's fun to use. The 
documentation is very good.
So first steps usually include:
- read some introductory docs on qt
- set up  a Qt4/KDE4 development environment - now that KDE4 beta1 is out, 
things are settling down and this is not so much of a problem any more
- try to orientate yourself in the digikam source
- try to fix a bug, scratch an itch, there is enough of this in digikam for 
KDE4
- visit the IRC channel, Gilles is usually there in the evening and I 
sometimes too.
- you can always find help on this list


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