|
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
|
2 <html> |
|
3 <head> |
|
4 <!-- |
|
5 Copyright 2000-2001 Sun Microsystems, Inc. All Rights Reserved. |
|
6 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
|
7 |
|
8 This code is free software; you can redistribute it and/or modify it |
|
9 under the terms of the GNU General Public License version 2 only, as |
|
10 published by the Free Software Foundation. Sun designates this |
|
11 particular file as subject to the "Classpath" exception as provided |
|
12 by Sun in the LICENSE file that accompanied this code. |
|
13 |
|
14 This code is distributed in the hope that it will be useful, but WITHOUT |
|
15 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
|
16 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
|
17 version 2 for more details (a copy is included in the LICENSE file that |
|
18 accompanied this code). |
|
19 |
|
20 You should have received a copy of the GNU General Public License version |
|
21 2 along with this work; if not, write to the Free Software Foundation, |
|
22 Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
|
23 |
|
24 Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, |
|
25 CA 95054 USA or visit www.sun.com if you need additional information or |
|
26 have any questions. |
|
27 --> |
|
28 |
|
29 <title>JPEG Metadata Format Specification and Usage Notes</title> |
|
30 </head> |
|
31 |
|
32 <body bgcolor="white"> |
|
33 |
|
34 <center><h1> |
|
35 JPEG Metadata Format Specification and Usage Notes |
|
36 </h1></center> |
|
37 |
|
38 <p> |
|
39 <a href=#metadata>JPEG Metadata</a><br> |
|
40 <a href=#abbrev>Abbreviated Streams</a><br> |
|
41 <a href=#tables>Sources of Tables</a><br> |
|
42 <a href=#color>Colorspace Transformations and Conventional Markers</a><br> |
|
43 <a href=#thumbs>Thumbnail Images</a><br> |
|
44 <a href=#prog>Progressive Encoding</a><br> |
|
45 <a href=#tree>Native Metadata Format Tree Structure and Editing</a><br> |
|
46 <a href=#image>Image Metadata DTD</a><br> |
|
47 <a href=#stream>Stream Metadata DTD</a> |
|
48 <p> |
|
49 <bold>NOTE</bold>: It is important to call <code>dispose()</code> |
|
50 on the JPEG reader and writer objects when they are no longer needed, as |
|
51 they consume significant native resources which are not adequately recovered |
|
52 by garbage collection. Both reader and writer call <code>dispose()</code> |
|
53 in their finalizers, but those finalizers may not be called before the native |
|
54 code has exhausted native memory. |
|
55 |
|
56 <p> |
|
57 |
|
58 The JPEG writer does not support replacing pixels. |
|
59 |
|
60 <p> |
|
61 <h2> |
|
62 <a name=metadata>JPEG Metadata</a> |
|
63 </h2> |
|
64 JPEG metadata consists of the data contained in marker segments in a JPEG |
|
65 stream. The image metadata object returned from a read describes the |
|
66 contents of the marker segments between the <code>SOI</code> marker and |
|
67 the <code>EOI</code> marker for that image. The image metadata object |
|
68 passed into a write determines the contents of the stream between the |
|
69 <code>SOI</code> marker and the <code>EOI</code> marker for that image, |
|
70 subject to the controls in any <code>ImageWriteParam</code>. |
|
71 |
|
72 <p> |
|
73 Stream metadata is used only for tables-only images found (or to be |
|
74 placed) at the beginning of a stream containing abbreviated images. |
|
75 Tables-only images are not treated as images and do not consume an |
|
76 image index. The stream metadata object returned from a read describes the |
|
77 contents of the marker segments between the <code>SOI</code> marker and |
|
78 the <code>EOI</code> marker for the single tables-only image at the |
|
79 beginning of the stream, if one is present. If no tables-only image is |
|
80 present at the front of the stream, the <code>getStreamMetadata</code> |
|
81 method of <code>ImageReader</code> returns <code>null</code>. If |
|
82 stream metadata is provided to the writer, a single tables-only image |
|
83 containing the tables from the stream metadata object will be written at |
|
84 the beginning of the stream. If the stream metadata object contains no |
|
85 tables, default tables will be written. As the sole purpose of stream |
|
86 metadata is for specifying tables-only images at the front of abbreviated |
|
87 streams, the stream metadata argument is useful only on the |
|
88 <code>ImageWriter.prepareWriteSequence</code> method. It is ignored on all |
|
89 other methods. |
|
90 |
|
91 <p> |
|
92 The <code>ImageWriter.getDefaultStreamMetadata</code> method returns an |
|
93 object containing the tables from the <code>ImageWriteParam</code> argument, |
|
94 if it is a <code>JPEGImageWriteParam</code> and contains tables. Otherwise, |
|
95 the returned object will contain default tables. |
|
96 |
|
97 <p>The <code>ImageWriter.getDefaultImageMetadata</code> method returns a |
|
98 metadata object containing <bold>no</bold> tables if the |
|
99 <code>ImageWriteParam</code> argument contains tables. Otherwise the |
|
100 returned metadata object will contain default visually lossless tables. |
|
101 Of course, only a <code>JPEGImageWriteParam</code> may contain tables. |
|
102 |
|
103 <p> |
|
104 If <code>ignoreMetadata</code> is set to <code>true</code> when the input |
|
105 is set on the reader, stream metadata will not be available, but image |
|
106 metadata will. |
|
107 |
|
108 <p> |
|
109 <h2> |
|
110 <a name=abbrev>Abbreviated Streams</a> |
|
111 </h2> |
|
112 Both the reader and the writer retain their tables from one operation to the |
|
113 next, thus permitting the use of abbreviated streams quite naturally, with a |
|
114 few minor restrictions: |
|
115 <ol> |
|
116 <li> Abbreviated streams may contain only one tables-only image, which must |
|
117 come first in the stream. Subsequent tables-only images will cause |
|
118 undefined behavior.</li> |
|
119 <li> Abbreviated streams must be read fully and in order. No random access |
|
120 is allowed, in either direction. The same image may be read multiple |
|
121 times. If a call is made with an image index that is not the same as |
|
122 or one greater than the most recent call (or 0 if no calls have been |
|
123 made), then an <code>IllegalArgumentException</code> is thrown.</li> |
|
124 </ol> |
|
125 These restrictions mean that streams may contain abbreviated images |
|
126 interspersed with images containing tables. As required by JPEG, any tables |
|
127 appearing in the stream override previous tables, regardless of the source |
|
128 of the previous tables. |
|
129 |
|
130 <p> |
|
131 Note that once a tables-only image has been read, it's contents is available |
|
132 as stream metadata from the reader until either another tables-only image |
|
133 is read from another stream or the reader is reset. Changing the input does |
|
134 not reset the stream metadata. This is useful for reading the tables from |
|
135 one file, then changing the input to read an abbreviated stream containing |
|
136 a sequence of images. The tables will be used automatically, and will remain |
|
137 available as "stream" metadata. |
|
138 |
|
139 <p> |
|
140 Abbreviated streams are written using the sequence methods of |
|
141 <code>ImageWriter</code>. Stream metadata is used to write a tables-only |
|
142 image at the beginning of the stream, and the tables are set up for use, using |
|
143 <code>ImageWriter.prepareWriteSequence</code>. If no stream metadata is |
|
144 supplied to <code>ImageWriter.prepareWriteSequence</code>, then no |
|
145 tables-only image is written. If stream metadata containing no tables is |
|
146 supplied to <code>ImageWriter.prepareWriteSequence</code>, then a tables-only |
|
147 image containing default visually lossless tables is written. |
|
148 |
|
149 <h2> |
|
150 <a name=tables>Sources of Tables</a> |
|
151 </h2> |
|
152 <p> |
|
153 Images are written with tables if tables are present in their metadata objects |
|
154 or without them if no tables are present in their metadata objects. If no |
|
155 metadata object is present then the tables are written. The tables used for |
|
156 compression are taken from one of the following sources, which are consulted |
|
157 in order: |
|
158 <ol> |
|
159 <li> If there is an <code>ImageWriteParam</code> and the compression mode is |
|
160 set to <code>EXPLICIT</code>, default tables constructed using the |
|
161 quality setting are used. They are written only if the metadata |
|
162 contains tables or if there is no metadata, but they replace the |
|
163 tables in the metadata.</li> |
|
164 <li> If there is an <code>ImageWriteParam</code> and the compression mode is |
|
165 set to <code>DEFAULT</code>, default visually lossles tables are used. |
|
166 They are written only if the metadata contains tables or if |
|
167 there is no metadata, but they replace the tables in the |
|
168 metadata.</li> |
|
169 <li> Otherwise the compression mode on the <code>ImageWriteParam</code> must |
|
170 be MODE_COPY_FROM_<code>METADATA</code>, in which case the following |
|
171 are used: |
|
172 <ol> |
|
173 <li> the tables in the image metadata, if present</li> |
|
174 <li> the tables in the stream metadata, if present</li> |
|
175 <li> the tables in the <code>JPEGImageWriteParam</code>, if present</li> |
|
176 <li> default visually lossless tables</li> |
|
177 </ol> Tables are written only if they are taken from image metadata. |
|
178 </li> |
|
179 </ol> |
|
180 |
|
181 This ordering implements the design intention that tables should be included |
|
182 in <code>JPEGImageWriteParam</code>s only as a means of specifying tables |
|
183 when no other source is available, and this can occur only when writing to an |
|
184 abbreviated stream without tables using known non-standard tables for |
|
185 compression. |
|
186 |
|
187 <p> |
|
188 When reading, tables in a <code>JPEGImageReadParam</code> are consulted only |
|
189 if tables have not been set by any previous read. Tables set from a |
|
190 <code>JPEGImageReadParam</code> are overridden by any tables present in the |
|
191 stream being read. |
|
192 |
|
193 <p> |
|
194 Note that if no image metadata object is specified for a particular image, a |
|
195 default object is used, which includes default tables. |
|
196 |
|
197 <p> |
|
198 <h2> |
|
199 <a name=color>Colorspace Transformations and Conventional Markers</a> |
|
200 </h2> |
|
201 Colorspace transformations are controlled by the destination type for |
|
202 both reading and writing of images. When <code>Raster</code>s are |
|
203 read, no colorspace transformation is performed, and any destination type |
|
204 is ignored. A warning is sent to any listeners if a destination type is |
|
205 specified in this case. When <code>Raster</code>s are written, any |
|
206 destination type is used to interpret the bands. This might result in a |
|
207 JFIF or Adobe header being written, or different component ids being written |
|
208 to the frame and scan headers. If values present in a metadata object do not |
|
209 match the destination type, the destination type is used and a warning is sent |
|
210 to any listeners. |
|
211 |
|
212 <p> |
|
213 |
|
214 When reading, the contents of the stream are interpreted by the usual |
|
215 JPEG conventions, as follows: |
|
216 |
|
217 <ul> |
|
218 <li> If a JFIF <code>APP0</code> marker segment is present, the colorspace |
|
219 is known to be either grayscale or YCbCr. If an <code>APP2</code> |
|
220 marker segment containing an embedded ICC profile is also present, then |
|
221 the YCbCr is converted to RGB according to the formulas given in the |
|
222 JFIF spec, and the ICC profile is assumed to refer to the resulting RGB |
|
223 space. |
|
224 <p> |
|
225 <li> If an Adobe <code>APP14</code> marker segment is present, the |
|
226 colorspace is determined by consulting the <code>transform</code> flag. |
|
227 The <code>transform</code> flag takes one of three values: |
|
228 <ul> |
|
229 <li> 2 - The image is encoded as YCCK (implicitly converted from |
|
230 CMYK on encoding). |
|
231 |
|
232 <li> 1 - The image is encoded as YCbCr (implicitly converted from RGB |
|
233 on encoding). |
|
234 |
|
235 <li> 0 - Unknown. 3-channel images are assumed to be RGB, 4-channel |
|
236 images are assumed to be CMYK. |
|
237 </ul> |
|
238 <p> |
|
239 <li> If neither marker segment is present, the following procedure is |
|
240 followed: Single-channel images are assumed to be grayscale, and |
|
241 2-channel images are assumed to be grayscale with an alpha channel. |
|
242 For 3- and 4-channel images, the component ids are consulted. If these |
|
243 values are 1-3 for a 3-channel image, then the image is assumed to be |
|
244 YCbCr. If these values are 1-4 for a 4-channel image, then the image |
|
245 is assumed to be YCbCrA. If these values are > 4, they are checked |
|
246 against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can |
|
247 encode the following colorspaces: |
|
248 <p> |
|
249 <br>RGB |
|
250 <br>RGBA |
|
251 <br>YCC (as 'Y','C','c'), assumed to be PhotoYCC |
|
252 <br>YCCA (as 'Y','C','c','A'), assumed to be PhotoYCCA |
|
253 <p> |
|
254 Otherwise, 3-channel subsampled images are assumed to be YCbCr, |
|
255 3-channel non-subsampled images are assumed to be RGB, 4-channel |
|
256 subsampled images are assumed to be YCCK, and 4-channel, non-subsampled |
|
257 images are assumed to be CMYK. |
|
258 |
|
259 <p> |
|
260 <li> All other images are declared uninterpretable and an exception is |
|
261 thrown if an attempt is made to read one as a |
|
262 <code>BufferedImage</code>. Such an image may be read only as a |
|
263 <code>Raster</code>. If an image is interpretable but there is no Java |
|
264 <code>ColorSpace</code> available corresponding to the encoded |
|
265 colorspace (<italic>e.g.</italic> YCbCr), then |
|
266 <code>ImageReader.getRawImageType</code> will return <code>null</code>. |
|
267 </ul> |
|
268 |
|
269 Once an encoded colorspace is determined, then the target colorspace is |
|
270 determined as follows: |
|
271 |
|
272 <ul> |
|
273 <li> If a destination type is not set, then the following default |
|
274 transformations take place after upsampling: YCbCr (and YCbCrA) images |
|
275 are converted to RGB (and RGBA) using the conversion provided by the |
|
276 underlying IJG library and either the built-in sRGB |
|
277 <code>ColorSpace</code> or a custom RGB <code>ColorSpace</code> object |
|
278 based on an embedded ICC profile is used to create the output |
|
279 <code>ColorModel</code>. PhotoYCC and PhotoYCCA images are not |
|
280 converted. CMYK and YCCK images are currently not supported.</li> |
|
281 |
|
282 <li> If a destination image or type is set, it is used as follows: |
|
283 If the IJG library provides an appropriate conversion, it is used. |
|
284 Otherwise the default library conversion is followed by a colorspace |
|
285 conversion in Java.</li> |
|
286 |
|
287 <li> Bands are selected AFTER any library colorspace conversion. If a |
|
288 subset of either source or destination bands is used, then the default |
|
289 library conversions are used with no further conversion in Java, |
|
290 regardless of any destination type.</li> |
|
291 |
|
292 <li> An exception is thrown if an attempt is made to read an image in an |
|
293 unsupported jpeg colorspace as a <code>BufferedImage</code> |
|
294 (<italic>e.g.</italic> CMYK). Such images may be read as |
|
295 <code>Raster</code>s. If an image colorspace is unsupported or |
|
296 uninterpretable, then <code>ImageReader.getImageTypes</code> will |
|
297 return an empty <code>Iterator</code>. If a subset of the raw bands |
|
298 are required, a <code>Raster</code> must be obtained first and the |
|
299 bands obtained from that. </li> |
|
300 </ul> |
|
301 |
|
302 <p> |
|
303 For writing, the color transformation to apply is determined as |
|
304 follows: |
|
305 |
|
306 <p> |
|
307 If a subset of the source bands is to be written, no color conversion is |
|
308 performed. Any destination, if set, must match the number of bands that will |
|
309 be written, and serves as an interpretation of the selected bands, rather than |
|
310 a conversion request. This behavior is identical to that for |
|
311 <code>Raster</code>s. If all the bands are to be written and an image |
|
312 (as opposed to a <code>Raster</code>) is being written, any destination type |
|
313 is ignored and a warning is sent to any listeners. |
|
314 |
|
315 <p> |
|
316 If a destination type is used and any aspect of the metadata object, if there |
|
317 is one, is not compatible with that type, the destination type is used, the |
|
318 metadata written is modified from that provided, and a warning is sent to |
|
319 listeners. This includes the <code>app0JFIF</code> and |
|
320 <code>app14Adobe</code> nodes. The component ids in the <code>sof</code> and |
|
321 <code>sos</code> nodes are not modified, however, as unless a |
|
322 <code>app0JFIF</code> node is present, any values may be used. |
|
323 <p> |
|
324 |
|
325 When a full image is written, a destination colorspace will be |
|
326 chosen based on the image contents and the metadata settings, according to |
|
327 the following algorithm: |
|
328 |
|
329 <p> |
|
330 |
|
331 If no metadata object is specified, then the following defaults apply: |
|
332 |
|
333 <ul> |
|
334 <li> Grayscale images are written with a JFIF <code>APP0</code> marker |
|
335 segment. Grayscale images with alpha are written with no special |
|
336 marker. As required by JFIF, the component ids in the frame and |
|
337 scan header is set to 1. |
|
338 |
|
339 <li> RGB images are converted to YCbCr, subsampled in the chrominance |
|
340 channels by half both vertically and horizontally, and written with a |
|
341 JFIF <code>APP0</code> marker segment. If the <code>ColorSpace</code> |
|
342 of the image is based on an <code>ICCProfile</code> (it is an instance |
|
343 of <code>ICC_ColorSpace</code>, but is not one of the standard built-in |
|
344 <code>ColorSpaces</code>), then that profile is embedded in an |
|
345 <code>APP2</code> marker segment. As required by JFIF, the |
|
346 component ids in the frame and scan headers are set to 1, 2, and 3. |
|
347 |
|
348 |
|
349 <li> RGBA images are converted to YCbCrA, subsampled in the |
|
350 chrominance channels by half both vertically and horizontally, and |
|
351 written without any special marker segments. The component ids |
|
352 in the frame and scan headers are set to 1, 2, 3, and 4. |
|
353 |
|
354 <li> PhotoYCC and YCCAimages are subsampled by half in the chrominance |
|
355 channels both vertically and horizontally and written with an |
|
356 Adobe <code>APP14</code> marker segment and 'Y','C', and 'c' (and |
|
357 'A' if an alpha channel is present) as component ids in the frame |
|
358 and scan headers. |
|
359 </ul> |
|
360 |
|
361 Default metadata objects for these image types will reflect these settings. |
|
362 |
|
363 <p> |
|
364 |
|
365 If a metadata object is specified, then the number of channels in the |
|
366 frame and scan headers must always match the number of bands to be |
|
367 written, or an exception is thrown. <code>app0JFIF</code> and |
|
368 <code>app14Adobe</code> nodes may appear in the same metadata object only |
|
369 if the <code>app14Adobe</code> node indicates YCbCr, and the component ids |
|
370 are JFIF compatible (0-2). The various image types are processed in the |
|
371 following ways: |
|
372 |
|
373 <br> |
|
374 |
|
375 (All multi-channel images are subsampled according to the sampling factors |
|
376 in the frame header node of the metadata object, regardless of color space.) |
|
377 |
|
378 <ul> |
|
379 <li> Grayscale Images: |
|
380 <ul> |
|
381 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
382 a JFIF <code>APP0</code> marker segment is written. |
|
383 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
384 object, it is checked for validity (<code>transform</code> must be |
|
385 <code>UNKNOWN</code>) and written. |
|
386 <li> If neither node is present in the metadata object, no special |
|
387 marker segment is written. |
|
388 </ul> |
|
389 |
|
390 <li> Grayscale Images with an Alpha Channel: |
|
391 <ul> |
|
392 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
393 it is ignored and a warning is sent to listeners, as JFIF does not |
|
394 support 2-channel images. |
|
395 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
396 object, it is checked for validity (<code>transform</code> must be |
|
397 <code>UNKNOWN</code>) and written. If <code>transform</code> is |
|
398 not <code>UNKNOWN</code>, a warning is sent to listeners and the |
|
399 correct transform is written. |
|
400 <li> If neither node is present in the metadata object, no special |
|
401 marker segment is written. |
|
402 </ul> |
|
403 |
|
404 <li> RGB Images: |
|
405 <ul> |
|
406 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
407 the image is converted to YCbCr and written with a JFIF |
|
408 <code>APP0</code> marker segment. If the <code>ColorSpace</code> |
|
409 of the image is based on a non-standard ICC Profile, then that |
|
410 profile is embedded in an <code>APP2</code> marker segment. If the |
|
411 <code>ColorSpace</code> is not based on a non-standard ICC Profile, |
|
412 but an <code>app2ICC</code> node appears in the metadata, then an |
|
413 <code>APP2</code> marker segment is written with the appropriate |
|
414 standard profile. Note that the profile must specify an RGB color |
|
415 space, as the file must be JFIF compliant. |
|
416 |
|
417 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
418 object, the image is converted according to the color transform |
|
419 setting and written with an Adobe <code>APP14</code> marker |
|
420 segment. Component ids are written just as they appear in the |
|
421 frame and scan headers. The color transform must be either YCbCr |
|
422 or <code>UNKNOWN</code>. If it is <code>UNKNOWN</code>, the image |
|
423 is not color converted. |
|
424 |
|
425 <li> If neither node is present, the component ids in the frame |
|
426 header are consulted. If these indicate a colorspace as described |
|
427 above, then the image is converted to that colorspace if possible. |
|
428 If the component ids do not indicate a colorspace, then the |
|
429 sampling factors are consulted. If the image is to be subsampled, |
|
430 it is converted to YCbCr first. If the image is not to be |
|
431 subsampled, then no conversion is applied. No special marker |
|
432 segmentss are written. |
|
433 </ul> |
|
434 |
|
435 <li> RGBA images: |
|
436 <ul> |
|
437 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
438 it is ignored and a warning is sent to listeners, as JFIF does not |
|
439 support 4-channel images. |
|
440 |
|
441 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
442 object, the image is written with an Adobe <code>APP14</code> marker |
|
443 segment. No colorspace conversion is performed. Component ids |
|
444 are written just as they appear in the frame and scan headers. |
|
445 The color transform must be <code>UNKNOWN</code>. If it is |
|
446 not, a warning is sent to listeners. |
|
447 |
|
448 <li> If no <code>app14Adobe</code> node is present, the component ids in |
|
449 the frame header are consulted. If these indicate a colorspace as |
|
450 described above, then the image is converted to that colorspace if |
|
451 possible. If the component ids do not indicate a colorspace, then |
|
452 the sampling factors are consulted. If the image is to be |
|
453 subsampled, it is converted to YCbCrA. If the image is not to be |
|
454 subsampled, then no conversion is applied. No special marker |
|
455 segments are written. |
|
456 </ul> |
|
457 |
|
458 <li> PhotoYCC Images: |
|
459 <ul> |
|
460 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
461 the image is converted to sRGB, and then to YCbCr during encoding, |
|
462 and a JFIF <code>APP0</code> marker segment is written. |
|
463 |
|
464 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
465 object, no conversion is applied, and an Adobe <code>APP14</code> |
|
466 marker segment is written. The color transform must be YCC. If it |
|
467 is not, a warning is sent to listeners. |
|
468 |
|
469 <li> If neither node is present in the metadata object, no conversion |
|
470 is applied, and no special marker segment is written. |
|
471 </ul> |
|
472 |
|
473 <li> PhotoYCCA Images: |
|
474 <ul> |
|
475 <li> If an <code>app0JFIF</code> node is present in the metadata object, |
|
476 it is ignored and a warning is sent to listeners, as JFIF does not |
|
477 support 4-channel images. |
|
478 |
|
479 <li> If an <code>app14Adobe</code> node is present in the metadata |
|
480 object, no conversion is applied, and an Adobe <code>APP14</code> |
|
481 marker segment is written. The color transform must be |
|
482 <code>UNKNOWN</code>. If it is not, a warning is sent to |
|
483 listeners. |
|
484 |
|
485 <li> If neither node is present in the metadata object, no conversion |
|
486 is applied, and no special marker segment is written. |
|
487 </ul> |
|
488 </ul> |
|
489 |
|
490 <p> |
|
491 <h2> |
|
492 <a name=thumbs>Thumbnail Images</a> |
|
493 </h2> |
|
494 Thumbnails are supported by the use of JFIF and JFIF extension marker segments. |
|
495 Thumbnails provided on the write methods determine the thumbnails that will be |
|
496 included. <code>app0JFIF</code> and <code>app0JFXX</code> nodes present in |
|
497 the metadata do not contain any thumbnail pixel data. However, the kinds of |
|
498 thumbnails written depend on the contents of the metadata object, as follows. |
|
499 Any thumbnail which is to be written as an indexed or RGB image and which is |
|
500 larger than 255 by 255 will be clipped, not scaled, to 255 by 255. Thumbnails |
|
501 written as JPEG images may be any size. A warning is sent to any listeners |
|
502 whenever a thumbnail is clipped. |
|
503 <ul> |
|
504 <li> If there is a single thumbnail, it is processed as follows: |
|
505 <ul> |
|
506 <li> If the thumbnail image is an RGB palette image, it is processed as |
|
507 follows: |
|
508 <ul> |
|
509 <li> If no <code>app0JFXX</code> node is present in the metadata, or |
|
510 the first <code>app0JFXX</code> node present in the metadata |
|
511 contains a <code>JFIFthumbPalette</code> element, a |
|
512 palette thumbnail is written in a JFXX <code>APP0</code> marker |
|
513 segment. |
|
514 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
515 contains another thumbnail form (RGB or JPEG), the palette |
|
516 image is expanded to RGB and the indicated thumbnail form is |
|
517 written. |
|
518 </ul> |
|
519 |
|
520 <li> If the thumbnail image is an RGB image, it is processed as follows: |
|
521 <ul> |
|
522 <li> If no <code>app0JFXX</code> node is present in the metadata, |
|
523 the thumbnail is written as part of the JFIF <code>APP0</code> |
|
524 marker segment. |
|
525 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
526 contains a <code>JFIFthumbRGB</code> element, an |
|
527 RGB thumbnail is written in a JFXX <code>APP0</code> marker |
|
528 segment. |
|
529 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
530 contains a <code>JFIFthumbJPEG</code> element, a |
|
531 JPEG thumbnail is written in a JFXX <code>APP0</code> marker |
|
532 segment. |
|
533 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
534 contains a <code>JFIFthumbPalette</code> element, an |
|
535 RGB thumbnail is written in a JFXX <code>APP0</code> marker |
|
536 segment and a warning is sent to any listeners. |
|
537 </ul> |
|
538 |
|
539 <li> If the thumbnail image is a grayscale image, it is processed as |
|
540 follows: |
|
541 <ul> |
|
542 <li> If no <code>app0JFXX</code> node is present in the metadata, |
|
543 the thumbnail is expanded to RGB and written as part of the |
|
544 JFIF <code>APP0</code> marker segment. |
|
545 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
546 contains a <code>JFIFthumbRGB</code> element, the thumbnail is |
|
547 expanded to RGB and written in a separate <code>JFXX</code> RGB |
|
548 marker segment. |
|
549 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
550 contains a <code>JFIFthumbJPEG</code> element, a |
|
551 JPEG thumbnail is written in a JFXX <code>APP0</code> marker |
|
552 segment. |
|
553 <li> If the first <code>app0JFXX</code> node present in the metadata |
|
554 contains a <code>JFIFthumbPalette</code> element, a |
|
555 JPEG thumbnail is written in a JFXX <code>APP0</code> marker |
|
556 segment and a warning is sent to any listeners. |
|
557 </ul> |
|
558 |
|
559 <li> Any other thumbnail image types are ignored and a warning is sent |
|
560 to any listeners. |
|
561 </ul> |
|
562 |
|
563 <li> If there are multiple thumbnails, each one is processed as above, except |
|
564 that no thumbnail is placed in the JFIF <code>APP0</code> segment, and |
|
565 the <code>app0JFXX</code> node consulted for each thumbnail is the |
|
566 <code>app0JFXX</code> node from the metadata that occurs in the same |
|
567 sequence as the thumbnail. <italic>I.e.</italic> the first |
|
568 <code>app0JFXX</code> node applies to the first thumbnail, the second |
|
569 node to the second thumbnail, and so on. If there are fewer |
|
570 <code>app0JFXX</code> nodes in the metadata than thumbnails, then |
|
571 those thumbnails are considered to have no matching |
|
572 <code>app0JFXX</code> node. An RGB thumbnail with no matching |
|
573 <code>app0JFXX</code> node is written in a JFXX <code>APP0</code> marker |
|
574 segment. A grayscale thumbnail with no matching |
|
575 <code>app0JFXX</code> node is written as a JPEG image to a JFXX |
|
576 <code>APP0</code> marker segment. |
|
577 </ul> |
|
578 <p> |
|
579 |
|
580 Note that as the only mechanism for storing thumbnails is via the |
|
581 JFIF or JFIF extension marker segments, only grayscale or RGB images |
|
582 may have thumbnails. If thumbnails are present when writing any other type |
|
583 of image, the thumbnails are ignored and a warning is sent to any warning |
|
584 listeners. |
|
585 |
|
586 <p> |
|
587 <h2> |
|
588 <a name=prog>Progressive Encoding</a> |
|
589 </h2> |
|
590 |
|
591 Progressive encoding must be enabled on the <code>ImageWriteParam</code> |
|
592 passed in to a write operation, or the image will be written sequentially, |
|
593 regardless of the scan headers included in the metadata object. If |
|
594 progressive encoding is enabled and set to copy from metadata, then |
|
595 the sequence of scan headers from the metadata is used to write the |
|
596 image. If progressive encoding is enabled and set to use a default, |
|
597 then the scans in the metadata are ignored and a default set of scans |
|
598 is used. Progressive encoding always forces optimized Huffman tables to |
|
599 be used. Any Huffman tables present in the metadata will be ignored, |
|
600 and a warning will be sent to any warning listeners. |
|
601 |
|
602 If Huffman-table optimization is requested on the <code>ImageWriteParam</code>, |
|
603 all Huffman tables in the metadata or in the <code>ImageWriteParam</code> |
|
604 itself are ignored, and a warning will be sent to any warning listeners if |
|
605 any such tables are present. |
|
606 |
|
607 <p> |
|
608 <h2> |
|
609 <a name=tree>Native Metadata Format Tree Structure and Editing</a> |
|
610 </h2> |
|
611 |
|
612 The DTDs below describe just the trees of metadata objects actually returned |
|
613 by the <code>IIOMetadata</code> object. They do not include nodes |
|
614 corresponding to <code>SOI</code>, <code>EOI</code>, or <code>RST</code> |
|
615 markers, as these parsing delimiters do not carry any meaningful metadata. |
|
616 <p> |
|
617 |
|
618 The first node is always a <code>JPEGvariety</code> node. In the |
|
619 <code>javax_imageio_jpeg_image_1.0</code> version of the JPEG metadata |
|
620 format, this node may have one child, an <code>app0JFIF</code> node, |
|
621 indicating that the JPEG stream contains a JFIF marker segment and related |
|
622 data, or no children, indicating that the stream contains no JFIF marker. |
|
623 In future versions of the JPEG metadata format, other varieties of JPEG |
|
624 metadata may be supported (e.g. Exif) by defining other types of nodes |
|
625 which may appear as a child of the <code>JPEGvariety</code> node. |
|
626 <p> |
|
627 |
|
628 (Note that an application wishing to interpret Exif metadata given |
|
629 a metadata tree structure in the <code>javax_imageio_jpeg_image_1.0</code> |
|
630 format must check for an <code>unknown</code> marker segment with a tag |
|
631 indicating an <code>APP1</code> marker and containing data identifying it |
|
632 as an Exif marker segment. Then it may use application-specific code to |
|
633 interpret the data in the marker segment. If such an application were |
|
634 to encounter a metadata tree formatted according to a future version of |
|
635 the JPEG metadata format, the Exif marker segment might not be |
|
636 <code>unknown</code> in that format - it might be structured as a |
|
637 child node of the <code>JPEGvariety</code> node. Thus, it is important |
|
638 for an application to specify which version to use by passing the string |
|
639 identifying the version to the method/constructor used to obtain an |
|
640 <code>IIOMetadata</code> object.) |
|
641 |
|
642 <p> |
|
643 |
|
644 On reading, <code>JFXX</code> and <code>app2ICC</code> nodes occur as |
|
645 children of an <code>app0JFIF</code> node. |
|
646 This is true regardless of where the JFXX <code>APP0</code> and |
|
647 <code>APP2</code> marker segments actually occur in the stream. The ordering |
|
648 of nodes within the <code>markerSequence</code> node corresponds to the |
|
649 ordering of marker segments found in the JPEG stream. |
|
650 <p> |
|
651 On writing, any <code>JFXX</code> and <code>app2ICC</code> nodes must |
|
652 occur as children of an <code>app0JFIF</code> node, itself a child of a |
|
653 <code>JPEGvariety</code> node, which must always be the first node. |
|
654 (If the stream is not to be JFIF compliant, no <code>app0JFIF</code> node |
|
655 should be provided, and the <code>JPEGvariety</code> node should have no |
|
656 children.) Any |
|
657 JFIF <code>APP0</code>, JFXX <code>APP0</code>, and <code>APP2</code> marker |
|
658 segments are written first, followed by all Adobe <code>APP14</code>, |
|
659 <code>APPn</code>, <code>COM</code> and unknown segments in the |
|
660 order in which their corresponding nodes appear in the |
|
661 <code>markerSequence</code> node, followed by <code>DQT</code> (and |
|
662 <code>DHT</code> for non-progressive writes) marker segments, followed by the |
|
663 <code>SOF</code> and <code>SOS</code> marker segments. For progressive writes |
|
664 using metadata to control progression, the <code>SOS</code> segments are used |
|
665 in the order in which their corresponding nodes occur in the |
|
666 <code>markerSequence</code> node. |
|
667 <p> |
|
668 |
|
669 The <code>reset</code>, <code>mergeTree</code> and <code>setFromTree</code> |
|
670 operations have the following semantics for the JPEG plug-in metadata object: |
|
671 |
|
672 <p> <code>reset</code> - A call to <code>reset</code> will restore the |
|
673 metadata object to the same state it had immediately after creation, whether |
|
674 this came about from reading a stream or by obtaining a default object from |
|
675 the <code>ImageWriter</code>. This is true regardless of how many times the |
|
676 metadata object has been modified since creation. |
|
677 |
|
678 <p> <code>mergeTree</code> - Native Format |
|
679 <br> The <code>mergeTree</code> operation accepts valid trees conforming to |
|
680 the DTD below, and merges the nodes using the following ordering rules. In |
|
681 all cases, only data present in the new node is changed in a corresponding |
|
682 existing node, if any. This means that nodes cannot be removed using |
|
683 <code>mergeTree</code>. To remove nodes, use <code>setFromTree</code>. The |
|
684 tree must consist of <code>IIOMetadataNode</code>s. |
|
685 <ul> |
|
686 <li> <code>app0JFIF</code> |
|
687 <ul> |
|
688 <li> If an <code>app0JFIF</code> node already exists, the contents |
|
689 of the new one modify the existing one. |
|
690 <li> If there is no such node, a new one is created and inserted in |
|
691 the appropriate position. |
|
692 </ul> |
|
693 <li> <code>dqt</code> |
|
694 <ul> |
|
695 <li> If there already exist <code>dqt</code> nodes in the sequence, |
|
696 then each table in the node replaces the first table, in any |
|
697 <code>dqt</code> node, with the same table id. |
|
698 <li> If none of the existing <code>dqt</code> nodes contain a table |
|
699 with the same id, then the table is added to the last existing |
|
700 <code>dqt</code> node. |
|
701 <li> If there are no <code>dqt</code> nodes, then a new one is |
|
702 created and added as follows: |
|
703 <ul> |
|
704 <li> If there are <code>dht</code> nodes, the new |
|
705 <code>dqt</code> node is inserted before the first one. |
|
706 <li> If there are no <code>dht</code> nodes, the new |
|
707 <code>dqt</code> node is inserted before an |
|
708 <code>sof</code> node, if there is one. |
|
709 <li> If there is no <code>sof</code> node, the new |
|
710 <code>dqt</code> node is inserted before the first |
|
711 <code>sos</code> node, if there is one. |
|
712 <li> If there is no <code>sos</code> node, the new |
|
713 <code>dqt</code> node is added to the end of the sequence. |
|
714 </ul> |
|
715 </ul> |
|
716 <li> <code>dht</code> |
|
717 <ul> |
|
718 <li> If there already exist <code>dht</code> nodes in the sequence, |
|
719 then each table in the node replaces the first table, in any |
|
720 <code>dht</code> node, with the same table class and table id. |
|
721 <li> If none of the existing <code>dht</code> nodes contain a table |
|
722 with the same class and id, then the table is added to the last |
|
723 existing <code>dht</code> node. |
|
724 <li> If there are no <code>dht</code> nodes, then a new one is |
|
725 created and added as follows: |
|
726 <ul> |
|
727 <li> If there are <code>dqt</code> nodes, the new |
|
728 <code>dht</code> node is inserted immediately following the |
|
729 last <code>dqt</code> node. |
|
730 <li> If there are no <code>dqt</code> nodes, the new |
|
731 <code>dht</code> node is inserted before an |
|
732 <code>sof</code> node, if there is one. |
|
733 <li> If there is no <code>sof</code> node, the new |
|
734 <code>dht</code> node is inserted before the first |
|
735 <code>sos</code> node, if there is one. |
|
736 <li> If there is no <code>sos</code> node, the new |
|
737 <code>dht</code> node is added to the end of the sequence. |
|
738 </ul> |
|
739 </ul> |
|
740 <li> <code>dri</code> |
|
741 <ul> |
|
742 <li> If there already exists a <code>dri</code> node, the restart |
|
743 interval value is updated. |
|
744 <li> If there is no <code>dri</code> node, then a new one is created |
|
745 and added as follows: |
|
746 <ul> |
|
747 <li> If there is an <code>sof</code> node, the new |
|
748 <code>dri</code> node is inserted before it. |
|
749 <li> If there is no <code>sof</code> node, the new |
|
750 <code>dri</code> node is inserted before the first |
|
751 <code>sos</code> node, if there is one. |
|
752 <li> If there is no <code>sos</code> node, the new |
|
753 <code>dri</code> node is added to the end of the sequence. |
|
754 </ul> |
|
755 </ul> |
|
756 <li> <code>com</code> |
|
757 <br> A new <code>com</code> node is created and inserted as follows: |
|
758 <ul> |
|
759 <li> If there already exist <code>com</code> nodes, the new one is |
|
760 inserted after the last one. |
|
761 <li> If there are no <code>com</code> nodes, the new |
|
762 <code>com</code> node is inserted after the |
|
763 <code>app14Adobe</code> node, if there is one. |
|
764 <li> If there is no <code>app14Adobe</code> node, the new |
|
765 <code>com</code> node is inserted at the beginning of the |
|
766 sequence. |
|
767 </ul> |
|
768 <li> <code>app14Adobe</code> |
|
769 <ul> |
|
770 <li> If there already exists an <code>app14Adobe</code> node, then |
|
771 its attributes are updated from the node. |
|
772 <li> If there is no <code>app14Adobe</code> node, then a new one is |
|
773 created and added as follows: |
|
774 <ul> |
|
775 <li> The new <code>app14Adobe</code> node is inserted after the |
|
776 last <code>unknown</code> node, if there are any. |
|
777 <li> If there are no <code>unknown</code> nodes, the new |
|
778 <code>app14Adobe</code> node is inserted at the beginning |
|
779 of the sequence. |
|
780 </ul> |
|
781 </ul> |
|
782 <li> <code>unknown</code> |
|
783 <br> A new <code>unknown</code> node is created and added to the |
|
784 sequence as follows: |
|
785 <ul> |
|
786 <li> If there already exist <code>unknown</code> marker nodes, the |
|
787 new one is inserted after the last one. |
|
788 <li> If there are no <code>unknown</code> nodes, the new |
|
789 <code>unknown</code> node is inserted before the |
|
790 <code>app14Adobe</code> node, if there is one. |
|
791 <li> If there is no <code>app14Adobe</code> node, the new |
|
792 <code>unknown</code> node is inserted at the beginning of the |
|
793 sequence. |
|
794 </ul> |
|
795 <li> <code>sof</code> |
|
796 <ul> |
|
797 <li> If there already exists an <code>sof</code> node in the |
|
798 sequence, then its values are updated from the node. |
|
799 <li> If there is no <code>sof</code> node, then a new one is created |
|
800 and added as follows: |
|
801 <ul> |
|
802 <li> If there are any <code>sos</code> nodes, the new |
|
803 <code>sof</code> node is inserted before the first one. |
|
804 <li> If there is no <code>sos</code> node, the new |
|
805 <code>sof</code> node is added to the end of the sequence. |
|
806 </ul> |
|
807 </ul> |
|
808 <li> <code>sos</code> |
|
809 <ul> |
|
810 <li> If there already exists a single <code>sos</code> node, then |
|
811 the values are updated from the node. |
|
812 <li> If there are more than one existing <code>sos</code> nodes, |
|
813 then an <code>IIOInvalidTreeException</code> is thrown, as |
|
814 <code>sos</code> nodes cannot be merged into a set of |
|
815 progressive scans. |
|
816 <li> If there are no <code>sos</code> nodes, a new one is created |
|
817 and added to the end of the sequence. |
|
818 </ul> |
|
819 </ul> |
|
820 |
|
821 <p> <code>mergeTree</code> - Standard Format |
|
822 <br> |
|
823 The <code>mergeTree</code> operation, when given a tree in the standard |
|
824 format, will modify the native tree in the following ways: |
|
825 <ul> |
|
826 <li> <code>Chroma</code> - The <code>ColorSpaceType</code> subnode of a |
|
827 <code>Chroma</code> node may change the target colorspace of the |
|
828 compressed image. The selection of a new colorspace can cause a number |
|
829 of changes, in keeping with the algorithms described above: |
|
830 <code>app0JFIF</code> and <code>app14Adobe</code> nodes may be added |
|
831 or removed, subsampling may be added or removed, component ids may |
|
832 be changed, and <code>sof</code> and <code>sos</code> nodes will be |
|
833 updated accordingly. If necessary, additional quantization and |
|
834 huffman tables are added. In the case of quantization tables, the |
|
835 default will be scaled to match the quality level of any existing |
|
836 tables. No tables are added to metadata that does not already contain |
|
837 tables. If the existing metadata specifies progressive encoding, then |
|
838 the number of channels must not change. Any <code>Transparency</code> |
|
839 node is also taken into account, as an explicit value of |
|
840 <code>none</code> for the <code>Alpha</code> subnode can cause the |
|
841 removal of an alpha channel, and anything other than <code>none</code> |
|
842 can cause the addition of an alpha channel. |
|
843 <li> <code>Dimension</code> - A <code>PixelAspectRatio</code> specification |
|
844 can cause the contents of an <code>app0JFIF</code> node to change, if |
|
845 there is one present, or the addition of an <code>app0JFIF</code> node |
|
846 containing appropriate values, if there can be one. An appropriate |
|
847 pair of integers is computed from the floating-point ratio for |
|
848 inclusion in the node. |
|
849 <li> <code>Text</code> - Each uncompressed text item is converted to a |
|
850 <code>com</code> node and inserted according to the rules above for |
|
851 merging <code>com</code> nodes. |
|
852 </ul> |
|
853 |
|
854 <p> <code>setFromTree</code> - Native Format |
|
855 <br> |
|
856 The <code>setFromTree</code> operation, when given a tree in the native |
|
857 format described below, will simply replace the existing tree in its entirety |
|
858 with the new one. The tree must consist of <code>IIOMetadataNode</code>s. |
|
859 |
|
860 <p> <code>setFromTree</code> - Standard Format |
|
861 <br> |
|
862 The <code>setFromTree</code> operation, when given a tree in the standard |
|
863 format, performs a <code>reset</code> followed by a merge of the new tree. |
|
864 |
|
865 <h2> |
|
866 <a name=image>Image Metadata DTD</a> |
|
867 </h2> |
|
868 |
|
869 <pre> |
|
870 <!DOCTYPE "javax_imageio_jpeg_image_1.0" [ |
|
871 |
|
872 <!ELEMENT "javax_imageio_jpeg_image_1.0" (JPEGvariety, markerSequence)> |
|
873 |
|
874 <!ELEMENT "JPEGvariety" (app0JFIF)> |
|
875 <!-- A node grouping all marker segments specific to the variety of |
|
876 stream being read/written (e.g. JFIF) - may be empty --> |
|
877 |
|
878 <!ELEMENT "app0JFIF" (JFXX?, app2ICC?)> |
|
879 <!ATTLIST "app0JFIF" "majorVersion" #CDATA "1"> |
|
880 <!-- The major JFIF version number --> |
|
881 <!-- Data type: Integer --> |
|
882 <!-- Min value: 0 (inclusive) --> |
|
883 <!-- Max value: 255 (inclusive) --> |
|
884 <!ATTLIST "app0JFIF" "minorVersion" #CDATA "2"> |
|
885 <!-- The minor JFIF version number --> |
|
886 <!-- Data type: Integer --> |
|
887 <!-- Min value: 0 (inclusive) --> |
|
888 <!-- Max value: 255 (inclusive) --> |
|
889 <!ATTLIST "app0JFIF" "resUnits" ("0" | "1" | "2") "0"> |
|
890 <!-- The resolution units for Xdensisty and Ydensity (0 = no |
|
891 units, just aspect ratio; 1 = dots/inch; 2 = dots/cm) --> |
|
892 <!ATTLIST "app0JFIF" "Xdensity" #CDATA "1"> |
|
893 <!-- The horizontal density or aspect ratio numerator --> |
|
894 <!-- Data type: Integer --> |
|
895 <!-- Min value: 1 (inclusive) --> |
|
896 <!-- Max value: 65535 (inclusive) --> |
|
897 <!ATTLIST "app0JFIF" "Ydensity" #CDATA "1"> |
|
898 <!-- The vertical density or aspect ratio denominator --> |
|
899 <!-- Data type: Integer --> |
|
900 <!-- Min value: 1 (inclusive) --> |
|
901 <!-- Max value: 65535 (inclusive) --> |
|
902 <!ATTLIST "app0JFIF" "thumbWidth" #CDATA "0"> |
|
903 <!-- The width of the thumbnail, or 0 if there isn't one --> |
|
904 <!-- Data type: Integer --> |
|
905 <!-- Min value: 0 (inclusive) --> |
|
906 <!-- Max value: 255 (inclusive) --> |
|
907 <!ATTLIST "app0JFIF" "thumbHeight" #CDATA "0"> |
|
908 <!-- The height of the thumbnail, or 0 if there isn't one --> |
|
909 <!-- Data type: Integer --> |
|
910 <!-- Min value: 0 (inclusive) --> |
|
911 <!-- Max value: 255 (inclusive) --> |
|
912 |
|
913 <!ELEMENT "JFXX" (app0JFXX)*> |
|
914 <!-- Min children: 1 --> |
|
915 |
|
916 <!ELEMENT "app0JFXX" (JFIFthumbJPEG | JFIFthumbPalette | |
|
917 JFIFthumbRGB)> |
|
918 <!-- A JFIF extension marker segment --> |
|
919 <!ATTLIST "app0JFXX" "extensionCode" ("16" | "17" | "19") |
|
920 #IMPLIED> |
|
921 <!-- The JFXX extension code identifying thumbnail type: (16 = |
|
922 JPEG, 17 = indexed, 19 = RGB --> |
|
923 |
|
924 <!ELEMENT "JFIFthumbJPEG" (markerSequence?)> |
|
925 <!-- A JFIF thumbnail in JPEG format (no JFIF segments |
|
926 permitted) --> |
|
927 |
|
928 <!ELEMENT "JFIFthumbPalette" EMPTY> |
|
929 <!-- A JFIF thumbnail as an RGB indexed image --> |
|
930 <!ATTLIST "JFIFthumbPalette" "thumbWidth" #CDATA #IMPLIED> |
|
931 <!-- The width of the thumbnail --> |
|
932 <!-- Data type: Integer --> |
|
933 <!-- Min value: 0 (inclusive) --> |
|
934 <!-- Max value: 255 (inclusive) --> |
|
935 <!ATTLIST "JFIFthumbPalette" "thumbHeight" #CDATA #IMPLIED> |
|
936 <!-- The height of the thumbnail --> |
|
937 <!-- Data type: Integer --> |
|
938 <!-- Min value: 0 (inclusive) --> |
|
939 <!-- Max value: 255 (inclusive) --> |
|
940 |
|
941 <!ELEMENT "JFIFthumbRGB" EMPTY> |
|
942 <!-- A JFIF thumbnail as an RGB image --> |
|
943 <!ATTLIST "JFIFthumbRGB" "thumbWidth" #CDATA #IMPLIED> |
|
944 <!-- The width of the thumbnail --> |
|
945 <!-- Data type: Integer --> |
|
946 <!-- Min value: 0 (inclusive) --> |
|
947 <!-- Max value: 255 (inclusive) --> |
|
948 <!ATTLIST "JFIFthumbRGB" "thumbHeight" #CDATA #IMPLIED> |
|
949 <!-- The height of the thumbnail --> |
|
950 <!-- Data type: Integer --> |
|
951 <!-- Min value: 0 (inclusive) --> |
|
952 <!-- Max value: 255 (inclusive) --> |
|
953 |
|
954 <!ELEMENT "app2ICC" EMPTY> |
|
955 <!-- An ICC profile APP2 marker segment --> |
|
956 <!-- Optional User object: java.awt.color.ICC_Profile --> |
|
957 |
|
958 <!ELEMENT "markerSequence" (dqt | dht | dri | com | unknown | |
|
959 app14Adobe | sof | sos)*> |
|
960 <!-- A node grouping all non-jfif marker segments --> |
|
961 |
|
962 <!ELEMENT "dqt" (dqtable)*> |
|
963 <!-- A Define Quantization Table(s) marker segment --> |
|
964 <!-- Min children: 1 --> |
|
965 <!-- Max children: 4 --> |
|
966 |
|
967 <!ELEMENT "dqtable" EMPTY> |
|
968 <!-- A single quantization table --> |
|
969 <!-- User object: javax.imageio.plugins.jpeg.JPEGQTable --> |
|
970 <!ATTLIST "dqtable" "elementPrecision" #CDATA "0"> |
|
971 <!-- The number of bits in each table element (0 = 8, 1 = 16) |
|
972 --> |
|
973 <!-- Data type: Integer --> |
|
974 <!ATTLIST "dqtable" "qtableId" ("0" | "1" | "2" | "3") #REQUIRED> |
|
975 |
|
976 <!ELEMENT "dht" (dhtable)*> |
|
977 <!-- A Define Huffman Table(s) marker segment --> |
|
978 <!-- Min children: 1 --> |
|
979 <!-- Max children: 4 --> |
|
980 |
|
981 <!ELEMENT "dhtable" EMPTY> |
|
982 <!-- A single Huffman table --> |
|
983 <!-- User object: javax.imageio.plugins.jpeg.JPEGHuffmanTable --> |
|
984 <!ATTLIST "dhtable" "class" ("0" | "1") #REQUIRED> |
|
985 <!-- Indicates whether this is a DC (0) or an AC (1) table --> |
|
986 <!ATTLIST "dhtable" "htableId" ("0" | "1" | "2" | "3") #REQUIRED> |
|
987 <!-- The table id --> |
|
988 |
|
989 <!ELEMENT "dri" EMPTY> |
|
990 <!-- A Define Restart Interval marker segment --> |
|
991 <!ATTLIST "dri" "interval" #CDATA #REQUIRED> |
|
992 <!-- The restart interval in MCUs --> |
|
993 <!-- Data type: Integer --> |
|
994 <!-- Min value: 0 (inclusive) --> |
|
995 <!-- Max value: 65535 (inclusive) --> |
|
996 |
|
997 <!ELEMENT "com" EMPTY> |
|
998 <!-- A Comment marker segment. The user object contains the actual |
|
999 bytes. --> |
|
1000 <!-- User object: array of [B --> |
|
1001 <!-- Min length: 1 --> |
|
1002 <!-- Max length: 65533 --> |
|
1003 <!ATTLIST "com" "comment" #CDATA #IMPLIED> |
|
1004 <!-- The comment as a string (used only if user object is null) |
|
1005 --> |
|
1006 <!-- Data type: String --> |
|
1007 |
|
1008 <!ELEMENT "unknown" EMPTY> |
|
1009 <!-- An unrecognized marker segment. The user object contains the |
|
1010 data not including length. --> |
|
1011 <!-- User object: array of [B --> |
|
1012 <!-- Min length: 1 --> |
|
1013 <!-- Max length: 65533 --> |
|
1014 <!ATTLIST "unknown" "MarkerTag" #CDATA #REQUIRED> |
|
1015 <!-- The tag identifying this marker segment --> |
|
1016 <!-- Data type: Integer --> |
|
1017 <!-- Min value: 0 (inclusive) --> |
|
1018 <!-- Max value: 255 (inclusive) --> |
|
1019 |
|
1020 <!ELEMENT "app14Adobe" EMPTY> |
|
1021 <!-- An Adobe APP14 marker segment --> |
|
1022 <!ATTLIST "app14Adobe" "version" #CDATA "100"> |
|
1023 <!-- The version of Adobe APP14 marker segment --> |
|
1024 <!-- Data type: Integer --> |
|
1025 <!-- Min value: 100 (inclusive) --> |
|
1026 <!-- Max value: 255 (inclusive) --> |
|
1027 <!ATTLIST "app14Adobe" "flags0" #CDATA "0"> |
|
1028 <!-- The flags0 variable of an APP14 marker segment --> |
|
1029 <!-- Data type: Integer --> |
|
1030 <!-- Min value: 0 (inclusive) --> |
|
1031 <!-- Max value: 65535 (inclusive) --> |
|
1032 <!ATTLIST "app14Adobe" "flags1" #CDATA "0"> |
|
1033 <!-- The flags1 variable of an APP14 marker segment --> |
|
1034 <!-- Data type: Integer --> |
|
1035 <!-- Min value: 0 (inclusive) --> |
|
1036 <!-- Max value: 65535 (inclusive) --> |
|
1037 <!ATTLIST "app14Adobe" "transform" ("0" | "1" | "2") #REQUIRED> |
|
1038 <!-- The color transform applied to the image (0 = Unknown, 1 = |
|
1039 YCbCr, 2 = YCCK) --> |
|
1040 |
|
1041 <!ELEMENT "sof" (componentSpec)*> |
|
1042 <!-- A Start Of Frame marker segment --> |
|
1043 <!-- Min children: 1 --> |
|
1044 <!-- Max children: 4 --> |
|
1045 <!ATTLIST "sof" "process" ("0" | "1" | "2") #IMPLIED> |
|
1046 <!-- The JPEG process (0 = Baseline sequential, 1 = Extended |
|
1047 sequential, 2 = Progressive) --> |
|
1048 <!ATTLIST "sof" "samplePrecision" #CDATA "8"> |
|
1049 <!-- The number of bits per sample --> |
|
1050 <!-- Data type: Integer --> |
|
1051 <!ATTLIST "sof" "numLines" #CDATA #IMPLIED> |
|
1052 <!-- The number of lines in the image --> |
|
1053 <!-- Data type: Integer --> |
|
1054 <!-- Min value: 0 (inclusive) --> |
|
1055 <!-- Max value: 65535 (inclusive) --> |
|
1056 <!ATTLIST "sof" "samplesPerLine" #CDATA #IMPLIED> |
|
1057 <!-- The number of samples per line --> |
|
1058 <!-- Data type: Integer --> |
|
1059 <!-- Min value: 0 (inclusive) --> |
|
1060 <!-- Max value: 65535 (inclusive) --> |
|
1061 <!ATTLIST "sof" "numFrameComponents" ("1" | "2" | "3" | "4") |
|
1062 #IMPLIED> |
|
1063 <!-- The number of components in the image --> |
|
1064 |
|
1065 <!ELEMENT "componentSpec" EMPTY> |
|
1066 <!-- A component specification for a frame --> |
|
1067 <!ATTLIST "componentSpec" "componentId" #CDATA #REQUIRED> |
|
1068 <!-- The id for this component --> |
|
1069 <!-- Data type: Integer --> |
|
1070 <!-- Min value: 0 (inclusive) --> |
|
1071 <!-- Max value: 255 (inclusive) --> |
|
1072 <!ATTLIST "componentSpec" "HsamplingFactor" #CDATA #REQUIRED> |
|
1073 <!-- The horizontal sampling factor for this component --> |
|
1074 <!-- Data type: Integer --> |
|
1075 <!-- Min value: 1 (inclusive) --> |
|
1076 <!-- Max value: 255 (inclusive) --> |
|
1077 <!ATTLIST "componentSpec" "VsamplingFactor" #CDATA #REQUIRED> |
|
1078 <!-- The vertical sampling factor for this component --> |
|
1079 <!-- Data type: Integer --> |
|
1080 <!-- Min value: 1 (inclusive) --> |
|
1081 <!-- Max value: 255 (inclusive) --> |
|
1082 <!ATTLIST "componentSpec" "QtableSelector" ("0" | "1" | "2" | |
|
1083 "3") #REQUIRED> |
|
1084 <!-- The quantization table to use for this component --> |
|
1085 |
|
1086 <!ELEMENT "sos" (scanComponentSpec)*> |
|
1087 <!-- A Start Of Scan marker segment --> |
|
1088 <!-- Min children: 1 --> |
|
1089 <!-- Max children: 4 --> |
|
1090 <!ATTLIST "sos" "numScanComponents" ("1" | "2" | "3" | "4") |
|
1091 #REQUIRED> |
|
1092 <!-- The number of components in the scan --> |
|
1093 <!ATTLIST "sos" "startSpectralSelection" #CDATA "0"> |
|
1094 <!-- The first spectral band included in this scan --> |
|
1095 <!-- Data type: Integer --> |
|
1096 <!-- Min value: 0 (inclusive) --> |
|
1097 <!-- Max value: 63 (inclusive) --> |
|
1098 <!ATTLIST "sos" "endSpectralSelection" #CDATA "63"> |
|
1099 <!-- The last spectral band included in this scan --> |
|
1100 <!-- Data type: Integer --> |
|
1101 <!-- Min value: 0 (inclusive) --> |
|
1102 <!-- Max value: 63 (inclusive) --> |
|
1103 <!ATTLIST "sos" "approxHigh" #CDATA "0"> |
|
1104 <!-- The highest bit position included in this scan --> |
|
1105 <!-- Data type: Integer --> |
|
1106 <!-- Min value: 0 (inclusive) --> |
|
1107 <!-- Max value: 15 (inclusive) --> |
|
1108 <!ATTLIST "sos" "approxLow" #CDATA "0"> |
|
1109 <!-- The lowest bit position included in this scan --> |
|
1110 <!-- Data type: Integer --> |
|
1111 <!-- Min value: 0 (inclusive) --> |
|
1112 <!-- Max value: 15 (inclusive) --> |
|
1113 |
|
1114 <!ELEMENT "scanComponentSpec" EMPTY> |
|
1115 <!-- A component specification for a scan --> |
|
1116 <!ATTLIST "scanComponentSpec" "componentSelector" #CDATA |
|
1117 #REQUIRED> |
|
1118 <!-- The id of this component --> |
|
1119 <!-- Data type: Integer --> |
|
1120 <!-- Min value: 0 (inclusive) --> |
|
1121 <!-- Max value: 255 (inclusive) --> |
|
1122 <!ATTLIST "scanComponentSpec" "dcHuffTable" ("0" | "1" | "2" | |
|
1123 "3") #REQUIRED> |
|
1124 <!-- The huffman table to use for encoding DC coefficients --> |
|
1125 <!ATTLIST "scanComponentSpec" "acHuffTable" ("0" | "1" | "2" | |
|
1126 "3") #REQUIRED> |
|
1127 <!-- The huffman table to use for encoding AC coefficients --> |
|
1128 ]> |
|
1129 </pre> |
|
1130 |
|
1131 <h2> |
|
1132 <a name=stream>Stream Metadata DTD</a> |
|
1133 </h2> |
|
1134 |
|
1135 <pre> |
|
1136 <!DOCTYPE "javax_imageio_jpeg_stream_1.0" [ |
|
1137 <!ELEMENT "javax_imageio_jpeg_stream_1.0" (dqt | |
|
1138 dht | |
|
1139 dri | |
|
1140 com | |
|
1141 unknown)*> |
|
1142 |
|
1143 <!-- All elements are as defined above for image metadata --> |
|
1144 ]> |
|
1145 </pre> |
|
1146 |
|
1147 </body> |
|
1148 </html> |