--- a/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html Wed Nov 29 09:47:02 2017 -0800
+++ b/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html Wed Nov 29 15:11:37 2017 -0800
@@ -1,8 +1,11 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
+<!doctype html>
+<html lang="en">
<head>
+ <meta charset="utf-8"/>
+ <title>JPEG Metadata Format Specification and Usage Notes</title>
+</head>
<!--
-Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
This code is free software; you can redistribute it and/or modify it
@@ -26,14 +29,9 @@
questions.
-->
-<title>JPEG Metadata Format Specification and Usage Notes</title>
-</head>
+<body>
-<body bgcolor="white">
-
-<center><h1>
-JPEG Metadata Format Specification and Usage Notes
-</h1></center>
+<h1>JPEG Metadata Format Specification and Usage Notes</h1>
<p>
<a href=#metadata>JPEG Metadata</a><br>
@@ -46,11 +44,11 @@
<a href=#image>Image Metadata DTD</a><br>
<a href=#stream>Stream Metadata DTD</a>
<p>
-<b>NOTE</b>: It is important to call <code>dispose()</code>
-on the JPEG reader and writer objects when they are no longer needed, as
-they consume significant native resources which are not adequately recovered
-by garbage collection. Both reader and writer call <code>dispose()</code>
-in their finalizers, but those finalizers may not be called before the native
+<b>NOTE</b>: It is important to call <code>dispose()</code>
+on the JPEG reader and writer objects when they are no longer needed, as
+they consume significant native resources which are not adequately recovered
+by garbage collection. Both reader and writer call <code>dispose()</code>
+in their finalizers, but those finalizers may not be called before the native
code has exhausted native memory.
<p>
@@ -58,45 +56,45 @@
The JPEG writer does not support replacing pixels.
<h2>
-<a name=metadata>JPEG Metadata</a>
+<a id=metadata>JPEG Metadata</a>
</h2>
JPEG metadata consists of the data contained in marker segments in a JPEG
stream. The image metadata object returned from a read describes the
-contents of the marker segments between the <code>SOI</code> marker and
-the <code>EOI</code> marker for that image. The image metadata object
-passed into a write determines the contents of the stream between the
-<code>SOI</code> marker and the <code>EOI</code> marker for that image,
+contents of the marker segments between the <code>SOI</code> marker and
+the <code>EOI</code> marker for that image. The image metadata object
+passed into a write determines the contents of the stream between the
+<code>SOI</code> marker and the <code>EOI</code> marker for that image,
subject to the controls in any <code>ImageWriteParam</code>.
<p>
-Stream metadata is used only for tables-only images found (or to be
-placed) at the beginning of a stream containing abbreviated images.
-Tables-only images are not treated as images and do not consume an
+Stream metadata is used only for tables-only images found (or to be
+placed) at the beginning of a stream containing abbreviated images.
+Tables-only images are not treated as images and do not consume an
image index. The stream metadata object returned from a read describes the
-contents of the marker segments between the <code>SOI</code> marker and
-the <code>EOI</code> marker for the single tables-only image at the
-beginning of the stream, if one is present. If no tables-only image is
-present at the front of the stream, the <code>getStreamMetadata</code>
-method of <code>ImageReader</code> returns <code>null</code>. If
-stream metadata is provided to the writer, a single tables-only image
-containing the tables from the stream metadata object will be written at
+contents of the marker segments between the <code>SOI</code> marker and
+the <code>EOI</code> marker for the single tables-only image at the
+beginning of the stream, if one is present. If no tables-only image is
+present at the front of the stream, the <code>getStreamMetadata</code>
+method of <code>ImageReader</code> returns <code>null</code>. If
+stream metadata is provided to the writer, a single tables-only image
+containing the tables from the stream metadata object will be written at
the beginning of the stream. If the stream metadata object contains no
tables, default tables will be written. As the sole purpose of stream
-metadata is for specifying tables-only images at the front of abbreviated
-streams, the stream metadata argument is useful only on the
-<code>ImageWriter.prepareWriteSequence</code> method. It is ignored on all
+metadata is for specifying tables-only images at the front of abbreviated
+streams, the stream metadata argument is useful only on the
+<code>ImageWriter.prepareWriteSequence</code> method. It is ignored on all
other methods.
-<p>
-The <code>ImageWriter.getDefaultStreamMetadata</code> method returns an
-object containing the tables from the <code>ImageWriteParam</code> argument,
-if it is a <code>JPEGImageWriteParam</code> and contains tables. Otherwise,
+<p>
+The <code>ImageWriter.getDefaultStreamMetadata</code> method returns an
+object containing the tables from the <code>ImageWriteParam</code> argument,
+if it is a <code>JPEGImageWriteParam</code> and contains tables. Otherwise,
the returned object will contain default tables.
-<p>The <code>ImageWriter.getDefaultImageMetadata</code> method returns a
-metadata object containing <b>no</b> tables if the
-<code>ImageWriteParam</code> argument contains tables. Otherwise the
-returned metadata object will contain default visually lossless tables.
+<p>The <code>ImageWriter.getDefaultImageMetadata</code> method returns a
+metadata object containing <b>no</b> tables if the
+<code>ImageWriteParam</code> argument contains tables. Otherwise the
+returned metadata object will contain default visually lossless tables.
Of course, only a <code>JPEGImageWriteParam</code> may contain tables.
<p>
@@ -105,59 +103,59 @@
metadata will.
<h2>
-<a name=abbrev>Abbreviated Streams</a>
+<a id=abbrev>Abbreviated Streams</a>
</h2>
-Both the reader and the writer retain their tables from one operation to the
-next, thus permitting the use of abbreviated streams quite naturally, with a
-few minor restrictions:
+Both the reader and the writer retain their tables from one operation to the
+next, thus permitting the use of abbreviated streams quite naturally, with a
+few minor restrictions:
<ol>
- <li> Abbreviated streams may contain only one tables-only image, which must
+ <li> Abbreviated streams may contain only one tables-only image, which must
come first in the stream. Subsequent tables-only images will cause
undefined behavior.</li>
<li> Abbreviated streams must be read fully and in order. No random access
- is allowed, in either direction. The same image may be read multiple
+ is allowed, in either direction. The same image may be read multiple
times. If a call is made with an image index that is not the same as
or one greater than the most recent call (or 0 if no calls have been
made), then an <code>IllegalArgumentException</code> is thrown.</li>
</ol>
-These restrictions mean that streams may contain abbreviated images
+These restrictions mean that streams may contain abbreviated images
interspersed with images containing tables. As required by JPEG, any tables
appearing in the stream override previous tables, regardless of the source
-of the previous tables.
+of the previous tables.
<p>
Note that once a tables-only image has been read, it's contents is available
as stream metadata from the reader until either another tables-only image
is read from another stream or the reader is reset. Changing the input does
not reset the stream metadata. This is useful for reading the tables from
-one file, then changing the input to read an abbreviated stream containing
+one file, then changing the input to read an abbreviated stream containing
a sequence of images. The tables will be used automatically, and will remain
available as "stream" metadata.
<p>
-Abbreviated streams are written using the sequence methods of
-<code>ImageWriter</code>. Stream metadata is used to write a tables-only
+Abbreviated streams are written using the sequence methods of
+<code>ImageWriter</code>. Stream metadata is used to write a tables-only
image at the beginning of the stream, and the tables are set up for use, using
-<code>ImageWriter.prepareWriteSequence</code>. If no stream metadata is
-supplied to <code>ImageWriter.prepareWriteSequence</code>, then no
+<code>ImageWriter.prepareWriteSequence</code>. If no stream metadata is
+supplied to <code>ImageWriter.prepareWriteSequence</code>, then no
tables-only image is written. If stream metadata containing no tables is
supplied to <code>ImageWriter.prepareWriteSequence</code>, then a tables-only
image containing default visually lossless tables is written.
<h2>
-<a name=tables>Sources of Tables</a>
+<a id=tables>Sources of Tables</a>
</h2>
<p>
-Images are written with tables if tables are present in their metadata objects
+Images are written with tables if tables are present in their metadata objects
or without them if no tables are present in their metadata objects. If no
-metadata object is present then the tables are written. The tables used for
-compression are taken from one of the following sources, which are consulted
-in order:
+metadata object is present then the tables are written. The tables used for
+compression are taken from one of the following sources, which are consulted
+in order:
<ol>
<li> If there is an <code>ImageWriteParam</code> and the compression mode is
set to <code>EXPLICIT</code>, default tables constructed using the
- quality setting are used. They are written only if the metadata
- contains tables or if there is no metadata, but they replace the
+ quality setting are used. They are written only if the metadata
+ contains tables or if there is no metadata, but they replace the
tables in the metadata.</li>
<li> If there is an <code>ImageWriteParam</code> and the compression mode is
set to <code>DEFAULT</code>, default visually lossles tables are used.
@@ -176,39 +174,39 @@
</li>
</ol>
-This ordering implements the design intention that tables should be included
-in <code>JPEGImageWriteParam</code>s only as a means of specifying tables
+This ordering implements the design intention that tables should be included
+in <code>JPEGImageWriteParam</code>s only as a means of specifying tables
when no other source is available, and this can occur only when writing to an
-abbreviated stream without tables using known non-standard tables for
+abbreviated stream without tables using known non-standard tables for
compression.
<p>
-When reading, tables in a <code>JPEGImageReadParam</code> are consulted only
-if tables have not been set by any previous read. Tables set from a
-<code>JPEGImageReadParam</code> are overridden by any tables present in the
+When reading, tables in a <code>JPEGImageReadParam</code> are consulted only
+if tables have not been set by any previous read. Tables set from a
+<code>JPEGImageReadParam</code> are overridden by any tables present in the
stream being read.
<p>
-Note that if no image metadata object is specified for a particular image, a
+Note that if no image metadata object is specified for a particular image, a
default object is used, which includes default tables.
<h2>
-<a name=color>Colorspace Transformations and Conventional Markers</a>
+<a id=color>Colorspace Transformations and Conventional Markers</a>
</h2>
Colorspace transformations are controlled by the destination type for
both reading and writing of images. When <code>Raster</code>s are
-read, no colorspace transformation is performed, and any destination type
-is ignored. A warning is sent to any listeners if a destination type is
-specified in this case. When <code>Raster</code>s are written, any
+read, no colorspace transformation is performed, and any destination type
+is ignored. A warning is sent to any listeners if a destination type is
+specified in this case. When <code>Raster</code>s are written, any
destination type is used to interpret the bands. This might result in a
-JFIF or Adobe header being written, or different component ids being written
-to the frame and scan headers. If values present in a metadata object do not
-match the destination type, the destination type is used and a warning is sent
+JFIF or Adobe header being written, or different component ids being written
+to the frame and scan headers. If values present in a metadata object do not
+match the destination type, the destination type is used and a warning is sent
to any listeners.
<p>
-<a name=optcolor><b>Optional ColorSpace support:</b></a>
+<a id=optcolor><b>Optional ColorSpace support:</b></a>
Handling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA and YCbCrA color spaces
by the standard plugin, as described below, is dependent on capabilities
of the libraries used to interpret the JPEG data. Thus all consequential
@@ -219,7 +217,7 @@
When writing, an Exception may be thrown if no suitable conversion
can be applied before encoding.
But where the support for these color spaces is available, the behavior
-must be as documented.
+must be as documented.
<p>
When reading, the contents of the stream are interpreted by the usual
@@ -232,7 +230,7 @@
the YCbCr is converted to RGB according to the formulas given in the
JFIF spec, and the ICC profile is assumed to refer to the resulting RGB
space.
- <li> If an Adobe <code>APP14</code> marker segment is present, the
+ <li> If an Adobe <code>APP14</code> marker segment is present, the
colorspace is determined by consulting the <code>transform</code> flag.
The <code>transform</code> flag takes one of three values:
<ul>
@@ -242,7 +240,7 @@
<li> 1 - The image is encoded as YCbCr (implicitly converted from RGB
on encoding).
- <li> 0 - Unknown. 3-channel images are assumed to be RGB, 4-channel
+ <li> 0 - Unknown. 3-channel images are assumed to be RGB, 4-channel
images are assumed to be CMYK.
</ul>
<li> If neither marker segment is present, the following procedure is
@@ -253,9 +251,9 @@
YCbCr. Subject to the availability of the
<a href=#optcolor>optional color space support</a>
described above, if these values are 1-4 for a 4-channel image,
- then the image is assumed to be YCbCrA.
- If these values are > 4, they are checked
- against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can
+ then the image is assumed to be YCbCrA.
+ If these values are > 4, they are checked
+ against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can
encode the following colorspaces:
<p>
<br>RGB
@@ -263,28 +261,28 @@
<br>YCC (as 'Y','C','c'), assumed to be PhotoYCC
<br>YCCA (as 'Y','C','c','A'), assumed to be PhotoYCCA
<p>
- Otherwise, 3-channel subsampled images are assumed to be YCbCr,
- 3-channel non-subsampled images are assumed to be RGB, 4-channel
+ Otherwise, 3-channel subsampled images are assumed to be YCbCr,
+ 3-channel non-subsampled images are assumed to be RGB, 4-channel
subsampled images are assumed to be YCCK, and 4-channel, non-subsampled
images are assumed to be CMYK.
<li> All other images are declared uninterpretable and an exception is
- thrown if an attempt is made to read one as a
- <code>BufferedImage</code>. Such an image may be read only as a
+ thrown if an attempt is made to read one as a
+ <code>BufferedImage</code>. Such an image may be read only as a
<code>Raster</code>. If an image is interpretable but there is no Java
- <code>ColorSpace</code> available corresponding to the encoded
- colorspace (<i>e.g.</i> YCbCr), then
+ <code>ColorSpace</code> available corresponding to the encoded
+ colorspace (<i>e.g.</i> YCbCr), then
<code>ImageReader.getRawImageType</code> will return <code>null</code>.
</ul>
-Once an encoded colorspace is determined, then the target colorspace is
+Once an encoded colorspace is determined, then the target colorspace is
determined as follows:
<ul>
<li> If a destination type is not set, then the following default
- transformations take place after upsampling: YCbCr (and YCbCrA) images
+ transformations take place after upsampling: YCbCr (and YCbCrA) images
are converted to RGB (and RGBA) using the conversion provided by the
- underlying IJG library and either the built-in sRGB
+ underlying IJG library and either the built-in sRGB
<code>ColorSpace</code> or a custom RGB <code>ColorSpace</code> object
based on an embedded ICC profile is used to create the output
<code>ColorModel</code>. PhotoYCC and PhotoYCCA images are not
@@ -292,16 +290,16 @@
<li> If a destination image or type is set, it is used as follows:
If the IJG library provides an appropriate conversion, it is used.
- Otherwise the default library conversion is followed by a colorspace
+ Otherwise the default library conversion is followed by a colorspace
conversion in Java.</li>
- <li> Bands are selected AFTER any library colorspace conversion. If a
- subset of either source or destination bands is used, then the default
+ <li> Bands are selected AFTER any library colorspace conversion. If a
+ subset of either source or destination bands is used, then the default
library conversions are used with no further conversion in Java,
regardless of any destination type.</li>
- <li> An exception is thrown if an attempt is made to read an image in an
- unsupported jpeg colorspace as a <code>BufferedImage</code>
+ <li> An exception is thrown if an attempt is made to read an image in an
+ unsupported jpeg colorspace as a <code>BufferedImage</code>
(<i>e.g.</i> CMYK). Such images may be read as
<code>Raster</code>s. If an image colorspace is unsupported or
uninterpretable, then <code>ImageReader.getImageTypes</code> will
@@ -315,26 +313,26 @@
follows:
<p>
-If a subset of the source bands is to be written, no color conversion is
-performed. Any destination, if set, must match the number of bands that will
-be written, and serves as an interpretation of the selected bands, rather than
-a conversion request. This behavior is identical to that for
-<code>Raster</code>s. If all the bands are to be written and an image
-(as opposed to a <code>Raster</code>) is being written, any destination type
+If a subset of the source bands is to be written, no color conversion is
+performed. Any destination, if set, must match the number of bands that will
+be written, and serves as an interpretation of the selected bands, rather than
+a conversion request. This behavior is identical to that for
+<code>Raster</code>s. If all the bands are to be written and an image
+(as opposed to a <code>Raster</code>) is being written, any destination type
is ignored and a warning is sent to any listeners.
<p>
-If a destination type is used and any aspect of the metadata object, if there
-is one, is not compatible with that type, the destination type is used, the
-metadata written is modified from that provided, and a warning is sent to
-listeners. This includes the <code>app0JFIF</code> and
-<code>app14Adobe</code> nodes. The component ids in the <code>sof</code> and
-<code>sos</code> nodes are not modified, however, as unless a
+If a destination type is used and any aspect of the metadata object, if there
+is one, is not compatible with that type, the destination type is used, the
+metadata written is modified from that provided, and a warning is sent to
+listeners. This includes the <code>app0JFIF</code> and
+<code>app14Adobe</code> nodes. The component ids in the <code>sof</code> and
+<code>sos</code> nodes are not modified, however, as unless a
<code>app0JFIF</code> node is present, any values may be used.
<p>
-When a full image is written, a destination colorspace will be
-chosen based on the image contents and the metadata settings, according to
+When a full image is written, a destination colorspace will be
+chosen based on the image contents and the metadata settings, according to
the following algorithm:
<p>
@@ -351,9 +349,9 @@
channels by half both vertically and horizontally, and written with a
JFIF <code>APP0</code> marker segment. If the <code>ColorSpace</code>
of the image is based on an <code>ICCProfile</code> (it is an instance
- of <code>ICC_ColorSpace</code>, but is not one of the standard built-in
- <code>ColorSpaces</code>), then that profile is embedded in an
- <code>APP2</code> marker segment. As required by JFIF, the
+ of <code>ICC_ColorSpace</code>, but is not one of the standard built-in
+ <code>ColorSpaces</code>), then that profile is embedded in an
+ <code>APP2</code> marker segment. As required by JFIF, the
component ids in the frame and scan headers are set to 1, 2, and 3.
@@ -361,7 +359,7 @@
described above,
RGBA images are converted to YCbCrA, subsampled in the
chrominance channels by half both vertically and horizontally, and
- written without any special marker segments. The component ids
+ written without any special marker segments. The component ids
in the frame and scan headers are set to 1, 2, 3, and 4.
<li> Subject to the <a href=#optcolor>optional library support</a>
@@ -378,16 +376,16 @@
<p>
If a metadata object is specified, then the number of channels in the
-frame and scan headers must always match the number of bands to be
-written, or an exception is thrown. <code>app0JFIF</code> and
-<code>app14Adobe</code> nodes may appear in the same metadata object only
-if the <code>app14Adobe</code> node indicates YCbCr, and the component ids
-are JFIF compatible (0-2). The various image types are processed in the
+frame and scan headers must always match the number of bands to be
+written, or an exception is thrown. <code>app0JFIF</code> and
+<code>app14Adobe</code> nodes may appear in the same metadata object only
+if the <code>app14Adobe</code> node indicates YCbCr, and the component ids
+are JFIF compatible (0-2). The various image types are processed in the
following ways:
<br>
-(All multi-channel images are subsampled according to the sampling factors
+(All multi-channel images are subsampled according to the sampling factors
in the frame header node of the metadata object, regardless of color space.)
<ul>
@@ -395,10 +393,10 @@
<ul>
<li> If an <code>app0JFIF</code> node is present in the metadata object,
a JFIF <code>APP0</code> marker segment is written.
- <li> If an <code>app14Adobe</code> node is present in the metadata
+ <li> If an <code>app14Adobe</code> node is present in the metadata
object, it is checked for validity (<code>transform</code> must be
<code>UNKNOWN</code>) and written.
- <li> If neither node is present in the metadata object, no special
+ <li> If neither node is present in the metadata object, no special
marker segment is written.
</ul>
@@ -412,14 +410,14 @@
<code>UNKNOWN</code>) and written. If <code>transform</code> is
not <code>UNKNOWN</code>, a warning is sent to listeners and the
correct transform is written.
- <li> If neither node is present in the metadata object, no special
+ <li> If neither node is present in the metadata object, no special
marker segment is written.
</ul>
<li> RGB Images:
<ul>
<li> If an <code>app0JFIF</code> node is present in the metadata object,
- the image is converted to YCbCr and written with a JFIF
+ the image is converted to YCbCr and written with a JFIF
<code>APP0</code> marker segment. If the <code>ColorSpace</code>
of the image is based on a non-standard ICC Profile, then that
profile is embedded in an <code>APP2</code> marker segment. If the
@@ -439,7 +437,7 @@
<li> If neither node is present, the component ids in the frame
header are consulted. If these indicate a colorspace as described
- above, then the image is converted to that colorspace if possible.
+ above, then the image is converted to that colorspace if possible.
If the component ids do not indicate a colorspace, then the
sampling factors are consulted. If the image is to be subsampled,
it is converted to YCbCr first. If the image is not to be
@@ -459,7 +457,7 @@
object, the image is written with an Adobe <code>APP14</code> marker
segment. No colorspace conversion is performed. Component ids
are written just as they appear in the frame and scan headers.
- The color transform must be <code>UNKNOWN</code>. If it is
+ The color transform must be <code>UNKNOWN</code>. If it is
not, a warning is sent to listeners.
<li> If no <code>app14Adobe</code> node is present, the component ids in
@@ -509,16 +507,16 @@
</ul>
<h2>
-<a name=thumbs>Thumbnail Images</a>
+<a id=thumbs>Thumbnail Images</a>
</h2>
Thumbnails are supported by the use of JFIF and JFIF extension marker segments.
-Thumbnails provided on the write methods determine the thumbnails that will be
-included. <code>app0JFIF</code> and <code>app0JFXX</code> nodes present in
-the metadata do not contain any thumbnail pixel data. However, the kinds of
-thumbnails written depend on the contents of the metadata object, as follows.
-Any thumbnail which is to be written as an indexed or RGB image and which is
-larger than 255 by 255 will be clipped, not scaled, to 255 by 255. Thumbnails
-written as JPEG images may be any size. A warning is sent to any listeners
+Thumbnails provided on the write methods determine the thumbnails that will be
+included. <code>app0JFIF</code> and <code>app0JFXX</code> nodes present in
+the metadata do not contain any thumbnail pixel data. However, the kinds of
+thumbnails written depend on the contents of the metadata object, as follows.
+Any thumbnail which is to be written as an indexed or RGB image and which is
+larger than 255 by 255 will be clipped, not scaled, to 255 by 255. Thumbnails
+written as JPEG images may be any size. A warning is sent to any listeners
whenever a thumbnail is clipped.
<ul>
<li> If there is a single thumbnail, it is processed as follows:
@@ -534,14 +532,14 @@
<li> If the first <code>app0JFXX</code> node present in the metadata
contains another thumbnail form (RGB or JPEG), the palette
image is expanded to RGB and the indicated thumbnail form is
- written.
+ written.
</ul>
<li> If the thumbnail image is an RGB image, it is processed as follows:
<ul>
<li> If no <code>app0JFXX</code> node is present in the metadata,
the thumbnail is written as part of the JFIF <code>APP0</code>
- marker segment.
+ marker segment.
<li> If the first <code>app0JFXX</code> node present in the metadata
contains a <code>JFIFthumbRGB</code> element, an
RGB thumbnail is written in a JFXX <code>APP0</code> marker
@@ -561,7 +559,7 @@
<ul>
<li> If no <code>app0JFXX</code> node is present in the metadata,
the thumbnail is expanded to RGB and written as part of the
- JFIF <code>APP0</code> marker segment.
+ JFIF <code>APP0</code> marker segment.
<li> If the first <code>app0JFXX</code> node present in the metadata
contains a <code>JFIFthumbRGB</code> element, the thumbnail is
expanded to RGB and written in a separate <code>JFXX</code> RGB
@@ -587,50 +585,50 @@
sequence as the thumbnail. <i>I.e.</i> the first
<code>app0JFXX</code> node applies to the first thumbnail, the second
node to the second thumbnail, and so on. If there are fewer
- <code>app0JFXX</code> nodes in the metadata than thumbnails, then
+ <code>app0JFXX</code> nodes in the metadata than thumbnails, then
those thumbnails are considered to have no matching
<code>app0JFXX</code> node. An RGB thumbnail with no matching
<code>app0JFXX</code> node is written in a JFXX <code>APP0</code> marker
segment. A grayscale thumbnail with no matching
- <code>app0JFXX</code> node is written as a JPEG image to a JFXX
+ <code>app0JFXX</code> node is written as a JPEG image to a JFXX
<code>APP0</code> marker segment.
</ul>
<p>
Note that as the only mechanism for storing thumbnails is via the
-JFIF or JFIF extension marker segments, only grayscale or RGB images
-may have thumbnails. If thumbnails are present when writing any other type
+JFIF or JFIF extension marker segments, only grayscale or RGB images
+may have thumbnails. If thumbnails are present when writing any other type
of image, the thumbnails are ignored and a warning is sent to any warning
listeners.
<h2>
-<a name=prog>Progressive Encoding</a>
+<a id=prog>Progressive Encoding</a>
</h2>
Progressive encoding must be enabled on the <code>ImageWriteParam</code>
passed in to a write operation, or the image will be written sequentially,
-regardless of the scan headers included in the metadata object. If
+regardless of the scan headers included in the metadata object. If
progressive encoding is enabled and set to copy from metadata, then
-the sequence of scan headers from the metadata is used to write the
-image. If progressive encoding is enabled and set to use a default,
-then the scans in the metadata are ignored and a default set of scans
+the sequence of scan headers from the metadata is used to write the
+image. If progressive encoding is enabled and set to use a default,
+then the scans in the metadata are ignored and a default set of scans
is used. Progressive encoding always forces optimized Huffman tables to
be used. Any Huffman tables present in the metadata will be ignored,
and a warning will be sent to any warning listeners.
If Huffman-table optimization is requested on the <code>ImageWriteParam</code>,
-all Huffman tables in the metadata or in the <code>ImageWriteParam</code>
-itself are ignored, and a warning will be sent to any warning listeners if
+all Huffman tables in the metadata or in the <code>ImageWriteParam</code>
+itself are ignored, and a warning will be sent to any warning listeners if
any such tables are present.
<h2>
-<a name=tree>Native Metadata Format Tree Structure and Editing</a>
+<a id=tree>Native Metadata Format Tree Structure and Editing</a>
</h2>
The DTDs below describe just the trees of metadata objects actually returned
-by the <code>IIOMetadata</code> object. They do not include nodes
-corresponding to <code>SOI</code>, <code>EOI</code>, or <code>RST</code>
-markers, as these parsing delimiters do not carry any meaningful metadata.
+by the <code>IIOMetadata</code> object. They do not include nodes
+corresponding to <code>SOI</code>, <code>EOI</code>, or <code>RST</code>
+markers, as these parsing delimiters do not carry any meaningful metadata.
<p>
The first node is always a <code>JPEGvariety</code> node. In the
@@ -659,60 +657,60 @@
<p>
-On reading, <code>JFXX</code> and <code>app2ICC</code> nodes occur as
+On reading, <code>JFXX</code> and <code>app2ICC</code> nodes occur as
children of an <code>app0JFIF</code> node.
-This is true regardless of where the JFXX <code>APP0</code> and
-<code>APP2</code> marker segments actually occur in the stream. The ordering
-of nodes within the <code>markerSequence</code> node corresponds to the
+This is true regardless of where the JFXX <code>APP0</code> and
+<code>APP2</code> marker segments actually occur in the stream. The ordering
+of nodes within the <code>markerSequence</code> node corresponds to the
ordering of marker segments found in the JPEG stream.
<p>
-On writing, any <code>JFXX</code> and <code>app2ICC</code> nodes must
-occur as children of an <code>app0JFIF</code> node, itself a child of a
+On writing, any <code>JFXX</code> and <code>app2ICC</code> nodes must
+occur as children of an <code>app0JFIF</code> node, itself a child of a
<code>JPEGvariety</code> node, which must always be the first node.
(If the stream is not to be JFIF compliant, no <code>app0JFIF</code> node
should be provided, and the <code>JPEGvariety</code> node should have no
-children.) Any
-JFIF <code>APP0</code>, JFXX <code>APP0</code>, and <code>APP2</code> marker
-segments are written first, followed by all Adobe <code>APP14</code>,
-<code>APPn</code>, <code>COM</code> and unknown segments in the
-order in which their corresponding nodes appear in the
-<code>markerSequence</code> node, followed by <code>DQT</code> (and
-<code>DHT</code> for non-progressive writes) marker segments, followed by the
+children.) Any
+JFIF <code>APP0</code>, JFXX <code>APP0</code>, and <code>APP2</code> marker
+segments are written first, followed by all Adobe <code>APP14</code>,
+<code>APPn</code>, <code>COM</code> and unknown segments in the
+order in which their corresponding nodes appear in the
+<code>markerSequence</code> node, followed by <code>DQT</code> (and
+<code>DHT</code> for non-progressive writes) marker segments, followed by the
<code>SOF</code> and <code>SOS</code> marker segments. For progressive writes
-using metadata to control progression, the <code>SOS</code> segments are used
-in the order in which their corresponding nodes occur in the
+using metadata to control progression, the <code>SOS</code> segments are used
+in the order in which their corresponding nodes occur in the
<code>markerSequence</code> node.
<p>
-The <code>reset</code>, <code>mergeTree</code> and <code>setFromTree</code>
+The <code>reset</code>, <code>mergeTree</code> and <code>setFromTree</code>
operations have the following semantics for the JPEG plug-in metadata object:
-<p> <code>reset</code> - A call to <code>reset</code> will restore the
-metadata object to the same state it had immediately after creation, whether
-this came about from reading a stream or by obtaining a default object from
-the <code>ImageWriter</code>. This is true regardless of how many times the
+<p> <code>reset</code> - A call to <code>reset</code> will restore the
+metadata object to the same state it had immediately after creation, whether
+this came about from reading a stream or by obtaining a default object from
+the <code>ImageWriter</code>. This is true regardless of how many times the
metadata object has been modified since creation.
<p> <code>mergeTree</code> - Native Format
-<br> The <code>mergeTree</code> operation accepts valid trees conforming to
-the DTD below, and merges the nodes using the following ordering rules. In
-all cases, only data present in the new node is changed in a corresponding
-existing node, if any. This means that nodes cannot be removed using
-<code>mergeTree</code>. To remove nodes, use <code>setFromTree</code>. The
+<br> The <code>mergeTree</code> operation accepts valid trees conforming to
+the DTD below, and merges the nodes using the following ordering rules. In
+all cases, only data present in the new node is changed in a corresponding
+existing node, if any. This means that nodes cannot be removed using
+<code>mergeTree</code>. To remove nodes, use <code>setFromTree</code>. The
tree must consist of <code>IIOMetadataNode</code>s.
<ul>
<li> <code>app0JFIF</code>
<ul>
- <li> If an <code>app0JFIF</code> node already exists, the contents
- of the new one modify the existing one.
+ <li> If an <code>app0JFIF</code> node already exists, the contents
+ of the new one modify the existing one.
<li> If there is no such node, a new one is created and inserted in
the appropriate position.
- </ul>
+ </ul>
<li> <code>dqt</code>
<ul>
<li> If there already exist <code>dqt</code> nodes in the sequence,
then each table in the node replaces the first table, in any
- <code>dqt</code> node, with the same table id.
+ <code>dqt</code> node, with the same table id.
<li> If none of the existing <code>dqt</code> nodes contain a table
with the same id, then the table is added to the last existing
<code>dqt</code> node.
@@ -720,10 +718,10 @@
created and added as follows:
<ul>
<li> If there are <code>dht</code> nodes, the new
- <code>dqt</code> node is inserted before the first one.
+ <code>dqt</code> node is inserted before the first one.
<li> If there are no <code>dht</code> nodes, the new
<code>dqt</code> node is inserted before an
- <code>sof</code> node, if there is one.
+ <code>sof</code> node, if there is one.
<li> If there is no <code>sof</code> node, the new
<code>dqt</code> node is inserted before the first
<code>sos</code> node, if there is one.
@@ -747,7 +745,7 @@
last <code>dqt</code> node.
<li> If there are no <code>dqt</code> nodes, the new
<code>dht</code> node is inserted before an
- <code>sof</code> node, if there is one.
+ <code>sof</code> node, if there is one.
<li> If there is no <code>sof</code> node, the new
<code>dht</code> node is inserted before the first
<code>sos</code> node, if there is one.
@@ -757,7 +755,7 @@
</ul>
<li> <code>dri</code>
<ul>
- <li> If there already exists a <code>dri</code> node, the restart
+ <li> If there already exists a <code>dri</code> node, the restart
interval value is updated.
<li> If there is no <code>dri</code> node, then a new one is created
and added as follows:
@@ -785,11 +783,11 @@
</ul>
<li> <code>app14Adobe</code>
<ul>
- <li> If there already exists an <code>app14Adobe</code> node, then
+ <li> If there already exists an <code>app14Adobe</code> node, then
its attributes are updated from the node.
- <li> If there is no <code>app14Adobe</code> node, then a new one is
+ <li> If there is no <code>app14Adobe</code> node, then a new one is
created and added as follows:
- <ul>
+ <ul>
<li> The new <code>app14Adobe</code> node is inserted after the
last <code>unknown</code> node, if there are any.
<li> If there are no <code>unknown</code> nodes, the new
@@ -838,13 +836,13 @@
<p> <code>mergeTree</code> - Standard Format
<br>
-The <code>mergeTree</code> operation, when given a tree in the standard
+The <code>mergeTree</code> operation, when given a tree in the standard
format, will modify the native tree in the following ways:
<ul>
<li> <code>Chroma</code> - The <code>ColorSpaceType</code> subnode of a
<code>Chroma</code> node may change the target colorspace of the
compressed image. The selection of a new colorspace can cause a number
- of changes, in keeping with the algorithms described above:
+ of changes, in keeping with the algorithms described above:
<code>app0JFIF</code> and <code>app14Adobe</code> nodes may be added
or removed, subsampling may be added or removed, component ids may
be changed, and <code>sof</code> and <code>sos</code> nodes will be
@@ -871,17 +869,17 @@
<p> <code>setFromTree</code> - Native Format
<br>
-The <code>setFromTree</code> operation, when given a tree in the native
-format described below, will simply replace the existing tree in its entirety
+The <code>setFromTree</code> operation, when given a tree in the native
+format described below, will simply replace the existing tree in its entirety
with the new one. The tree must consist of <code>IIOMetadataNode</code>s.
<p> <code>setFromTree</code> - Standard Format
<br>
-The <code>setFromTree</code> operation, when given a tree in the standard
+The <code>setFromTree</code> operation, when given a tree in the standard
format, performs a <code>reset</code> followed by a merge of the new tree.
<h2>
-<a name=image>Image Metadata DTD</a>
+<a id=image>Image Metadata DTD</a>
</h2>
<pre>
@@ -891,39 +889,39 @@
<!ELEMENT "JPEGvariety" (app0JFIF)>
<!-- A node grouping all marker segments specific to the variety of
- stream being read/written (e.g. JFIF) - may be empty -->
+ stream being read/written (e.g. JFIF) - may be empty -->
<!ELEMENT "app0JFIF" (JFXX?, app2ICC?)>
<!ATTLIST "app0JFIF" "majorVersion" #CDATA "1">
- <!-- The major JFIF version number -->
+ <!-- The major JFIF version number -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "app0JFIF" "minorVersion" #CDATA "2">
- <!-- The minor JFIF version number -->
+ <!-- The minor JFIF version number -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "app0JFIF" "resUnits" ("0" | "1" | "2") "0">
- <!-- The resolution units for Xdensisty and Ydensity (0 = no
- units, just aspect ratio; 1 = dots/inch; 2 = dots/cm) -->
+ <!-- The resolution units for Xdensisty and Ydensity (0 = no
+ units, just aspect ratio; 1 = dots/inch; 2 = dots/cm) -->
<!ATTLIST "app0JFIF" "Xdensity" #CDATA "1">
- <!-- The horizontal density or aspect ratio numerator -->
+ <!-- The horizontal density or aspect ratio numerator -->
<!-- Data type: Integer -->
<!-- Min value: 1 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "app0JFIF" "Ydensity" #CDATA "1">
- <!-- The vertical density or aspect ratio denominator -->
+ <!-- The vertical density or aspect ratio denominator -->
<!-- Data type: Integer -->
<!-- Min value: 1 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "app0JFIF" "thumbWidth" #CDATA "0">
- <!-- The width of the thumbnail, or 0 if there isn't one -->
+ <!-- The width of the thumbnail, or 0 if there isn't one -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "app0JFIF" "thumbHeight" #CDATA "0">
- <!-- The height of the thumbnail, or 0 if there isn't one -->
+ <!-- The height of the thumbnail, or 0 if there isn't one -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
@@ -931,233 +929,233 @@
<!ELEMENT "JFXX" (app0JFXX)*>
<!-- Min children: 1 -->
- <!ELEMENT "app0JFXX" (JFIFthumbJPEG | JFIFthumbPalette |
+ <!ELEMENT "app0JFXX" (JFIFthumbJPEG | JFIFthumbPalette |
JFIFthumbRGB)>
- <!-- A JFIF extension marker segment -->
+ <!-- A JFIF extension marker segment -->
<!ATTLIST "app0JFXX" "extensionCode" ("16" | "17" | "19")
#IMPLIED>
- <!-- The JFXX extension code identifying thumbnail type: (16 =
- JPEG, 17 = indexed, 19 = RGB -->
+ <!-- The JFXX extension code identifying thumbnail type: (16 =
+ JPEG, 17 = indexed, 19 = RGB -->
<!ELEMENT "JFIFthumbJPEG" (markerSequence?)>
- <!-- A JFIF thumbnail in JPEG format (no JFIF segments
- permitted) -->
+ <!-- A JFIF thumbnail in JPEG format (no JFIF segments
+ permitted) -->
<!ELEMENT "JFIFthumbPalette" EMPTY>
- <!-- A JFIF thumbnail as an RGB indexed image -->
+ <!-- A JFIF thumbnail as an RGB indexed image -->
<!ATTLIST "JFIFthumbPalette" "thumbWidth" #CDATA #IMPLIED>
- <!-- The width of the thumbnail -->
+ <!-- The width of the thumbnail -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "JFIFthumbPalette" "thumbHeight" #CDATA #IMPLIED>
- <!-- The height of the thumbnail -->
+ <!-- The height of the thumbnail -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ELEMENT "JFIFthumbRGB" EMPTY>
- <!-- A JFIF thumbnail as an RGB image -->
+ <!-- A JFIF thumbnail as an RGB image -->
<!ATTLIST "JFIFthumbRGB" "thumbWidth" #CDATA #IMPLIED>
- <!-- The width of the thumbnail -->
+ <!-- The width of the thumbnail -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "JFIFthumbRGB" "thumbHeight" #CDATA #IMPLIED>
- <!-- The height of the thumbnail -->
+ <!-- The height of the thumbnail -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ELEMENT "app2ICC" EMPTY>
- <!-- An ICC profile APP2 marker segment -->
+ <!-- An ICC profile APP2 marker segment -->
<!-- Optional User object: java.awt.color.ICC_Profile -->
- <!ELEMENT "markerSequence" (dqt | dht | dri | com | unknown |
+ <!ELEMENT "markerSequence" (dqt | dht | dri | com | unknown |
app14Adobe | sof | sos)*>
- <!-- A node grouping all non-jfif marker segments -->
+ <!-- A node grouping all non-jfif marker segments -->
<!ELEMENT "dqt" (dqtable)*>
- <!-- A Define Quantization Table(s) marker segment -->
+ <!-- A Define Quantization Table(s) marker segment -->
<!-- Min children: 1 -->
<!-- Max children: 4 -->
<!ELEMENT "dqtable" EMPTY>
- <!-- A single quantization table -->
+ <!-- A single quantization table -->
<!-- User object: javax.imageio.plugins.jpeg.JPEGQTable -->
<!ATTLIST "dqtable" "elementPrecision" #CDATA "0">
- <!-- The number of bits in each table element (0 = 8, 1 = 16)
- -->
+ <!-- The number of bits in each table element (0 = 8, 1 = 16)
+ -->
<!-- Data type: Integer -->
<!ATTLIST "dqtable" "qtableId" ("0" | "1" | "2" | "3") #REQUIRED>
<!ELEMENT "dht" (dhtable)*>
- <!-- A Define Huffman Table(s) marker segment -->
+ <!-- A Define Huffman Table(s) marker segment -->
<!-- Min children: 1 -->
<!-- Max children: 4 -->
<!ELEMENT "dhtable" EMPTY>
- <!-- A single Huffman table -->
+ <!-- A single Huffman table -->
<!-- User object: javax.imageio.plugins.jpeg.JPEGHuffmanTable -->
<!ATTLIST "dhtable" "class" ("0" | "1") #REQUIRED>
- <!-- Indicates whether this is a DC (0) or an AC (1) table -->
+ <!-- Indicates whether this is a DC (0) or an AC (1) table -->
<!ATTLIST "dhtable" "htableId" ("0" | "1" | "2" | "3") #REQUIRED>
- <!-- The table id -->
+ <!-- The table id -->
<!ELEMENT "dri" EMPTY>
- <!-- A Define Restart Interval marker segment -->
+ <!-- A Define Restart Interval marker segment -->
<!ATTLIST "dri" "interval" #CDATA #REQUIRED>
- <!-- The restart interval in MCUs -->
+ <!-- The restart interval in MCUs -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ELEMENT "com" EMPTY>
- <!-- A Comment marker segment. The user object contains the actual
- bytes. -->
+ <!-- A Comment marker segment. The user object contains the actual
+ bytes. -->
<!-- User object: array of [B -->
<!-- Min length: 1 -->
<!-- Max length: 65533 -->
<!ATTLIST "com" "comment" #CDATA #IMPLIED>
- <!-- The comment as a string (used only if user object is null)
- -->
+ <!-- The comment as a string (used only if user object is null)
+ -->
<!-- Data type: String -->
<!ELEMENT "unknown" EMPTY>
- <!-- An unrecognized marker segment. The user object contains the
- data not including length. -->
+ <!-- An unrecognized marker segment. The user object contains the
+ data not including length. -->
<!-- User object: array of [B -->
<!-- Min length: 1 -->
<!-- Max length: 65533 -->
<!ATTLIST "unknown" "MarkerTag" #CDATA #REQUIRED>
- <!-- The tag identifying this marker segment -->
+ <!-- The tag identifying this marker segment -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ELEMENT "app14Adobe" EMPTY>
- <!-- An Adobe APP14 marker segment -->
+ <!-- An Adobe APP14 marker segment -->
<!ATTLIST "app14Adobe" "version" #CDATA "100">
- <!-- The version of Adobe APP14 marker segment -->
+ <!-- The version of Adobe APP14 marker segment -->
<!-- Data type: Integer -->
<!-- Min value: 100 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "app14Adobe" "flags0" #CDATA "0">
- <!-- The flags0 variable of an APP14 marker segment -->
+ <!-- The flags0 variable of an APP14 marker segment -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "app14Adobe" "flags1" #CDATA "0">
- <!-- The flags1 variable of an APP14 marker segment -->
+ <!-- The flags1 variable of an APP14 marker segment -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "app14Adobe" "transform" ("0" | "1" | "2") #REQUIRED>
- <!-- The color transform applied to the image (0 = Unknown, 1 =
- YCbCr, 2 = YCCK) -->
+ <!-- The color transform applied to the image (0 = Unknown, 1 =
+ YCbCr, 2 = YCCK) -->
<!ELEMENT "sof" (componentSpec)*>
- <!-- A Start Of Frame marker segment -->
+ <!-- A Start Of Frame marker segment -->
<!-- Min children: 1 -->
<!-- Max children: 4 -->
<!ATTLIST "sof" "process" ("0" | "1" | "2") #IMPLIED>
- <!-- The JPEG process (0 = Baseline sequential, 1 = Extended
- sequential, 2 = Progressive) -->
+ <!-- The JPEG process (0 = Baseline sequential, 1 = Extended
+ sequential, 2 = Progressive) -->
<!ATTLIST "sof" "samplePrecision" #CDATA "8">
- <!-- The number of bits per sample -->
+ <!-- The number of bits per sample -->
<!-- Data type: Integer -->
<!ATTLIST "sof" "numLines" #CDATA #IMPLIED>
- <!-- The number of lines in the image -->
+ <!-- The number of lines in the image -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "sof" "samplesPerLine" #CDATA #IMPLIED>
- <!-- The number of samples per line -->
+ <!-- The number of samples per line -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 65535 (inclusive) -->
<!ATTLIST "sof" "numFrameComponents" ("1" | "2" | "3" | "4")
#IMPLIED>
- <!-- The number of components in the image -->
+ <!-- The number of components in the image -->
<!ELEMENT "componentSpec" EMPTY>
- <!-- A component specification for a frame -->
+ <!-- A component specification for a frame -->
<!ATTLIST "componentSpec" "componentId" #CDATA #REQUIRED>
- <!-- The id for this component -->
+ <!-- The id for this component -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "componentSpec" "HsamplingFactor" #CDATA #REQUIRED>
- <!-- The horizontal sampling factor for this component -->
+ <!-- The horizontal sampling factor for this component -->
<!-- Data type: Integer -->
<!-- Min value: 1 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
<!ATTLIST "componentSpec" "VsamplingFactor" #CDATA #REQUIRED>
- <!-- The vertical sampling factor for this component -->
+ <!-- The vertical sampling factor for this component -->
<!-- Data type: Integer -->
<!-- Min value: 1 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
- <!ATTLIST "componentSpec" "QtableSelector" ("0" | "1" | "2" |
+ <!ATTLIST "componentSpec" "QtableSelector" ("0" | "1" | "2" |
"3") #REQUIRED>
- <!-- The quantization table to use for this component -->
+ <!-- The quantization table to use for this component -->
<!ELEMENT "sos" (scanComponentSpec)*>
- <!-- A Start Of Scan marker segment -->
+ <!-- A Start Of Scan marker segment -->
<!-- Min children: 1 -->
<!-- Max children: 4 -->
<!ATTLIST "sos" "numScanComponents" ("1" | "2" | "3" | "4")
#REQUIRED>
- <!-- The number of components in the scan -->
+ <!-- The number of components in the scan -->
<!ATTLIST "sos" "startSpectralSelection" #CDATA "0">
- <!-- The first spectral band included in this scan -->
+ <!-- The first spectral band included in this scan -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 63 (inclusive) -->
<!ATTLIST "sos" "endSpectralSelection" #CDATA "63">
- <!-- The last spectral band included in this scan -->
+ <!-- The last spectral band included in this scan -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 63 (inclusive) -->
<!ATTLIST "sos" "approxHigh" #CDATA "0">
- <!-- The highest bit position included in this scan -->
+ <!-- The highest bit position included in this scan -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 15 (inclusive) -->
<!ATTLIST "sos" "approxLow" #CDATA "0">
- <!-- The lowest bit position included in this scan -->
+ <!-- The lowest bit position included in this scan -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 15 (inclusive) -->
<!ELEMENT "scanComponentSpec" EMPTY>
- <!-- A component specification for a scan -->
+ <!-- A component specification for a scan -->
<!ATTLIST "scanComponentSpec" "componentSelector" #CDATA
#REQUIRED>
- <!-- The id of this component -->
+ <!-- The id of this component -->
<!-- Data type: Integer -->
<!-- Min value: 0 (inclusive) -->
<!-- Max value: 255 (inclusive) -->
- <!ATTLIST "scanComponentSpec" "dcHuffTable" ("0" | "1" | "2" |
+ <!ATTLIST "scanComponentSpec" "dcHuffTable" ("0" | "1" | "2" |
"3") #REQUIRED>
- <!-- The huffman table to use for encoding DC coefficients -->
- <!ATTLIST "scanComponentSpec" "acHuffTable" ("0" | "1" | "2" |
+ <!-- The huffman table to use for encoding DC coefficients -->
+ <!ATTLIST "scanComponentSpec" "acHuffTable" ("0" | "1" | "2" |
"3") #REQUIRED>
- <!-- The huffman table to use for encoding AC coefficients -->
+ <!-- The huffman table to use for encoding AC coefficients -->
]>
</pre>
<h2>
-<a name=stream>Stream Metadata DTD</a>
+<a id=stream>Stream Metadata DTD</a>
</h2>
<pre>
<!DOCTYPE "javax_imageio_jpeg_stream_1.0" [
<!ELEMENT "javax_imageio_jpeg_stream_1.0" (dqt |
- dht |
- dri |
- com |
+ dht |
+ dri |
+ com |
unknown)*>
-
+
<!-- All elements are as defined above for image metadata -->
]>
</pre>