IPTC-IIM standard

from Wikipedia, the free encyclopedia

The IPTC-IIM standard (often just IPTC for short ) is a data format for storing metadata in image files (e.g. in JPEG or TIFF files). It was defined as the Information Interchange Model (IIM) in 1991 . Information - text as well as date and numerical values ​​- are stored in a special area of ​​the file in a format defined by this standard.

Background and history

The IPTC-IIM standard was developed by the International Press Telecommunications Council (IPTC) together with the Newspaper Association of America (NAA) and is basically suitable for all types of media, i.e. text, photos, graphics, audio or video. The standard defines two aspects of metadata: on the one hand a list of fields and their meaning, on the other hand a technical format for storing these fields with the values ​​entered. The standard allows copyright notices , the name of the creator , a heading or keywords to be specified and saved directly in the image file. This type of storage of metadata is very common in picture agencies and picture archives . With suitable programs (mostly image databases in a professional context ), files enriched in this way can be searched for specific entries or keywords. In this way, the administration, maintenance and use of large image archives can be simplified.

As of 2003, in addition to storage in the technical format of the IPTC-IIM standard, storage in the XMP format ( Extensible Metadata Platform ) has been used, although the fields defined in the IPTC-IIM standard and their meaning have been retained. This has been defined in the IPTC Core Photo Metadata Standard since 2004. Products support storage in both the IPTC-IIM standard and the XMP format. Some products also synchronize the metadata values ​​between the two formats; there is a comprehensive guideline for this from the Metadata Working Group .

After version 1 of the IIM was adopted in 1991, the model has been further developed. With the advent of new data display technologies - especially XML  - the development of the IIM was frozen in 1997. Only a minor change was adopted in 2014. The latest version is 4.2.

use

When the standard was first adopted in 1991, the specification aimed to standardize data transmission in the journalism industry. However, the first product to implement the IIM was Adobe's "Photoshop" in 1994 - an image editing program, not a message transfer program. In the following years other image processing and image management programs implemented the standard. An IPTC list of programs that support IIM and IPTC Core mainly contains products that are dedicated to image processing and management; only a few products from Adobe for processing multimedia data use the standard for other data types; IIM is now referred to as a "Photo Metadata Standard". Few news agencies still use IIM to exchange text messages; photography is still a "stronghold" of the IIM application: since Adobe implemented IIM to add metadata to photos in Photoshop more than 10 years ago and this technology has been implemented by many software manufacturers, millions of photos have been binding IIM- Fields of one and several dozen computer programs support IIM.

In August 2014, the IPTC examined 19 software products for image processing and management from the low-budget (<150 US- $ / € / £ ) and freeware segment for their ability to write or read IPTC data. The test was devoted exclusively to four fields that serve to protect copyrights: Creator (photographer), copyright notice , "Rights Usage Terms", no IIM field, but a field from the more recent IPTC core standard. and creation date . The results varied, ranging from “All fields are available for writing and reading” to “Copyright notice and terms of use are not available”.

Handling metadata

Online communities and online photo services deal with IPTC (and Exif -) metadata uploaded image files different, both in the presentation on the web, and in the cases in which opt users into images from the online service to download. The scope of the metadata of downloaded photos varies, ranging from “all metadata will be retained” to “all metadata will be deleted”. Examples:

  • When uploading photos, Facebook adopts the title of an image file (“title” corresponds to the object name , not the heading ) and description, and creates a combined title / description field from this. Other metadata are not displayed. When the photo is downloaded, all IPTC and Exif metadata are deleted, with the exception of the creator and the copyright notice . Facebook adds its own metadata to the images, which is retained when the photo is downloaded. In the ITPC fields "Original Transmission Reference" and "Special Instructions", user-related data is presumably stored in coded form.
  • After the upload, Google+ shows the description and some Exif data, including a. the geographic coordinates. All IPTC and Exif metadata are retained when the photo is downloaded.
  • Flickr offers a function "Show EXIF", it shows Exif and IPTC metadata. When downloading photos, metadata is only retained if the image is downloaded in full size - all metadata is deleted if the image is smaller. Keywords that can be added in the web interface are not written back to the IPTC header.
  • Pinterest does not display any metadata after the upload. All IPTC and Exif metadata are retained when downloading photos.

In professional photo journalism, a. Notes on authorship (in the fields creator , provider , source ) and on copyrights ( copyright notice ) from photographers, graphic designers and agencies stored in the IPTC metadata. The completion of the supply chain from the author (photographer / graphic artist) to the presentation of the images on the websites of (for example) magazine and magazine publishers can be categorized into two ways of handling the metadata: preservation or removal. Examples:

Metadata and copyright

The maintenance of IPTC metadata on authorship in the "Copyright Notice" field is recommended for rights holders such as photographers, graphic designers or image and news agencies in order to be able to prove their own authorship.

The German copyright law makes this data by means of a special provision under protection ( § 95c Copyright Act , "the protection of the rights necessary for the perception of information"). According to this regulation, "information for rights management originating from right holders" may not be removed or changed. If the information for the management of rights has been removed or changed without authorization, it may not be knowingly distributed, introduced for dissemination, broadcast, publicly reproduced or made publicly available without authorization.

Photographers, graphic designers and agencies therefore often include appropriate notes in the metadata of their images. With a special contractual clause, you can ensure that digital retransmission can only take place with the metadata.

In 2016, the Freelens Photographers' Association won a judgment before the Hamburg Regional Court (Az .: 308 O 48/15), according to which Facebook is no longer allowed to automatically remove the IPTC metadata when uploading photos.

IPTC fields

The data representation of the IPTC-IIM is referred to as "IPTC data", "IPTC fields" or "IPTC header".
A message object (or "object") can be, for example, an image (photo / scan / graphic), text (news report), an audio / video file or a combination of these objects.

IPTC field in
English		 IPTC field
German		 description Example example image Characters max. IPTC code
Envelope Record
File format File format A number representing the file format. The information is used to forward the data in a receiving system to a responsible part and to allow this to carry out the appropriate action. Examples:
  • “11” for JPEG image files
  • “23” for MP3 audio files
  • "25" for NITF -formatted messages
 11 2 1:20
Coded Character Set Character encoding Examples: ESC% G 32 1:90
Application Record
Object name Object name Short reference to the object, can be file name. Changes to existing data, such as B. updated reports or new image sections should be indicated in the processing status. 2007-05-23 - IMG_8393.CR2 64 2:05
Edit status Processing status Status of the message object, according to the provider's practice . correction 64 2:07
Urgency urgency Specifies the editorial urgency of the content. “1” is the highest priority, “5” the normal and “8” the lowest; “9” and “0” are reserved for future use. 5 1 2:10
Category category Category (discontinued) ; Examples:
  • "ACE" for Arts, Culture and Entertainment
  • "EDU" for Education
  • "SPO" for sport
 ACE 3 2:15
Supplemental Category Other categories Freely selectable categories (discontinued) Architecture, Gothic, Neo-Gothic Any number of categories, each max. 32 characters long 2:20
Keywords Keywords Keywords that express what the content is about. Keywords can be any text and do not have to be taken from a fixed vocabulary. It is expected that a provider of different types of data, which are related in the subject matter, use the same keyword so that the receiving system or sub-system can search for relevant material over all types of data. architecture, Architektur, Cologne, Cologne Cathedral, Dach, facade, Façade, flying buttress, Köln, Kölner Dom, roof, Strebebogen Any number of keywords, each max. 64 characters long, including spaces 2:25
Special Instructions Special instructions Further editorial instructions regarding the use of the news items, such as B. embargo periods, usage restrictions or warnings Not released for sale, publication only after the Pope's visit has ended 256 2:40
Date Created Creation Date Creation date in the form YYYYMMDD. Follows the ISO-8601 standard. Unknown dates are expressed with “00”. Indicates the date when the message object's mental contents were created, not the date when the physical data file was created. Therefore, a photo taken during the American Civil War would have a date of creation from that era (1861–1865), not the date the photo was digitized for archiving. Example:
  • “18630127” means that the spiritual content was created on January 27, 1863
 18801015 8th 2:55
Time Created Creation time Creation time in the form HHMMSS ± HHMM (time ± time zone correction compared to UTC ). Follows the ISO-8601 standard. Indicates the time the message object's mental contents were created, and not necessarily the time the physical data file was created. If the time cannot be accurately determined, the best approximation should be made. Example:
  • "133015 + 0100" means that the intellectual content was created at 13:30 and 15 seconds in the time zone "UTC +1" (= CET )
 120000 + 0100 11 2:60
Digital Creation Date Digitization date Digitization date in the form YYYYMMDD. Follows the ISO-8601 standard. Indicates the date the digital representation was created. Therefore, a photo taken during the American Civil War would have a creation date from the last few years, not a date from that era (1861–1865) when the photo was taken on film, glass, or other substrates. Example:
  • “19900127” means that the digital representation of the property was created on January 27, 1990
 20070523 8th 2:62
Digital creation time Digitization time Digitization time in the form HHMMSS ± HHMM (time ± time zone correction compared to UTC ). Follows the ISO-8601 standard. Indicates the time that the digital representation was created. Example:
  • "133015 + 0100" means that the digital representation of the object was created at 13:30 and 15 seconds in the time zone "UTC +1" (= CET )
 172917 + 0100 11 2:63
Originating Program Original program Identifies the computer program used to create the message object. Examples:
  • "WordPerfect"
  • "Adobe Photoshop"
 Adobe Photoshop Lightroom 32 2:65
By-line Creator Name of the message object creator, e.g. B. Author, photographer or graphic artist; "Name line" ("by-line") in the sense of how the creator is called in the case of publication in one line of the message object Erika Mustermann 32 2:80
By-line title Creator Title Title of the message object creator (s), i.e. the person (s) listed in the Creator field , typically job title. Should be placed after the creator information on publication. Since this is a supplementary information to the creator field, this must be filled out before anything can be entered here. Examples:
  • "Portrait photographer"
  • "Correspondent"
 Architecture photographer 32 2:85
City City / place Identifies the city or town of the message object's origin, according to established guidelines of the creator. Examples:
  • "Zurich"
  • "Milan"
  • "New York"
 Cologne 32 2:90
Sublocation Location detail Identifies the location within a city or town of the message object's origin, according to the guidelines specified by the creator. Examples:
  • "Schanzenviertel"
  • "Olympic Stadium"
  • "Beethoven Hall"
 Cathedral monastery 4 32 2:92
State / Province State / Canton Identifies the federal state or canton of origin, according to the guidelines set by the creator. Examples:
  • "Baden-Württemberg"
  • "Graubünden"
  • "Sussex"
 North Rhine-Westphalia 32 2:95
Country / Primary Location Code ISO country code Identifies the country code of the country in which the message object was created, e.g. B. where a photo was taken or an event took place. The code should be taken from the two- or three-letter codes specified in ISO 3166 (for Germany: DE or DEU). The full name of the country should be entered in Land . Examples:
  • "USA" (United States)
  • "FRA" (France)
  • "XUN" (United Nations)
 DE 2 or 3 2: 100
Country country Identifies the full, publishable name of the country in which the news item was created, e.g. B. where a photo was taken or an event took place, according to established guidelines of the creator. The full name should be expressed as a linguistic designation and not as a code, because a code should be entered in ISO country codes . Germany 64 2: 101
Original Transmission Reference Original transmission reference A code that represents the location of the original transmission, according to the provider's practice . Examples:
  • "BER-5"
  • "PAR-12-11-01"
 em1234 32 2: 103
Headline heading A publishable entry that summarizes the contents of the message object. Example:
  • "Lindbergh lands in Paris"
 Facade of Cologne Cathedral 256 2: 105
Credit providers Identifies the provider of the message object, not necessarily the owner or creator Muster-Foto GmbH 32 2: 110
Source source The name of a person or party who has a role in the supply chain. This can be an agency, a member of an agency, an individual or a combination. The source may differ from the creator and from the entries in the copyright notice . Sample photo / Erika Mustermann 32 2: 115
Copyright Notice Copyright notice Includes any necessary copyright notice © Copyright 2014 Erika Mustermann, all rights reserved - em@mufoto.de 128 2: 116
Contact Contact Identifies the person or organization who can provide further background information on the message object. Erika Mustermann 128 2: 118
Caption / abstract description A textual description of the message object; is used especially when the object is not text. View of the facade, roof and flying buttresses of Cologne Cathedral on the north side. The Cologne Cathedral is one of the world's most important cathedrals in the Gothic style. Many art historians see a unique harmonization of all building elements and jewelry in the style of late medieval Gothic architecture. It is important to understand that the construction of Cologne Cathedral began in the 13th century (Gothic), but the cathedral was not completed until the 19th century after centuries of construction (neo-Gothic). The end of the cathedral building was celebrated on October 15, 1880 with a festival that Wilhelm I used as a means of public representation and as an element of identity for the empire founded nine years earlier. 2000 2: 120
Writer / Editor Author / editor Identification of the name of the person involved in writing, editing and correcting the message object or description . John Doe 32 2: 122
Example imageThe IPTC-IIM metadata of an example image with example data from the table above can be viewed with the Jeffrey's Exif Viewer online service , as well as with the widely used IrfanView image viewer with the corresponding plug-in.

Character encoding

The IPTC-IIM standard does not prescribe a specific character encoding , but allows data to be stored in different character encodings. The standard stipulates that the encoding used is specified in the Character encoding field . In fact, however, some applications ignore this field and instead assume that the data was written in a certain encoding. B. the Latin-1 character encoding ISO 8859-1 or UTF-8 . Some applications even assume that the ASCII character coding is strictly restricted . For the user, this results in the need to check whether the codings of the programs used are compatible with one another.

See also

Web links

References and comments

  1. ^ A b The Information Interchange Model ( Memento from November 26, 2014 in the Internet Archive ) on the IPTC website
  2. ↑ Software supporting IPTC photo metadata standards IIM and “IPTC Core” on the IPTC website
  3. ^ IIM Information Interchange Model - Who's Using It? ( Memento of October 28, 2014 in the Internet Archive ) on the IPTC website
  4. ↑ IPTC Web - Photo Metadata - Software for Rights Test on the IPTC website. The date of the test is not given there. Since z. As is mentioned in the test "Lightroom 5.6" (which on July 31, 2014 was published ), the test can be done at the earliest in August 2014; a forum post on the publication of the test results comes from August 2014.
  5. ↑ Status of the study: October 2014. See also social media websites: Foot metadata test results with tests from October 2012 to June 2013, as well as the column “IPTC support” in the comparison of photo sharing websites the English language Wikipedia.
  6. ↑ Facebook Tracking - The Hacker Factor Blog. Retrieved July 14, 2019 .
  7. ↑ Status of the investigation: October 2014.
  8. ↑ Websites of the examples: Spiegel Online , Frankfurter Allgemeine , Süddeutsche.de , Zeit Online , Focus Online , Stern , Bild , Heise Online , lemonde.fr , The New York Times , The Times
  9. ↑ Paula Tamm: Like! Deletion of IPTC data prohibited. Freelens, November 17, 2016.
  10. ↑ According to Software supporting IPTC photo metadata standards IIM and “IPTC Core” ( Memento of October 27, 2014 in the Internet Archive ) on the IPTC website
  11. ↑ The table essentially follows the IPTC IIM specification 4.2 (PDF) The German-language translations of the IPTC fields are based on the German-language user interfaces of the Adobe Photoshop Lightroom and Capture One Pro image management programs from Phase One . The implementation of the IPTC standards by Adobe in the products Photoshop and Lightroom can be used as a reference, since Adobe has taken on a cooperating role in the specification of the IPTC standards.
    The examples are fictitious and use German umlauts to demonstrate that the available character encoding is not limited to the restricted 7-bit ASCII code. Problems in this context (subject of character encoding ) are known .
    The table is not a complete reference of the specification, as it essentially names the fields that are accessible from the user's point of view.
  12. ↑ The character coding is typically not set by the user, but by the program used. For example, Adobe Photoshop (version CS5 or higher), Adobe Bridge (version CS5 or higher), Adobe Photoshop Lightroom and Capture One Pro use UTF-8 as the character encoding .
  13. ↑ a b "Obsolete" means that this field should no longer be used as it is likely that it will no longer be included in future versions of the IIM.
  14. ↑ Guideline for mapping Category Codes to Subject NewsCodes on the IPTC website
  15. ↑ a b "Publishable" means that it is expected that the information in this data record was written in such a way that it can be printed or otherwise published in its present form.
  16. ↑ Roland Freist: The 10 best tips for Irfanview . In: PC-Welt , June 22, 2018; accessed on July 8, 2019.
  17. ↑ The IPTC-IIM data of an example image demonstrate an incompatibility of two character encodings: The field Supplemental Categories is encoded in UTF-8 (see illustration of the letter "ü" in "Nürburgring"), the fields City ("Nürburg") and Caption -Abstract ("Nürburgring", "Nürburg") are coded in ISO 8859-1 . You can see this by switching back and forth between the two character encodings in the browser options. The different character encodings arise when the data has been entered in different applications: one uses UTF-8, the other ISO 8859-1 (or a related coding such as ISO 8859-15 ).