(page 21)
Exif within XMP
The most recent (as of mid-2008) XMP specification describes the usage of Exif/TIFF properties within XMP itself. Both Exif (http://ns.adobe.com/exif/1.0/) and TIFF (http://ns.adobe.com/tiff/1.0/) namespaces have been defined so corresponding Exif properties can be stored. This is particularly useful if Exif properties need to be stored but the file format does not support native Exif (e.g. PNG).
In the case of file formats that do support Exif however, the current XMP specification describes mechanisms to reconcile data between the native Exif values and the mapped Exif properties in XMP (see “TIFF and Exif digests” under section “Reconciling metadata properties” in the XMP specification).
However, this document changes this earlier XMP guidance and recommends that Exif and Tiff device properties only be mapped into XMP in the case the file format does not support Exif natively.
(page 22)
IPTC within XMP
In contrast to the earlier IPTC-IIM specification, the most recent IPTC Core specification allows storing IPTC properties within XMP. Most of the properties are mapped to existing standard namespaces but for those where this was not possible a new namespace “http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/” has been introduced. The IPTC group encourages people to move from IPTC-IIM to its newer IPTC Core / IPTC Extension standard.
If a file contains both EXIF and XMP, then reader applications should read both but prefer EXIF (page 23-24).
If writing XMP and IPTC-IIM in sync, an md5 checksum of the IPTC-IIM block must be stored in the file. Then when reading the metadata, the application should check whether the stored checksum matches the current checksum of the IPTC-IIM block. If it doesn't match (means the IPTC-IIM has been changed by a non-compliant application), the application should prefer IPTC-IIM, otherwise it should read both and prefer XMP (pages 25-27).
(page 32)
Time-zone handling
...
Exif date/time values such as DateTimeOriginal do not contain time zone information. The camera is presumably in an appropriate local time when a photograph is taken, but there is no indication in the Exif metadata of what that time zone was. The photograph's time zone MUST NOT be presumed to be the same as that of a computer later used to process the photograph.
The XMP specification formats date/time values according to the W3C note “http://www.w3.org/TR/NOTE-datetime”. In this note a time zone designator is required if any time information is present. A date- only value is allowed. The XMP specification has been recently revised to make the time zone designator be optional.
The representation of time zone as an offset from UTC can be ambiguous with regard to daylight savings time (DST). While date information can provide a strong hint, the use of DST is not universal and the date checking is complicated by changing rules for the start and end of DST in various locations. These issues are beyond the scope of this document; they may be addressed in a future revision.
...
When time zone information is available, XMP values SHOULD be stored using the local+offset form, not the “Zulu” form (for example, use “2008-04-30T12:34:56-06:00” instead of “2008-04-30T18:34:56Z”). The local+offset form carries additional information, the Zulu value is easily determined when needed, e.g. for sorting in a UI.
I noticed on page 33 it said:
(page 33)
Hierarchical keywords are not covered. However it's well understood that this is an important use case even in the context of the consumer and will be added to future versions of this document. There are existing solutions available e.g. Adobe Bridge, Adobe Lightroom as well as Microsoft Expression Media and Windows Live Photo Gallery that have introduced hierarchical keyword workflows specific to their needs.
I didn't realise Bridge could handle hierarchical keywords, so I looked into this. Bridge has a seperate panel/pallet for hierarchical keywords, seperate to the normal keywords box on the IPTC panel/pallet. You can only add hierarchical keywords by right-clicking on the appropriate existing hierarchical keyword, and then selecting 'New Keyword' or 'New Sub Keyword'. These keywords are then saved into the XMP in two places - the dc:subject field, where keywords are normally stored, and the lr:hierarchicalSubject, which is used for storing the keyword hierarchy.
Here's what they look like in the XMP:
Events
Events|Graduation
People
People|Matthew
People|Jimmy Villnar
People|Ryan
Events
Graduation
Matthew
People
Ryan
Jimmy Villnar
If you add your own hierarchical keywords, you must add them to both the dc:subject and lr:hierarchicalSubject fields, else they won't show up in the Hierarchical keywords panel in Bridge. Hierarchical Keywords that haven't previously been entered for an image in Bridge appear in the Hierarchical Keywords panel in italics. You can right-click on them and choose 'Make persistent' if you want it to be included in the list of available hierarchical keywords for all images.
I did some googling on hierarchical keywords to see if they might be worth using, but all I could come up with is that they might be.
I also had a look at adding metadata to multiple files at once. I found that for the dc:subject field, when multiple files were selected, it would say '(multiple values)' and then list the keywords used. If you clicked in the box to edit the keywords, the existing keywords would stay there and allow you to edit and add to them.
However, with custom bag fields, when multiple files were selected, it would just say '(multiple values)'. If you click in the box, all you can do is add new values, and all existing values for that field in each file would be deleted. I tried this on both my own panel and Massimo Novi's Expression Media panel, both with the same results. So I think the CS4 panels have something built into them that works with the dc:subject field, but not other bag fields.
After doing some more testing, it seems that so long as all your selected files have exactly the same data in a field, then that data will be loaded, and it won't just say '(multiple values)' and delete whatever values you have in that field when you edit it.
After getting partway through the Metadata Working Group Guidance, I stopped reading it and started going through the IPTC Photo Metadata 2008 Standards instead, deciding what fields I wanted to include in my custom XMP schema.
About 8pm I went in the garden and took some photos of a fly that didn't move about constantly. I came back in about 9pm because it was getting too dark, then processed the pics and did a backup.
Food
Breakfast: Blackcurrant jam toast sandwich; cup o' tea.
Lunch: Slice of Turkey breast with mayonnaise and sweet & crunchy salad sandwich; baby plum tomatoes (yes, they were baby plum when the ones we had before were cherry plum); banana; slice of cherry madeira cake; Fox's triple; cup o' tea; Rest of the chocolate bunny.
Dinner: Slice of ham pizza; chips; sweet & crunchy salad. Pudding was lemon and lime sponge with custard. Coffee.
No comments:
Post a Comment