2008/10/7 Vladimir Nadvornik <[EMAIL PROTECTED]>: > This is my proposal for metadata handling. > > Requirements: > - metadata go with the image, preferably in the image > - no data loss, no legacy data loss > - automatically migrate legacy data to XMP > - XMP sidecar can override exif values stored in unwritable raw file > - cooperation with metadata editors that don't support XMP > - preserve originals > - handle photos on read-only filesystems reasonably well
Hello, just giving my point of view on this matter. I think modifying picture metadata is a tricky topic, and one has to decide what geekie will be: - a picture viewer - a picture editor ? - a picture metadata editor ? (eg: fix the date in the picture exif) - a picture collection manager (with sorting/classification capabilities...) in the first case, all operation should be read only (or explicitly warn the user). The second and the third are not that different : I would tend to consider a change of the exif date or orientation as a change in the picture. At last, I would expect the following features from a picture manager : - let people organize their files as they want - a clear policy regarding picture modification: "never modify a picture without asking", "never modify a picture at all", "never modify without creating a new revision" - real picture versioning () And some - sometimes the media is read-only - it creates new versions of the picture (duplicates between on-cd and on disk version cannot be found through simple binary data comparison then) - general-metadata-aware-desktop may some day be available (see freedesktop xesam) and replace in picture metadata I would enjoy ... > reading algorithm: > 1. read exif, iptc and XMP from the file > 2. now we have "unprocessed" data -> show them in "advanced exif" > 3. for files with empty XMP look for sidecar, use it if > Xmp.crs.rawfilename matches > 4. sync XMP with exif and Iptc using Exiv2 convert API > - detect which of Exif and Xmp.exif is newer and copy the data > in appropriate direction > - detect which of Iptc and Xmp is newer and copy the data > in appropriate direction > 5. read internal database (text files for now, real database later) and > add tags that are missing (data from database should not overwrite > existing tags from file) > 6. now we have "processed" data - use them in everything except > "advanced exif" > 7. grouped files handling (raw + jpeg): description tags (keywords, > comments, whole iptc) are merged from all image files in the group > (a group contains the same image in various formats, descriptions > should be the same), technical tags (exif) are handled separately > for each file > > > writing algorithm: > - geeqie updates "processed" XMP tags > - description tags (keywords, comments) are written to all image files > in a group (raw + jpeg) > - technical tags (exif orientation) is written to each file separately > - writing can possibly copy files, thus it should use write-back cache > and run in backround > > 1. update exif and iptc from XMP > (for example Exif.Image.Orientation is updated from Xmp.exif.orientation) > 2. try to write exif, iptc and XMP to the file if it supported by exiv2 > - there should be a "backup" option - if it is enabled and no backup file > exists yet, the original is reamed to *.backup and the metadata are > written to newly created copy of the file - that preserves original files > and helps with handling of read-only files in rw dirs > - another option would make sense for writting legacy iptc block - > possibilities are: > write always, only update existing, delete iptc if exists > 3. try to write XMP sidecar for raw file if step 2 was not successful > 4. write XMP metadata to internal database (text files for now) > > > internal database: > Geeqie now uses text files for storing keywords and comments. This format > should be used only for compatibility and when the XMP via Exiv2 is not > available. I agree with Maybe we could drop write support completely. > Recommended format for internal database should be XMP, stored either in > standalone files or in a "real" database with indexes for faster searching. > > > The required functionality is available with Exiv2 0.17 and newer. With older > versions the metadata will be written only to internal database (text files). > > > See also: > http://exiv2.org/metadata.html > http://exiv2.org/doc/classExiv2_1_1Converter.html > > > Vladimir > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geeqie-devel mailing list > Geeqie-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geeqie-devel > -- Sébastien Barthélemy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
