[KPhotoAlbum] Importing and Exporting tags

[Mark Eichin]

I'm also in the "don't alter your negatives" camp.  (I'm also a
software engineer, so I'm perhaps more sensitive than most to the fact
that software has bugs.) Likewise, "If it isn't there, it can't break"
(George Mochet about car design) - a workflow that doesn't involve
writing to originals *can't* corrupt them, something you simply can't
say about one that does no matter how "well known" the algorithm is --
see http://www.tbray.org/ongoing/When/200x/2003/03/22/Binary on binary
search in java, for example -- and no matter how carefully you review
the code (and we're talking photo editing code, not life support
systems - noone's *going* to review them that closely.)

I would not be surprised to learn that the professionals you (Molteni)
cite only add those tags to copies of the images that get passed
further along; after all, storage is cheap in that space.  Perhaps a
compromise here is an export step, that takes (a tagged subset of) KPA
images with XML and produces standalone images with IPTC; that's even
easy to prototype *without* having to convince anybody of anything
(because you can do a decent job with the raw XML, the thok.org
kimdaba_album code, and http://cheeseshop.python.org/pypi/IPTCInfo/ if
you're not up to writing a kipi plugin...)

On 6/18/06, Robert L Krawitz <rlk at alum.mit.edu> wrote:
>    Date: Sun, 18 Jun 2006 19:56:32 +0200
>    From: Marco Molteni <marco.molteni at laposte.net>
>
>    Ashley J Gittins wrote:
>    > On Sunday 18 June 2006 20:35, Rui Malheiro wrote:
>    >> I think it would be great to have a standard XML format so that every image
>    >> browser/manager could pickup tags when displaying an image.
>    >
>    > Sounds like a job for IPCT tags (since I think that's what they
>    > were invented for) - does anyone know if there is a standardised
>    > method/format for placing them in separate files (like a
>    > image.jpg.ipct) rather than embedding the info into the image
>    > file itself? I am thinking of cases where the original format
>    > (raw files) may not support iptc or where people don't want their
>    > originals modified at any cost.
>
>    It *is* a job for IPTC.
>
>    And I really cannot understand why so many people don't want their
>    image files modified.
>
> I'll give you a few reasons why:
>
> 1) Paranoia (don't do anything to your negative!)
>
> 1a) The image may be stored on read-only media.
>
> 2) Some cameras are able to "sign" images, to prove that they haven't
> been manipulated after the shot was taken and to prove which camera
> took the shot.  Some of the higher end Canon cameras can do this;
> there's special software Canon makes available to verify the
> signature.  Admittedly I don't know whether adding IPCT tags breaks
> the signature or not, but police or others who need this kind of
> signature may well have policies that image files must not be modified
> in any way whatsoever (chain of custody and all that) but who still
> need to tag images to reflect which investigation they're related to.
>
>    Let's look at how professionals manage their workflow: they tag
>    their images with IPTC keywords, that are stored INSIDE their raw
>    files.
>
>    Why? Interoperability. As simple as that.
>
>    All the XML or binary databases or whatever can just be used as a
>    quick lookup cache, or maybe for file formats that do not support
>    IPTC tagging.
>
>    And please spare me the "I am afraid that storing the IPTC keywords
>    in the file might corrupt it". This is pure nonsense. There are
>    well-known algorithms to preserve a file and commit (in database
>    jargon) a new version only when it is safe to do so.
>
> Sorry, I'm not going to spare you this "nonsense".  I know that it's
> possible to do this, but it adds complexity and it's possible that the
> code has a bug in it.  Certainly it's possible that cp also has a bug,
> but a) it's much less likely and b) the fewer things modifying images
> the better.
>
> --
> Robert Krawitz                                     <rlk at alum.mit.edu>
>
> Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
>
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>
> _______________________________________________
> KPhotoAlbum mailing list
> KPhotoAlbum at kdab.net
> http://mail.kdab.net/mailman/listinfo/kphotoalbum
>
>


-- 
_Mark_ <eichin at thok.org> <eichin at gmail.com>