NAME¶
Image::MetaData::JPEG::Structures - This document describes the structure of a
JPEG 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.
THE STRUCTURE OF JPEG PICTURES¶
The JPEG (Joint Photographic Experts Group) ISO 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 JPEG 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
"baseline" JPEG 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 ...). JPEG refers only to a class of compression
algorithms, not to a specific file format. In order to produce files with
embedded JPEG 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 JPEG file can be described by the following pseudo
production rules (for sake of simplicity, some additional constraints between
tables and SOF segments are neglected).
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
This package does not check that a JPEG file is really correct; it accepts a
looser syntax, were segments and ECS blocks are just contiguous (basically,
because it does not need to display the image!). All meta-data information is
concentrated in the (COM*) and (APP) Segments, exception made for some records
in the (SOF*) segment (e.g. image dimensions).
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>.
A SHORT HISTORY OF JPEG FILE FORMATS¶
TIFF [not supported]
The TIFF (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 TIFF file, each page in a separate IFD (Image
File Directory), all IFD's being linked in a linear structure. The designers
of TIFF 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 TIFF support by the first publicly available
readers resulted in a "reduced standard", so that even today most
TIFF files contain only 32-bit uncompressed images. Support for JPEG streams
was included in version 6.0 (in 1992), but it was badly designed, so that
JPEG/TIFF 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).
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>.
JFIF
The JFIF (JPEG 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. JFIF is designed to allow
files containing JPEG-encoded data streams to be exchanged between otherwise
incompatible systems and applications. A JFIF file basically consists of a
JPEG file with an APP0 segment of JFIF or JFXX type at the beginning,
providing information missing from the JPEG stream: version number, horizontal
and vertical pixel density, pixel aspect ratio and an optional thumbnail
(extended JFIF files can contain also compressed thumbnails). JFIF files
conform to the general file interchange specifications in ISO/IEC 10918-1.
Reference: B<"JPEG File Interchange Format", version 1.02, September 1992,
Eric Hamilton, C-Cube Microsystems, Milpitas, CA, USA>.
SPIFF [not supported yet]
The SPIFF (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 JPEG
and JBIG. When JPEG was standardised, disagreements among ISO committees
prevented a standard JPEG file format from being created. The de-facto format
that appeared was JFIF, with which a JPEG/SPIFF file is backward compatible.
In addition to the image data, SPIFF includes information necessary to render
it on common output devices, within the constraints imposed by that device.
SPIFF appears not to be widely adopted; most producers prefer simple JFIF
files.
Reference: B<ISO/IEC IS 10918-1, part 3> (extensions to the standard).
CIFF [not supported yet]
The CIFF (Camera Image File Format) is a JPEG-based image file format developed
by some camera makers in 1997, and constitutes an evolution of the JFIF. A
CIFF file has a standard JFIF APP0 segment, immediately followed by another
APP0 segment holding information specific to a particular digital camera in a
particular format. CIFF was not at all successful and was rapidly replaced by
DCF/Exif.
Reference: B<"CIFF: Specification on Image Data File",
version 1.0 rev.4, December 1997, Canon corporation>.
Exif and DCT
The Exif (Exchangeable image file format), developed by the JEITA (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 (DCF or Design rule for Camera File
system, 1999). An Exif file is a valid JPEG file with application marker
segments (APP1 and APP2) inserted. Uncompressed files are recorded in TIFF-6
format. Related attribute information is stored in the tag information format
defined in TIFF-6 (i.e., in a chain of IFD's in the APP1 segment). Information
specific to the camera system and not defined in TIFF is stored in private
tags registered for Exif. The Exif image file specification also specifies the
method for recording thumbnails. The APP2 segment is used when recording
Flashpix extensions. Exif is the most common JPEG file format used by digital
cameras nowadays.
Reference: B<JEITA CP-3451, "Exchangeable image file format for digital
still cameras: Exif Version 2.2", April 2002, Japan Electronics
and Information Technology Industries Association>.
Structure of a JFIF APP0 segment¶
APP0 segments are used in the old JFIF standard to store information about the
picture dimensions and an optional thumbnail. The format of a JFIF APP0
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):
[Record name] [size] [description]
---------------------------------------
Identifier 5 bytes ("JFIF\000" = 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
There is also an
extended JFIF (only possible for JFIF versions 1.02 and
above). In this case the identifier is not JFIF but JFXX. This extension
allows for the inclusion of differently encoded thumbnails. The syntax in this
case is modified as follows:
[Record name] [size] [description]
---------------------------------------
Identifier 5 bytes ("JFXX\000" = 0x4a46585800)
ExtensionCode 1 byte (0x10 Thumbnail coded using JPEG
0x11 Thumbnail using 1 byte/pixel
0x13 Thumbnail using 3 bytes/pixel)
Then, depending on the extension code, there are other records to define the
thumbnail. If the thumbnail is coded using a
JPEG stream, a binary JPEG
stream immediately follows the extension code (the byte count of this file is
included in the byte count of the APP0 Segment). This stream conforms to the
syntax for a JPEG file (SOI .... SOF ... EOI); however, no 'JFIF' or 'JFXX'
marker Segments should be present:
[Record name] [size] [description]
---------------------------------------
JPEGThumbnail ... bytes a variable length JPEG picture
If the thumbnail is stored using one byte per pixel, after the extension code
one should find a palette and an indexed RGB. The records are as follows
(remember that n = Xthumbnail * Ythumbnail):
[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
If the thumbnail is stored using three bytes per pixel, there is no colour
palette, so the previous fields simplify into:
[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
Structure of an Exif APP1 segment¶
Exif (Exchangeable Image File format) JPEG files use APP1 segments in order not
to conflict with JFIF files (which use APP0). Exif APP1 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 GPS data. The reference document for Exif 2.2 and the
Interoperability standards are respectively:
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)>
The TIFF (Tagged Image File format) standard documents, as well as some updates
and corrections, are also useful:
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>
Exif APP1 segments are made up by an identifier, a TIFF header and a sequence of
IFDs (Image File Directories) and subIFDs. The high level IFDs are only two
(IFD0, for photographic parameters, and IFD1 for thumbnail parameters); they
can be followed by thumbnail data. The structure is as follows:
[Record name] [size] [description]
---------------------------------------
Identifier 6 bytes ("Exif\000\000" = 0x457869660000), not stored
Endianness 2 bytes 'II' (little-endian) or 'MM' (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)
So, each Exif APP1 segment starts with the identifier string
"Exif\000\000"; this avoids a conflict with other applications using
APP1, for instance XMP data. The three following fields (Endianness, Signature
and IFD0_Pointer) constitute the so called
TIFF header. The offset of
the 0th IFD in the TIFF header, as well as IFD links in the following IFDs, is
given with respect to the beginning of the TIFF header (i.e. the address of
the 'MM' or 'II' pair). This means that if the 0th IFD begins (as usual)
immediately after the end of the TIFF header, the offset value is 8. An Exif
segment is the only part of a JPEG file whose endianness is not fixed to
big-endian.
If the thumbnail is present it is located after the 1st IFD. There are 3
possible formats: JPEG (only this is compressed), RGB TIFF, and YCbCr TIFF. It
seems that JPEG and 160x120 pixels are recommended for Exif ver. 2.1 or higher
(mandatory for DCF files). Since the segment size for a segment is recorded in
2 bytes, thumbnails are limited to slightly less than 64KB.
Each IFD block is a structured sequence of records, called, in the Exif jargon,
Interoperability arrays. The beginning of the 0th IFD is given by the
'IFD0_Pointer' value. The structure of an IFD is the following:
[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
The next_link field of the 0th IFD, if non-null, points to the beginning of the
1st IFD. The 1st IFD 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 IFD. The structure of an Interoperability array is:
[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)
The possible types are the same as for the Record class, exception made for
nibbles and references (see "Managing a JPEG Record object" 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 "value offset"
field gives the offset from the TIFF 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 "Valid
tags for Exif APP1 data" in Image::MetaData::JPEG::TagLists.
Structure of an XMP APP1 segment¶
XMP (eXtensible Metadata Platform) JPEG files use APP1 segments in order to
store metadata information; the storage format (serialisation) is RDF
(Resource Description Framework) implemented as an application of XML. XMP
Exif APP1 segments can store all information stored in Exif and IPTC segments,
as well as custom and future schemas. The reference document for XMP 3.2 can
be requested from Adobe Systems Incorporated:
B<"XMP Specification", version 3.2, June 2005, Adobe Systems Inc.,
345 Park Avenue, San Jose, CA 95110-2704, L<http://www.adobe.com>>
B<See also: L<http://xml.coverpages.org/xmp.html>>
B<See also: L<http://www.w3.org/TR/REC-rdf-syntax/>>
XMP APP1 segments are made up by an identifier and a Unicode XMP packet (the
encoding is usually UTF-8, but it can also be UTF-16 or UTF-32, 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 XMP namespace URI (null terminated, and without quotation
marks) followed by the XMP packet:
[Record name] [size] [description]
---------------------------------------
Identifier 29 bytes http://ns.adobe.com/xap/1.0/\000
<XMP packet> ... the actual Unicode XMP packet
The packet content is sandwiched between a header and a trailer, and may contain
padding whitespaces at the end. The
xpacket header has two mandatory
attributes,
begin and
id (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
begin must be the Unicode
zero-width non-breaking space
(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 UTF-8. The
value of
id is fixed. Other attributes, like (deprecated)
bytes
or
encoding, may be ignored. A padding of 2KB or 4KB, with a newline
every 100 spaces, is recommended. The
end attribute of the trailer may
have a value of "r" (read-only) or "w" (modifiable).
Header <?xpacket begin="..." id="W5M0MpCehiHzreSzNTczkc9d" ...?>
Content ... serialised XMP data (see later) ...
Padding ... padding with XML whitespaces ...
Trailer <?xpacket end="w"?>
The structure of the packet content is as follows. There is an optional
x:xmpmeta (or
x:xapmeta for older files) element, with a
mandatory
xmlns:x attribute set to "adobe:ns:meta/" and other
optional attributes, which can be ignored (currently, Adobe's toolkit stores
its version in
x:xmptk). Inside it (or at top level, if it is absent),
there is exactly one
rdf:RDF element with an attribute specifying the
xmlns:rdf namespace (other namespaces, whose role is not clear to me,
can be listed here as additional attributes). Inside the
rdf:RDF
element then, all XMP properties are stored inside one or more
rdf:Description elements:
<x:xmpmeta xmlns:x='adobe:ns:meta/' ..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>
rdf:Description 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,
rdf:about and
xmlns:NAME.
The
rdf:about attribute is usually empty (it can however contain an
application specific URI), and its value
must be shared among all
rdf:Description elements. The
xmlns:NAME attribute specifies the
local namespace prefix (NAME stands for the actual prefix). Additional
namespaces can be specified via
xmlns attributes.
<rdf:Description rdf:about="" xmlns:NAME="...">
<NAME:propname1 ...> .... </NAME:propname1>
<NAME:propname2 ...> .... </NAME:propname2>
.........
<NAME:propnameN ...> .... </NAME:propnameN>
</rdf:Description>
Properties can come in various flavours. A
simple property 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
rdf:Description tag (in this case there is no closing
rdf:Description 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:
<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"/>
A
structured property is characterised by a
rdf:Description block
instead of a simple content. The inner description block, which does not allow
for an
rdf:about 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:
<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> -----------------' property
</xmpTPg:MaxPageSize>
</rdf:Description>
An
array property is, on the other hand, just an array of same-type
properties. It can come in three varieties: as a
Bag (an unordered
set), as a
Sequence (an ordered list) and as an
Alternative 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
rdf:Bag, an
rdf:Seq, or an
rdf:Alt tag pair,
respectively. Each item is delimited by a pair of
rdf:li tags. The
following example illustrates an unordered array property with three items:
<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> ----------------' dc:subject
</dc:subject>
</rdf:Description>
A simple property (but, currently, not a structured or array property) can have
qualifiers. For instance, items in an array property can be qualified;
in this case, the content of
rdf:li is not text, but an
rdf:Description (without attributes) containing the actual value (as
rdf:value) and the qualifiers as additional properties; a qualifier
name belongs to a secondary namespace, specified as an attribute of the outer
rdf:Description. The following example illustrates the use of property
qualifiers:
<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> ----------------' 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>
Text properties in an
alternative array property may have a special
qualifier (the
xml:lang property) specifying the language of the text.
In this case, the serialisation is different:
xml:lang for each item of
the array becomes an attribute of the
rdf:li 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
language
alternatives:
<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> ----------------' is xml:lang
</xmp:Title>
The interpretation of the values of properties conforming to the previously
described syntax is done with the aid of the
schema corresponding to
the property namespace. The most common schemas in JPEG files are the
following ones (note, however, that XMP is intrinsically extensible, so this
list will never be exhaustive):
- 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
Structure of a Photoshop-style APP13 segment¶
The Adobe's Photoshop program, a de-facto standard for image manipulation, uses
the APP13 segment for storing non-graphic information, such as layers, paths,
IPTC data and more. The unit for this kind of information is called a
"resource data block" (because they hold data that was stored in the
Macintosh's resource fork in early versions of Photoshop). The content of an
APP13 segment is formed by an identifier string (usually "Photoshop
3.0\000", 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:
[Record name] [size] [description]
---------------------------------------
(Type) 4 bytes Photoshop uses '8BIM' from ver 4.0 on
(ID) 2 bytes a unique identifier, e.g., "\004\004" 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
(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 'PHUT'
("PHotoshop User Tags" ?) 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 IPTC block, which can be quite large; the structure of this block
is analysed in more detail in the IPTC data block section.
The reference document for the Photoshop file format is:
B<"Adobe Photoshop 6.0: File Formats Specifications",
Adobe System Inc., ver.6.0, rel.2, November 2000>.
Another interesting source of information is:
B<"\"Solo\" Image File Format. RichTIFF and its
replacement by \"Solo\" JFIF", version 2.0a,
Coatsworth Comm. Inc., Brampton, Ontario, Canada>
Structure of an IPTC data block
An IPTC/NAA resource data block of a Photoshop-style APP13 segment embeds an
IPTC stream conforming to the standard defined by the International Press and
Telecommunications Council (IPTC) and the Newspaper Association of America
(NAA) for exchanging interoperability information related to various news
objects. The data part of a resource block, an IPTC stream, is simply a
sequence of units called
datasets; 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 IPTC 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:
[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)
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 "standard" from
"extended"; 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 IPTC block spanning more than one APP13
segment. The record types defined by the IPTC-NAA standard are the following
(but the "pseudo"-standard by Adobe for APP13 IPTC 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 JPEG Segments):
[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
The reference document for the IPTC standard is:
B<"IPTC-NAA: Information Interchange Model", version 4, 1-Jul-1999,
ComitE<eacute> International des TE<eacute>lE<eacute>communications de Presse>
AUTHOR¶
Stefano Bettelli,
bettelli@cpan.org
COPYRIGHT AND LICENSE¶
Copyright (C) 2004,2005,2006 by Stefano Bettelli
This library is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License. See the COPYING and LICENSE file
for the license terms.
SEE ALSO¶
The main documentation page for the Image::MetaData::JPEG module.
