Hi Bengt, I'm very keen on storing the metadata in the EXIF actually. As I said, support for this seems to be in the Gthumb cvs already. Some random thoughts and concerns though: * What are risks involved in changing exif headers? I guess any changes to files risk corruption. So moving to storing metadata inside peoples images by default increases the risk of data-loss considerably. These routines should be carefully written. * Changes to EXIF headers will change the file hash we've been discussing (we could exploit the md5 weakness here actually, depending where the EXIF is stored, heh) * F-spot (and gthumb) should read EXIF on import and update EXIF when changed. * Could use file modification timestamp as an indication that the EXIF header has been changed outside of f-spot. Some benchmarks I just did show a file stat of over 11,000 file in less than a second from cold cache (?!). Even with some database look-ups (for last known modified) this shouldn't be a big deal on start-up. * We need to all agree what fields to store this data in to make it work cross-application. Does the EXIF standard cover this stuff? What are other apps using (if any)? * What happens when somebody deletes a keyword/tag from an image in one app and then loads another app? Does the new app delete any missing tags from it's own database? I guess we can decide on some smart defaults. * Should we think about assigning EXIF unique ids on initial import (assuming it doesn't already have on). There is a unique ID field as part of the EXIF standard. I've cc'ed in the author of Gthumb, Paolo Bacchilega. Hopefully he can tell us his views. Unfortunately I'm away on holiday from tomorrow until next Sunday, so won't be able to respond to anything until then. Bye, John. On Fri, 2005-08-26 at 01:03 +0900, Bengt Thuree wrote: > Hi John > > I have not been using Gthumb much, but it do make good sence what you say. > 1) If there is a .comment directory import those Tags to F-Spot. > 2) When exporting the tags (not done yet), there should be an option to > create Gthumb's .comment directory. > 3) F-Spot should (I think) have a way to syncronize between F-Spot and the > picture it self (either direction). And here again it should be possible > to sync then with .comment as well. > > But I strongly think that the original tags should reside in the picture > itself. I do not belive in having meta tags anywhere else than in the > picture. I do know that if I do send any pictures to someone else I would > not expect them to be able to understand whatever format we store it in, > unless it is in the picture according to EXIF/XMP/IPTC standard. > > Also, all picture programs will be able to handle the embedded tags, but > not to much of any external tags. > > But that should not stop us from allowing to export to another format :) > > Just my small comments. > > By the way, I managed to be able to recognize the IPTC tags in the photos, > by using another GPL EXIF/IPTC tag library. But did not manage to create > the tags in F-Spot. Also, this library do not have write functions, only > read is possible. > > /Bengt > > On Fr, 2005-08-26, 12:39 am, John Leach skrev: > > Hi all, > > > > I've been using Gthumb[1] for my photo management for a few years now, > > so have amassed much metadata in it's own format. > > > > Gthumb stores metadata in compressed xml files in sub-directories named > > ".comments/" (a sub-directory of the images own directory). It's rather > > convenient as I can move directories around using other file management > > tools and not lose the metadata. > > > > I've been thinking about how F-spot could achieve this and I came to the > > conclusion that it would be nice if it supported the gthumb format. > > > > On import, f-spot could read any gthumb metadata it finds and whenever > > metadata is changed in f-spot it could export it back out in the gthumb > > format. This would obviously be in addition to the sqlite database, > > which allows for speedy searches (which Gthumb currently lacks). > > > > The problem arises when metadata is changed in Gthumb *after* import > > into F-spot. Perhaps F-spot could keep a record of the gthumb metadata > > modification times, and reimport? Should this happen every time f-spot > > is first run? (in addition to inotify events of course :) or manually > > done? How should tag lists be merged? > > > > Should F-spot do this automatically? or should it be an option? Is it > > outside the scope of f-spot? The Gthumb format, whilst not a standard > > of any kind, it is nice and simple. Support for this metadata could be > > added to Nautilus too. > > > > One problem is that if the photo is moved out of the directory manually, > > the metadata is still lost. Could we start to save metadata in exif > > headers? Is this bad behaviour for an app? Gthumb seems to have code > > in cvs to start doing this (well, as I understand the code anyway). I > > can't decide whether I'd be happy for my photo management tool to be > > modifying my photos; even just the headers. > > > > Anyway, in the mean time I've hacked up a nasty patch for F-spot to read > > Gthumb metadata on import. Any new tags are created with the generic > > "other" icon. > > > > I had a bit of trouble creating tags from within the FileImportBackend > > Step routine, so I made some previously private variables public > > elsewhere. This is most likely bad form but it is currently just a > > hack. If anything, it might hilite new places that new tag creation > > functions need to be available (or it might just hilite that I couldn't > > figure out how to do it properly). > > > > Also, I just manually added my Gthumb.cs file to Makefile, which I > > believe is autogenerated. Ick. > > > > Perhaps this could lead to a metadata import class, which could be used > > to support various other metadata formats on import? > > > > There are lots of problems with this patch as you'll notice. Lot's for > > me to think about, and hopefully some people might be able to help :) > > > > Thanks, > > > > > > John. > > > > > > [1] http://gthumb.sourceforge.net/ > > _______________________________________________ > > F-spot-list mailing list > > F-spot-list gnome org > > http://mail.gnome.org/mailman/listinfo/f-spot-list > > > >
Attachment:
signature.asc
Description: This is a digitally signed message part