JPEG Metadata
Abbreviated Streams
Sources of Tables
Colorspace Transformations and Conventional Markers
Thumbnail Images
Progressive Encoding
Native Metadata Format Tree Structure and Editing
Image Metadata DTD
Stream Metadata DTD
NOTE: It is important to call dispose() 
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 dispose() 
in their finalizers, but those finalizers may not be called before the native 
code has exhausted native memory.
The JPEG writer does not support replacing pixels.
SOI marker and 
the EOI marker for that image.  The image metadata object 
passed into a write determines the contents of the stream between the 
SOI marker and the EOI marker for that image, 
subject to the controls in any ImageWriteParam.
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 SOI marker and 
the EOI 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 getStreamMetadata 
method of ImageReader returns null.  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 
ImageWriter.prepareWriteSequence method.  It is ignored on all 
other methods.
 
The ImageWriter.getDefaultStreamMetadata method returns an 
object containing the tables from the ImageWriteParam argument, 
if it is a JPEGImageWriteParam and contains tables.  Otherwise, 
the returned object will contain default tables.
The ImageWriter.getDefaultImageMetadata method returns a 
metadata object containing no tables if the 
ImageWriteParam argument contains tables.  Otherwise the 
returned metadata object will contain default visually lossless tables.  
Of course, only a JPEGImageWriteParam may contain tables.
If ignoreMetadata is set to true when the input
is set on the reader, stream metadata will not be available, but image
metadata will.
IllegalArgumentException is thrown.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 a sequence of images. The tables will be used automatically, and will remain available as "stream" metadata.
Abbreviated streams are written using the sequence methods of 
ImageWriter.  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
ImageWriter.prepareWriteSequence.  If no stream metadata is 
supplied to ImageWriter.prepareWriteSequence, then no 
tables-only image is written.  If stream metadata containing no tables is
supplied to ImageWriter.prepareWriteSequence, then a tables-only
image containing default visually lossless tables is written.
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:
ImageWriteParam and the compression mode is
       set to EXPLICIT, 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 
       tables in the metadata.ImageWriteParam and the compression mode is
       set to DEFAULT, default visually lossles tables 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.ImageWriteParam must
       be MODE_COPY_FROM_METADATA, in which case the following
       are used:
    JPEGImageWriteParam, if presentJPEGImageWriteParams 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 
compression.
When reading, tables in a JPEGImageReadParam are consulted only 
if tables have not been set by any previous read.  Tables set from a 
JPEGImageReadParam are overridden by any tables present in the 
stream being read.
Note that if no image metadata object is specified for a particular image, a default object is used, which includes default tables.
Rasters 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 Rasters 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 
to any listeners.
Optional ColorSpace support: 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 behaviors are optional. If the support is not available when decoding, the color space will be treated as unrecognized and the appropriate default color space for the specified number of component channels may be used. 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.
When reading, the contents of the stream are interpreted by the usual JPEG conventions, as follows:
APP0 marker segment is present, the colorspace
       is known to be either grayscale or YCbCr.  If an APP2
       marker segment containing an embedded ICC profile is also present, then
       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.
  APP14 marker segment is present, the 
       colorspace is determined by consulting the transform flag.
       The transform flag takes one of three values:
    
       
RGB
       
RGBA
       
YCC (as 'Y','C','c'), assumed to be PhotoYCC
       
YCCA (as 'Y','C','c','A'), assumed to be PhotoYCCA
       
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.
BufferedImage.  Such an image may be read only as a 
       Raster.  If an image is interpretable but there is no Java
       ColorSpace available corresponding to the encoded 
       colorspace (e.g. YCbCr), then 
       ImageReader.getRawImageType will return null.
ColorSpace or a custom RGB ColorSpace object
       based on an embedded ICC profile is used to create the output
       ColorModel.  PhotoYCC and PhotoYCCA images are not
       converted.  CMYK and YCCK images are currently not supported.BufferedImage 
       (e.g. CMYK).  Such images may be read as
       Rasters.  If an image colorspace is unsupported or
       uninterpretable, then ImageReader.getImageTypes will
       return an empty Iterator.   If a subset of the raw bands
       are required, a Raster must be obtained first and the
       bands obtained from that. For writing, the color transformation to apply is determined as follows:
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 
Rasters.  If all the bands are to be written and an image 
(as opposed to a Raster) is being written, any destination type 
is ignored and a warning is sent to any listeners.
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 app0JFIF and 
app14Adobe nodes.  The component ids in the sof and 
sos nodes are not modified, however, as unless a 
app0JFIF node is present, any values may be used.
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:
If no metadata object is specified, then the following defaults apply:
APP0 marker
       segment.  Grayscale images with alpha are written with no special
       marker.  As required by JFIF, the component ids in the frame and
       scan header is set to 1.
  APP0 marker segment.  If the ColorSpace
       of the image is based on an ICCProfile (it is an instance
       of ICC_ColorSpace, but is not one of the standard built-in 
       ColorSpaces), then that profile is embedded in an 
       APP2 marker segment.  As required by JFIF, the 
       component ids in the frame and scan headers are set to 1, 2, and 3.
  APP14 marker segment and 'Y','C', and 'c' (and
       'A' if an alpha channel is present) as component ids in the frame
        and scan headers.
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.  app0JFIF and 
app14Adobe nodes may appear in the same metadata object only 
if the app14Adobe node indicates YCbCr, and the component ids 
are JFIF compatible (0-2).  The various image types are processed in the 
following ways:
(All multi-channel images are subsampled according to the sampling factors 
in the frame header node of the metadata object, regardless of color space.)
app0JFIF node is present in the metadata object,
           a JFIF APP0 marker segment is written.
      app14Adobe node is present in the metadata 
           object, it is checked for validity (transform must be
           UNKNOWN) and written.
      app0JFIF node is present in the metadata object,
           it is ignored and a warning is sent to listeners, as JFIF does not
           support 2-channel images.
      app14Adobe node is present in the metadata
           object, it is checked for validity (transform must be
           UNKNOWN) and written.  If transform is
           not UNKNOWN, a warning is sent to listeners and the
           correct transform is written.
      app0JFIF node is present in the metadata object,
           the image is converted to YCbCr and written with a JFIF 
           APP0 marker segment.  If the ColorSpace
           of the image is based on a non-standard ICC Profile, then that
           profile is embedded in an APP2 marker segment.  If the
           ColorSpace is not based on a non-standard ICC Profile,
           but an app2ICC node appears in the metadata, then an
           APP2 marker segment is written with the appropriate
           standard profile.  Note that the profile must specify an RGB color
           space, as the file must be JFIF compliant.
      app14Adobe node is present in the metadata
           object, the image is converted according to the color transform
           setting and written with an Adobe APP14 marker
           segment.  Component ids are written just as they appear in the
           frame and scan headers.  The color transform must be either YCbCr
           or UNKNOWN.  If it is UNKNOWN, the image
           is not color converted.
      app0JFIF node is present in the metadata object,
           it is ignored and a warning is sent to listeners, as JFIF does not
           support 4-channel images.
      app14Adobe node is present in the metadata
           object, the image is written with an Adobe APP14 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 UNKNOWN.  If it is 
           not, a warning is sent to listeners.
      app14Adobe 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.  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 YCbCrA.  If the image is not to be
           subsampled, then no conversion is applied.  No special marker
           segments are written.
    app0JFIF node is present in the metadata object,
           the image is converted to sRGB, and then to YCbCr during encoding,
           and a JFIF APP0 marker segment is written.
      app14Adobe node is present in the metadata
           object, no conversion is applied, and an Adobe APP14
           marker segment is written.  The color transform must be YCC.  If it
           is not, a warning is sent to listeners.
      app0JFIF node is present in the metadata object,
           it is ignored and a warning is sent to listeners, as JFIF does not
           support 4-channel images.
      app14Adobe node is present in the metadata
           object, no conversion is applied, and an Adobe APP14
           marker segment is written.  The color transform must be
           UNKNOWN.  If it is not, a warning is sent to
           listeners.
      app0JFIF and app0JFXX 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.
app0JFXX node is present in the metadata, or
               the first app0JFXX node present in the metadata
               contains a JFIFthumbPalette element, a
               palette thumbnail is written in a JFXX APP0 marker
               segment.
          app0JFXX 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.  
        app0JFXX node is present in the metadata,
               the thumbnail is written as part of the JFIF APP0
               marker segment. 
          app0JFXX node present in the metadata
               contains a JFIFthumbRGB element, an
               RGB thumbnail is written in a JFXX APP0 marker
               segment.
          app0JFXX node present in the metadata
               contains a JFIFthumbJPEG element, a
               JPEG thumbnail is written in a JFXX APP0 marker
               segment.
          app0JFXX node present in the metadata
               contains a JFIFthumbPalette element, an
               RGB thumbnail is written in a JFXX APP0 marker
               segment and a warning is sent to any listeners.
        app0JFXX node is present in the metadata,
               the thumbnail is expanded to RGB and written as part of the
               JFIF APP0 marker segment. 
          app0JFXX node present in the metadata
               contains a JFIFthumbRGB element, the thumbnail is
               expanded to RGB and written in a separate JFXX RGB
               marker segment.
          app0JFXX node present in the metadata
               contains a JFIFthumbJPEG element, a
               JPEG thumbnail is written in a JFXX APP0 marker
               segment.
          app0JFXX node present in the metadata
               contains a JFIFthumbPalette element, a
               JPEG thumbnail is written in a JFXX APP0 marker
               segment and a warning is sent to any listeners.
        APP0 segment, and
       the app0JFXX node consulted for each thumbnail is the
       app0JFXX node from the metadata that occurs in the same
       sequence as the thumbnail.  I.e. the first
       app0JFXX node applies to the first thumbnail, the second
       node to the second thumbnail, and so on.  If there are fewer
       app0JFXX nodes in the metadata than thumbnails, then 
       those thumbnails are considered to have no matching
       app0JFXX node.  An RGB thumbnail with no matching
       app0JFXX node is written in a JFXX APP0 marker
       segment.  A grayscale thumbnail with no matching
       app0JFXX node is written as a JPEG image to a JFXX 
       APP0 marker segment.
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 of image, the thumbnails are ignored and a warning is sent to any warning listeners.
ImageWriteParam
passed in to a write operation, or the image will be written sequentially,
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 
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 ImageWriteParam,
all Huffman tables in the metadata or in the ImageWriteParam 
itself are ignored, and a warning will be sent to any warning listeners if 
any such tables are present.
IIOMetadata object.  They do not include nodes 
corresponding to SOI, EOI, or RST 
markers, as these parsing delimiters do not carry any meaningful metadata.  
The first node is always a JPEGvariety node.  In the
javax_imageio_jpeg_image_1.0 version of the JPEG metadata
format, this node may have one child, an app0JFIF node,
indicating that the JPEG stream contains a JFIF marker segment and related
data, or no children, indicating that the stream contains no JFIF marker.
In future versions of the JPEG metadata format, other varieties of JPEG
metadata may be supported (e.g. Exif) by defining other types of nodes
which may appear as a child of the JPEGvariety node.
(Note that an application wishing to interpret Exif metadata given
a metadata tree structure in the javax_imageio_jpeg_image_1.0
format must check for an unknown marker segment with a tag
indicating an APP1 marker and containing data identifying it
as an Exif marker segment.  Then it may use application-specific code to
interpret the data in the marker segment.  If such an application were
to encounter a metadata tree formatted according to a future version of
the JPEG metadata format, the Exif marker segment might not be
unknown in that format - it might be structured as a
child node of the JPEGvariety node.  Thus, it is important
for an application to specify which version to use by passing the string
identifying the version to the method/constructor used to obtain an
IIOMetadata object.)
On reading, JFXX and app2ICC nodes occur as 
children of an app0JFIF node.
This is true regardless of where the JFXX APP0 and 
APP2 marker segments actually occur in the stream.  The ordering 
of nodes within the markerSequence node corresponds to the 
ordering of marker segments found in the JPEG stream.
On writing, any JFXX and app2ICC nodes must 
occur as children of an app0JFIF node, itself a child of a 
JPEGvariety node, which must always be the first node.
(If the stream is not to be JFIF compliant, no app0JFIF node
should be provided, and the JPEGvariety node should have no
children.)  Any 
JFIF APP0, JFXX APP0, and APP2 marker 
segments are written first, followed by all Adobe APP14, 
APPn, COM and unknown segments in the 
order in which their corresponding nodes appear in the 
markerSequence node, followed by DQT (and 
DHT for non-progressive writes) marker segments, followed by the 
SOF and SOS marker segments.  For progressive writes
using metadata to control progression, the SOS segments are used 
in the order in which their corresponding nodes occur in the 
markerSequence node.
The reset, mergeTree and setFromTree 
operations have the following semantics for the JPEG plug-in metadata object:
 reset - A call to reset 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 ImageWriter.  This is true regardless of how many times the 
metadata object has been modified since creation.
 mergeTree - Native Format
 The mergeTree 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 
mergeTree.  To remove nodes, use setFromTree.  The 
tree must consist of IIOMetadataNodes.
app0JFIF
        app0JFIF node already exists, the contents 
               of the new one modify the existing one. 
          dqt
        dqt nodes in the sequence,
               then each table in the node replaces the first table, in any
               dqt node, with the same table id.  
          dqt nodes contain a table
               with the same id, then the table is added to the last existing
               dqt node.
          dqt nodes, then a new one is
               created and added as follows:
            dht nodes, the new
                   dqt node is inserted before the first one.  
              dht nodes, the new
                   dqt node is inserted  before an
                   sof node, if there is one. 
              sof node, the new
                   dqt node is inserted before the first
                   sos node, if there is one.
              sos node, the new
                   dqt node is added to the end of the sequence.
            dht
        dht nodes in the sequence,
               then each table in the node replaces the first table, in any
               dht node, with the same table class and table id.
          dht nodes contain a table
               with the same class and id, then the table is added to the last
               existing dht node.
          dht nodes, then a new one is
               created and added as follows:
            dqt nodes, the new
                   dht node is inserted immediately following the
                   last dqt node.
              dqt nodes, the new
                   dht node is inserted before an
                   sof node, if there is one. 
              sof node, the new
                   dht node is inserted before the first
                   sos node, if there is one.
              sos node, the new
                   dht node is added to the end of the sequence.
            dri
        dri node, the restart 
               interval value is updated.
          dri node, then a new one is created
               and added as follows:
            sof node, the new
                   dri node is inserted before it.
              sof node, the new
                   dri node is inserted before the first
                   sos node, if there is one.
              sos node, the new
                   dri node is added to the end of the sequence.
            com
        com node is created and inserted as follows:
        com nodes, the new one is
               inserted after the last one.
          com nodes, the new
               com node is inserted after the
               app14Adobe node, if there is one.
          app14Adobe node, the new
               com node is inserted at the beginning of the
               sequence.
        app14Adobe
        app14Adobe node, then 
               its attributes are updated from the node.
          app14Adobe node, then a new one is 
               created and  added as follows:
            app14Adobe node is inserted after the
                   last unknown node, if there are any.
              unknown nodes, the new
                   app14Adobe node is inserted at the beginning
                   of the sequence.
            unknown
       unknown node is created and added to the
            sequence as follows:
        unknown marker nodes, the
               new one is inserted after the last one.
          unknown nodes, the new
               unknown node is inserted before the
               app14Adobe node, if there is one.
          app14Adobe node, the new
               unknown node is inserted at the beginning of the
               sequence.
        sof
        sof node in the
               sequence, then its values are updated from the node.
          sof node, then a new one is created
               and added as follows:
            sos nodes, the new
                   sof node is inserted before the first one.
              sos node, the new
                   sof node is added to the end of the sequence.
            sos
        sos node, then
               the values are updated from the node.
          sos nodes,
               then an IIOInvalidTreeException is thrown, as
               sos nodes cannot be merged into a set of
               progressive scans.
          sos nodes, a new one is created
               and added to the end of the sequence.
         mergeTree - Standard Format
The mergeTree operation, when given a tree in the standard 
format, will modify the native tree in the following ways:
Chroma - The ColorSpaceType subnode of a
        Chroma 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: 
        app0JFIF and app14Adobe nodes may be added
        or removed, subsampling may be added or removed, component ids may
        be changed, and sof and sos nodes will be
        updated accordingly.  If necessary, additional quantization and
        huffman tables are added.  In the case of quantization tables, the
        default will be scaled to match the quality level of any existing
        tables.  No tables are added to metadata that does not already contain
        tables.  If the existing metadata specifies progressive encoding, then
        the number of channels must not change.  Any Transparency
        node is also taken into account, as an explicit value of
        none for the Alpha subnode can cause the
        removal of an alpha channel, and anything other than none
        can cause the addition of an alpha channel.
   Dimension - A PixelAspectRatio specification
        can cause the contents of an app0JFIF node to change, if
        there is one present, or the addition of an app0JFIF node
        containing appropriate values, if there can be one.  An appropriate
        pair of integers is computed from the floating-point ratio for
        inclusion in the node.
   Text - Each uncompressed text item is converted to a
        com node and inserted according to the rules above for
        merging com nodes.
 setFromTree - Native Format
The setFromTree 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 IIOMetadataNodes.
 setFromTree - Standard Format
The setFromTree operation, when given a tree in the standard 
format, performs a reset followed by a merge of the new tree.
<!DOCTYPE "javax_imageio_jpeg_image_1.0" [
  <!ELEMENT "javax_imageio_jpeg_image_1.0" (JPEGvariety, markerSequence)>
    <!ELEMENT "JPEGvariety" (app0JFIF)>
      <!-- A node grouping all marker segments specific to the variety of
              stream being read/written (e.g. JFIF) - may be empty --> 
      <!ELEMENT "app0JFIF" (JFXX?, app2ICC?)>
        <!ATTLIST "app0JFIF" "majorVersion" #CDATA "1">
          <!-- 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 --> 
          <!-- 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) --> 
        <!ATTLIST "app0JFIF" "Xdensity" #CDATA "1">
          <!-- 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 --> 
          <!-- 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 --> 
          <!-- 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 --> 
          <!-- Data type: Integer -->
          <!-- Min value: 0 (inclusive) -->
          <!-- Max value: 255 (inclusive) -->
        <!ELEMENT "JFXX" (app0JFXX)*>
          <!-- Min children: 1 -->
        <!ELEMENT "app0JFXX" (JFIFthumbJPEG | JFIFthumbPalette | 
          JFIFthumbRGB)>
          <!-- 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 --> 
          <!ELEMENT "JFIFthumbJPEG" (markerSequence?)>
            <!-- A JFIF thumbnail in JPEG format (no JFIF segments 
                 permitted) --> 
          <!ELEMENT "JFIFthumbPalette" EMPTY>
            <!-- A JFIF thumbnail as an RGB indexed image --> 
            <!ATTLIST "JFIFthumbPalette" "thumbWidth" #CDATA #IMPLIED>
              <!-- 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 --> 
              <!-- Data type: Integer -->
              <!-- Min value: 0 (inclusive) -->
              <!-- Max value: 255 (inclusive) -->
          <!ELEMENT "JFIFthumbRGB" EMPTY>
            <!-- A JFIF thumbnail as an RGB image --> 
            <!ATTLIST "JFIFthumbRGB" "thumbWidth" #CDATA #IMPLIED>
              <!-- 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 --> 
              <!-- Data type: Integer -->
              <!-- Min value: 0 (inclusive) -->
              <!-- Max value: 255 (inclusive) -->
        <!ELEMENT "app2ICC" EMPTY>
          <!-- An ICC profile APP2 marker segment --> 
          <!-- Optional User object: java.awt.color.ICC_Profile -->
    <!ELEMENT "markerSequence" (dqt | dht | dri | com | unknown | 
      app14Adobe | sof | sos)*>
      <!-- A node grouping all non-jfif marker segments --> 
      <!ELEMENT "dqt" (dqtable)*>
        <!-- A Define Quantization Table(s) marker segment --> 
        <!-- Min children: 1 -->
        <!-- Max children: 4 -->
        <!ELEMENT "dqtable" EMPTY>
          <!-- 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) 
                 --> 
            <!-- Data type: Integer -->
          <!ATTLIST "dqtable" "qtableId" ("0" | "1" | "2" | "3") #REQUIRED>
      <!ELEMENT "dht" (dhtable)*>
        <!-- A Define Huffman Table(s) marker segment --> 
        <!-- Min children: 1 -->
        <!-- Max children: 4 -->
        <!ELEMENT "dhtable" EMPTY>
          <!-- 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 --> 
          <!ATTLIST "dhtable" "htableId" ("0" | "1" | "2" | "3") #REQUIRED>
            <!-- The table id --> 
      <!ELEMENT "dri" EMPTY>
        <!-- A Define Restart Interval marker segment --> 
        <!ATTLIST "dri" "interval" #CDATA #REQUIRED>
          <!-- 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. --> 
        <!-- 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) 
               --> 
          <!-- Data type: String -->
      <!ELEMENT "unknown" EMPTY>
        <!-- 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 --> 
          <!-- Data type: Integer -->
          <!-- Min value: 0 (inclusive) -->
          <!-- Max value: 255 (inclusive) -->
      <!ELEMENT "app14Adobe" EMPTY>
        <!-- An Adobe APP14 marker segment --> 
        <!ATTLIST "app14Adobe" "version" #CDATA "100">
          <!-- 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 --> 
          <!-- Data type: Integer -->
          <!-- Min value: 0 (inclusive) -->
          <!-- Max value: 65535 (inclusive) -->
        <!ATTLIST "app14Adobe" "flags1" #CDATA "0">
          <!-- 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) --> 
      <!ELEMENT "sof" (componentSpec)*>
        <!-- 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) --> 
        <!ATTLIST "sof" "samplePrecision" #CDATA "8">
          <!-- The number of bits per sample --> 
          <!-- Data type: Integer -->
        <!ATTLIST "sof" "numLines" #CDATA #IMPLIED>
          <!-- 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 --> 
          <!-- 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 --> 
        <!ELEMENT "componentSpec" EMPTY>
          <!-- A component specification for a frame --> 
          <!ATTLIST "componentSpec" "componentId" #CDATA #REQUIRED>
            <!-- 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 --> 
            <!-- Data type: Integer -->
            <!-- Min value: 1 (inclusive) -->
            <!-- Max value: 255 (inclusive) -->
          <!ATTLIST "componentSpec" "VsamplingFactor" #CDATA #REQUIRED>
            <!-- The vertical sampling factor for this component --> 
            <!-- Data type: Integer -->
            <!-- Min value: 1 (inclusive) -->
            <!-- Max value: 255 (inclusive) -->
          <!ATTLIST "componentSpec" "QtableSelector" ("0" | "1" | "2" | 
            "3") #REQUIRED>
            <!-- The quantization table to use for this component --> 
      <!ELEMENT "sos" (scanComponentSpec)*>
        <!-- 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 --> 
        <!ATTLIST "sos" "startSpectralSelection" #CDATA "0">
          <!-- 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 --> 
          <!-- Data type: Integer -->
          <!-- Min value: 0 (inclusive) -->
          <!-- Max value: 63 (inclusive) -->
        <!ATTLIST "sos" "approxHigh" #CDATA "0">
          <!-- 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 --> 
          <!-- Data type: Integer -->
          <!-- Min value: 0 (inclusive) -->
          <!-- Max value: 15 (inclusive) -->
        <!ELEMENT "scanComponentSpec" EMPTY>
          <!-- A component specification for a scan --> 
          <!ATTLIST "scanComponentSpec" "componentSelector" #CDATA
             #REQUIRED>
            <!-- The id of this component --> 
            <!-- Data type: Integer -->
            <!-- Min value: 0 (inclusive) -->
            <!-- Max value: 255 (inclusive) -->
          <!ATTLIST "scanComponentSpec" "dcHuffTable" ("0" | "1" | "2" | 
            "3") #REQUIRED>
            <!-- 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 --> 
]>
<!DOCTYPE "javax_imageio_jpeg_stream_1.0" [
  <!ELEMENT "javax_imageio_jpeg_stream_1.0" (dqt |
                      dht | 
                      dri | 
                      com | 
                      unknown)*>
   
  <!-- All elements are as defined above for image metadata -->
]>