Re: Sidecar :(

[Larry Ewing <lewing novell com>]

This is nothing new, a jpeg can have embedded exif, jfif, iptc and xmp
metadata as well as side car xmp, they all overlap to some degree or
another.  Some of the formats store dates that are supposed to be
updated any time you change the data for precisely this reason, but
whenever you store metadata in more than one place you quickly run into
synchronization problems.

On Thu, 2006-05-25 at 22:48 +0800, Bengt Thuree wrote:
> On Thu, 2006-05-25 at 17:35 +0400, Alexandre Prokoudine wrote:
> > On 5/25/06, Bengt Thuree wrote:
> > 
> > > The thoughts we had was for raw files which do not have embedded tags,
> > > we should use a sidecar (same filename as photo, but ending
> > > with .jpg.xmp), if it exists.
> > >
> > > But since the raw file also have embedded data, I do not know which one
> > > to prioritise...
> > > Any suggestions most welcome...
> > 
> > I think it's pretty easy. Any additional data (which is exactly what
> > .jpg.xmp is) should be considered as newer and therefore have higher
> > priority.
> 
> Would be nice if that were true...
> For instance a sidecar can follow a file, and then along the way the
> user starts to embed his tags... but the sidecar is still there...
> 
> On the issue of priority...
> 
> Which priority should we have for the various "Description" fields that
> exists.
> 
> a) Adobe User Comment (F-Spot stores comment here)
> b) PhotoShop - Headline : PhotoShop - Caption
> c) Sidecar - title : Sidecar - description
> d) EXIF description (F-Spot clears this one on input)

If fairly certain what you are talking about here was just a bug.

> I prioritise them in the above order, and when one value is found, I use
> it and stops to look for more. I do not look for EXIF description at
> all.
> 

It would probably be better to read them all and try to reconcile them
by date where possible. You could build up the store in sections then
look for the key fields.

--Larry