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

Tibor Blenessy tiborb at matfyz.cz
Sun Aug 26 17:16:05 BST 2007


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

I will try to list some advantages, I see, from using albums tag vs. 
filesystem based albums.

- filesystem folder structure can be different from albums structure. I 
personally use folder name in the form
[album date in ISO format][album name]
Nowadays I'm therefore forced to include album date in album title, 
which is illogical. But having folder named like this is reasonable, 
because if I order items by name in file manager, folders get sorted by 
album date (I can't sort folders using filesystem folder date, because 
that can be different from album date). I also often have photos from 
the same event, but taken by different people. I like to have such 
foreign photos in entirely different folder from mine photos. But I 
would like to see their photos in the album of that event. This is 
impossible with filesystem based albums, with tag albums it is something 
very easy.

- using tags to have image in multiple albums is only partial solution, 
  because it brings inconsistency and it is not user friendly.

- another advantage is nesting albums - albums can be nested, but 
sometimes I don't want nesting in filesystem. I prefer filesystem photo 
structure to be relatively flat (it's easier to copy and find physical 
files), but I like rich albums structure.

- using tags for albums, brings bigger reuse of code and simpler code. 
db schema is simpler (you can drop albums table, things like album date 
can be property of tag). Managing albums and tags is more consistent 
(everything is tag). Album icon is the same thing as tag icon. Many 
parts of gui can be generalized - albums pane will be same thing as tags 
pane, only with different root tag).

- using tags for albums will bring collection nesting with no 
programming and changes in db

- I find "organize files" feature quite useful, sometimes I get photos 
from other people and I want to sort it into mine collection. This can 
include massive photos moves, sometimes during sorting I change my mind, 
and sort it other way. This can include massive IO operations. Using 
albums as tag, this will only mean changes in db. All the IO will be 
done at the end (with nice progress bar) when I press organize files button.

I accept that historic feature has also some value (to provide some 
continuation to users, who get used to it). I think that this albums 
tags can be implemented like "Virtual albums" or something like that, 
and provide albums both ways. Maybe it can be implemented like plugin - 
only as a new pane on the left side of ui. But I would like to have this 
album tags invisible in tags view (maybe provide some option to hide 
certain trees in tags). What do you think about implementing it this 
way?  But maybe it will be just too complicated to maintain both systems 
in long term.

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

Spliting it to one-to-one makes impossible for image to be visible in 
one group but not in another. I'm thinking if this is something needed, 
maybe not. Another disadvantage of spliting this is some loss of 
information - derivate images are no more kind of group.


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

that's ultimately true


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

Never edit the original could be implemented by grouping the original 
file with modifications and intelligent editor, which automatically 
create groups tags.

I think, that db is wrong place to place modifications of file. Maybe to 
include this modification to custom jpeg  header (as digikam makernote) 
or use (develop?) custom image format (something based on xml + jpeg 
blob, maybe svg is able to do this).

> 
>> 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've seen in db structure that for representing tag tree two column 
table with tag id and parent tag id is used. Have you considered using 
another three representation in db? There are ways to represented three 
in the way, that getting whole three path to the node is only one db 
select. Of course this means more complicated inserts and updates. But 
maybe it can significantly reduce number of queries. I have only article 
in czech about it, I can try to google something in english if you are 
interested.

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

Can you provide some links how to setup such environment? Info on 
digikam page is kde3 only :-( . Are you using kdevelop or some other ide?


Tibor Blenessy




More information about the Digikam-devel mailing list