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

[Gilles Caulier]

2007/8/26, Tibor Blenessy <tiborb at matfyz.cz>:
>
> >> 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.


No. Later we can add a search UI to scan modification over image versions...
This is a very powerfull features. Imagine a query like this : "I want to
found all photo where i have apply Red Eyes Correction" tool...


Maybe to
> include this modification to custom jpeg  header (as digikam makernote)


No, a JPEG hearder can break interoperability. It's dangerous. And JPEG is
not the only one format used in photograph world. Do you know RAW ? Pro
photogrpah use it. This format is Read only...

Makernote (Exif in general) is dedicaced to store camera settings used to
take the picture. Better place is to use IPTC or, XMP I work currently on
XMP support.

Unforget than with JPEG, Exif or IPTC or XMP are stored in a JPEG section
which is limited to 64Kb.

With DB, we don't have limitation.


or use (develop?) custom image format (something based on xml + jpeg
> blob, maybe svg is able to do this).


I'm not agree to use sidebar file. We have already aDB dedicaced for that.
Using a sidebar will reduce the capability, especially for searching. A
metadata is a metadata. It must be stored in file when it's possible. This
is true with JPEG, TIFF and PNG.

Of course, and XML (XMP in fact with pictures) must be add in the future, to
improve interroperability.

RAW file is another problem. With Exiv2 library project, we will try to give
RAW writting support with all RAW files based on TIFF file format (CR2, MRW,
NEF, etc.) But it's not yet done...


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


I'm use Kdevelop every time. There is a project file in svn.

Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070826/37383d62/attachment.html>