The following table lists the embedded metadata capabilities for the supported file formats.
File format |
Metadata access |
XMP packet handling |
EXIF & IPTC synchr. |
Image data synchr. |
---|---|---|---|---|
JPEG, TIFF |
Read and write (*) |
Smart read and write (*) |
For reading and writing (*) |
For reading |
Photoshop |
Read and write (*) |
Smart read and write (*) |
For reading and writing (*) |
None |
PNG |
Read and write (*) |
Smart read and write (*) |
None |
For reading |
Read and write (*) |
Smart read and write (*) |
None |
None |
|
InDesign, PostScript |
Read-only |
Smart read-only |
None |
None |
Other formats |
Read-only |
Generic read-only |
None |
None |
(*) Write access is available only through scripting
There are two distinct methods to locate XMP packets embedded in a file:
Scan the complete file for the magic markers at the head and tail of a packet: this works for any file format, but may possibly locate the wrong packet in case a composite document contains multiple packets.
Interpret the file format's structure to track down the packet: this guarantees that the correct packet has been located and it is usually much faster, but it requires a specific algorithm for each distinct file format.
As indicated in the table, Switch offers three levels of support for embedded XMP packets depending on the file format:
Smart read and write: interprets the file format to allow reading, updating and inserting an XMP packet.
Smart read-only: interprets the file format to locate the appropriate document-level XMP packet but does not allow changes.
Generic read-only: uses generic packet scanning to locate one of the XMP packets in the document; does not allow changes.
As indicated in the table, for some file formats Switch performs two-way synchronization between binary EXIF and IPTC tags on the one hand and XMP properties on the other hand, similar to the behavior of the Adobe Creative Suite applications.
For supported file formats, when creating the embedded dataset for a job, Switch performs these steps:
Locate the primary embedded XMP packet and parse it into an XMP object model; if there is no XMP packet start with an empty XMP object model.
Read the appropriate binary EXIF and IPTC tags, if present and merge their values into the XMP object model as the equivalent XMP properties.
Offer access to the resulting unified XMP object model.
For supported file formats, when saving changes for a writable embedded dataset, Switch performs these steps:
If any changes were made to the dataset as compared to the original XMP packet, save the complete unified XMP information in an updated or inserted XMP packet.
If changes were made to one or more synchronized properties that are "user-editable", update or insert the corresponding binary EXIF or IPTC tags. Properties that reflect characteristics of the image (and thus should never be edited by a user) are not updated in the binary tags.
As indicated in the table, for some file formats Switch retrieves basic information about the image from the image data itself and writes this information to the appropriate fields in the XMP packet. This ensures that the following fields are always present for these formats:
Variable name |
XMP location path |
---|---|
Image.ColorMode |
photoshop:ColorMode |
Image.ICCProfile |
photoshop:ICCProfile |
Image.SamplesPerPixel |
tiff:SamplesPerPixel |
Photo.ColorSpace |
exif:ColorSpace |
Photo.PixelXDimension |
exif:PixelXDimension |
Photo.PixelYDimension |
exif:PixelYDimension |
The backing file for an embedded dataset is determined as follows:
If the job is an individual file, use it as the backing file.
Otherwise if the job folder immediately contains a single Adobe InDesign file (that is, at the uppermost level), use that InDesign file as the backing file.
Otherwise use the job folder path for the backing file and return an empty read-only dataset.