Handling Image metadata

From RidgeRun Developer Connection
Jump to: navigation, search

Introduction

The metadata, also called "data about data", stores additional information from the primary content that is already when the image is taken. This information could be the condition in which the image was taken, for example: shutter speed, exposure, gain, white balance, and lens information [1]. In order to provide some guidance, the Guidelines for handling image metadata documentation could be consulted.

The metadata in an image can be managed by different actors according to their roles. These actors use their definitions to access and manage the image metadata. The definitions start with a Creator going through Changer actors and ending with the Consumer actor. This workflow can be seen in the following diagram:

Actor state diagram. Taken from Guidelines for handling image metadata

In general, the actors mentioned above perform the following actions[1]:

  • Creator: Creates the first metadata instances in a new image file. It is common that there is no old metadata to preserve.
  • Changer: It first reads the metadata and then modifies it back to the image or writes new metadata.
  • Consumer: This actor does not modify the metadata in the file itself, only reads and exposes it for display purposes, research, etc.

This wiki page is focused on JPEG image format.

Types of metadata

According to Guidelines for handling image metadata there are three types of standard metadata that are used in the images the most: Exif, IPTC and XMP.

Exif

Exif stands for Exchangeable Image File Format and this standard stores the additional metadata in digital images [2]. The Exif format borrows some set TIFF tags in order to describe the photographic images [1].

In the JPEG Compressed Image Format, the Exif Attribute Information is written in the Application Market Segment (APP1) and the APP1 size shall not exceed the 64 KBytes specified in the PEG standard. Other APPn that APP1 and APP2 or COM (Comment) segments are not used by Exif. However, they are not restricted, they can be used for recording by vendors or trade groups. The APP1 contains the attribute information which is stored in the TIFF structure and includes a File header with two IFD (sub-Image File Directory) (0th IFD and 1st IFD) at most. The 0th IFD stores the primary information while the 1st IFD may be used to record a thumbnail image [3].

The IFD in Exif, according to the TIFF Rev. 6.0, is made by 2-byte count (number of fields), 12-byte field 12-byte field Interoperability arrays, and 4-byte offset to the next IFD. The 12-byte are divided in the following four elements respectively [3]:

  • Bytes 0-1 Tag
  • Bytes 2-3 Type
  • Bytes 4-7 Count
  • Bytes 8-11 Value Offset

In the case of the Tags, they have a field that is identified with a unique 2-byte number. These tag numbers are in the Exif 0th IFD and 1st IFD and are all the same as the TIFF tag numbers. The following types are used in Exif [3]:


  • 1 = BYTE An 8-bit unsigned integer.
  • 2 = ASCII An 8-bit byte. 7-bit ASCII code and the final byte is terminated with NULL.
  • 3 = SHORT A 16-bit (2-byte) unsigned integer.
  • 4 = LONG A 32-bit (4-byte) unsigned integer.
  • 5 = RATIONAL Two LONGs. The first LONG is the numerator and the second LONG is the denominator.
  • 7 = UNDEFINED An 8-bit byte that may take any value depending on the field definition.
  • 9 = SLONG A 32-bit (4-byte) signed integer (2's complement notation).
  • 10 = SRATIONAL Two SLONGs. The first SLONG is the numerator and the second SLONG is the denominator.

IPTC metadata

At the beginning of the IPTC standard was to work with text-only information. Later on, the “Information Interchange Model” (IIM), was created. With IIM, the IPTC headers were incorporated and they are the IIM metadata embedded in images. IPTC has adopted the XMP standard as the successor to the IPTC headers [1].

In the IPTC standard, each individual metadata entity is called property and they are divided into Administrative, Descriptive and Rights-related properties. This standard technical implementation works as follows [4]:

  1. The image file format specifies an outermost wrapper header
  2. The header has the Image Resource Blocks (IRB). The IRB manages a structure that contains different types of data and also could not be metadata. Each data contains a specific identifier
  3. There are 2 specifications related to the metadata fields in the IPTC IIM. One is the administrative and this specification uses the identifier that is used to identify the metadata field and the field (Tags) numbers. The second specification contains a technical description of the data stored by the field.
  4. The IPTC identifier field contains an envelope record which is a field number that is used for information such as the type of data and file format. Moreover, the data object transfer could be a photographic image, text or perhaps a combination of many types. Additional information, such as caption, news category or dateline also is included and the IIM assumes that the sender wishes to transfer this data object. When the data is sent, it does with together information such as the size of the data pertinent editorial and technical description [5].

XMP metadata

The Extensible Metadata Platform (XMP) was introduced by Adobe Systems Incorporated in 2001 and IPTC has adopted this standard. When a software program or device uses the XMP metadata it can add its own information to a digital resource and this information can be retained in the final file [6]. Also, the XMP standard uses a subset of the W3C Resource Description Framework (RDF) to be stored and is serialized in XML [1].

The XMP data model is also called an XMP packet and is a group of metadata properties. Each property has a name and a value, for example: dc:subject. The name of each property in a XMP packet has to be unique and the names of the properties shall be XML expanded names, consisting of a namespace URI and a local name. The namespace URI has not to be empty [7].

The size of the XMP packet can be at most 65502 bytes. However, it is around 2 KB typically. If the packet becomes larger than the 64 KB limit, you can divide it into a main portion (StandardXMP) and an extended portion (ExtendedXMP), and store it in multiple JPEG marker segments. By convention, an APPn marker identifies the usage with a string called namespace or signature string. The APP1 marker is used to identify the Exif and TIFF metadata; an APP13 marker identifies the IPTC metadata that is contained in the Photoshop Image Resource (PSIR). The APP13 designates the PSIR. Another APP1 marker designates the location of the XMP packet [8].

The JPEG standard format does not oblige ordering among APPn segments, but some related standards do. For example, the APP1 segment has to be immediately after the Star of Image (SOI). Moreover, some applications suppose that the segments are in a particular order. It is better, for compatibility, to follow the next order: Exif in the APP1 marker first, later the XMP APP1, then the PSIR APP13, followed by all other marker segments [8]

Handling multiple metadata formats

The following figure is a simplified view of metadata for which guidance is being provided by the Guidelines for handling image metadata:

Error creating thumbnail: Unable to save thumbnail to destination
Handling multiple metadata formats. Taken from Guidelines for handling image metadata

The properties described earlier have been identified by the rkinggroup.org/pdf/mwg_guidance.pdf Guidelines for handling image metadata as the most relevant in the consumer workflows today. There are some properties or tags that are defined in more than one metadata format. Actually, only four are available in Exif, IPTC-IIM and XMP:

  • Date/Time
  • Description
  • Copyright
  • Creator

Exif and XMP

In order to read the Exif and XMP metadata from an image, the following figure shows an overview of how to do it:

Error creating thumbnail: Unable to save thumbnail to destination
Read Exif and XMP metadata. Taken from Guidelines for handling image metadata
.

Moreover, there are two cases when Exif metadata is being mapped into XMP:

  • The Exif native properties mapped to the respective XMP properties (e.g. Exif Copyright => XMP (dc:rights))
  • The duplicated Exif and TIFF device properties into specific “exif:” or “tiff:” namespaces (e.g. Exif ApertureValue => XMP (exif:ApertureValue))

On the other hand, the writing process depends on the actor's definition role: Creator or Changer.

Creator

In the case of the Creator role, the Guidelines for handling image metadata defines the following rules guidance on how to write XMP and/or Exif metadata:

  • If a property can be stored in both locations, the XMP metadata MAY be created. Otherwise, the XMP metadata MUST be created (which is true for file formats where Exif is not defined).
  • Exif metadata MUST be created if the XMP metadata is not written.

Changer

In the case of the Changer role, the Guidelines for handling image metadata defines the following rules guidance on how to read and write XMP and/or Exif metadata:

  • To consume the Exif and XMP metadata, the Figure above should be followed.
  • When Exif and XMP metadata are both supported in the file format, a Changer should update both values. If only one form value is updated, the other form value must be deleted.
  • If the Exif metadata is not supported natively in a file format, in the XMP exif: and tiff: namespaces should not be any Exif and TIFF device properties (e.g. XResolution, YResolution, WhitePoint, etc.) duplicated
  • The Changer should maintain the byte-order. For example, the Exif metadata is a TIFF stream format. The TIFF streams must be big endian or little endian byte-order.
  • The Exif string values should be written as UTF-8. However, to allow more interoperability, the client may write them as ASCII.
  • It should be written into the XMP standard a checksum value for Exif/TIFF.
  • If there is no data in a file format, the Creator rules guidance should be followed.

Exif and IMM

The next figure shows Consumer guidance on how to read IPTC-IIM related metadata.

Read IPTC-IMM and XMP metadata. Taken from Guidelines for handling image metadata

On the other hand, the writing process depends on the following actor's rules[1].

Creator

  • Unless there is a backward compatibility requirement with non-compliant Consumers that do not read XMP, a Creator should not create IPTC-IIM metadata. Otherwise, the XMP metadata should be written.
  • A Creator must produce a checksum value if IPTC-IIM and XMP metadata are both written.

Changer

  • If an IPTC-IIM value is already in the file format, both XMP and IPTC-IIM metadata values should be written back to the file by a Changer. Otherwise, only XMP should be written.
  • IPTC-IIM should be written using the Coded Character Set (1:90) as UTF-8.
  • A strong Changer should convert all property values to UTF-8 and write the corresponding identifier for UTF-8 to the 1:90 DataSet if the IPTC-IIM values have not been written as UTF-8.
  • A Changer must generate or update the checksum value If IPTC-IIM and XMP are both present, regardless of whether the values changed or not.
  • If there is no data in a file format, the Creator rules guidance should be followed.

Handling Exif/TIFF, IPTC-IIM and XMP metadata

In the case of handling the Exif/TIFF, IPTC-IIM and XMP metadata standards, the next rules should be followed [1]:

  • In the case of conflict between the Exif and IPTC-IIM metadata and if the IPTC-IIM checksum matches or does not exist, a Consumer should prefer the Exif metadata.
  • If there is a conflict between the Exif and IPTC-IIM metadata and if the IPTC-IIM checksum does not match, a Consumer should prefer the IPTC-IIM metadata.
  • A string property must be managed as non-existent if it is comprised of only spaces or only null character.

JPEG file format

For the JPEG file format, the Exif/TIFF, IPTC-IIM and XMP metadata standards are handled as follows:

Error creating thumbnail: Unable to save thumbnail to destination
Metadata in JPEG file format. Taken from Guidelines for handling image metadata

The tag 34664 points to the IFD structure that stores all the Exif tags. The identifier 1028 (decimal) was assigned to a block of metadata provided in the IPTC IIM 4 format [4]. The 1061 IIM is where the checksum is stored [1].

These metadata standards should be handled as [1]:

  • Exif and XMP should be read from the Exif APP1 section and IPTC-IIM should be read from the image resource block (IRB) in Photoshop APP13 (1028).
  • Exif APP1 must follow immediately after SOI. If not, the Exif metadata may not show correctly in the current camera models.

References

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Guidelines for handling image metadata
  2. ↑ https://jimpl.com/
  3. ↑ 3.0 3.1 3.2 Exchangeable image file format for digital still cameras: Exif Version 2.32
  4. ↑ 4.0 4.1 IPTC Standards Photo Metadata White Paper 2007
  5. ↑ Information Interchange Model (IIM)
  6. ↑ XMP metadata
  7. ↑ XMP Specification Part 1
  8. ↑ 8.0 8.1 XMP Specification Part 3
Retrieved from "http://developer.ridgerun.com/wiki/index.php?title=Handling_Image_metadata&oldid=50537"