Re: critical missing feature: embedding tags in EXIF/IPTC


Am Sonntag, den 29.08.2010, 16:16 -0400 schrieb e.m.fields:
> IPTC support:
> So, I'm understanding from your email that while not supporting IPTC,
> F-Spot is storing to XMP format which should make it readable by newer
> photo-editing applications, is this correct? 

Currently, there are just the tags (dc:subject), comment, date-time and
the rating of a photo written to file. Every newer (and older) photo
application should understand XMP.

> Tagging in F-spot:
> I've examined f-spot-tagged images in an image metadata viewer (Geeqie
> Image Viewer), and after much digging found the tags under
> XMP.dc.subject. 
> So this XMP tagging location was not recognized by a few other
> applications - (for example, a big one is the ubiquitous iPhoto.)  I
> do gather that XMP is the upcoming new standard metadata format, and
> that IPTC may be on its way out. Is it reasonably safe to assume that
> future / modern image-editing and image-management applications will
> be able to read the XMP keyword tags as F-Spot is currently storing
> them?

Every reasonable photo application (today and also some years ago)
should be able to read XMP data. What field is iPhoto using?
I don't consider XMP as an upcoming new standard, IMHO it's just the
(de-facto) standard.

> Three things I would humbly request for consideration with
> edits/renaming/versioning:
>      1. Choice of versioning name with opening for editing in GIMP (or
>         whatever):  Right now, the naming system is pretty bad, though
>         a functional solution of sorts.  I would like to be able to
>         choose an image-naming format, or at least choose version
>         filename at time of save. 
>      2. Saving edits in XCF format:  As Rolf from the popular Meet the
>         GIMP podcast has requested, it would be a very large step
>         towards integration with GIMP if user had the option to save
>         edits versions in the GIMP native .xcf format. For someone who
>         uses GIMP to create multiple edits to images which need to be
>         reversible/modifiable, linking XCF files to their original
>         image and JPEG exports is very important.
>      3. Location of Originals folder:  It is a bit messy from a
>         file-structure standpoint having originals mixed in with edits
>         of various names, and some linked via F-Spot database and some
>         not, undeterminable from file-structure.  A very clean
>         solution was suggested on this same subject on the KDE DigiKam
>         forums, which is the one I use for my own organization /
>         versions system: Optional creation of an Originals folder for
>         the base images, with edits / versions stored in another
>         (configurable) location.  This way if need be the originals
>         can easily be retrieved and archived if necessary to export
>         from f-spot to another location without digging through a pile
>         of versions.  If this could even be added as a plugin, it
>         would be all the difference in the world.

Yeah, the whole naming stuff should be configureable (see banshee). But
there are some changes which need to be done first.
To point (3), that depends on your point of view. I access my photos
through f-spot and want that f-spot shows me my photos in the
way/organization I need. I don't care about the file system and where
orininals or edits are stored. The problem is, that media does not
really match with the tree structure of a file system (that holds for
audio, video and photos, imho).


> Thank you sincerely for the response, and hope to hear back on these
> three above issues.  I am reconsidering F-Spot now over digiKam, and
> these last three issues would be a clincher for myself, as well as I
> am sure hundreds / thousands of other Meet the Gimp viewers.  ;)  
> Thank you again for this quality piece of software.
> With gratitude,
> - e.m.fields
> chapel hill, nc
> On Sun, Aug 29, 2010 at 5:28 AM, Mike Gemünde <mike gemuende de>
> wrote:
>         Hi,
>         I'm not sure which version of f-spot you are using. I guess
>         that you use
>         the one from latest (stable) ubuntu, this should be 0.6.5. The
>         0.7.x
>         series uses a new metadata backend which ruben and me build on
>         base of
>         taglib-sharp. So, metadata handling will change a bit in the
>         future.
>         However, our taglib-sharp implementation currently not
>         supports ITPC
>         records and I'm not sure if it will. All IPTC data can also be
>         stored in
>         the xmp namespaces Iptc4xmpCore and Iptc4xmpExt. I think that
>         some of
>         this fields will be used in the future for storing metadata.
>         However, all tags are stored (in 0.6.5 and in all other
>         versions) in xmp
>         (as long as the "write metadata to file" option is enabled).
>         So every
>         other (reasonable) photo application should be able read them.
>         Mike
>         Am Samstag, den 28.08.2010, 19:13 -0400 schrieb e.m.fields:
>         > Hi all,
>         > As a Ubuntu user I love F-Spot for its quality integration
>         with
>         > Gnome / Nautilus, and I'm very pleased with the refreshingly
>         intuitive
>         > interface, (Go U.I. team!) ... and I'm ESPECIALLY happy to
>         see the
>         > integration of a good versioning system, but there's one
>         feature that
>         > has me switching away from f-spot towards the KDE
>         application digiKam,
>         > despite its more complicated and not-well-integrated
>         interface, (not
>         > to mention the annoyance of the 100 other bundled KDE apps
>         on my GNOME
>         > desktop!).
>         >
>         > But that missing feature is the embedding / importing /
>         exporting of
>         > image tags within the image, in IPTC/EXIF format.  Right
>         now, if I tag
>         > and organize all my photos within F-spot and then move those
>         images
>         > someday to another system (or another hard drive), all those
>         tags are
>         > lost except within the old F-Spot database.  This is tying
>         the user
>         > into one system, and locking them into one software package,
>         which is
>         > not very much the FOSS/Linux way of doing things, no?
>         >
>         > I understand there were probably some intelligent reasons
>         made for
>         > this decision not to use IPTC tags, but why should this not
>         be an
>         > option?
>         >
>         > If anyone can correct me on this and say that this feature
>         is possible
>         > or "in the pipeline", I would be exuberantly happy to hear
>         so.
>         > Otherwise I shall (sadly) be continuing my migration to
>         digiKam.
>         >
>         > I sincerely hope that this feature will be considered
>         seriously by the
>         > development team.
>         >
>         > peace, and thank you to the development team for this
>         quality piece of
>         > open-source software
>         >
>         > - e.m.fields
>         > chapel hill, nc
>         > _______________________________________________
>         > f-spot-list mailing list
>         > f-spot-list gnome org
>         >
> _______________________________________________
> f-spot-list mailing list
> f-spot-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]