[Digikam-users] User experience (or bugs, hopes and wishes)

[Gilles Caulier]

On Monday 02 October 2006 12:58, Birkir A. Barkarson wrote:
> Hello everyone,
>
> This is my first posting to the mailing list. It is mainly intended for
> the Digikam mailing list as that is what I am currently using but I
> cross post this to the KPhotoAlbum list as well since I like their
> interface and it is my hope that they will adopt similar way to store
> metadata in-tag like digikam does.  My apologies if this is offends or
> is not welcomed.
>
> I would like to give you a short account of my experiences with Digikam
> and explain what I look for in a photo management tool.  Then I will
> note a few things that I think could be improved along with some hopes
> for future features.  I hope developers will take a note and I ask other
> users for comment and critique.
>
>
> I have been searching for a long while for a tool that I can use to
> adequately manage my ever expanding collection of photos.  My number one
> and absolute requirement is that I can apply meta data to the photos
> such as keywords or tags, title and description along with location and
> or other pertinent information.  I refused to use applications that did
> this by storing the data in a database since that would make my data
> very unportable and would most likely result in lot of annoying
> copy/paste work when I want to duplicate metadata across applications.
> Second I wanted free software.  Every once and a while I would search
> and see what developments had taken place. 

digikam store some metadata in a database to speedup keywords search ! Try to 
do the same thing only using metadata from pictures : you can take a coffee.

All pictures management software witch provide a search feature use this 
technic.

So, since we using Exiv2 library, all metadata hosted by the database are 
stored into pictures metadata.

>
> When I was a frustrated Windows user I used a program called Exifer, it
> did the job but was closed sourced freeware, unmaintained, and had some
> annoying bugs.  So I didn't miss it much when I moved to GNU/Linux
> although I did need a replacement.
> After a long search I came across the exiv2 tool/library and used that
> for a while. Being a command line only program this proved somewhat
> inefficient and tiring but was the best I had. I looked at programs such
> as F-Spot and KPhotoAlbum.  Both have many good qualities but I avoid
> programs that move images to their own structures or store data
> internally.  I found a few proprietary applications that seemed to do
> the work but since I am now all Linux those were out of the picture.
> I have to admit that I have been suprised at the apparent lack of demand
> for a program with these kind of features.  My main point in wanting
> this features is that I want to keep my metadata centralized so that I
> can apply it to my photos before viewing them or uploading them to
> services such as Flickr or web Gallery.
>
> Then I came across Digikam and despite the innocuous sounding name I
> found that your latest beta version having incorporated the exiv2
> library came closest to what I have been looking for.  I downloaded the
> source and hunted down every dependency to compile the program.  When
> done I found something eminently useful and to the developers of Digikam
> I express my heartfelt gratitude for their efforts and insight.
>
> In using the program I have come across several things that I want to
> share with the users and developers of Digikam.
>
> -----
>
> First the apparent bugs:
>
> A1.
> Having enabled automatic insertion of byline, source and related
> information in the settings I find that in some cases it isn't applied.
>   Mostly it seems to be when tags are applied on multiple images at the
> same time (eg. removing and re-applying a tag to a single images seems
> to cause the IPTC data to be correctly written).
>

Problem already reported into KDE bugzilla. Will be fixed to 0.9.0 final.

> A2.
> When loading a few images I had previously annotated directly with exiv2
> the text comes out scrambled even though it exiv2 outputs it correctly
> when I use it from the command line.  This affects only the EXIF fields
> since the same text in the IPTC tags is displayed correctly.  Is the
> exiv2 library not used to read all metadata?

Not sure to understand properly. Please give us a screensot...

>
> A3.
> On occasion when replacing comments only the IPTC fields are replaced
> not the corresponding EXIF fields (eg. an image with a text scrambled as
> per 2 displays the scrambled text in the comment/tag section. I copy the
> text from the IPTC field and paste it into the comment section, it then
> appears correctly in the comment section however the EXIF field still
> contains the scrambled text).

idem than A1 point.

>
> A4.
> Encoding issues in text can cause corruption of text when tags are
> updated (more on this below).

IPTC only support prinatble ascii characters. This way will be fixed when we 
use XMP metadata (when Exiv2 will support in the future)

>
>
> Suggested improvements:
>
> B1. Encoding issues.
>
> It would probably be best to nail this down somehow.
> As far as I can tell the only way to support multiple character sets is
> to use unicode wherever possible.  I would recommend that Digikam refuse
> to use local character sets as this invites further complications and
> incompatibility across the board.  From what I can tell of the Exif
> standard Unicode is supported in the User Comment section but carries a
> special marker to identify the encoding.  The standard doesn't specify
> what kind of Unicode encoding (UTF-16 BE/LE, UTF8 or whatever) but I get
> the feeling its UCS2.  Anyway it might be a good idea to always use this
> marker when writing to the EXIF field as it would be the most correct
> and foolproof way.  For other fields such as title/headline and IPTC
> data UTF-8 should be used wherever possible provided the high order bit
> can be other than zero (non 7bit ascii). If not 7bit ascii will of
> course have to be enforced.  Text on platforms using other local
> encodings would have to be encoded/decoded for displaying purposes.

Marcel, you have fixed encoding issue with comments tags. i let's you explain 
your investiguations here.

>
> B2. Tagging
>
> When tagging multiple photos it can be real time consuming to use the
> right-click menu.  So much that I tend to use the sidebar single
> comment/tag section even for multiple images (up to five or so,
> depending on tag number), pressing space or pg down to advance to the
> next one.  The most efficient way I can think of is to allow multiple
> selection and then drag and drop. Either drag the images to a tag or
> vice versa.  This would really speed up tagging.
> Batch editing dates would also come in handy (I often receive photos
> with an incorrect year or date set, really annoying when viewing photos
> by date)

Planed to the future.

>
> B3. Title support.
>
> Both the EXIF and IPTC fields support a "title" field.  Many
> viewers and online services, such as Flickr make a distinction between
> title and comment.  The iTag program home page has table noting some of
> these [1].  Personally I like to put a title on most photos while only
> commenting on specific things.  A title is generally shorter and
> therefore more appropriate for displaying with the thumbnails than the
> comment field.  In a manner similar to the comment field I would like to
> be able to set and view the title/headline tags.  Batch setting the
> title on a few photos would also come in handy (for many similar photos
> which often appear in a row).

idem than B2. A full IPTC editor is planed later 0.9.0

>
> B4. Versioning
>
> When viewing photos it is often superfluous to see the same image more
> often than once.  This is particularly so when you have JPG and CR2
> versions of the same photo in a directory since it take a good while to
> load the thumbnail for CR2 photos. Same goes for resized photos and
> somewhat cropped/modified ones.  I know F-spot has implements this
> although I am not sure how.  One way I can think of is to stack together
> photos which have the same file name up to the first dot (this way
> IMG001.jpg, IMG001.cr2 and IMG001.resized.jpg, IMG001.ver2.jpg etc.
> would be stacked together).  I am sure there are better ways although
> this one seems nice and simple.  An on/off option would of course be
> necessary.

Already reported to KDE bugzilla. 

>
> B5. Geotagging
>
> I would love to be able to geotag inside digikam (using Goggle Map API
> or something).  I saw that you have a plugin to correlate GPS data with
> photo dates and that looks like something I want to take advantage of
> but sometime you need to set or adjust the data manually so this ability
> would be a real plus.

Implemented like a new kipi-plugin by me. A screenshot :

http://digikam3rdparty.free.fr/Screenshots/newkipigpssyncplugin.png


>
> Other pet-peeves:
>
> C1. Tag hierarchy
>
> I am wondering if there is a better way to store the hierarchy
> information for tags other than slash seperated. When importing to
> Flickr this comes out as Top Group/Sub Group/Tag name, while I would
> prefer for it to come out as either three tags (Top Group, Sub Group,
> Tag name) or just the last Tag name.  Any good ideas on this? Having a
> space before and after the slash might accomplish the former but I am
> not sure.

There is a lot of report in KDE bugzilla to improve tags view. Please post 
your comments at the right place.

>
> C2. Separate name/people tagging.
>
> While tags are nicely placed in the keyword fields, peoples names might
> be best kept separate. KPhotoAlbum seems to emphasize this feature, and
> if you would consider such a feature as well I would suggest the
> objectname IPTC field for storing such information.  Of course this can
> be implemented with tags so it might be considered superfluous but when
> I upload to Flick I want the keywords there for tags but don't want
> peoples name to appear as such since it is mostly useless and
> potentially harmful (hence a lot of work removing them).

Later 0.9.0 when full IPTC editor will be implemented.

>
> -----
>
> To those who made it all the way down here, thanks for reading.  Hope
> you have comments to make. In my mind an application with these features
> should be a real killer-app when it comes to applying metadata to images
> especially with people who use services like Flickr.
> I look forward to seeing Digikam go from strength to strength.

Thanks for your comments. I recommend you to post all these comments to KDE 
bugzilla (B.K.O). Look the links at digikam project page :

http://www.digikam.org/?q=contact

It's very important to use B.K.O instead ML, because it very difficult to 
manage wishes and report by ML. ML message live is short. With B.K.O, the 
history is preserved.

Gilles Caulier