store tags and other metadata in photo files
Submitted by Adam Dingle
Assigned to Jim Nelson
Link to original bug (#715766)
Description
---- Reported by adam@yorba.org 2010-01-15 10:55:00 -0800 ----
Original Redmine bug id: 1290
Original URL: http://redmine.yorba.org/issues/1290
Searchable id: yorba-bug-1290
Original author: Adam Dingle
Original description:
store tags and other metadata in photo files
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:41:00 -0700 ----
History
Comment 1
Updated by Matěj Cepl over 3 years ago
… and of course read them from EXIF data as well. I have now 20,000+ pictures tagged with IPTC tags (via jbrout), so this is a deal breaker for me. However, just to tell, shotwell shocked how good it is just after couple of months of development. You guys, rock!
Comment 2
Updated by Adam Dingle over 3 years ago
- Priority set to High
Comment 3
Updated by Adam Dingle over 3 years ago
I've created a separate ticket (#1596) for importing IPTC tags since it's possible that we'll implement importing and exporting separately (perhaps even in different releases).
As for writing IPTC tags (which is what this ticket covers), we need to decide whether to write them (a) as soon as tags are applied to photos, or (b) only when photos are exported.
Comment 4
Updated by Matěj Cepl over 3 years ago
Replying to [comment:5 adam]:
I've created a separate ticket (#1596) for importing IPTC tags since it's possible that we'll implement importing and exporting separately (perhaps even in different releases).
You are very right with that.
As for writing IPTC tags (which is what this ticket covers), we need to decide whether to write them (a) as soon as tags are applied to photos, or (b) only when photos are exported.
When we separate importing from storing, the question opens whether shotwell shouldn't store tags as something else (e.g., XMP).
I vote for (a) … this should be The Canonical Storage of the data. We may have to have some caches somewhere for speed, but the canonical The Only True source of tags should be the file itself. At least that's how it is done in jbrout, and I think it is the better way.
Comment 5
Updated by Adam Dingle over 3 years ago
- Subject changed from store tags in EXIF data to store tags in photo files
I looked around a bit to see how other programs store tags in photo files. I think Shotwell should write tags in XMP format (seehttp://en.wikipedia.org/wiki/Extensible_Metadata_Platform). We should probably write tags in the older IPTC format too for the benefit of applications which don't (yet) understand XMP.
Comment 6
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
I've created a separate ticket (#1623 (closed)) for allowing the user to export tags to photo files, which is easier. This ticket will be for storing in tags in photo files all the time, which we may implement at some point (and which may end up being a user option).
Comment 7
Updated by Adam Dingle over 3 years ago
- Priority set to High
Comment 8
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 9
Updated by Jim Nelson over 3 years ago
- Subject changed from store tags in photo files to store tags and other metadata in photo files
Downstream ticket: https://bugs.launchpad.net/ubuntu/source/shotwell/bug/579804
Also, at least one user has requested we also store titles in the backing files like Picasa does. It would also make sense to store other metadata (i.e. ratings) in the backing files as well. I'm renaming this ticket to suggest that.
Comment 10
Updated by Adam Dingle about 3 years ago
- Priority set to High
Comment 11
Updated by Noran - about 3 years ago
In fact, we should store quickly the title, tags & rating in EXIF/%(=caps)IPTC%/%(=caps)XMP% (if fields are empty) to avoid doing jobs twice later.
Comment 12
Updated by Jim Nelson about 3 years ago
- Status changed from Open to Review
- Assignee changed from Anonymous to Jim Nelson
Comment 13
Updated by Jim Nelson about 3 years ago
- Status changed from Review to 5
- Resolution set to fixed
- % Done set to 100
I've committed a patch which performs this work in the background. It will store the photo's title (caption), rating, exposure date/time, and all tags. Note that in the case of tags, it replaces the tags with Shotwell's list rather than appends (or unions) them. Since tags are imported when the photo is brought into the library and the startup scan now catches changes to the file (including metadata), this should be okay.
If Shotwell is closed while the metadata is being written, Shotwell will resume where it left off.
In order to activate this feature, you must run Shotwell with the --autocommit-metadata command-line argument. This will be formalized in the UI with ticket #2492 (closed). NOTE: Using this flag means your master files will be modified without asking you first!
One thing not dealt with this patch is whether changes made in prior versions of Shotwell (or changes made in Shotwell while it was turned off) are then committed when it's turned off, _ changes are only committed when they are noticed and it's turned on. If it's the former, a bit more work needs to be done.
Comment 14
Updated by Tim White almost 3 years ago
It would be great if this didn't just write to XMP, but also IPTC and EXIF so that older applications can work with the tags/title as well. (e.g. YAPB Bulk Uploader only reads IPTC, not XMP).
Comment 15
Updated by Jim Nelson almost 3 years ago
tim,
See this ticket: #3044 (closed).
Comment 16
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:42 UTC ---
This bug was previously known as bug 1290 at http://redmine.yorba.org/show_bug.cgi?id=1290
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Resolution: RESOLVED FIXED