Dne úterý 07 říjen 2008 Klaus Ethgen napsal(a): > Hi, > > Am Di den 7. Okt 2008 um 0:04 schrieb Vladimir Nadvornik: > > Requirements: > > - metadata go with the image, preferably in the image > > If it is configurable then it is OK. The image might be on CD-ROM where > it is not writeable or one do not want to get the original image altered.
I think that the most clean solution is to rely on file permissions here. > > > - automatically migrate legacy data to XMP > > Would also be a issue for a configuration option. I do not like if > software automatically do such think. A dialogue like the one for > thumbnail maintenance would be nice. Adding XMP should not have any negative effects as long as the file is writable. > > > - preserve originals > > That is one of the most important point I think. But there should be a > option/dialogue to include that information direct in the image. > Writing to jpg and dng files should be safe, other raw files will have a read-retie sidecar. Paranoid people can also enable creating backup files. > > - handle photos on read-only filesystems reasonably well > > Ah, yes. :-) > > > reading algorithm: > > 3. for files with empty XMP look for sidecar, use it if > > Xmp.crs.rawfilename matches > > Why don't save/read this data from .metadata/...? I like that way to > have a separate sub directory for the meta data. This has 2 problems: - it is hard to maintain consistency if the image files are moved around - it is not a standard so other programs have no chance to find it Thus it should be used only as a fallback. > > > 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 > > There should be a way to change that for one image only if one of the > data timestamp is corrupt. Maybe one can disable the reading of one > source by options in the context menu. This should be possible but I still think that the automatic method will work correctly with all real-life cases. > > > 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 > > That is a interesting idea. > > > 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 > > Again, there should be a way to NOT alter the original image. Yes, it is the backup file. > > > 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. Maybe we could drop write support completely. > > That would be OK if the old data (from a archive CD) is still readable. > > Maybe there is a way to configure the standard way and exceptions for > special paths. > 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
