Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Image::MetaData::JPEG:UseruContributed PerImage::MetaData::JPEG::Structures(3)

       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 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>.

       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>.


       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

	 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

	  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

   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<>>

	  B<See	also: L<>>
	  B<See	also: L<>>

       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\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="">
		 <rdf:Description ...> .... </rdf:Description>
		 <rdf:Description ...> .... </rdf:Description>
		 <rdf:Description ...> .... </rdf:Description>

       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>

       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="">
	      <xap:CreatorTool>Adobe Photoshop Elements	3.0</xap:CreatorTool>

	   <rdf:Description rdf:about="" xmlns:xap=""
	      xap:CreatorTool="Adobe Photoshop Elements	3.0"

       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=" URI..">
		 <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

       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

	   <rdf:Description rdf:about="" xmlns:dc="	URI..">
		 <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

       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..">
		    <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:value>Arthur Sullivan</rdf:value>

       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:

	      <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

       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,
	  ComitA(C) International des TA(C)lA(C)communications de Presse>

       Stefano Bettelli,

       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.

       The main	documentation page for the Image::MetaData::JPEG module.

       Hey! The	above document had some	coding errors, which are explained

       Around line 633:
	   Non-ASCII character seen before =encoding in	'ComitA(C)'. Assuming

perl v5.32.1			  2006-05-Image::MetaData::JPEG::Structures(3)


Want to link to this manual page? Use this URL:

home | help