[KimDaBa] new feature: IPTC keywords

[Dotan Cohen]

On 10/23/05, Robert L Krawitz <rlk at alum.mit.edu> wrote:
>    Date: Sun, 23 Oct 2005 18:23:47 +0200
>    From: Dotan Cohen <dotancohen at gmail.com>
>
>    On 10/18/05, Marco Molteni <molter at tin.it> wrote:
>
>    > 2) keywords should stay in the image files themselves (and
>    > eventually cached in a database or the equivalent index.xml
>    > file), because IPTC is a standard and you get automatic
>    > interoperability by storing the keywords in the files.
>
>    I see that I got to this thread a little late. I second the opinion
>    that there is a definite need for IPTC support in a product such as
>    KimDaBa. My home system has a windows box KVM'ed in only because I
>    need to run BrilliantPhoto in Windows. I have found no comparable
>    program for Linux, with the exception of KimDaBa, which
>    unfortunatly does not support the IPTC data in my photos. And I
>    can't get BrilliantPhoto to run in wine, crossover, or anything
>    else that I tried.
>
>    If KimDaBa were to support the IPTC data, then I could pilot that
>    winbox right out my fourth floor window! As BrilliantPhoto was an
>    $18 investment, I would be willing to make a similar investment in
>    KimDaBa for similar performance. Just something for an OpenSource
>    programer in need of OpenSource funds to consider.
>
> Do the keywords actually need to be kept in the master image files at
> all times, or can they be added separately (during export, for
> example)?
>
> I can see good points both ways.  I think it's an excellent design
> point to have Kimdaba never modify the master files (it's possible to
> be comfortable that no matter what you do you won't mess up the images
> -- plugins excepted), but it also makes sense to be able to store
> keywords in images, particularly if there's a standard for it.
>
> If you added keywords in only during export, you could preserve both
> properties, although obviously at the cost of extra disk space.
> Adding them into the master files has to be programmed very carefully;
> it's very easy to lose data if you're not extremely careful.  There
> are lots of corner cases (computer crashes at exactly the wrong
> moment, for example), and even something as mundane as different
> filesystems may be different in this regard.
>
> BTW, I'm not convinced that a plugin is the right way to do this;
> adding a keyword would change the MD5 hash, which is something the
> core application needs to know about.  I'm also dubious about an
> architecture that specifies that it won't change the file, but it's
> perfectly OK for a plugin to; users shouldn't really have to know
> about the difference between a plugin and the core application.
>

I personally wouldn't mind if KimDaBa touched this part of the photo.
It supposedly does not affect the image, or the quality of the image
(like rotating does). Maybe a big fat warning popup when IPTC data is
first entered would be in order. Or even an import feature whereby
imported photos CAN be touched. That would lead the way to other
plugins that are nessaccary, such as red-eye reduction and brightness/
contrast control. As an end user, I expect these basic features to be
in the image organizing software. Although, anything else should be
left to the Gimp or Photoshop.

Dotan
http://technology-sleuth.com/question/what_is_a_firewall.html