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

Marcel Wiesweg marcel.wiesweg at gmx.de
Mon Oct 2 15:17:16 BST 2006


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

http://bugs.kde.org/show_bug.cgi?id=127583
(Comment #5)

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

See below (B1)

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

The "Comments" field of the "Comments/Tags" sidebar is primarily read from DB. 
Only on import the value is read from the metadata, and the value is written 
back to metadata when you change it, if it is enabled in the setup.

>
> A4.
> Encoding issues in text can cause corruption of text when tags are
> updated (more on this below).
>
>
> 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.

As Gilles pointed out, the relevant code was written by me ;-)

First, reading the comment. We need one comment, we have three fields. Order 
is
1)JFIF comments section
2)EXIF UserComment
3)IPTC Caption

So you get 3 only if 1+2 are empty.

IPTC is converted from Latin1, that's easy.
EXIF user comment _may_ provide charset info, that's handled by Exiv2, so if 
it is marked as Unicode (UCS2 apparently, though you're right nothing in the 
standard), Jis or ASCII, we take it.
If not, we use the same as we do per default for the JFIF comments: Apply 
basic autodetection.
First, we use a KDE function to test if it is UTF8 (only KDE>=3.2). If not, we 
use QTextCodec to look if it might be Latin1 or local encoding, and take the 
best match.

Writing the comment is much more easy. UTF8 for JFIF, if possible ASCII for 
EXIF, otherwise UCS2, of course Latin1 for IPTC.

I have tested this with exotic characters and all seems to work. Maybe the 
UCS2 writing is broken? What do I need to do to reproduce the scrambled EXIF 
encoding?


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

The sidebar is currently not capable of multiple selection editing, this 
feature requires a bit of careful thought but is certainly planned, IIRC 
later 0.9.

Drag and drop works!
It's currently _the_ way to do fast tagging of many pictures.

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

http://bugs.kde.org/show_bug.cgi?id=125387

This requires a lot of thought.

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

This could be achieved by providing a setup option to exclude a hierarchy of 
tags from being written to IPTC.


Thanks for your observations, your feedback is appreciated!

Marcel

>
> -----
>
> 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.
>
>
>
> Sincerely,
>
> BAB
>
>
> [1] http://www.itagsoftware.awswa.com/compat.php



More information about the Digikam-users mailing list