[KPhotoAlbum] Importing and Exporting tags
eichin at gmail.com
Mon Jun 19 05:14:51 CEST 2006
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
> 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
_Mark_ <eichin at thok.org> <eichin at gmail.com>
More information about the KPhotoAlbum