User experience (or bugs, hopes and wishes)

[Birkir A. Barkarson]

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.

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

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?

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

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.

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)

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.

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

-----

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
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

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
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Pedro Venda-3]

On Monday 02 October 2006 12:18, Gilles Caulier wrote:

> On Monday 02 October 2006 12:58, Birkir A. Barkarson wrote:
> > 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.

It would be very nice to be able to do it the other way around:
Suppose my digikam.db file gets corrupted; My tagged photos are still tagged
but digikam doesn't index them. There isn't a way to rebuild the tag index
from the picture's metadata. Or is it and I just don't know where it is?

Cheers,
--

Pedro João Lopes Venda
email: pjvenda at pjvenda org
http://www.pjvenda.org

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Pedro Venda-3]

On Monday 02 October 2006 11:58, Birkir A. Barkarson wrote:
> 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.

Hello Birkir,

That was a nice review and it takes some dedication and effort to do what you
did (in my point of view).

I too have been searching for a good photo organizer app. Before using digikam
for everything, I used picasa, and don't get me wrong: picasa it is really
really good.

The issues that led me to abandon it were the following:
1. weak photo editor (cool but only useful for very small tweaks);
2. runs on Linux - good, but under wine (ARGH!!);
3. the windows client refused to use my data partition (ext3 - before you
label me as "totally dumb", know that I'm using an ext3 IFS native driver for
windows and it accesses the partition perfectly for all other applications);
4. slow development cycle, especially for the Linux port;
5. free but not opensource (yes, I'm a geek, but I sleep better like this);
6. runs under wine (did I already mention that?);

Digikam, on the other side, lacks some other features that would make it much
better than picasa:
1. a hand tool for progressively zooming photos (like picasa - sorry);
2. multiple tag search (this is possible but it's not that simple. something
like a direct text form where we'd input space separated tags would be much
nicer);
3. reindexing tags from picture metadata;
4. a slightly better album interface (a single click on a picture would simply
do the "View..." action achieved by the right click menu. Then some visible
Next and Previous (eventually with small thumbnails for visual guide) to
navigate... like picasa - sorry!);
5. searching per date (across all albums, like already discussed in this
list);
6. picture versioning or meta-changes. picture edits would be made in the
metadata database and would only be written on request (like picasa - sorry);

I'm trying to gather some time to research through the bugzilla to find
similar feature requests and put some on my own (those not already found).

Dont take the 6 improvement request as defects! Digikam is a great tool and
better by far than all others that I've tried before! There are only a
handfull of expensive commercial apps that top it.

Cheers,
--

Pedro João Lopes Venda
email: pjvenda at pjvenda org
http://www.pjvenda.org

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Robert Krawitz-2]

   Date: Mon, 02 Oct 2006 19:58:22 +0900
   From: "Birkir A. Barkarson" <[hidden email]>

   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.

Just to be fair, there are also disadvantages to storing metadata in
the images:

1) Any time the original image files are modified there's a risk of
   corrupting them.

2) It doesn't work if the images are physically stored on a read-only
   medium.

3) Updating many images is likely to be very slow (the image file will
   likely have to be resized to add or remove metadata, which will
   result in the entire file having to be rewritten).  For example, I
   tagged 3500 images totaling 25 GB from a recent vacation.

4) Some cameras can sign images to later verify that they have not
   been modified (e. g. for use as evidence in court).  Depending upon
   exactly what the signature covers, modifying the image file may
   destroy the signature.

5) It's much harder to implement undo across sessions or versioning if
   the metadata is stored in the images.

I actually rather like the database and "do not modify the original
image file" myself, and it's a big reason why I use KPhotoAlbum.

--
Robert Krawitz                                     <[hidden email]>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [hidden email]
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Monday 02 October 2006 13:45, Pedro Venda wrote:

> On Monday 02 October 2006 11:58, Birkir A. Barkarson wrote:
> > 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.
>
> Hello Birkir,
>
> That was a nice review and it takes some dedication and effort to do what
> you did (in my point of view).
>
> I too have been searching for a good photo organizer app. Before using
> digikam for everything, I used picasa, and don't get me wrong: picasa it is
> really really good.
>
> The issues that led me to abandon it were the following:
> 1. weak photo editor (cool but only useful for very small tweaks);
> 2. runs on Linux - good, but under wine (ARGH!!);
> 3. the windows client refused to use my data partition (ext3 - before you
> label me as "totally dumb", know that I'm using an ext3 IFS native driver
> for windows and it accesses the partition perfectly for all other
> applications); 4. slow development cycle, especially for the Linux port;
> 5. free but not opensource (yes, I'm a geek, but I sleep better like this);
> 6. runs under wine (did I already mention that?);
>
> Digikam, on the other side, lacks some other features that would make it
> much better than picasa:
> 1. a hand tool for progressively zooming photos (like picasa - sorry);

There is a file in B.K.O about.

> 2. multiple tag search (this is possible but it's not that simple.
> something like a direct text form where we'd input space separated tags
> would be much nicer);

idem.

> 3. reindexing tags from picture metadata;

What do you mean exactly ?

> 4. a slightly better album interface (a single click on a picture would
> simply do the "View..." action achieved by the right click menu. Then some
> visible Next and Previous (eventually with small thumbnails for visual
> guide) to navigate... like picasa - sorry!);

see B.K.O

> 5. searching per date (across all albums, like already discussed in this
> list);

already implemented...

> 6. picture versioning or meta-changes. picture edits would be made in the
> metadata database and would only be written on request (like picasa -
> sorry);

Planed later than 0.9.0

>
> I'm trying to gather some time to research through the bugzilla to find
> similar feature requests and put some on my own (those not already found).
>
> Dont take the 6 improvement request as defects! Digikam is a great tool and
> better by far than all others that I've tried before! There are only a
> handfull of expensive commercial apps that top it.

I would to said than if digiKam 0.9.0 do not include some new advanced
features like versionning, it's to prevent huge problems to the
implementation. There are a lots of changes between 0.8.x and 0.9.0, like 16
bits/color/pixel support or Color Management for example witch are require a
lot of changes in digikam core and DigikamImagePlugins. We are limited in
time and ressources (developers). We cannot do all at the same time.

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Monday 02 October 2006 13:58, Robert L Krawitz wrote:

>    Date: Mon, 02 Oct 2006 19:58:22 +0900
>    From: "Birkir A. Barkarson" <[hidden email]>
>
>    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.
>
> Just to be fair, there are also disadvantages to storing metadata in
> the images:
>
> 1) Any time the original image files are modified there's a risk of
>    corrupting them.
>
> 2) It doesn't work if the images are physically stored on a read-only
>    medium.
>
> 3) Updating many images is likely to be very slow (the image file will
>    likely have to be resized to add or remove metadata, which will
>    result in the entire file having to be rewritten).  For example, I
>    tagged 3500 images totaling 25 GB from a recent vacation.

This is not true about JPEG. Only JFIF, EXIF and IPTC section are rewritten.
The image data are untouched.

Later, i will implement in Exiv2 the same thing about PNG to write metadata on
the fly without decoding/encoding image data. About TIFF, Andreas (Exiv2
coordinator)  will implemente the TIFF-EP/RAW file metadata writting on the
fly using the same rules.

>
> 4) Some cameras can sign images to later verify that they have not
>    been modified (e. g. for use as evidence in court).  Depending upon
>    exactly what the signature covers, modifying the image file may
>    destroy the signature.

If sign is in metadata, well yes something can be lost. I suspect than
Makernotes are used for that. Since Exiv2 Makernotes support have been
improved with the last stable release, i think than this problem is now
limited.

If sign is a watermark embedded into image data, we don't change these data
during metatada update.

>
> 5) It's much harder to implement undo across sessions or versioning if
>    the metadata is stored in the images.
>
> I actually rather like the database and "do not modify the original
> image file" myself, and it's a big reason why I use KPhotoAlbum.

In digiKam you has the choise : database only, database+pictures. Look in
metadata setup tab.

Gilles Caulier


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Dnia poniedziałek, 2 października 2006 13:30, Pedro Venda napisał:
>
> It would be very nice to be able to do it the other way around:
> Suppose my digikam.db file gets corrupted; My tagged photos are still
> tagged but digikam doesn't index them. There isn't a way to rebuild the
> tag index from the picture's metadata. Or is it and I just don't know
> where it is?

It is planned. Maybe not exactly as rescue tool but idea is: store all
tag/hierarchy data in XMP tags nad (re)import photos into Digikam using
them.

m.

ps. XMP not IPTC to support non-ascii characters in tags.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

>> 3. reindexing tags from picture metadata;
>
> What do you mean exactly ?

Just now I had an case where I accidentally moved a few images from my
album to another folder.  When I moved them back the database didn't
pick up the tag data in the ITPC field.  In this case re-indexing the
tags from picture metadata is necessary.

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

Gilles Caulier wrote:

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

Strangely enough it seems that I have been able to save utf-8 strings in
ITPC via digikam (my locale is UTF8 based) and import it successfully to
my own Gallery server with the IPTC data intact (and properly inserted
into the appropriate field).

>>
>> Suggested improvements:
>>
>> B1. Encoding issues.

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

Ok, I would like to hear this, since I often use different languages for
tags this is quite important to me.

> Implemented like a new kipi-plugin by me. A screenshot :
>
> http://digikam3rdparty.free.fr/Screenshots/newkipigpssyncplugin.png

Very cool! I thought it was only for syncing.  I will take a look at this.

> 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

Thanks for the answers.  Looks like there is a lot to look forward to in
Digikam.  I will direct the points you mentioned to the bugzilla database.

Regards,

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Pedro Venda-3]

On Monday 02 October 2006 12:59, Gilles Caulier wrote:

> On Monday 02 October 2006 13:45, Pedro Venda wrote:
> > On Monday 02 October 2006 11:58, Birkir A. Barkarson wrote:
> > > 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.
> >
> > Hello Birkir,
> >
> > That was a nice review and it takes some dedication and effort to do what
> > you did (in my point of view).
> >
> > I too have been searching for a good photo organizer app. Before using
> > digikam for everything, I used picasa, and don't get me wrong: picasa it
> > is really really good.
> >
> > The issues that led me to abandon it were the following:
> > 1. weak photo editor (cool but only useful for very small tweaks);
> > 2. runs on Linux - good, but under wine (ARGH!!);
> > 3. the windows client refused to use my data partition (ext3 - before you
> > label me as "totally dumb", know that I'm using an ext3 IFS native driver
> > for windows and it accesses the partition perfectly for all other
> > applications); 4. slow development cycle, especially for the Linux port;
> > 5. free but not opensource (yes, I'm a geek, but I sleep better like
> > this); 6. runs under wine (did I already mention that?);
> >
> > Digikam, on the other side, lacks some other features that would make it
> > much better than picasa:
> > 1. a hand tool for progressively zooming photos (like picasa - sorry);
>
> There is a file in B.K.O about.

cool! I'll check it out :)

>
> > 2. multiple tag search (this is possible but it's not that simple.
> > something like a direct text form where we'd input space separated tags
> > would be much nicer);
>
> idem.

cool.

>
> > 3. reindexing tags from picture metadata;
>
> What do you mean exactly ?

We've discussed this before (just now). It's about rebuilding the tag indexing
from the pictures. Suppose I loose my digikam.db; I need to rebuild it from
the picture's metadata themselves.

> > 4. a slightly better album interface (a single click on a picture would
> > simply do the "View..." action achieved by the right click menu. Then
> > some visible Next and Previous (eventually with small thumbnails for
> > visual guide) to navigate... like picasa - sorry!);
>
> see B.K.O

cool!

>
> > 5. searching per date (across all albums, like already discussed in this
> > list);
>
> already implemented...

hmmm, I'm not sure you've understood what I meant.
If I do a date search, the result I get is organized by album and by date; not
only by date.
If in two consecutive albums I have these two pictures:
album 1:
2006-03-01.jpg
2006-09-01.jpg
album 2:
2006-01-01.jpg
2006-06-01.jpg

What I get from a date search is the following:
album 2:
2006-01-01.jpg
2006-06-01.jpg
album 1:
2006-03-01.jpg
2006-09-01.jpg

What I'd like to get is the following:
2006-01-01.jpg
2006-03-01.jpg
2006-06-01.jpg
2006-09-01.jpg

Two of the pictures ended up wrong in the search result due to being in
different albums.

>
> > 6. picture versioning or meta-changes. picture edits would be made in the
> > metadata database and would only be written on request (like picasa -
> > sorry);
>
> Planed later than 0.9.0

nice!

>
> > I'm trying to gather some time to research through the bugzilla to find
> > similar feature requests and put some on my own (those not already
> > found).
> >
> > Dont take the 6 improvement request as defects! Digikam is a great tool
> > and better by far than all others that I've tried before! There are only
> > a handfull of expensive commercial apps that top it.
>
> I would to said than if digiKam 0.9.0 do not include some new advanced
> features like versionning, it's to prevent huge problems to the
> implementation. There are a lots of changes between 0.8.x and 0.9.0, like
> 16 bits/color/pixel support or Color Management for example witch are
> require a lot of changes in digikam core and DigikamImagePlugins. We are
> limited in time and ressources (developers). We cannot do all at the same
> time.

Absolutely! I (and many others) really appreciate your dedication and effort
into developing this great software in the opensource model.
A big thank you!

Cheers,
--

Pedro João Lopes Venda
email: pjvenda at pjvenda org
http://www.pjvenda.org
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> 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

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Peter Neubauer-3]

+1

Great job guys!

/peter

On 10/2/06, Pedro Venda <[hidden email]> wrote:

> On Monday 02 October 2006 12:59, Gilles Caulier wrote:
> > On Monday 02 October 2006 13:45, Pedro Venda wrote:
> > > On Monday 02 October 2006 11:58, Birkir A. Barkarson wrote:
> > > > 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.
> > >
> > > Hello Birkir,
> > >
> > > That was a nice review and it takes some dedication and effort to do what
> > > you did (in my point of view).
> > >
> > > I too have been searching for a good photo organizer app. Before using
> > > digikam for everything, I used picasa, and don't get me wrong: picasa it
> > > is really really good.
> > >
> > > The issues that led me to abandon it were the following:
> > > 1. weak photo editor (cool but only useful for very small tweaks);
> > > 2. runs on Linux - good, but under wine (ARGH!!);
> > > 3. the windows client refused to use my data partition (ext3 - before you
> > > label me as "totally dumb", know that I'm using an ext3 IFS native driver
> > > for windows and it accesses the partition perfectly for all other
> > > applications); 4. slow development cycle, especially for the Linux port;
> > > 5. free but not opensource (yes, I'm a geek, but I sleep better like
> > > this); 6. runs under wine (did I already mention that?);
> > >
> > > Digikam, on the other side, lacks some other features that would make it
> > > much better than picasa:
> > > 1. a hand tool for progressively zooming photos (like picasa - sorry);
> >
> > There is a file in B.K.O about.
>
> cool! I'll check it out :)
>
> >
> > > 2. multiple tag search (this is possible but it's not that simple.
> > > something like a direct text form where we'd input space separated tags
> > > would be much nicer);
> >
> > idem.
>
> cool.
>
> >
> > > 3. reindexing tags from picture metadata;
> >
> > What do you mean exactly ?
>
> We've discussed this before (just now). It's about rebuilding the tag indexing
> from the pictures. Suppose I loose my digikam.db; I need to rebuild it from
> the picture's metadata themselves.
>
> > > 4. a slightly better album interface (a single click on a picture would
> > > simply do the "View..." action achieved by the right click menu. Then
> > > some visible Next and Previous (eventually with small thumbnails for
> > > visual guide) to navigate... like picasa - sorry!);
> >
> > see B.K.O
>
> cool!
>
> >
> > > 5. searching per date (across all albums, like already discussed in this
> > > list);
> >
> > already implemented...
>
> hmmm, I'm not sure you've understood what I meant.
> If I do a date search, the result I get is organized by album and by date; not
> only by date.
> If in two consecutive albums I have these two pictures:
> album 1:
> 2006-03-01.jpg
> 2006-09-01.jpg
> album 2:
> 2006-01-01.jpg
> 2006-06-01.jpg
>
> What I get from a date search is the following:
> album 2:
> 2006-01-01.jpg
> 2006-06-01.jpg
> album 1:
> 2006-03-01.jpg
> 2006-09-01.jpg
>
> What I'd like to get is the following:
> 2006-01-01.jpg
> 2006-03-01.jpg
> 2006-06-01.jpg
> 2006-09-01.jpg
>
> Two of the pictures ended up wrong in the search result due to being in
> different albums.
>
> >
> > > 6. picture versioning or meta-changes. picture edits would be made in the
> > > metadata database and would only be written on request (like picasa -
> > > sorry);
> >
> > Planed later than 0.9.0
>
> nice!
>
> >
> > > I'm trying to gather some time to research through the bugzilla to find
> > > similar feature requests and put some on my own (those not already
> > > found).
> > >
> > > Dont take the 6 improvement request as defects! Digikam is a great tool
> > > and better by far than all others that I've tried before! There are only
> > > a handfull of expensive commercial apps that top it.
> >
> > I would to said than if digiKam 0.9.0 do not include some new advanced
> > features like versionning, it's to prevent huge problems to the
> > implementation. There are a lots of changes between 0.8.x and 0.9.0, like
> > 16 bits/color/pixel support or Color Management for example witch are
> > require a lot of changes in digikam core and DigikamImagePlugins. We are
> > limited in time and ressources (developers). We cannot do all at the same
> > time.
>
> Absolutely! I (and many others) really appreciate your dedication and effort
> into developing this great software in the opensource model.
> A big thank you!
>
> Cheers,
> --
>
> Pedro João Lopes Venda
> email: pjvenda at pjvenda org
> http://www.pjvenda.org
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

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

Great.  The solution proposed sounds good.

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

Like Pedro noted it would be great if the same would be done with the
tag fields.

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

This does seem to be a most sensible approach.
Yes, I also assumed the EXIF Unicode should be UCS2.  I do recall that
there was a bug in exiv2 a while back that caused this tag to be
incorrect.  Although I haven't verified it, it is possible that I wrote
those tags with that bug in effect.  For now lets assume it to be so.
A couple of issues remain.  The Exif user tag is not overwritten even if
I change the comment.   I am still noting that the IPTC sidebar does not
display correctly latin 1 characters (in the toolbar or if the info is
copied to the clipboard, umlaut characters and so forth come out as
question marks).

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

Cool. I can do it from the Tag Filters bar.  Brilliant (^^)b

> http://bugs.kde.org/show_bug.cgi?id=125387
>
> This requires a lot of thought.

Yes, this is a complex issue.  For me just doing the edits, saving them
under a different name and having them stack under the same thumbnail
would be good enough.

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

Gilles noted a kipi plugin for this.  I looked around.  Where can I
get/build it from?

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

That would be swell, so multiple check in a hierarchy would save
multiple tags.

> Thanks for your observations, your feedback is appreciated!

Most certainly welcome. I appreciate your efforts.

Regards,

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Dnia poniedziałek, 2 października 2006 16:02, Pedro Venda napisał:
>
> hmmm, I'm not sure you've understood what I meant.
> If I do a date search, the result I get is organized by album and by
> date; not only by date.

AFAIK on TODO list, post 0.9 because changes into code are bigger than
expected.

m.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Monday 02 October 2006 17:08, Birkir A. Barkarson wrote:
> Gilles noted a kipi plugin for this.  I looked around.  Where can I
> get/build it from?

The plugin is available from KDE svn repository, in trunk.

http://websvn.kde.org/trunk/extragear/libs/kipi-plugins/gpssync/

It will be avaialble to the next kipi-plugin release.

The plugin is ready to use. It can be certainly improved. Feedback welcome.

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

  > It will be avaialble to the next kipi-plugin release.
>
> The plugin is ready to use. It can be certainly improved. Feedback welcome.

Got this working.  Just too cool!

I did notice that gpssync and indeed digikam as well does not recognize
that extension of a file as that after the last period but after the first.
Thus I can not GPS edit an "image.edit.jpg" or rename it from within
digikam.  I suspect this bug is already in bugzilla I just figured I'd
mention it in passing.

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Tuesday 03 October 2006 16:05, Birkir A. Barkarson wrote:

>   > It will be avaialble to the next kipi-plugin release.
> >
> > The plugin is ready to use. It can be certainly improved. Feedback
> > welcome.
>
> Got this working.  Just too cool!
>
> I did notice that gpssync and indeed digikam as well does not recognize
> that extension of a file as that after the last period but after the first.
> Thus I can not GPS edit an "image.edit.jpg" or rename it from within
> digikam.  I suspect this bug is already in bugzilla I just figured I'd
> mention it in passing.
>
> BAB

Hum, i think this problem have been fixed in current implementation.

Take a look in the list of B.K.O files fixed :

http://websvn.kde.org/trunk/extragear/graphics/digikam/NEWS?rev=591949&view=auto

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

  > Hum, i think this problem have been fixed in current implementation.
>
> Take a look in the list of B.K.O files fixed :
>
> http://websvn.kde.org/trunk/extragear/graphics/digikam/NEWS?rev=591949&view=auto

Hmm... I am using 0.9.beta2.
Can't see it in the fixlist for beta3 but I will upgrade soon and file a
bug report if it is still there.

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users