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



Hi Mike,
I am (pleasantly!) suprised to get this response!  Thank you for being concerned to do so.

I am using f-spot version 0.6.1.5-2ubuntu6

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?

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?

If so, this would make a large difference in the practicality of F-Spot as a respectable tool for any serious photo management.


Another (lovingly offered) gripe/feature request/humble plea:

I'm sure you've heard this before, but the editing version filenaming format ("IMAGE0123 V2 (Edited in Gimp photo editor).JPG") is pretty clunky.  I'm *very* pleased and happy that you've so seamlessly integrated versioning in Ubuntu with GIMP, this is huge.

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.
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
> http://mail.gnome.org/mailman/listinfo/f-spot-list





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