0N/A<!
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2362N/ACopyright (c) 2000, 2001, Oracle and/or its affiliates. All rights reserved. 0N/ADO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/AThis code is free software; you can redistribute it and/or modify it 0N/Aunder the terms of the GNU General Public License version 2 only, as 2362N/Apublished by the Free Software Foundation. Oracle designates this 0N/Aparticular file as subject to the "Classpath" exception as provided 2362N/Aby Oracle in the LICENSE file that accompanied this code. 0N/AThis code is distributed in the hope that it will be useful, but WITHOUT 0N/AANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/AFITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/Aversion 2 for more details (a copy is included in the LICENSE file that 0N/Aaccompanied this code). 0N/AYou should have received a copy of the GNU General Public License version 0N/A2 along with this work; if not, write to the Free Software Foundation, 0N/AInc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2365N/APlease contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A<
title>JPEG Metadata Format Specification and Usage Notes</
title>
0N/A<
body bgcolor="white">
0N/AJPEG Metadata Format Specification and Usage Notes
0N/A<
a href=#
metadata>JPEG Metadata</
a><
br>
0N/A<
a href=#
abbrev>Abbreviated Streams</
a><
br>
0N/A<
a href=#
tables>Sources of Tables</
a><
br>
0N/A<
a href=#
color>Colorspace Transformations and Conventional Markers</
a><
br>
0N/A<
a href=#
thumbs>Thumbnail Images</
a><
br>
0N/A<
a href=#
prog>Progressive Encoding</
a><
br>
0N/A<
a href=#
tree>Native Metadata Format Tree Structure and Editing</
a><
br>
0N/A<
a href=#
image>Image Metadata DTD</
a><
br>
0N/A<
a href=#
stream>Stream Metadata DTD</
a>
0N/A<
bold>NOTE</
bold>: It is important to call <
code>dispose()</
code>
0N/Aon the JPEG reader and writer objects when they are no longer needed, as
0N/Athey consume significant native resources which are not adequately recovered
0N/Aby garbage collection. Both reader and writer call <
code>dispose()</
code>
0N/Ain their finalizers, but those finalizers may not be called before the native
0N/Acode has exhausted native memory.
0N/AThe JPEG writer does not support replacing pixels.
0N/A<
a name=metadata>JPEG Metadata</
a>
0N/AJPEG metadata consists of the data contained in marker segments in a JPEG
0N/Astream. The image metadata object returned from a read describes the
0N/Acontents of the marker segments between the <
code>SOI</
code> marker and
0N/Athe <
code>EOI</
code> marker for that image. The image metadata object
0N/Apassed into a write determines the contents of the stream between the
0N/A<
code>SOI</
code> marker and the <
code>EOI</
code> marker for that image,
0N/Asubject to the controls in any <
code>ImageWriteParam</
code>.
0N/AStream metadata is used only for tables-only images found (or to be
0N/Aplaced) at the beginning of a stream containing abbreviated images.
0N/ATables-only images are not treated as images and do not consume an
0N/Aimage index. The stream metadata object returned from a read describes the
0N/Acontents of the marker segments between the <
code>SOI</
code> marker and
0N/Athe <
code>EOI</
code> marker for the single tables-only image at the
0N/Abeginning of the stream, if one is present. If no tables-only image is
0N/Apresent at the front of the stream, the <
code>getStreamMetadata</
code>
0N/Amethod of <
code>ImageReader</
code> returns <
code>null</
code>. If
0N/Astream metadata is provided to the writer, a single tables-only image
0N/Acontaining the tables from the stream metadata object will be written at
0N/Athe beginning of the stream. If the stream metadata object contains no
0N/Atables, default tables will be written. As the sole purpose of stream
0N/Ametadata is for specifying tables-only images at the front of abbreviated
0N/Astreams, the stream metadata argument is useful only on the
0N/Aobject containing the tables from the <
code>ImageWriteParam</
code> argument,
0N/Aif it is a <
code>JPEGImageWriteParam</
code> and contains tables. Otherwise,
0N/Athe returned object will contain default tables.
0N/Ametadata object containing <
bold>no</
bold> tables if the
0N/A<
code>ImageWriteParam</
code> argument contains tables. Otherwise the
0N/Areturned metadata object will contain default visually lossless tables.
0N/AOf course, only a <
code>JPEGImageWriteParam</
code> may contain tables.
0N/AIf <
code>ignoreMetadata</
code> is set to <
code>true</
code> when the input
0N/Ais set on the reader, stream metadata will not be available, but image
0N/A<
a name=abbrev>Abbreviated Streams</
a>
0N/ABoth the reader and the writer retain their tables from one operation to the
0N/Anext, thus permitting the use of abbreviated streams quite naturally, with a
0N/Afew minor restrictions:
0N/A <
li> Abbreviated streams may contain only one tables-only image, which must
0N/A come first in the stream. Subsequent tables-only images will cause
0N/A undefined behavior.</
li>
0N/A <
li> Abbreviated streams must be read fully and in order. No random access
0N/A is allowed, in either direction. The same image may be read multiple
0N/A times. If a call is made with an image index that is not the same as
0N/A or one greater than the most recent call (or 0 if no calls have been
0N/A made), then an <
code>IllegalArgumentException</
code> is thrown.</
li>
0N/AThese restrictions mean that streams may contain abbreviated images
0N/Ainterspersed with images containing tables. As required by JPEG, any tables
0N/Aappearing in the stream override previous tables, regardless of the source
0N/Aof the previous tables.
0N/ANote that once a tables-only image has been read, it's contents is available
0N/Aas stream metadata from the reader until either another tables-only image
0N/Ais read from another stream or the reader is reset. Changing the input does
0N/Anot reset the stream metadata. This is useful for reading the tables from
0N/Aone file, then changing the input to read an abbreviated stream containing
0N/Aa sequence of images. The tables will be used automatically, and will remain
0N/Aavailable as "stream" metadata.
0N/AAbbreviated streams are written using the sequence methods of
0N/A<
code>ImageWriter</
code>. Stream metadata is used to write a tables-only
0N/Aimage at the beginning of the stream, and the tables are set up for use, using
0N/Atables-only image is written. If stream metadata containing no tables is
0N/Aimage containing default visually lossless tables is written.
0N/A<
a name=tables>Sources of Tables</
a>
0N/AImages are written with tables if tables are present in their metadata objects
0N/Aor without them if no tables are present in their metadata objects. If no
0N/Ametadata object is present then the tables are written. The tables used for
0N/Acompression are taken from one of the following sources, which are consulted
0N/A <
li> If there is an <
code>ImageWriteParam</
code> and the compression mode is
0N/A set to <
code>EXPLICIT</
code>, default tables constructed using the
0N/A quality setting are used. They are written only if the metadata
0N/A contains tables or if there is no metadata, but they replace the
0N/A tables in the metadata.</
li>
0N/A <
li> If there is an <
code>ImageWriteParam</
code> and the compression mode is
0N/A set to <
code>DEFAULT</
code>, default visually lossles tables are used.
0N/A They are written only if the metadata contains tables or if
0N/A there is no metadata, but they replace the tables in the
0N/A <
li> Otherwise the compression mode on the <
code>ImageWriteParam</
code> must
0N/A be MODE_COPY_FROM_<
code>METADATA</
code>, in which case the following
0N/A <
li> the tables in the image metadata, if present</
li>
0N/A <
li> the tables in the stream metadata, if present</
li>
0N/A <
li> the tables in the <
code>JPEGImageWriteParam</
code>, if present</
li>
0N/A <
li> default visually lossless tables</
li>
0N/A </
ol> Tables are written only if they are taken from image metadata.
0N/AThis ordering implements the design intention that tables should be included
0N/Ain <
code>JPEGImageWriteParam</
code>s only as a means of specifying tables
0N/Awhen no other source is available, and this can occur only when writing to an
0N/Aabbreviated stream without tables using known non-standard tables for
0N/AWhen reading, tables in a <
code>JPEGImageReadParam</
code> are consulted only
0N/Aif tables have not been set by any previous read. Tables set from a
0N/A<
code>JPEGImageReadParam</
code> are overridden by any tables present in the
0N/ANote that if no image metadata object is specified for a particular image, a
0N/Adefault object is used, which includes default tables.
0N/A<
a name=color>Colorspace Transformations and Conventional Markers</
a>
0N/AColorspace transformations are controlled by the destination type for
0N/Aboth reading and writing of images. When <
code>Raster</
code>s are
0N/Aread, no colorspace transformation is performed, and any destination type
0N/Ais ignored. A warning is sent to any listeners if a destination type is
0N/Aspecified in this case. When <
code>Raster</
code>s are written, any
0N/Adestination type is used to interpret the bands. This might result in a
0N/AJFIF or Adobe header being written, or different component ids being written
0N/Ato the frame and scan headers. If values present in a metadata object do not
0N/Amatch the destination type, the destination type is used and a warning is sent
4192N/A<
a name=optcolor><
b>Optional ColorSpace support:</
b></
a>
4192N/AHandling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA and YCbCrA color spaces
4192N/Aby the standard plugin, as described below, is dependent on capabilities
4192N/Aof the libraries used to interpret the JPEG data. Thus all consequential
4192N/Abehaviors are optional. If the support is not available when decoding,
4192N/Athe color space will be treated as unrecognized and the appropriate
4192N/Adefault color space for the specified number of component channels
4192N/AWhen writing, an Exception may be thrown if no suitable conversion
4192N/Acan be applied before encoding.
4192N/ABut where the support for these color spaces is available, the behavior
0N/AWhen reading, the contents of the stream are interpreted by the usual
0N/AJPEG conventions, as follows:
0N/A <
li> If a JFIF <
code>APP0</
code> marker segment is present, the colorspace
0N/A is known to be either grayscale or YCbCr. If an <
code>APP2</
code>
0N/A marker segment containing an embedded ICC profile is also present, then
0N/A the YCbCr is converted to RGB according to the formulas given in the
0N/A JFIF spec, and the ICC profile is assumed to refer to the resulting RGB
0N/A <
li> If an Adobe <
code>APP14</
code> marker segment is present, the
0N/A colorspace is determined by consulting the <
code>transform</
code> flag.
0N/A The <
code>transform</
code> flag takes one of three values:
0N/A <
li> 2 - The image is encoded as YCCK (implicitly converted from
0N/A <
li> 1 - The image is encoded as YCbCr (implicitly converted from RGB
0N/A <
li> 0 - Unknown. 3-channel images are assumed to be RGB, 4-channel
0N/A images are assumed to be CMYK.
0N/A <
li> If neither marker segment is present, the following procedure is
0N/A followed: Single-channel images are assumed to be grayscale, and
0N/A 2-channel images are assumed to be grayscale with an alpha channel.
0N/A For 3- and 4-channel images, the component ids are consulted. If these
0N/A values are 1-3 for a 3-channel image, then the image is assumed to be
4192N/A YCbCr. Subject to the availability of the
4192N/A <
a href=#
optcolor>optional color space support</
a>
4192N/A described above, if these values are 1-4 for a 4-channel image,
4192N/A then the image is assumed to be YCbCrA.
4192N/A If these values are > 4, they are checked
0N/A against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can
0N/A encode the following colorspaces:
0N/A <
br>YCC (as 'Y','C','c'), assumed to be PhotoYCC
0N/A <
br>YCCA (as 'Y','C','c','A'), assumed to be PhotoYCCA
0N/A Otherwise, 3-channel subsampled images are assumed to be YCbCr,
0N/A 3-channel non-subsampled images are assumed to be RGB, 4-channel
0N/A subsampled images are assumed to be YCCK, and 4-channel, non-subsampled
0N/A images are assumed to be CMYK.
0N/A <
li> All other images are declared uninterpretable and an exception is
0N/A thrown if an attempt is made to read one as a
0N/A <
code>BufferedImage</
code>. Such an image may be read only as a
0N/A <
code>Raster</
code>. If an image is interpretable but there is no Java
0N/A <
code>ColorSpace</
code> available corresponding to the encoded
0N/A colorspace (<
italic>
e.g.</
italic> YCbCr), then
0N/AOnce an encoded colorspace is determined, then the target colorspace is
0N/Adetermined as follows:
0N/A <
li> If a destination type is not set, then the following default
0N/A transformations take place after upsampling: YCbCr (and YCbCrA) images
0N/A are converted to RGB (and RGBA) using the conversion provided by the
0N/A underlying IJG library and either the built-in sRGB
0N/A <
code>ColorSpace</
code> or a custom RGB <
code>ColorSpace</
code> object
0N/A based on an embedded ICC profile is used to create the output
0N/A <
code>ColorModel</
code>. PhotoYCC and PhotoYCCA images are not
0N/A converted. CMYK and YCCK images are currently not supported.</
li>
0N/A <
li> If a destination image or type is set, it is used as follows:
0N/A If the IJG library provides an appropriate conversion, it is used.
0N/A Otherwise the default library conversion is followed by a colorspace
0N/A conversion in Java.</
li>
0N/A <
li> Bands are selected AFTER any library colorspace conversion. If a
0N/A subset of either source or destination bands is used, then the default
0N/A library conversions are used with no further conversion in Java,
0N/A regardless of any destination type.</
li>
0N/A <
li> An exception is thrown if an attempt is made to read an image in an
0N/A unsupported jpeg colorspace as a <
code>BufferedImage</
code>
0N/A (<
italic>
e.g.</
italic> CMYK). Such images may be read as
0N/A <
code>Raster</
code>s. If an image colorspace is unsupported or
0N/A return an empty <
code>Iterator</
code>. If a subset of the raw bands
0N/A are required, a <
code>Raster</
code> must be obtained first and the
0N/A bands obtained from that. </
li>
0N/AFor writing, the color transformation to apply is determined as
0N/AIf a subset of the source bands is to be written, no color conversion is
0N/Aperformed. Any destination, if set, must match the number of bands that will
0N/Abe written, and serves as an interpretation of the selected bands, rather than
0N/Aa conversion request. This behavior is identical to that for
0N/A<
code>Raster</
code>s. If all the bands are to be written and an image
0N/A(as opposed to a <
code>Raster</
code>) is being written, any destination type
0N/Ais ignored and a warning is sent to any listeners.
0N/AIf a destination type is used and any aspect of the metadata object, if there
0N/Ais one, is not compatible with that type, the destination type is used, the
0N/Ametadata written is modified from that provided, and a warning is sent to
0N/Alisteners. This includes the <
code>app0JFIF</
code> and
0N/A<
code>app14Adobe</
code> nodes. The component ids in the <
code>sof</
code> and
0N/A<
code>sos</
code> nodes are not modified, however, as unless a
0N/A<
code>app0JFIF</
code> node is present, any values may be used.
0N/AWhen a full image is written, a destination colorspace will be
0N/Achosen based on the image contents and the metadata settings, according to
0N/Athe following algorithm:
0N/AIf no metadata object is specified, then the following defaults apply:
0N/A <
li> Grayscale images are written with a JFIF <
code>APP0</
code> marker
0N/A segment. Grayscale images with alpha are written with no special
0N/A marker. As required by JFIF, the component ids in the frame and
0N/A scan header is set to 1.
0N/A <
li> RGB images are converted to YCbCr, subsampled in the chrominance
0N/A channels by half both vertically and horizontally, and written with a
0N/A JFIF <
code>APP0</
code> marker segment. If the <
code>ColorSpace</
code>
0N/A of the image is based on an <
code>ICCProfile</
code> (it is an instance
0N/A of <
code>ICC_ColorSpace</
code>, but is not one of the standard built-in
0N/A <
code>ColorSpaces</
code>), then that profile is embedded in an
0N/A <
code>APP2</
code> marker segment. As required by JFIF, the
0N/A component ids in the frame and scan headers are set to 1, 2, and 3.
4192N/A <
li> Subject to the <
a href=#
optcolor>optional library support</
a>
4192N/A RGBA images are converted to YCbCrA, subsampled in the
0N/A chrominance channels by half both vertically and horizontally, and
0N/A written without any special marker segments. The component ids
0N/A in the frame and scan headers are set to 1, 2, 3, and 4.
4192N/A <
li> Subject to the <
a href=#
optcolor>optional library support</
a>
4192N/A PhotoYCC and YCCAimages are subsampled by half in the chrominance
0N/A channels both vertically and horizontally and written with an
0N/A Adobe <
code>APP14</
code> marker segment and 'Y','C', and 'c' (and
0N/A 'A' if an alpha channel is present) as component ids in the frame
0N/ADefault metadata objects for these image types will reflect these settings.
0N/AIf a metadata object is specified, then the number of channels in the
0N/Aframe and scan headers must always match the number of bands to be
0N/Awritten, or an exception is thrown. <
code>app0JFIF</
code> and
0N/A<
code>app14Adobe</
code> nodes may appear in the same metadata object only
0N/Aif the <
code>app14Adobe</
code> node indicates YCbCr, and the component ids
0N/Aare JFIF compatible (0-2). The various image types are processed in the
0N/A(All multi-channel images are subsampled according to the sampling factors
0N/Ain the frame header node of the metadata object, regardless of color space.)
0N/A <
li> Grayscale Images:
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A a JFIF <
code>APP0</
code> marker segment is written.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, it is checked for validity (<
code>transform</
code> must be
0N/A <
code>UNKNOWN</
code>) and written.
0N/A <
li> If neither node is present in the metadata object, no special
0N/A marker segment is written.
0N/A <
li> Grayscale Images with an Alpha Channel:
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A it is ignored and a warning is sent to listeners, as JFIF does not
0N/A support 2-channel images.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, it is checked for validity (<
code>transform</
code> must be
0N/A <
code>UNKNOWN</
code>) and written. If <
code>transform</
code> is
0N/A not <
code>UNKNOWN</
code>, a warning is sent to listeners and the
0N/A correct transform is written.
0N/A <
li> If neither node is present in the metadata object, no special
0N/A marker segment is written.
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A the image is converted to YCbCr and written with a JFIF
0N/A <
code>APP0</
code> marker segment. If the <
code>ColorSpace</
code>
0N/A of the image is based on a non-standard ICC Profile, then that
0N/A profile is embedded in an <
code>APP2</
code> marker segment. If the
0N/A <
code>ColorSpace</
code> is not based on a non-standard ICC Profile,
0N/A but an <
code>app2ICC</
code> node appears in the metadata, then an
0N/A <
code>APP2</
code> marker segment is written with the appropriate
0N/A standard profile. Note that the profile must specify an RGB color
0N/A space, as the file must be JFIF compliant.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, the image is converted according to the color transform
0N/A setting and written with an Adobe <
code>APP14</
code> marker
0N/A segment. Component ids are written just as they appear in the
0N/A frame and scan headers. The color transform must be either YCbCr
0N/A or <
code>UNKNOWN</
code>. If it is <
code>UNKNOWN</
code>, the image
0N/A is not color converted.
0N/A <
li> If neither node is present, the component ids in the frame
0N/A header are consulted. If these indicate a colorspace as described
0N/A above, then the image is converted to that colorspace if possible.
0N/A If the component ids do not indicate a colorspace, then the
0N/A sampling factors are consulted. If the image is to be subsampled,
0N/A it is converted to YCbCr first. If the image is not to be
0N/A subsampled, then no conversion is applied. No special marker
0N/A segmentss are written.
4192N/A Subject to the <
a href=#
optcolor>optional library support</
a>
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A it is ignored and a warning is sent to listeners, as JFIF does not
0N/A support 4-channel images.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, the image is written with an Adobe <
code>APP14</
code> marker
0N/A segment. No colorspace conversion is performed. Component ids
0N/A are written just as they appear in the frame and scan headers.
0N/A The color transform must be <
code>UNKNOWN</
code>. If it is
0N/A not, a warning is sent to listeners.
0N/A <
li> If no <
code>app14Adobe</
code> node is present, the component ids in
0N/A the frame header are consulted. If these indicate a colorspace as
0N/A described above, then the image is converted to that colorspace if
0N/A possible. If the component ids do not indicate a colorspace, then
0N/A the sampling factors are consulted. If the image is to be
0N/A subsampled, it is converted to YCbCrA. If the image is not to be
0N/A subsampled, then no conversion is applied. No special marker
0N/A segments are written.
0N/A <
li> PhotoYCC Images:
4192N/A Subject to the <
a href=#
optcolor>optional library support</
a>
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A the image is converted to sRGB, and then to YCbCr during encoding,
0N/A and a JFIF <
code>APP0</
code> marker segment is written.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, no conversion is applied, and an Adobe <
code>APP14</
code>
0N/A marker segment is written. The color transform must be YCC. If it
0N/A is not, a warning is sent to listeners.
0N/A <
li> If neither node is present in the metadata object, no conversion
0N/A is applied, and no special marker segment is written.
0N/A <
li> PhotoYCCA Images:
4192N/A Subject to the <
a href=#
optcolor>optional library support</
a>
0N/A <
li> If an <
code>app0JFIF</
code> node is present in the metadata object,
0N/A it is ignored and a warning is sent to listeners, as JFIF does not
0N/A support 4-channel images.
0N/A <
li> If an <
code>app14Adobe</
code> node is present in the metadata
0N/A object, no conversion is applied, and an Adobe <
code>APP14</
code>
0N/A marker segment is written. The color transform must be
0N/A <
code>UNKNOWN</
code>. If it is not, a warning is sent to
0N/A <
li> If neither node is present in the metadata object, no conversion
0N/A is applied, and no special marker segment is written.
0N/A<
a name=thumbs>Thumbnail Images</
a>
0N/AThumbnails are supported by the use of JFIF and JFIF extension marker segments.
0N/AThumbnails provided on the write methods determine the thumbnails that will be
0N/Aincluded. <
code>app0JFIF</
code> and <
code>app0JFXX</
code> nodes present in
0N/Athe metadata do not contain any thumbnail pixel data. However, the kinds of
0N/Athumbnails written depend on the contents of the metadata object, as follows.
0N/AAny thumbnail which is to be written as an indexed or RGB image and which is
0N/Alarger than 255 by 255 will be clipped, not scaled, to 255 by 255. Thumbnails
0N/Awritten as JPEG images may be any size. A warning is sent to any listeners
0N/Awhenever a thumbnail is clipped.
0N/A <
li> If there is a single thumbnail, it is processed as follows:
0N/A <
li> If the thumbnail image is an RGB palette image, it is processed as
0N/A <
li> If no <
code>app0JFXX</
code> node is present in the metadata, or
0N/A the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbPalette</
code> element, a
0N/A palette thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains another thumbnail form (RGB or JPEG), the palette
0N/A image is expanded to RGB and the indicated thumbnail form is
0N/A <
li> If the thumbnail image is an RGB image, it is processed as follows:
0N/A <
li> If no <
code>app0JFXX</
code> node is present in the metadata,
0N/A the thumbnail is written as part of the JFIF <
code>APP0</
code>
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbRGB</
code> element, an
0N/A RGB thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbJPEG</
code> element, a
0N/A JPEG thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbPalette</
code> element, an
0N/A RGB thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A segment and a warning is sent to any listeners.
0N/A <
li> If the thumbnail image is a grayscale image, it is processed as
0N/A <
li> If no <
code>app0JFXX</
code> node is present in the metadata,
0N/A the thumbnail is expanded to RGB and written as part of the
0N/A JFIF <
code>APP0</
code> marker segment.
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbRGB</
code> element, the thumbnail is
0N/A expanded to RGB and written in a separate <
code>JFXX</
code> RGB
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbJPEG</
code> element, a
0N/A JPEG thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A <
li> If the first <
code>app0JFXX</
code> node present in the metadata
0N/A contains a <
code>JFIFthumbPalette</
code> element, a
0N/A JPEG thumbnail is written in a JFXX <
code>APP0</
code> marker
0N/A segment and a warning is sent to any listeners.
0N/A <
li> Any other thumbnail image types are ignored and a warning is sent
0N/A <
li> If there are multiple thumbnails, each one is processed as above, except
0N/A that no thumbnail is placed in the JFIF <
code>APP0</
code> segment, and
0N/A the <
code>app0JFXX</
code> node consulted for each thumbnail is the
0N/A <
code>app0JFXX</
code> node from the metadata that occurs in the same
0N/A sequence as the thumbnail. <
italic>
I.e.</
italic> the first
0N/A <
code>app0JFXX</
code> node applies to the first thumbnail, the second
0N/A node to the second thumbnail, and so on. If there are fewer
0N/A <
code>app0JFXX</
code> nodes in the metadata than thumbnails, then
0N/A those thumbnails are considered to have no matching
0N/A <
code>app0JFXX</
code> node. An RGB thumbnail with no matching
0N/A <
code>app0JFXX</
code> node is written in a JFXX <
code>APP0</
code> marker
0N/A segment. A grayscale thumbnail with no matching
0N/A <
code>app0JFXX</
code> node is written as a JPEG image to a JFXX
0N/A <
code>APP0</
code> marker segment.
0N/ANote that as the only mechanism for storing thumbnails is via the
0N/AJFIF or JFIF extension marker segments, only grayscale or RGB images
0N/Amay have thumbnails. If thumbnails are present when writing any other type
0N/Aof image, the thumbnails are ignored and a warning is sent to any warning
0N/A<
a name=prog>Progressive Encoding</
a>
0N/AProgressive encoding must be enabled on the <
code>ImageWriteParam</
code>
0N/Apassed in to a write operation, or the image will be written sequentially,
0N/Aregardless of the scan headers included in the metadata object. If
0N/Aprogressive encoding is enabled and set to copy from metadata, then
0N/Athe sequence of scan headers from the metadata is used to write the
0N/Aimage. If progressive encoding is enabled and set to use a default,
0N/Athen the scans in the metadata are ignored and a default set of scans
0N/Ais used. Progressive encoding always forces optimized Huffman tables to
0N/Abe used. Any Huffman tables present in the metadata will be ignored,
0N/Aand a warning will be sent to any warning listeners.
0N/AIf Huffman-table optimization is requested on the <
code>ImageWriteParam</
code>,
0N/Aall Huffman tables in the metadata or in the <
code>ImageWriteParam</
code>
0N/Aitself are ignored, and a warning will be sent to any warning listeners if
0N/Aany such tables are present.
0N/A<
a name=tree>Native Metadata Format Tree Structure and Editing</
a>
0N/AThe DTDs below describe just the trees of metadata objects actually returned
0N/Aby the <
code>IIOMetadata</
code> object. They do not include nodes
0N/Acorresponding to <
code>SOI</
code>, <
code>EOI</
code>, or <
code>RST</
code>
0N/Amarkers, as these parsing delimiters do not carry any meaningful metadata.
0N/AThe first node is always a <
code>JPEGvariety</
code> node. In the
0N/A<
code>javax_imageio_jpeg_image_1.0</
code> version of the JPEG metadata
0N/Aformat, this node may have one child, an <
code>app0JFIF</
code> node,
0N/Aindicating that the JPEG stream contains a JFIF marker segment and related
0N/Adata, or no children, indicating that the stream contains no JFIF marker.
0N/AIn future versions of the JPEG metadata format, other varieties of JPEG
0N/Ametadata may be supported (
e.g. Exif) by defining other types of nodes
0N/Awhich may appear as a child of the <
code>JPEGvariety</
code> node.
0N/A(Note that an application wishing to interpret Exif metadata given
0N/Aa metadata tree structure in the <
code>javax_imageio_jpeg_image_1.0</
code>
0N/Aformat must check for an <
code>unknown</
code> marker segment with a tag
0N/Aindicating an <
code>APP1</
code> marker and containing data identifying it
0N/Aas an Exif marker segment. Then it may use application-specific code to
0N/Ainterpret the data in the marker segment. If such an application were
0N/Ato encounter a metadata tree formatted according to a future version of
0N/Athe JPEG metadata format, the Exif marker segment might not be
0N/A<
code>unknown</
code> in that format - it might be structured as a
0N/Achild node of the <
code>JPEGvariety</
code> node. Thus, it is important
0N/Afor an application to specify which version to use by passing the string
0N/A<
code>IIOMetadata</
code> object.)
0N/AOn reading, <
code>JFXX</
code> and <
code>app2ICC</
code> nodes occur as
0N/Achildren of an <
code>app0JFIF</
code> node.
0N/AThis is true regardless of where the JFXX <
code>APP0</
code> and
0N/A<
code>APP2</
code> marker segments actually occur in the stream. The ordering
0N/Aof nodes within the <
code>markerSequence</
code> node corresponds to the
0N/Aordering of marker segments found in the JPEG stream.
0N/AOn writing, any <
code>JFXX</
code> and <
code>app2ICC</
code> nodes must
0N/Aoccur as children of an <
code>app0JFIF</
code> node, itself a child of a
0N/A<
code>JPEGvariety</
code> node, which must always be the first node.
0N/A(If the stream is not to be JFIF compliant, no <
code>app0JFIF</
code> node
0N/Ashould be provided, and the <
code>JPEGvariety</
code> node should have no
0N/AJFIF <
code>APP0</
code>, JFXX <
code>APP0</
code>, and <
code>APP2</
code> marker
0N/Asegments are written first, followed by all Adobe <
code>APP14</
code>,
0N/A<
code>APPn</
code>, <
code>COM</
code> and unknown segments in the
0N/Aorder in which their corresponding nodes appear in the
0N/A<
code>markerSequence</
code> node, followed by <
code>DQT</
code> (and
0N/A<
code>DHT</
code> for non-progressive writes) marker segments, followed by the
0N/A<
code>SOF</
code> and <
code>SOS</
code> marker segments. For progressive writes
0N/Ausing metadata to control progression, the <
code>SOS</
code> segments are used
0N/Ain the order in which their corresponding nodes occur in the
0N/A<
code>markerSequence</
code> node.
0N/AThe <
code>reset</
code>, <
code>mergeTree</
code> and <
code>setFromTree</
code>
0N/Aoperations have the following semantics for the JPEG plug-in metadata object:
0N/A<
p> <
code>reset</
code> - A call to <
code>reset</
code> will restore the
0N/Ametadata object to the same state it had immediately after creation, whether
0N/Athis came about from reading a stream or by obtaining a default object from
0N/Athe <
code>ImageWriter</
code>. This is true regardless of how many times the
0N/Ametadata object has been modified since creation.
0N/A<
p> <
code>mergeTree</
code> - Native Format
0N/A<
br> The <
code>mergeTree</
code> operation accepts valid trees conforming to
0N/Athe DTD below, and merges the nodes using the following ordering rules. In
0N/Aall cases, only data present in the new node is changed in a corresponding
0N/Aexisting node, if any. This means that nodes cannot be removed using
0N/A<
code>mergeTree</
code>. To remove nodes, use <
code>setFromTree</
code>. The
0N/Atree must consist of <
code>IIOMetadataNode</
code>s.
0N/A <
li> <
code>app0JFIF</
code>
0N/A <
li> If an <
code>app0JFIF</
code> node already exists, the contents
0N/A of the new one modify the existing one.
0N/A <
li> If there is no such node, a new one is created and inserted in
0N/A the appropriate position.
0N/A <
li> <
code>dqt</
code>
0N/A <
li> If there already exist <
code>dqt</
code> nodes in the sequence,
0N/A then each table in the node replaces the first table, in any
0N/A <
code>dqt</
code> node, with the same table id.
0N/A <
li> If none of the existing <
code>dqt</
code> nodes contain a table
0N/A with the same id, then the table is added to the last existing
0N/A <
code>dqt</
code> node.
0N/A <
li> If there are no <
code>dqt</
code> nodes, then a new one is
0N/A created and added as follows:
0N/A <
li> If there are <
code>dht</
code> nodes, the new
0N/A <
code>dqt</
code> node is inserted before the first one.
0N/A <
li> If there are no <
code>dht</
code> nodes, the new
0N/A <
code>dqt</
code> node is inserted before an
0N/A <
code>sof</
code> node, if there is one.
0N/A <
li> If there is no <
code>sof</
code> node, the new
0N/A <
code>dqt</
code> node is inserted before the first
0N/A <
code>sos</
code> node, if there is one.
0N/A <
li> If there is no <
code>sos</
code> node, the new
0N/A <
code>dqt</
code> node is added to the end of the sequence.
0N/A <
li> <
code>dht</
code>
0N/A <
li> If there already exist <
code>dht</
code> nodes in the sequence,
0N/A then each table in the node replaces the first table, in any
0N/A <
code>dht</
code> node, with the same table class and table id.
0N/A <
li> If none of the existing <
code>dht</
code> nodes contain a table
0N/A with the same class and id, then the table is added to the last
0N/A existing <
code>dht</
code> node.
0N/A <
li> If there are no <
code>dht</
code> nodes, then a new one is
0N/A created and added as follows:
0N/A <
li> If there are <
code>dqt</
code> nodes, the new
0N/A <
code>dht</
code> node is inserted immediately following the
0N/A last <
code>dqt</
code> node.
0N/A <
li> If there are no <
code>dqt</
code> nodes, the new
0N/A <
code>dht</
code> node is inserted before an
0N/A <
code>sof</
code> node, if there is one.
0N/A <
li> If there is no <
code>sof</
code> node, the new
0N/A <
code>dht</
code> node is inserted before the first
0N/A <
code>sos</
code> node, if there is one.
0N/A <
li> If there is no <
code>sos</
code> node, the new
0N/A <
code>dht</
code> node is added to the end of the sequence.
0N/A <
li> <
code>dri</
code>
0N/A <
li> If there already exists a <
code>dri</
code> node, the restart
0N/A interval value is updated.
0N/A <
li> If there is no <
code>dri</
code> node, then a new one is created
0N/A and added as follows:
0N/A <
li> If there is an <
code>sof</
code> node, the new
0N/A <
code>dri</
code> node is inserted before it.
0N/A <
li> If there is no <
code>sof</
code> node, the new
0N/A <
code>dri</
code> node is inserted before the first
0N/A <
code>sos</
code> node, if there is one.
0N/A <
li> If there is no <
code>sos</
code> node, the new
0N/A <
code>dri</
code> node is added to the end of the sequence.
0N/A <
li> <
code>com</
code>
0N/A <
br> A new <
code>com</
code> node is created and inserted as follows:
0N/A <
li> If there already exist <
code>com</
code> nodes, the new one is
0N/A inserted after the last one.
0N/A <
li> If there are no <
code>com</
code> nodes, the new
0N/A <
code>com</
code> node is inserted after the
0N/A <
code>app14Adobe</
code> node, if there is one.
0N/A <
li> If there is no <
code>app14Adobe</
code> node, the new
0N/A <
code>com</
code> node is inserted at the beginning of the
0N/A <
li> <
code>app14Adobe</
code>
0N/A <
li> If there already exists an <
code>app14Adobe</
code> node, then
0N/A its attributes are updated from the node.
0N/A <
li> If there is no <
code>app14Adobe</
code> node, then a new one is
0N/A created and added as follows:
0N/A <
li> The new <
code>app14Adobe</
code> node is inserted after the
0N/A last <
code>unknown</
code> node, if there are any.
0N/A <
li> If there are no <
code>unknown</
code> nodes, the new
0N/A <
code>app14Adobe</
code> node is inserted at the beginning
0N/A <
li> <
code>unknown</
code>
0N/A <
br> A new <
code>unknown</
code> node is created and added to the
0N/A sequence as follows:
0N/A <
li> If there already exist <
code>unknown</
code> marker nodes, the
0N/A new one is inserted after the last one.
0N/A <
li> If there are no <
code>unknown</
code> nodes, the new
0N/A <
code>unknown</
code> node is inserted before the
0N/A <
code>app14Adobe</
code> node, if there is one.
0N/A <
li> If there is no <
code>app14Adobe</
code> node, the new
0N/A <
code>unknown</
code> node is inserted at the beginning of the
0N/A <
li> <
code>sof</
code>
0N/A <
li> If there already exists an <
code>sof</
code> node in the
0N/A sequence, then its values are updated from the node.
0N/A <
li> If there is no <
code>sof</
code> node, then a new one is created
0N/A and added as follows:
0N/A <
li> If there are any <
code>sos</
code> nodes, the new
0N/A <
code>sof</
code> node is inserted before the first one.
0N/A <
li> If there is no <
code>sos</
code> node, the new
0N/A <
code>sof</
code> node is added to the end of the sequence.
0N/A <
li> <
code>sos</
code>
0N/A <
li> If there already exists a single <
code>sos</
code> node, then
0N/A the values are updated from the node.
0N/A <
li> If there are more than one existing <
code>sos</
code> nodes,
0N/A then an <
code>IIOInvalidTreeException</
code> is thrown, as
0N/A <
code>sos</
code> nodes cannot be merged into a set of
0N/A <
li> If there are no <
code>sos</
code> nodes, a new one is created
0N/A and added to the end of the sequence.
0N/A<
p> <
code>mergeTree</
code> - Standard Format
0N/AThe <
code>mergeTree</
code> operation, when given a tree in the standard
0N/Aformat, will modify the native tree in the following ways:
0N/A <
li> <
code>Chroma</
code> - The <
code>ColorSpaceType</
code> subnode of a
0N/A <
code>Chroma</
code> node may change the target colorspace of the
0N/A compressed image. The selection of a new colorspace can cause a number
0N/A of changes, in keeping with the algorithms described above:
0N/A <
code>app0JFIF</
code> and <
code>app14Adobe</
code> nodes may be added
0N/A or removed, subsampling may be added or removed, component ids may
0N/A be changed, and <
code>sof</
code> and <
code>sos</
code> nodes will be
0N/A updated accordingly. If necessary, additional quantization and
0N/A huffman tables are added. In the case of quantization tables, the
0N/A default will be scaled to match the quality level of any existing
0N/A tables. No tables are added to metadata that does not already contain
0N/A tables. If the existing metadata specifies progressive encoding, then
0N/A the number of channels must not change. Any <
code>Transparency</
code>
0N/A node is also taken into account, as an explicit value of
0N/A <
code>none</
code> for the <
code>Alpha</
code> subnode can cause the
0N/A removal of an alpha channel, and anything other than <
code>none</
code>
0N/A can cause the addition of an alpha channel.
0N/A <
li> <
code>Dimension</
code> - A <
code>PixelAspectRatio</
code> specification
0N/A can cause the contents of an <
code>app0JFIF</
code> node to change, if
0N/A there is one present, or the addition of an <
code>app0JFIF</
code> node
0N/A containing appropriate values, if there can be one. An appropriate
0N/A pair of integers is computed from the floating-point ratio for
0N/A inclusion in the node.
0N/A <
li> <
code>Text</
code> - Each uncompressed text item is converted to a
0N/A <
code>com</
code> node and inserted according to the rules above for
0N/A merging <
code>com</
code> nodes.
0N/A<
p> <
code>setFromTree</
code> - Native Format
0N/AThe <
code>setFromTree</
code> operation, when given a tree in the native
0N/Aformat described below, will simply replace the existing tree in its entirety
0N/Awith the new one. The tree must consist of <
code>IIOMetadataNode</
code>s.
0N/A<
p> <
code>setFromTree</
code> - Standard Format
0N/AThe <
code>setFromTree</
code> operation, when given a tree in the standard
0N/Aformat, performs a <
code>reset</
code> followed by a merge of the new tree.
0N/A<
a name=image>Image Metadata DTD</
a>
0N/A<!DOCTYPE "javax_imageio_jpeg_image_1.0" [
0N/A <!ELEMENT "javax_imageio_jpeg_image_1.0" (JPEGvariety, markerSequence)>
0N/A <!ELEMENT "JPEGvariety" (app0JFIF)>
0N/A <!-- A node grouping all marker segments specific to the variety of
0N/A <!ELEMENT "app0JFIF" (JFXX?, app2ICC?)>
0N/A <!ATTLIST "app0JFIF" "majorVersion" #CDATA "1">
0N/A <!-- The major JFIF version number -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "app0JFIF" "minorVersion" #CDATA "2">
0N/A <!-- The minor JFIF version number -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "app0JFIF" "resUnits" ("0" | "1" | "2") "0">
0N/A <!-- The resolution units for Xdensisty and Ydensity (0 = no
0N/A <!ATTLIST "app0JFIF" "Xdensity" #CDATA "1">
0N/A <!-- The horizontal density or aspect ratio numerator -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 1 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "app0JFIF" "Ydensity" #CDATA "1">
0N/A <!-- The vertical density or aspect ratio denominator -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 1 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "app0JFIF" "thumbWidth" #CDATA "0">
0N/A <!-- The width of the thumbnail, or 0 if there isn't one -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "app0JFIF" "thumbHeight" #CDATA "0">
0N/A <!-- The height of the thumbnail, or 0 if there isn't one -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ELEMENT "JFXX" (app0JFXX)*>
0N/A <!-- Min children: 1 -->
0N/A <!ELEMENT "app0JFXX" (JFIFthumbJPEG | JFIFthumbPalette |
0N/A <!-- A JFIF extension marker segment -->
0N/A <!ATTLIST "app0JFXX" "extensionCode" ("16" | "17" | "19")
0N/A <!-- The JFXX extension code identifying thumbnail type: (16 =
0N/A JPEG, 17 = indexed, 19 = RGB -->
0N/A <!ELEMENT "JFIFthumbJPEG" (markerSequence?)>
0N/A <!-- A JFIF thumbnail in JPEG format (no JFIF segments
0N/A <!ELEMENT "JFIFthumbPalette" EMPTY>
0N/A <!-- A JFIF thumbnail as an RGB indexed image -->
0N/A <!ATTLIST "JFIFthumbPalette" "thumbWidth" #CDATA #IMPLIED>
0N/A <!-- The width of the thumbnail -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "JFIFthumbPalette" "thumbHeight" #CDATA #IMPLIED>
0N/A <!-- The height of the thumbnail -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ELEMENT "JFIFthumbRGB" EMPTY>
0N/A <!-- A JFIF thumbnail as an RGB image -->
0N/A <!ATTLIST "JFIFthumbRGB" "thumbWidth" #CDATA #IMPLIED>
0N/A <!-- The width of the thumbnail -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "JFIFthumbRGB" "thumbHeight" #CDATA #IMPLIED>
0N/A <!-- The height of the thumbnail -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ELEMENT "app2ICC" EMPTY>
0N/A <!-- An ICC profile APP2 marker segment -->
0N/A <!ELEMENT "markerSequence" (dqt | dht | dri | com | unknown |
0N/A app14Adobe | sof | sos)*>
0N/A <!-- A node grouping all non-jfif marker segments -->
0N/A <!ELEMENT "dqt" (dqtable)*>
0N/A <!-- A Define Quantization Table(s) marker segment -->
0N/A <!-- Min children: 1 -->
0N/A <!-- Max children: 4 -->
0N/A <!ELEMENT "dqtable" EMPTY>
0N/A <!-- A single quantization table -->
0N/A <!ATTLIST "dqtable" "elementPrecision" #CDATA "0">
0N/A <!-- The number of bits in each table element (0 = 8, 1 = 16)
0N/A <!-- Data type: Integer -->
0N/A <!ATTLIST "dqtable" "qtableId" ("0" | "1" | "2" | "3") #REQUIRED>
0N/A <!ELEMENT "dht" (dhtable)*>
0N/A <!-- A Define Huffman Table(s) marker segment -->
0N/A <!-- Min children: 1 -->
0N/A <!-- Max children: 4 -->
0N/A <!ELEMENT "dhtable" EMPTY>
0N/A <!-- A single Huffman table -->
0N/A <!ATTLIST "dhtable" "class" ("0" | "1") #REQUIRED>
0N/A <!-- Indicates whether this is a DC (0) or an AC (1) table -->
0N/A <!ATTLIST "dhtable" "htableId" ("0" | "1" | "2" | "3") #REQUIRED>
0N/A <!-- The table id -->
0N/A <!ELEMENT "dri" EMPTY>
0N/A <!-- A Define Restart Interval marker segment -->
0N/A <!ATTLIST "dri" "interval" #CDATA #REQUIRED>
0N/A <!-- The restart interval in MCUs -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ELEMENT "com" EMPTY>
0N/A <!-- A Comment marker segment. The user object contains the actual
0N/A <!-- User object: array of [B -->
0N/A <!-- Min length: 1 -->
0N/A <!-- Max length: 65533 -->
0N/A <!ATTLIST "com" "comment" #CDATA #IMPLIED>
0N/A <!-- The comment as a string (used only if user object is null)
0N/A <!-- Data type: String -->
0N/A <!ELEMENT "unknown" EMPTY>
0N/A <!-- An unrecognized marker segment. The user object contains the
0N/A data not including length. -->
0N/A <!-- User object: array of [B -->
0N/A <!-- Min length: 1 -->
0N/A <!-- Max length: 65533 -->
0N/A <!ATTLIST "unknown" "MarkerTag" #CDATA #REQUIRED>
0N/A <!-- The tag identifying this marker segment -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ELEMENT "app14Adobe" EMPTY>
0N/A <!-- An Adobe APP14 marker segment -->
0N/A <!ATTLIST "app14Adobe" "version" #CDATA "100">
0N/A <!-- The version of Adobe APP14 marker segment -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 100 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "app14Adobe" "flags0" #CDATA "0">
0N/A <!-- The flags0 variable of an APP14 marker segment -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "app14Adobe" "flags1" #CDATA "0">
0N/A <!-- The flags1 variable of an APP14 marker segment -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "app14Adobe" "transform" ("0" | "1" | "2") #REQUIRED>
0N/A <!-- The color transform applied to the image (0 = Unknown, 1 =
0N/A YCbCr, 2 = YCCK) -->
0N/A <!ELEMENT "sof" (componentSpec)*>
0N/A <!-- A Start Of Frame marker segment -->
0N/A <!-- Min children: 1 -->
0N/A <!-- Max children: 4 -->
0N/A <!ATTLIST "sof" "process" ("0" | "1" | "2") #IMPLIED>
0N/A <!-- The JPEG process (0 = Baseline sequential, 1 = Extended
0N/A sequential, 2 = Progressive) -->
0N/A <!ATTLIST "sof" "samplePrecision" #CDATA "8">
0N/A <!-- The number of bits per sample -->
0N/A <!-- Data type: Integer -->
0N/A <!ATTLIST "sof" "numLines" #CDATA #IMPLIED>
0N/A <!-- The number of lines in the image -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "sof" "samplesPerLine" #CDATA #IMPLIED>
0N/A <!-- The number of samples per line -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 65535 (inclusive) -->
0N/A <!ATTLIST "sof" "numFrameComponents" ("1" | "2" | "3" | "4")
0N/A <!-- The number of components in the image -->
0N/A <!ELEMENT "componentSpec" EMPTY>
0N/A <!-- A component specification for a frame -->
0N/A <!ATTLIST "componentSpec" "componentId" #CDATA #REQUIRED>
0N/A <!-- The id for this component -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "componentSpec" "HsamplingFactor" #CDATA #REQUIRED>
0N/A <!-- The horizontal sampling factor for this component -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 1 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "componentSpec" "VsamplingFactor" #CDATA #REQUIRED>
0N/A <!-- The vertical sampling factor for this component -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 1 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "componentSpec" "QtableSelector" ("0" | "1" | "2" |
0N/A <!-- The quantization table to use for this component -->
0N/A <!ELEMENT "sos" (scanComponentSpec)*>
0N/A <!-- A Start Of Scan marker segment -->
0N/A <!-- Min children: 1 -->
0N/A <!-- Max children: 4 -->
0N/A <!ATTLIST "sos" "numScanComponents" ("1" | "2" | "3" | "4")
0N/A <!-- The number of components in the scan -->
0N/A <!ATTLIST "sos" "startSpectralSelection" #CDATA "0">
0N/A <!-- The first spectral band included in this scan -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 63 (inclusive) -->
0N/A <!ATTLIST "sos" "endSpectralSelection" #CDATA "63">
0N/A <!-- The last spectral band included in this scan -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 63 (inclusive) -->
0N/A <!ATTLIST "sos" "approxHigh" #CDATA "0">
0N/A <!-- The highest bit position included in this scan -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 15 (inclusive) -->
0N/A <!ATTLIST "sos" "approxLow" #CDATA "0">
0N/A <!-- The lowest bit position included in this scan -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 15 (inclusive) -->
0N/A <!ELEMENT "scanComponentSpec" EMPTY>
0N/A <!-- A component specification for a scan -->
0N/A <!ATTLIST "scanComponentSpec" "componentSelector" #CDATA
0N/A <!-- The id of this component -->
0N/A <!-- Data type: Integer -->
0N/A <!-- Min value: 0 (inclusive) -->
0N/A <!-- Max value: 255 (inclusive) -->
0N/A <!ATTLIST "scanComponentSpec" "dcHuffTable" ("0" | "1" | "2" |
0N/A <!-- The huffman table to use for encoding DC coefficients -->
0N/A <!ATTLIST "scanComponentSpec" "acHuffTable" ("0" | "1" | "2" |
0N/A <!-- The huffman table to use for encoding AC coefficients -->
0N/A<
a name=stream>Stream Metadata DTD</
a>
0N/A<!DOCTYPE "javax_imageio_jpeg_stream_1.0" [
0N/A <!ELEMENT "javax_imageio_jpeg_stream_1.0" (dqt |
0N/A <!-- All elements are as defined above for image metadata -->