.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.42) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Image::MetaData::JPEG::Structures 3pm" .TH Image::MetaData::JPEG::Structures 3pm "2022-03-07" "perl v5.34.0" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" Image::MetaData::JPEG::Structures \- describes the structure of a JPEG file .SH "OVERVIEW" .IX Header "OVERVIEW" This document describes the structure of a \s-1JPEG\s0 file; it is an appendix to the main manual page of the Image::MetaData::JPEG module, which the reader should refer to for further details and the general scope. .SH "THE STRUCTURE OF JPEG PICTURES" .IX Header "THE STRUCTURE OF JPEG PICTURES" The \s-1JPEG\s0 (Joint Photographic Experts Group) \s-1ISO\s0 standard is a lossy image compression mechanism developed before 1990, designed for compressing colour or gray-scale photo-realistic images (it performs poorly on line-art drawings). The \s-1JPEG\s0 mechanism is designed to exploit known limitations of the human eye, in particular the fact that colour changes are perceived less accurately than changes in brightness. Note that although the \&\*(L"baseline\*(R" \s-1JPEG\s0 format is patent-free, there are patents associated with some optional features, namely arithmetic coding and hierarchical storage. For this reason, these optional features are never used on the Web (good job, patent fans ...). \s-1JPEG\s0 refers only to a class of compression algorithms, not to a specific file format. In order to produce files with embedded \s-1JPEG\s0 streams, a number of file format (semi\-)standards have been adapted or devised, some of which are listed in the format section. The structure of a well formed \s-1JPEG\s0 file can be described by the following pseudo production rules (for sake of simplicity, some additional constraints between tables and \s-1SOF\s0 segments are neglected). .PP .Vb 8 \& JPEG \-\-> (SOI)(misc)*(image)?(EOI) \& (image) \-\-> (hierarch.)|(non\-hier.) \& (hierarch.) \-\-> (DHP)(frame)+ \& (frame) \-\-> (misc)*(EXP)?(non\-hier.) \& (non\-hier.) \-\-> (SOF)(scan)+ \& (scan) \-\-> (misc)*(SOS)(data)*(ECS)(DNL)? \& (data) \-\-> (ECS)(RST) \& (misc) \-\-> (DQT)|(DHT)|(DAC)|(DRI)|(COM)|(APP) \& \& (SOI) = Start Of Image \& (EOI) = End Of Image \& (SOF) = Start Of Frame header (10 types) \& (SOS) = Start Of Scan header \& (ECS) = Entropy Coded Segment (row data, not a real segment) \& (DNL) = Define Number of Lines segment \& (DHP) = Define Hierarchical P??? segment \& (EXP) = EXPansion segment \& (RST) = ReSTart segment (8 types) \& (DQT) = Define Quantisation Table \& (DHT) = Define Huffman coding Table \& (DAC) = Define Arithmetic coding Table \& (DRI) = Define Restart Interval \& (COM) = COMment segment \& (APP) = APPlication segment .Ve .PP This package does not check that a \s-1JPEG\s0 file is really correct; it accepts a looser syntax, were segments and \s-1ECS\s0 blocks are just contiguous (basically, because it does not need to display the image!). All meta-data information is concentrated in the (COM*) and (\s-1APP\s0) Segments, exception made for some records in the (SOF*) segment (e.g. image dimensions). .PP .Vb 6 \& Reference: B<"Digital compression and coding of continuous\-tone still \& images: requirements and guidelines", CCITT recommend. T.81, 1992, \& The International Telegraph and Telephone Consultative Committee, \& standard ISO/IEC IS 10918\-1 or ITU\-T Recommendation T.81>. \& Also: B<"The JPEG still picture compression standard", G.K.Wallace, \& 1991, IEEE Transactions on Consumer Electronics>. .Ve .SS "A \s-1SHORT HISTORY OF JPEG FILE FORMATS\s0" .IX Subsection "A SHORT HISTORY OF JPEG FILE FORMATS" \fI\s-1TIFF\s0 [not supported]\fR .IX Subsection "TIFF [not supported]" .PP The \s-1TIFF\s0 (Tagged Image File Format) is one of the most popular and flexible raster file formats for digital images, and is the de-facto standard graphics format for high colour depths. It was initially developed by Aldus (in 1986) and is now maintained (or neglected) by Adobe. Multiple images (e.g., fax pages) can be stored in a single \s-1TIFF\s0 file, each page in a separate \s-1IFD\s0 (Image File Directory), all \s-1IFD\s0's being linked in a linear structure. The designers of \s-1TIFF\s0 wanted to be able to include all sorts of image information in the file (tags), like geometry, size, data arrangement and various compression options. However, lack of full \s-1TIFF\s0 support by the first publicly available readers resulted in a \*(L"reduced standard\*(R", so that even today most \s-1TIFF\s0 files contain only 32\-bit uncompressed images. Support for \s-1JPEG\s0 streams was included in version 6.0 (in 1992), but it was badly designed, so that \s-1JPEG/TIFF\s0 files are nowadays very uncommon (some changes were proposed in various technical notes in 1995 and 2002, but they never made it to version 7.0). .PP .Vb 4 \& Reference: B<"TIFF (TM)", revision 6.0, June 1992, Adobe Developers \& Association, Adobe Systems Incorporated, Mountain View, CA, USA>. \& Also: B<"Adobe PageMaker 6.0: TIFF Technical Notes", September 1995>, \& B<"Adobe Photoshop: TIFF Technical Notes", March 2002>. .Ve .PP \fI\s-1JFIF\s0\fR .IX Subsection "JFIF" .PP The \s-1JFIF\s0 (\s-1JPEG\s0 File Interchange Format) was created by Eric Hamilton at C\-Cube Microsystems in 1991 for storing JPEG-encoded data, and put into the public domain together with example reference software. \s-1JFIF\s0 is designed to allow files containing JPEG-encoded data streams to be exchanged between otherwise incompatible systems and applications. A \s-1JFIF\s0 file basically consists of a \s-1JPEG\s0 file with an \s-1APP0\s0 segment of \s-1JFIF\s0 or \s-1JFXX\s0 type at the beginning, providing information missing from the \s-1JPEG\s0 stream: version number, horizontal and vertical pixel density, pixel aspect ratio and an optional thumbnail (extended \s-1JFIF\s0 files can contain also compressed thumbnails). \s-1JFIF\s0 files conform to the general file interchange specifications in \s-1ISO/IEC 10918\-1.\s0 .PP .Vb 2 \& Reference: B<"JPEG File Interchange Format", version 1.02, September 1992, \& Eric Hamilton, C\-Cube Microsystems, Milpitas, CA, USA>. .Ve .PP \fI\s-1SPIFF\s0 [not supported yet]\fR .IX Subsection "SPIFF [not supported yet]" .PP The \s-1SPIFF\s0 (Still Picture Interchange File Format) is an official file format released in 1996 by the Joint Photographic Experts Group. It can contain image data streams encoded with a variety of compression mechanism, including \s-1JPEG\s0 and \s-1JBIG.\s0 When \s-1JPEG\s0 was standardised, disagreements among \&\s-1ISO\s0 committees prevented a standard \s-1JPEG\s0 file format from being created. The de-facto format that appeared was \s-1JFIF,\s0 with which a \s-1JPEG/SPIFF\s0 file is backward compatible. In addition to the image data, \s-1SPIFF\s0 includes information necessary to render it on common output devices, within the constraints imposed by that device. \s-1SPIFF\s0 appears not to be widely adopted; most producers prefer simple \s-1JFIF\s0 files. .PP .Vb 1 \& Reference: B (extensions to the standard). .Ve .PP \fI\s-1CIFF\s0 [not supported yet]\fR .IX Subsection "CIFF [not supported yet]" .PP The \s-1CIFF\s0 (Camera Image File Format) is a JPEG-based image file format developed by some camera makers in 1997, and constitutes an evolution of the \s-1JFIF. A CIFF\s0 file has a standard \s-1JFIF APP0\s0 segment, immediately followed by another \s-1APP0\s0 segment holding information specific to a particular digital camera in a particular format. \s-1CIFF\s0 was not at all successful and was rapidly replaced by DCF/Exif. .PP .Vb 2 \& Reference: B<"CIFF: Specification on Image Data File", \& version 1.0 rev.4, December 1997, Canon corporation>. .Ve .PP \fIExif and \s-1DCT\s0\fR .IX Subsection "Exif and DCT" .PP The Exif (Exchangeable image file format), developed by the \s-1JEITA\s0 (1996 v.1.0, 1997 v.1.1, 1998 v.2.1, 2002 v.2.2) standard was aimed at realizing a common format for the image files used with digital still cameras and other related equipment. Exif is paired with a set of naming conventions and directory layout for files in a camera memory (\s-1DCF\s0 or Design rule for Camera File system, 1999). An Exif file is a valid \s-1JPEG\s0 file with application marker segments (\s-1APP1\s0 and \s-1APP2\s0) inserted. Uncompressed files are recorded in \s-1TIFF\-6\s0 format. Related attribute information is stored in the tag information format defined in \s-1TIFF\-6\s0 (i.e., in a chain of \s-1IFD\s0's in the \s-1APP1\s0 segment). Information specific to the camera system and not defined in \s-1TIFF\s0 is stored in private tags registered for Exif. The Exif image file specification also specifies the method for recording thumbnails. The \s-1APP2\s0 segment is used when recording Flashpix extensions. Exif is the most common \s-1JPEG\s0 file format used by digital cameras nowadays. .PP .Vb 3 \& Reference: B. .Ve .SS "Structure of a \s-1JFIF APP0\s0 segment" .IX Subsection "Structure of a JFIF APP0 segment" \&\s-1APP0\s0 segments are used in the old \s-1JFIF\s0 standard to store information about the picture dimensions and an optional thumbnail. The format of a \s-1JFIF APP0\s0 segment is as follows (note that the size of thumbnail data is 3n, where n = Xthumbnail * Ythumbnail, and it is present only if n is not zero; only the first 8 records are mandatory): .PP .Vb 10 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Identifier 5 bytes ("JFIF\e000" = 0x4a46494600) \& MajorVersion 1 byte major version (e.g. 0x01) \& MinorVersion 1 byte minor version (e.g. 0x01 or 0x02) \& Units 1 byte units (0: densities give aspect ratio \& 1: density values are dots per inch \& 2: density values are dots per cm) \& Xdensity 2 bytes horizontal pixel density \& Ydensity 2 bytes vertical pixel density \& Xthumbnail 1 byte thumbnail horizontal pixel count \& Ythumbnail 1 byte thumbnail vertical pixel count \& ThumbnailData 3n bytes thumbnail image .Ve .PP There is also an \fIextended\fR \s-1JFIF\s0 (only possible for \s-1JFIF\s0 versions 1.02 and above). In this case the identifier is not \s-1JFIF\s0 but \s-1JFXX.\s0 This extension allows for the inclusion of differently encoded thumbnails. The syntax in this case is modified as follows: .PP .Vb 6 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Identifier 5 bytes ("JFXX\e000" = 0x4a46585800) \& ExtensionCode 1 byte (0x10 Thumbnail coded using JPEG \& 0x11 Thumbnail using 1 byte/pixel \& 0x13 Thumbnail using 3 bytes/pixel) .Ve .PP Then, depending on the extension code, there are other records to define the thumbnail. If the thumbnail is coded using a \fI\s-1JPEG\s0 stream\fR, a binary \&\s-1JPEG\s0 stream immediately follows the extension code (the byte count of this file is included in the byte count of the \s-1APP0\s0 Segment). This stream conforms to the syntax for a \s-1JPEG\s0 file (\s-1SOI .... SOF ... EOI\s0); however, no \&'\s-1JFIF\s0' or '\s-1JFXX\s0' marker Segments should be present: .PP .Vb 3 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& JPEGThumbnail ... bytes a variable length JPEG picture .Ve .PP If the thumbnail is stored using one byte per pixel, after the extension code one should find a palette and an indexed \s-1RGB.\s0 The records are as follows (remember that n = Xthumbnail * Ythumbnail): .PP .Vb 8 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Xthumbnail 1 byte thumbnail horizontal pixel count \& YThumbnail 1 byte thumbnail vertical pixel count \& ColorPalette 768 bytes 24\-bit RGB values for the colour palette \& (defining the colours represented by each \& value of an 8\-bit binary encoding) \& 1ByteThumbnail n bytes 8\-bit indexed values for the thumbnail .Ve .PP If the thumbnail is stored using three bytes per pixel, there is no colour palette, so the previous fields simplify into: .PP .Vb 5 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Xthumbnail 1 byte thumbnail horizontal pixel count \& YThumbnail 1 byte thumbnail vertical pixel count \& 3BytesThumbnail 3n bytes 24\-bit RGB values for the thumbnail .Ve .SS "Structure of an Exif \s-1APP1\s0 segment" .IX Subsection "Structure of an Exif APP1 segment" Exif (Exchangeable Image File format) \s-1JPEG\s0 files use \s-1APP1\s0 segments in order not to conflict with \s-1JFIF\s0 files (which use \s-1APP0\s0). Exif \s-1APP1\s0 segments store a great amount of information on photographic parameters for digital cameras and are the preferred way to store thumbnail images nowadays. They can also host an additional section with \s-1GPS\s0 data. The reference document for Exif 2.2 and the Interoperability standards are respectively: .PP .Vb 3 \& B<"Exchangeable image file format for digital still cameras: \& Exif Version 2.2", JEITA CP\-3451, Apr 2002 \& Japan Electronic Industry Development Association (JEIDA)> \& \& B<"Design rule for Camera File system", (DCF), v1.0 \& English Version 1999.1.7, Adopted December 1998 \& Japan Electronic Industry Development Association (JEIDA)> .Ve .PP The \s-1TIFF\s0 (Tagged Image File format) standard documents, as well as some updates and corrections, are also useful: .PP .Vb 8 \& B<\- "TIFF(TM) Revision 6.0, Final", June 3, 1992, Adobe Devel. Association \& \- ISO 12639, "Graphic technology \-\- Prepress digital data exchange \& \-\- Tag image file format for image technology (TIFF/IT)" \& \- ISO 12234\-2, "Electronic still\-picture imaging \-\- Removable memory \& \-\- Part 2: TIFF/EP image data format" \& \- DRAFT \- TIFF CLASS F, October 1, 1991 \& \- DRAFT \- TIFF Technical Note #2, 17\-Mar\-95 (updates for JPEG\-in\-TIFF) \& \- "Adobe Pagemaker 6.0 TIFF Technical Notes", (1,2,3 and OPI), 14\-Sep\-1995> .Ve .PP Exif \s-1APP1\s0 segments are made up by an identifier, a \s-1TIFF\s0 header and a sequence of IFDs (Image File Directories) and subIFDs. The high level IFDs are only two (\s-1IFD0,\s0 for photographic parameters, and \s-1IFD1\s0 for thumbnail parameters); they can be followed by thumbnail data. The structure is as follows: .PP .Vb 12 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Identifier 6 bytes ("Exif\e000\e000" = 0x457869660000), not stored \& Endianness 2 bytes \*(AqII\*(Aq (little\-endian) or \*(AqMM\*(Aq (big\-endian) \& Signature 2 bytes a fixed value = 42 \& IFD0_Pointer 4 bytes offset of 0th IFD (usually 8), not stored \& IFD0 ... main image IFD \& IFD0@SubIFD ... Exif private tags (optional, linked by IFD0) \& IFD0@SubIFD@Interop ... Interoperability IFD (optional,linked by SubIFD) \& IFD0@GPS ... GPS IFD (optional, linked by IFD0) \& APP1@IFD1 ... thumbnail IFD (optional, pointed to by IFD0) \& ThumbnailData ... Thumbnail image (optional, 0xffd8.....ffd9) .Ve .PP So, each Exif \s-1APP1\s0 segment starts with the identifier string \&\*(L"Exif\e000\e000\*(R"; this avoids a conflict with other applications using \s-1APP1,\s0 for instance \s-1XMP\s0 data. The three following fields (Endianness, Signature and IFD0_Pointer) constitute the so called \fI\s-1TIFF\s0 header\fR. The offset of the 0th \s-1IFD\s0 in the \s-1TIFF\s0 header, as well as \s-1IFD\s0 links in the following IFDs, is given with respect to the beginning of the \s-1TIFF\s0 header (i.e. the address of the '\s-1MM\s0' or '\s-1II\s0' pair). This means that if the 0th \s-1IFD\s0 begins (as usual) immediately after the end of the \s-1TIFF\s0 header, the offset value is 8. An Exif segment is the only part of a \s-1JPEG\s0 file whose endianness is not fixed to big-endian. .PP If the thumbnail is present it is located after the 1st \s-1IFD.\s0 There are 3 possible formats: \s-1JPEG\s0 (only this is compressed), \s-1RGB TIFF,\s0 and YCbCr \s-1TIFF.\s0 It seems that \s-1JPEG\s0 and 160x120 pixels are recommended for Exif ver. 2.1 or higher (mandatory for \s-1DCF\s0 files). Since the segment size for a segment is recorded in 2 bytes, thumbnails are limited to slightly less than 64KB. .PP Each \s-1IFD\s0 block is a structured sequence of records, called, in the Exif jargon, \fIInteroperability arrays\fR. The beginning of the 0th \s-1IFD\s0 is given by the 'IFD0_Pointer' value. The structure of an \s-1IFD\s0 is the following: .PP .Vb 6 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& 2 bytes number n of Interoperability arrays \& 12n bytes the n arrays (12 bytes each) \& 4 bytes link to next IFD (can be zero) \& ... additional data area .Ve .PP The next_link field of the 0th \s-1IFD,\s0 if non-null, points to the beginning of the 1st \s-1IFD.\s0 The 1st \s-1IFD\s0 as well as all other sub-IFDs must have next_link set to zero. The thumbnail location and size is given by some interoperability arrays in the 1st \s-1IFD.\s0 The structure of an Interoperability array is: .PP .Vb 6 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& 2 bytes Tag (a unique 2\-byte number) \& 2 bytes Type (one out of 12 types) \& 4 bytes Count (the number of values) \& 4 bytes Value Offset (value or offset) .Ve .PP The possible types are the same as for the Record class, exception made for nibbles and references (see \*(L"Managing a \s-1JPEG\s0 Record object\*(R" in Image::MetaData::JPEG). Indeed, the Record class is modelled after interoperability arrays, and each interoperability array gets stored as a Record with given tag, type, count and values. The \*(L"value offset\*(R" field gives the offset from the \s-1TIFF\s0 header base where the value is recorded. It contains the actual value if it is not larger than 4 bytes (32 bits). If the value is shorter than 4 bytes, it is recorded in the lower end of the 4\-byte area (smaller offsets). For further details see the section \&\*(L"Valid tags for Exif \s-1APP1\s0 data\*(R" in Image::MetaData::JPEG::TagLists. .SS "Structure of an \s-1XMP APP1\s0 segment" .IX Subsection "Structure of an XMP APP1 segment" \&\s-1XMP\s0 (eXtensible Metadata Platform) \s-1JPEG\s0 files use \s-1APP1\s0 segments in order to store metadata information; the storage format (serialisation) is \s-1RDF\s0 (Resource Description Framework) implemented as an application of \s-1XML. XMP\s0 Exif \s-1APP1\s0 segments can store all information stored in Exif and \s-1IPTC\s0 segments, as well as custom and future schemas. The reference document for \&\s-1XMP 3.2\s0 can be requested from Adobe Systems Incorporated: .PP .Vb 2 \& B<"XMP Specification", version 3.2, June 2005, Adobe Systems Inc., \& 345 Park Avenue, San Jose, CA 95110\-2704, L> \& \& B> \& B> .Ve .PP \&\s-1XMP APP1\s0 segments are made up by an identifier and a Unicode \s-1XMP\s0 packet (the encoding is usually \s-1UTF\-8,\s0 but it can also be \s-1UTF\-16\s0 or \s-1UTF\-32,\s0 both big-endian or little-endian). The packet cannot be split in multiple segments, so there is a maximum size of approximately 64KB. The structure is very simple: a fixed \s-1XMP\s0 namespace \s-1URI\s0 (null terminated, and without quotation marks) followed by the \s-1XMP\s0 packet: .PP .Vb 4 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Identifier 29 bytes http://ns.adobe.com/xap/1.0/\e000 \& ... the actual Unicode XMP packet .Ve .PP The packet content is sandwiched between a header and a trailer, and may contain padding whitespaces at the end. The \fIxpacket\fR header has two mandatory attributes, \fIbegin\fR and \fIid\fR (order is important), separated by exactly one space (U+0020). Attribute values, here and in the following, are enclosed by single quotes (U+0027) or double quotes (U+0022). The value of \fIbegin\fR must be the Unicode \fIzero-width non-breaking space\fR (U+FEFF), to be used as a byte-order marker during blind scans; an empty value is also acceptable (for backward compatibility), and stands for \s-1UTF\-8.\s0 The value of \fIid\fR is fixed. Other attributes, like (deprecated) \fIbytes\fR or \&\fIencoding\fR, may be ignored. A padding of 2KB or 4KB, with a newline every 100 spaces, is recommended. The \fIend\fR attribute of the trailer may have a value of \*(L"r\*(R" (read-only) or \*(L"w\*(R" (modifiable). .PP .Vb 4 \& Header <?xpacket begin="..." id="W5M0MpCehiHzreSzNTczkc9d" ...?> \& Content ... serialised XMP data (see later) ... \& Padding ... padding with XML whitespaces ... \& Trailer <?xpacket end="w"?> .Ve .PP The structure of the packet content is as follows. There is an optional \&\fIx:xmpmeta\fR (or \fIx:xapmeta\fR for older files) element, with a mandatory \&\fIxmlns:x\fR attribute set to \*(L"adobe:ns:meta/\*(R" and other optional attributes, which can be ignored (currently, Adobe's toolkit stores its version in \&\fIx:xmptk\fR). Inside it (or at top level, if it is absent), there is exactly one \fIrdf:RDF\fR element with an attribute specifying the \fIxmlns:rdf\fR namespace (other namespaces, whose role is not clear to me, can be listed here as additional attributes). Inside the \fIrdf:RDF\fR element then, all \s-1XMP\s0 properties are stored inside one or more \fIrdf:Description\fR elements: .PP .Vb 8 \& <x:xmpmeta xmlns:x=\*(Aqadobe:ns:meta/\*(Aq ..opt.attributes..> \& <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22\-rdf\-syntax\-ns#"> \& <rdf:Description ...> .... </rdf:Description> \& <rdf:Description ...> .... </rdf:Description> \& ......... \& <rdf:Description ...> .... </rdf:Description> \& </rdf:RDF> \& </x:xmpmeta> .Ve .PP \&\fBrdf:Description\fR elements and schemas are usually in one-to-one correspondence, although this is just a convention and not a rule. Each element has two mandatory attributes, \fIrdf:about\fR and \fIxmlns:NAME\fR. The \&\fIrdf:about\fR attribute is usually empty (it can however contain an application specific \s-1URI\s0), and its value \fBmust\fR be shared among all \&\fIrdf:Description\fR elements. The \fIxmlns:NAME\fR attribute specifies the local namespace prefix (\s-1NAME\s0 stands for the actual prefix). Additional namespaces can be specified via \fIxmlns\fR attributes. .PP .Vb 6 \& <rdf:Description rdf:about="" xmlns:NAME="..."> \& <NAME:propname1 ...> .... </NAME:propname1> \& <NAME:propname2 ...> .... </NAME:propname2> \& ......... \& <NAME:propnameN ...> .... </NAME:propnameN> \& </rdf:Description> .Ve .PP Properties can come in various flavours. A \fBsimple property\fR is just some literal value between opening and closing tags carrying the property name; there exists also an abbreviated form where properties are listed as attributes of the \fIrdf:Description\fR tag (in this case there is no closing \&\fIrdf:Description\fR tag, and the opening tags ends with the '/' character). Simple properties can have qualifiers (attributes). This is an example of a description element with only simple properties: .PP .Vb 5 \& <rdf:Description rdf:about="" xmlns:xap="http://ns.adobe.com/xap/1.0/"> \& <xap:CreatorTool>Adobe Photoshop Elements 3.0</xap:CreatorTool> \& <xap:ModifyDate>2005\-05\-12T44:39:11+03:00</xap:ModifyDate> \& </rdf:Description> \& or \& \& <rdf:Description rdf:about="" xmlns:xap="http://ns.adobe.com/xap/1.0/" \& xap:CreatorTool="Adobe Photoshop Elements 3.0" \& xap:ModifyDate="2005\-06\-13T23:38:11+02:00"/> .Ve .PP A \fBstructured property\fR is characterised by a \fIrdf:Description\fR block instead of a simple content. The inner description block, which does not allow for an \fIrdf:about\fR attribute, contains one or more named properties (which can, of course, contain further substructures). This is an example of a description element with one structured property: .PP .Vb 9 \& <rdf:Description rdf:about="" xmlns:xmpTPg="..an URI.."> \& <xmpTPg:MaxPageSize> \& <rdf:Description xmlns:stDim="..another URI.."> \-\-\-. Content \& <stDim:w>21</stDim:w> | of the \& <stDim:h>27</stDim:h> | MaxPageSize \& <stDim:unit>centimetres</stDim:unit> | structured \& </rdf:Description> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\*(Aq property \& </xmpTPg:MaxPageSize> \& </rdf:Description> .Ve .PP An \fBarray property\fR is, on the other hand, just an array of same-type properties. It can come in three varieties: as a \fIBag\fR (an unordered set), as a \fISeq\fRuence (an ordered list) and as an \fIAlt\fRernative list (see later). As for structured properties, each item in the array is a property and can contain further substructures. The item list is delimited by an \&\fIrdf:Bag\fR, an \fIrdf:Seq\fR, or an \fIrdf:Alt\fR tag pair, respectively. Each item is delimited by a pair of \fIrdf:li\fR tags. The following example illustrates an unordered array property with three items: .PP .Vb 9 \& <rdf:Description rdf:about="" xmlns:dc="..an URI.."> \& <dc:subject> \& <rdf:Bag> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. Content \& <rdf:li>metadata</rdf:li> | of the \& <rdf:li>schema</rdf:li> | unordered \& <rdf:li>XMP</rdf:li> | array \& </rdf:Bag> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\*(Aq dc:subject \& </dc:subject> \& </rdf:Description> .Ve .PP A simple property (but, currently, not a structured or array property) can have \fIqualifiers\fR. For instance, items in an array property can be qualified; in this case, the content of \fIrdf:li\fR is not text, but an \&\fIrdf:Description\fR (without attributes) containing the actual value (as \&\fIrdf:value\fR) and the qualifiers as additional properties; a qualifier name belongs to a secondary namespace, specified as an attribute of the outer \&\fIrdf:Description\fR. The following example illustrates the use of property qualifiers: .PP .Vb 10 \& <rdf:Description rdf:about="" xmlns:dc="..1stURI.." xmlns:ns="..2ndURI.."> \& <dc:creator> \& <rdf:Seq> \& <rdf:li> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. An element \& <rdf:Description> | of the \& <rdf:value>William Gilbert</rdf:value> | ordered array \& <ns:role>lyricist</ns:role> | dc:creator \& </rdf:Description> | with a \& </rdf:li> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\*(Aq qualifier \& <rdf:li> \& <rdf:Description> \& <rdf:value>Arthur Sullivan</rdf:value> \& <ns:role>composer</ns:role> \& </rdf:Description> \& </rdf:li> \& </rdf:Seq> \& </dc:creator> \& </rdf:Description> .Ve .PP Text properties in an \fIalternative array property\fR may have a special qualifier (the \fIxml:lang\fR property) specifying the language of the text. In this case, the serialisation is different: \fIxml:lang\fR for each item of the array becomes an attribute of the \fIrdf:li\fR tag. The default value is indicated by a special value of the qualifier, or is taken from the first item in the list. The following example illustrates an array of \&\fIlanguage alternatives\fR: .PP .Vb 8 \& <xmp:Title> \& <rdf:Alt> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. List of \& <rdf:li xml:lang="x\-default">Title</rdf:li> | alternatives \& <rdf:li xml:lang="en\-us">Title</rdf:li> | corresponding \& <rdf:li xml:lang="fr\-fr">Titre</rdf:li> | to xmp:Title; \& <rdf:li xml:lang="it\-it">Titolo</rdf:li> | the language \& </rdf:Alt> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\*(Aq is xml:lang \& </xmp:Title> .Ve .PP The interpretation of the values of properties conforming to the previously described syntax is done with the aid of the \fBschema\fR corresponding to the property namespace. The most common schemas in \s-1JPEG\s0 files are the following ones (note, however, that \s-1XMP\s0 is intrinsically extensible, so this list will never be exhaustive): .IP "Dublin Core schema =item \s-1XMP\s0 basic schema =item \s-1XMP\s0 rights management schema =item \s-1XMP\s0 media management schema =item \s-1XMP\s0 basic job ticket schema =item \s-1XMP\s0 paged-text schema =item \s-1XMP\s0 dynamic media schema =item Adobe Photoshop schema =item Camera row schema =item Exif schemas =item \s-1IPTC\s0 schema" 4 .IX Item "Dublin Core schema =item XMP basic schema =item XMP rights management schema =item XMP media management schema =item XMP basic job ticket schema =item XMP paged-text schema =item XMP dynamic media schema =item Adobe Photoshop schema =item Camera row schema =item Exif schemas =item IPTC schema" .SS "Structure of a Photoshop-style \s-1APP13\s0 segment" .IX Subsection "Structure of a Photoshop-style APP13 segment" The Adobe's Photoshop program, a de-facto standard for image manipulation, uses the \s-1APP13\s0 segment for storing non-graphic information, such as layers, paths, \s-1IPTC\s0 data and more. The unit for this kind of information is called a \*(L"resource data block\*(R" (because they hold data that was stored in the Macintosh's resource fork in early versions of Photoshop). The content of an \s-1APP13\s0 segment is formed by an identifier string (usually \*(L"Photoshop 3.0\e000\*(R", but also 'Adobe_Photoshop2.5:', used by earlier versions, is accepted; in this case some additional undocumented bytes are read (resolution info?) and saved in a root 'Resolution' record) followed by a sequence of resource data blocks; a resource block has the following structure: .PP .Vb 7 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& (Type) 4 bytes Photoshop uses \*(Aq8BIM\*(Aq from ver 4.0 on \& (ID) 2 bytes a unique identifier, e.g., "\e004\e004" for IPTC \& (Name) ... a Pascal string (padded to make size even) \& (Size) 4 bytes actual size of resource data \& (Data) ... resource data, padded to make size even .Ve .PP (a Pascal string is made up of a single byte, giving the string length, followed by the string itself, padded to make size even including the length byte; since the string length is explicit, there is no need of a terminating null character). The signature (type) is usually '8BIM', but Photoshop used '8BPS' up to version 3.0, and some rogue program (Adobe PhotoDeluxe?) is using '\s-1PHUT\s0' (\*(L"PHotoshop User Tags\*(R" ?) for path information (ID=7d0\-bb7). Valid Image Resource IDs are listed in the Photoshop-style tags' list section. In general a resource block contains only a few bytes, but there is an important block, the \s-1IPTC\s0 block, which can be quite large; the structure of this block is analysed in more detail in the \s-1IPTC\s0 data block section. .PP The reference document for the Photoshop file format is: .PP .Vb 2 \& B<"Adobe Photoshop 6.0: File Formats Specifications", \& Adobe System Inc., ver.6.0, rel.2, November 2000>. .Ve .PP Another interesting source of information is: .PP .Vb 3 \& B<"\e"Solo\e" Image File Format. RichTIFF and its \& replacement by \e"Solo\e" JFIF", version 2.0a, \& Coatsworth Comm. Inc., Brampton, Ontario, Canada> .Ve .PP \fIStructure of an \s-1IPTC\s0 data block\fR .IX Subsection "Structure of an IPTC data block" .PP An \s-1IPTC/NAA\s0 resource data block of a Photoshop-style \s-1APP13\s0 segment embeds an \s-1IPTC\s0 stream conforming to the standard defined by the International Press and Telecommunications Council (\s-1IPTC\s0) and the Newspaper Association of America (\s-1NAA\s0) for exchanging interoperability information related to various news objects. The data part of a resource block, an \s-1IPTC\s0 stream, is simply a sequence of units called \fIdatasets\fR; no preamble nor count is present. Each dataset consists of a unique tag header and a data field (the list of valid tags [dataset numbers] can be found in section about \s-1IPTC\s0 data). A standard tag header is used when the data field size is less than 32768 bytes; otherwise, an extended tag header is used. The datasets do not need to show up in numerical order according to their tag. The structure of a dataset is: .PP .Vb 8 \& [Record name] [size] [description] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& (Tag marker) 1 byte this must be 0x1c \& (Record number) 1 byte always 2 for 2:xx datasets \& (Dataset number) 1 byte this is what we call a "tag" \& (Size specifier) 2 bytes data length (< 32768 bytes) or length of ... \& (Size specifier) ... data length (> 32767 bytes only) \& (Data) ... (its length is specified before) .Ve .PP So, standard datasets have a 5 bytes tag header; the last two bytes in the header contain the data field length, the most significant bit being always 0. For extended datasets instead, these two bytes contain the length of the (following) data field length, the most significant bit being always 1. The value of the most significant bit thus distinguishes \*(L"standard\*(R" from \&\*(L"extended\*(R"; in digital photographies, I assume that the datasets which are actually used (a subset of the standard) are always standard; therefore, we likely do not have the \s-1IPTC\s0 block spanning more than one \s-1APP13\s0 segment. The record types defined by the IPTC-NAA standard are the following (but the \&\*(L"pseudo\*(R"\-standard by Adobe for \s-1APP13 IPTC\s0 data is restricted to the first application record, 2:xx, and sometimes to the envelope record, 1:xx, I believe, because everything else can be accomodated more simply by other \&\s-1JPEG\s0 Segments): .PP .Vb 7 \& [Record name] [dataset record number] \& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \& Object Envelop Record 1:xx \& Application Records: 2:xx through 6:xx \& Pre\-ObjectData Descriptor Record: 7:xx \& ObjectData Record: 8:xx \& Post\-ObjectData Descriptor Record: 9:xx .Ve .PP The reference document for the \s-1IPTC\s0 standard is: .PP .Vb 2 \& B<"IPTC\-NAA: Information Interchange Model", version 4, 1\-Jul\-1999, \& Comité International des Télécommunications de Presse> .Ve .SH "AUTHOR" .IX Header "AUTHOR" Stefano Bettelli, \fBbettelli@cpan.org\fR .SH "COPYRIGHT AND LICENSE" .IX Header "COPYRIGHT AND LICENSE" Copyright (C) 2004,2005,2006 by Stefano Bettelli .PP This library is free software; you can redistribute it and/or modify it under the terms of the \s-1GNU\s0 General Public License. See the \&\s-1COPYING\s0 and \s-1LICENSE\s0 file for the license terms. .SH "SEE ALSO" .IX Header "SEE ALSO" The main documentation page for the Image::MetaData::JPEG module.