pngspec.html (310591B)
1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 4 <html lang="en" xmlns="http://www.w3.org/1999/xhtml"> 5 <head> 6 <title>Portable Network Graphics (PNG) Specification (Second Edition)</title> 7 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 8 <link rel="stylesheet" href="./isostyle.css" type="text/css" /> 9 <style type="text/css"> 10 /* remove annoying green color from definition terms */ 11 dt {color: black} 12 </style> 13 <link rel="stylesheet" type="text/css" media="screen" 14 href="http://www.w3.org/StyleSheets/TR/W3C-REC" /> 15 </head> 16 <body> 17 <div class="head"> 18 <p><a href="http://www.w3.org/"><img height="48" width="72" 19 alt="W3C" src="w3c_home.png" /></a></p> 20 <h1 id="pagetitle">Portable Network Graphics (PNG) Specification (Second Edition)<br class="xhtml" /> 21 Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification. ISO/IEC 15948:2003 (E)</h1> 22 <!--h2 id="pagesubtitle">W3C Recommendation 1 October 1996, revised 14 October 2003</h2--> 23 <h2 id="pagesubtitle">W3C Recommendation 10 November 2003</h2> 24 <dl> 25 <dt>This version:</dt> 26 <dd><a 27 href="http://www.w3.org/TR/2003/REC-PNG-20031110">http://www.w3.org/TR/2003/REC-PNG-20031110</a></dd> 28 <dt>Latest version:</dt> 29 <dd><a 30 href="http://www.w3.org/TR/PNG">http://www.w3.org/TR/PNG</a></dd> 31 <dt>Previous version:</dt> 32 <dd><a 33 href="http://www.w3.org/TR/2003/PR-PNG-20030520">http://www.w3.org/TR/2003/PR-PNG-20030520</a></dd> 34 <dt>Editor:</dt> 35 <dd>David Duce, Oxford Brookes University (Second Edition)</dd> 36 <dt>Authors:</dt> 37 <dd>See <a href="#F-Relationship">author list</a></dd> 38 </dl> 39 <p>Please refer to the <a href="http://www.w3.org/2003/11/REC-PNG-20031110-errata"><strong>errata</strong></a> for this document, which may include some normative corrections.</p> 40 41 <!--p>This document is also available in these non-normative 42 packages: <a href="REC-SVG11-20030114.zip">zip archive of 43 HTML</a> (without external dependencies) and <a 44 href="REC-SVG11-20030114.pdf">PDF</a>.</p--> 45 46 <p>See also the <a href="http://www.w3.org/Consortium/Translation/">translations</a> of this document.</p> 47 48 <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> © 2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p> 49 </div> 50 <hr title="Separator from Header" /> 51 52 <h2 id="specabstract"><a id="abstract" name="abstract">Abstract</a></h2> 53 <p>This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.</p> 54 <p>PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also, PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.</p> 55 56 <p>This specification defines an Internet Media Type image/png.</p> 57 58 <h2 id="status">Status of this document</h2> 59 <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p> 60 61 <p>This document is the 14 October 2003 W3C 62 Recommendation of the PNG specification, second edition. It is also International Standard, ISO/IEC 15948:2003. The two documents have exactly identical content except for cover page and boilerplate differences as appropriate to the two organisations.</p> 63 64 <p>This International Standard is strongly based on the W3C Recommendation 'PNG Specification Version 1.0' which was reviewed by W3C members, approved as a W3C Recommendation and published in October 1996. This second edition incorporates all known errata and clarifications. </p> 65 66 <p>A complete review of the document has been done by ISO/IEC/JTC 1/SC 24 in collaboration with W3C and the PNG development group (the original authors of the PNG 1.0 Recommendation) in order to transform that Recommendation into an ISO/IEC international standard. A major design goal during this review was to avoid changes that will invalidate existing files, editors, or viewers that conform to W3C Recommendation PNG Specification Version 1.0.</p> 67 68 <p>The PNG specification enjoys a good level of <a href="http://www.libpng.org/pub/png/pngstatus.html">implementation</a> with good interoperability. At the time of this publication more than 180 <a href="http://www.libpng.org/pub/png/pngapvw.html">image viewers</a> could display PNG images and over 100 <a href="http://www.libpng.org/pub/png/pngaped.html">image editors</a> could read and write valid PNG files. Full support of PNG is required for conforming <a href="/Graphics/SVG">SVG</a> viewers; at the time of publication all eighteen <a href="/Graphics/SVG/SVG-Implementations.htm8#viewer">SVG viewers</a> had PNG support. HTML has no required image formats, but over 60 <a href="http://www.libpng.org/pub/png/pngapbr.html">HTML browsers</a> had at least basic support of PNG images.</p> 69 70 <p>Public comments on this W3C Recommendation are welcome. 71 Please send them to the <a href="http://lists.w3.org/Archives/Public/png-group">archived</a> list <a href="mailto:png-group@w3.org">png-group@w3.org</a> .</p> 72 73 <p>The latest information regarding <a rel="disclosure" 74 href="http://www.w3.org/Graphics/PNG/Disclosures">patent 75 disclosures</a> related to this document is available on the 76 Web. As of this publication, the PNG Group are not 77 aware of any royalty-bearing patents they believe to be 78 essential to PNG.</p> 79 80 <p>This document has been produced by ISO/IEC JTC1 SC24 and the PNG Group as part of the <a 81 href="http://www.w3.org/Graphics/Activity">Graphics 82 Activity</a> within the <a href="http://www.w3.org/Interaction/">W3C 83 Interaction Domain</a>. </p> 84 85 <!-- removed p>A list of current W3C Recommendations and 86 other technical documents can be found at <a 87 href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>. 88 W3C publications may be updated, replaced, or obsoleted by other 89 documents at any time. 90 </p--> 91 92 <div><p><strong>Note:</strong> To provide the highest quality images, this specification uses SVG diagrams with a PNG fallback using the HTML object element. SVG-enabled browsers will see the SVG figures with selectable text, other browsers will display the raster PNG version.</p> 93 <p>W3C is aware that there is a <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=133567">known incompatibility</a> between the unsupported beta of Adobe SVG plugin for Linux and Mozilla versions greater than 0.9.9 due to changes in the plug-in API, causing a browser crash. Therefore, a normative <a href="./index-noobject.html">PNG-only alternative version</a> is available that does not use an object element. The two versions are otherwise identical.</p></div> 94 95 <h3 id="AvailableLanguages">Available languages</h3> 96 <p>The English version of this specification is the only 97 normative version. However, for translations in other languages 98 see <a 99 href="http://www.w3.org/Consortium/Translation/"> 100 http://www.w3.org/Consortium/Translation/</a>.</p> 101 102 <div class="toc"> 103 <h2><a id="minitoc" name="minitoc">Table of Contents</a></h2> 104 <ul class="toc"> 105 <!--li class="tocline1"--> 106 <li class='Contents'><a class='Href' href='#1Scope'>1 107 Scope</a></li> 108 109 <li class='Contents'><a class='Href' href='#2NormRefs'>2 110 Normative references</a></li> 111 112 <li class='Contents'><a class='Href' href='#3Defsandabbrevs'>3 113 Terms, definitions, and abbreviated terms</a> 114 115 <ul> 116 <li class='Contents'><a class='Href' href='#3Definitions'>3.1 117 Definitions</a></li> 118 119 <li class='Contents'><a class='Href' href='#3Abbreviations'>3.2 120 Abbreviated terms</a></li> 121 </ul> 122 </li> 123 124 <li class='Contents'><a class='Href' href='#4Concepts'>4 125 Concepts</a> 126 127 <ul> 128 <li class='Contents'><a class='Href' href= 129 '#4Concepts.Sourceimage'>4.1 Images</a></li> 130 131 <li class='Contents'><a class='Href' href= 132 '#4Concepts.ColourSpaces'>4.2 Colour spaces</a></li> 133 134 <li class='Contents'><a class='Href' href= 135 '#4Concepts.PNGImageTransformation'>4.3 Reference image to PNG 136 image transformation</a> 137 138 <ul> 139 <li class='Contents'><a class='Href' href= 140 '#4Concepts.Introduction'>4.3.1 Introduction</a></li> 141 142 <li class='Contents'><a class='Href' href= 143 '#4Concepts.Implied-alpha'>4.3.2 Alpha separation</a></li> 144 145 <li class='Contents'><a class='Href' href= 146 '#4Concepts.Indexing'>4.3.3 Indexing</a></li> 147 148 <li class='Contents'><a class='Href' href= 149 '#4Concepts.RGBMerging'>4.3.4 RGB merging</a></li> 150 151 <li class='Contents'><a class='Href' href= 152 '#4Concepts.Alpha-indexing'>4.3.5 Alpha compaction</a></li> 153 154 <li class='Contents'><a class='Href' href= 155 '#4Concepts.Scaling'>4.3.6 Sample depth scaling</a></li> 156 </ul> 157 </li> 158 159 <li class='Contents'><a class='Href' href= 160 '#4Concepts.PNGImage'>4.4 PNG image</a></li> 161 162 <li class='Contents'><a class='Href' href= 163 '#4Concepts.Encoding'>4.5 Encoding the PNG image</a> 164 165 <ul> 166 <li class='Contents'><a class='Href' href= 167 '#4Concepts.EncodingIntro'>4.5.1 Introduction</a></li> 168 169 <li class='Contents'><a class='Href' href= 170 '#4Concepts.EncodingPassAbs'>4.5.2 Pass extraction</a></li> 171 172 <li class='Contents'><a class='Href' href= 173 '#4Concepts.EncodingScanlineAbs'>4.5.3 Scanline 174 serialization</a></li> 175 176 <li class='Contents'><a class='Href' href= 177 '#4Concepts.EncodingFiltering'>4.5.4 Filtering</a></li> 178 179 <li class='Contents'><a class='Href' href= 180 '#4Concepts.EncodingCompression'>4.5.5 Compression</a></li> 181 182 <li class='Contents'><a class='Href' href= 183 '#4Concepts.EncodingChunking'>4.5.6 Chunking</a></li> 184 </ul> 185 </li> 186 187 <li class='Contents'><a class='Href' href= 188 '#4Concepts.AncillInfo'>4.6 Additional information</a></li> 189 190 <li class='Contents'><a class='Href' href='#4Concepts.Format'>4.7 191 PNG datastream</a> 192 193 <ul> 194 <li class='Contents'><a class='Href' href= 195 '#4Concepts.FormatChunks'>4.7.1 Chunks</a></li> 196 197 <li class='Contents'><a class='Href' href= 198 '#4Concepts.FormatTypes'>4.7.2 Chunk types</a></li> 199 </ul> 200 </li> 201 202 <li class='Contents'><a class='Href' href='#4Concepts.Errors'>4.8 203 Error handling</a></li> 204 205 <li class='Contents'><a class='Href' href= 206 '#4Concepts.Registration'>4.9 Extension and registration</a></li> 207 </ul> 208 </li> 209 210 <li class='Contents'><a class='Href' href='#5DataRep'>5 211 Datastream structure</a> 212 213 <ul> 214 <li class='Contents'><a class='Href' href='#5Introduction'>5.1 215 Introduction</a></li> 216 217 <li class='Contents'><a class='Href' href= 218 '#5PNG-file-signature'>5.2 PNG signature</a></li> 219 220 <li class='Contents'><a class='Href' href='#5Chunk-layout'>5.3 221 Chunk layout</a></li> 222 223 <li class='Contents'><a class='Href' href= 224 '#5Chunk-naming-conventions'>5.4 Chunk naming 225 conventions</a></li> 226 227 <li class='Contents'><a class='Href' href='#5CRC-algorithm'>5.5 228 Cyclic Redundancy Code algorithm</a></li> 229 230 <li class='Contents'><a class='Href' href='#5ChunkOrdering'>5.6 231 Chunk ordering</a></li> 232 </ul> 233 </li> 234 235 <li class='Contents'><a class='Href' href='#6Transformation'>6 236 Reference image to PNG image transformation</a> 237 238 <ul> 239 <li class='Contents'><a class='Href' href='#6Colour-values'>6.1 240 Colour types and values</a></li> 241 242 <li class='Contents'><a class='Href' href= 243 '#6AlphaRepresentation'>6.2 Alpha representation</a></li> 244 </ul> 245 </li> 246 247 <li class='Contents'><a class='Href' href='#7Transformation'>7 248 Encoding the PNG image as a PNG datastream</a> 249 250 <ul> 251 <li class='Contents'><a class='Href' href= 252 '#7Integers-and-byte-order'>7.1 Integers and byte order</a></li> 253 254 <li class='Contents'><a class='Href' href='#7Scanline'>7.2 255 Scanlines</a></li> 256 257 <li class='Contents'><a class='Href' href='#7Filtering'>7.3 258 Filtering</a></li> 259 </ul> 260 </li> 261 262 <li class='Contents'><a class='Href' href='#8Interlace'>8 263 Interlacing and pass extraction</a> 264 265 <ul> 266 <li class='Contents'><a class='Href' href='#8InterlaceIntro'>8.1 267 Introduction</a></li> 268 269 <li class='Contents'><a class='Href' href= 270 '#8InterlaceMethods'>8.2 Interlace methods</a></li> 271 </ul> 272 </li> 273 274 <li class='Contents'><a class='Href' href='#9Filters'>9 275 Filtering</a> 276 277 <ul> 278 <li class='Contents'><a class='Href' href='#9FtIntro'>9.1 Filter 279 methods and filter types</a></li> 280 281 <li class='Contents'><a class='Href' href='#9Filter-types'>9.2 282 Filter types for filter method 0</a></li> 283 284 <li class='Contents'><a class='Href' href= 285 '#9Filter-type-3-Average'>9.3 Filter type 3: Average</a></li> 286 287 <li class='Contents'><a class='Href' href= 288 '#9Filter-type-4-Paeth'>9.4 Filter type 4: Paeth</a></li> 289 </ul> 290 </li> 291 292 <li class='Contents'><a class='Href' href='#10Compression'>10 293 Compression</a> 294 295 <ul> 296 <li class='Contents'><a class='Href' href= 297 '#10CompressionCM0'>10.1 Compression method 0</a></li> 298 299 <li class='Contents'><a class='Href' href= 300 '#10CompressionFSL'>10.2 Compression of the sequence of filtered 301 scanlines</a></li> 302 303 <li class='Contents'><a class='Href' href= 304 '#10CompressionOtherUses'>10.3 Other uses of compression</a></li> 305 </ul> 306 </li> 307 308 <li class='Contents'><a class='Href' href='#11Chunks'>11 Chunk 309 specifications</a> 310 311 <ul> 312 <li class='Contents'><a class='Href' href='#11Introduction'>11.1 313 Introduction</a></li> 314 315 <li class='Contents'><a class='Href' href= 316 '#11Critical-chunks'>11.2 Critical chunks</a> 317 318 <ul> 319 <li class='Contents'><a class='Href' href='#11CcGen'>11.2.1 320 General</a></li> 321 322 <li class='Contents'><a class='Href' href='#11IHDR'>11.2.2 <span 323 class='chunk'>IHDR</span> Image header</a></li> 324 325 <li class='Contents'><a class='Href' href='#11PLTE'>11.2.3 <span 326 class='chunk'>PLTE</span> Palette</a></li> 327 328 <li class='Contents'><a class='Href' href='#11IDAT'>11.2.4 <span 329 class='chunk'>IDAT</span> Image data</a></li> 330 331 <li class='Contents'><a class='Href' href='#11IEND'>11.2.5 <span 332 class='chunk'>IEND</span> Image trailer</a></li> 333 </ul> 334 </li> 335 336 <li class='Contents'><a class='Href' href= 337 '#11Ancillary-chunks'>11.3 Ancillary chunks</a> 338 339 <ul> 340 <li class='Contents'><a class='Href' href='#11AcGen'>11.3.1 341 General</a></li> 342 343 <li class='Contents'><a class='Href' href='#11transinfo'>11.3.2 344 Transparency information</a> 345 346 <ul> 347 <li class='Contents'><a class='Href' href='#11tRNS'>11.3.2.1 348 <span class='chunk'>tRNS</span> Transparency</a></li> 349 </ul> 350 </li> 351 352 <li class='Contents'><a class='Href' href= 353 '#11addnlcolinfo'>11.3.3 Colour space information</a> 354 355 <ul> 356 <li class='Contents'><a class='Href' href='#11cHRM'>11.3.3.1 357 <span class='chunk'>cHRM</span> Primary chromaticities and white 358 point</a></li> 359 360 <li class='Contents'><a class='Href' href='#11gAMA'>11.3.3.2 361 <span class='chunk'>gAMA</span> Image gamma</a></li> 362 363 <li class='Contents'><a class='Href' href='#11iCCP'>11.3.3.3 364 <span class='chunk'>iCCP</span> Embedded ICC profile</a></li> 365 366 <li class='Contents'><a class='Href' href='#11sBIT'>11.3.3.4 367 <span class='chunk'>sBIT</span> Significant bits</a></li> 368 369 <li class='Contents'><a class='Href' href='#11sRGB'>11.3.3.5 370 <span class='chunk'>sRGB</span> Standard RGB colour 371 space</a></li> 372 </ul> 373 </li> 374 375 <li class='Contents'><a class='Href' href='#11textinfo'>11.3.4 376 Textual information</a> 377 378 <ul> 379 <li class='Contents'><a class='Href' href='#11textIntro'>11.3.4.1 380 Introduction</a></li> 381 382 <li class='Contents'><a class='Href' href='#11keywords'>11.3.4.2 383 Keywords and text strings</a></li> 384 385 <li class='Contents'><a class='Href' href='#11tEXt'>11.3.4.3 386 <span class='chunk'>tEXt</span> Textual data</a></li> 387 388 <li class='Contents'><a class='Href' href='#11zTXt'>11.3.4.4 389 <span class='chunk'>zTXt</span> Compressed textual data</a></li> 390 391 <li class='Contents'><a class='Href' href='#11iTXt'>11.3.4.5 392 <span class='chunk'>iTXt</span> International textual 393 data</a></li> 394 </ul> 395 </li> 396 397 <li class='Contents'><a class='Href' href='#11addnlsiinfo'>11.3.5 398 Miscellaneous information</a> 399 400 <ul> 401 <li class='Contents'><a class='Href' href='#11bKGD'>11.3.5.1 402 <span class='chunk'>bKGD</span> Background colour</a></li> 403 404 <li class='Contents'><a class='Href' href='#11hIST'>11.3.5.2 405 <span class='chunk'>hIST</span> Image histogram</a></li> 406 407 <li class='Contents'><a class='Href' href='#11pHYs'>11.3.5.3 408 <span class='chunk'>pHYs</span> Physical pixel 409 dimensions</a></li> 410 411 <li class='Contents'><a class='Href' href='#11sPLT'>11.3.5.4 412 <span class='chunk'>sPLT</span> Suggested palette</a></li> 413 </ul> 414 </li> 415 416 <li class='Contents'><a class='Href' href= 417 '#11timestampinfo'>11.3.6 Time stamp information</a> 418 419 <ul> 420 <li class='Contents'><a class='Href' href='#11tIME'>11.3.6.1 421 <span class='chunk'>tIME</span> Image last-modification 422 time</a></li> 423 424 </ul> 425 </li> 426 </ul> 427 </li> 428 </ul> 429 </li> 430 431 <li class='Contents'><a class='Href' href='#12Encoders'>12 PNG 432 Encoders</a> 433 434 <ul> 435 <li class='Contents'><a class='Href' href='#12Introduction'>12.1 436 Introduction</a></li> 437 438 <li class='Contents'><a class='Href' href= 439 '#12Encoder-gamma-handling'>12.2 Encoder gamma handling</a></li> 440 441 <li class='Contents'><a class='Href' href= 442 '#12Encoder-colour-handling'>12.3 Encoder colour 443 handling</a></li> 444 445 <li class='Contents'><a class='Href' href= 446 '#12Alpha-channel-creation'>12.4 Alpha channel creation</a></li> 447 448 <li class='Contents'><a class='Href' href= 449 '#12Sample-depth-scaling'>12.5 Sample depth scaling</a></li> 450 451 <li class='Contents'><a class='Href' href= 452 '#12Suggested-palettes'>12.6 Suggested palettes</a></li> 453 454 <li class='Contents'><a class='Href' href='#12Interlacing'>12.7 455 Interlacing</a></li> 456 457 <li class='Contents'><a class='Href' href= 458 '#12Filter-selection'>12.8 Filter selection</a></li> 459 460 <li class='Contents'><a class='Href' href='#12Compression'>12.9 461 Compression</a></li> 462 463 <li class='Contents'><a class='Href' href= 464 '#12Text-chunk-processing'>12.10 Text chunk processing</a></li> 465 466 <li class='Contents'><a class='Href' href= 467 '#12Chunk-processing'>12.11 Chunking</a> 468 469 <ul> 470 <li class='Contents'><a class='Href' href= 471 '#12Use-of-private-chunks'>12.11.1 Use of private chunks</a></li> 472 473 <li class='Contents'><a class='Href' href= 474 '#12Private-type-and-method-codes'>12.11.2 Private type and 475 method codes</a></li> 476 477 <li class='Contents'><a class='Href' href='#12Ancillary'>12.11.3 478 Ancillary chunks</a></li> 479 </ul> 480 </li> 481 </ul> 482 </li> 483 484 <li class='Contents'><a class='Href' href='#13Decoders'>13 PNG 485 decoders and viewers</a> 486 487 <ul> 488 <li class='Contents'><a class='Href' href='#13Introduction'>13.1 489 Introduction</a></li> 490 491 <li class='Contents'><a class='Href' href= 492 '#13Decoders.Errors'>13.2 Error handling</a></li> 493 494 <li class='Contents'><a class='Href' href= 495 '#13Error-checking'>13.3 Error checking</a></li> 496 497 <li class='Contents'><a class='Href' href= 498 '#13Security-considerations'>13.4 Security 499 considerations</a></li> 500 501 <li class='Contents'><a class='Href' href='#13Chunking'>13.5 502 Chunking</a></li> 503 504 <li class='Contents'><a class='Href' href= 505 '#13Pixel-dimensions'>13.6 Pixel dimensions</a></li> 506 507 <li class='Contents'><a class='Href' href= 508 '#13Text-chunk-processing'>13.7 Text chunk processing</a></li> 509 510 <li class='Contents'><a class='Href' href='#13Decompression'>13.8 511 Decompression</a></li> 512 513 <li class='Contents'><a class='Href' href='#13Filtering'>13.9 514 Filtering</a></li> 515 516 <li class='Contents'><a class='Href' href= 517 '#13Progressive-display'>13.10 Interlacing and progressive 518 display</a></li> 519 520 <li class='Contents'><a class='Href' href= 521 '#13Truecolour-image-handling'>13.11 Truecolour image 522 handling</a></li> 523 524 <li class='Contents'><a class='Href' href= 525 '#13Sample-depth-rescaling'>13.12 Sample depth rescaling</a></li> 526 527 <li class='Contents'><a class='Href' href= 528 '#13Decoder-gamma-handling'>13.13 Decoder gamma handling</a></li> 529 530 <li class='Contents'><a class='Href' href= 531 '#13Decoder-colour-handling'>13.14 Decoder colour 532 handling</a></li> 533 534 <li class='Contents'><a class='Href' href= 535 '#13Background-colour'>13.15 Background colour</a></li> 536 537 <li class='Contents'><a class='Href' href= 538 '#13Alpha-channel-processing'>13.16 Alpha channel 539 processing</a></li> 540 541 <li class='Contents'><a class='Href' href= 542 '#13Histogram-and-suggested-palette-usage'>13.17 543 Histogram and suggested palette usage</a></li> 544 </ul> 545 </li> 546 547 <li class='Contents'><a class='Href' href='#14EditorsExt'>14 548 Editors and extensions</a> 549 550 <ul> 551 <li class='Contents'><a class='Href' href= 552 '#14Additional-chunk-types'>14.1 Additional chunk types</a></li> 553 554 <li class='Contents'><a class='Href' href='#14Ordering'>14.2 555 Behaviour of PNG editors</a></li> 556 557 <li class='Contents'><a class='Href' href= 558 '#14Ordering-of-chunks'>14.3 Ordering of chunks</a> 559 560 <ul> 561 <li class='Contents'><a class='Href' href= 562 '#14Ordering-of-critical-chunks'>14.3.1 Ordering of critical 563 chunks</a></li> 564 565 <li class='Contents'><a class='Href' href= 566 '#14Ordering-of-ancillary-chunks'>14.3.2 Ordering of ancillary 567 chunks</a></li> 568 </ul> 569 </li> 570 </ul> 571 </li> 572 573 <li class='Contents'><a class='Href' href='#15Conformance'>15 574 Conformance</a> 575 576 <ul> 577 <li class='Contents'><a class='Href' href='#15ConfIntro'>15.1 578 Introduction</a> 579 580 <ul> 581 <li class='Contents'><a class='Href' href= 582 '#15ConfObjectives'>15.1.1 Objectives</a></li> 583 584 <li class='Contents'><a class='Href' href='#15ConfScope'>15.1.2 585 Scope</a></li> 586 </ul> 587 </li> 588 589 <li class='Contents'><a class='Href' href= 590 '#15ConformanceConf'>15.2 Conformance conditions</a> 591 592 <ul> 593 <li class='Contents'><a class='Href' href= 594 '#15FileConformance'>15.2.1 Conformance of PNG 595 datastreams</a></li> 596 597 <li class='Contents'><a class='Href' href= 598 '#15ConformanceEncoder'>15.2.2 Conformance of PNG 599 encoders</a></li> 600 601 <li class='Contents'><a class='Href' href= 602 '#15ConformanceDecoder'>15.2.3 Conformance of PNG 603 decoders</a></li> 604 605 <li class='Contents'><a class='Href' href= 606 '#15ConformanceEditor'>15.2.4 Conformance of PNG editors</a></li> 607 </ul> 608 </li> 609 </ul> 610 </li> 611 612 <li class='Contents'><a class='Href' href='#A-Conventions'>Annex 613 A File conventions and Internet media type</a> 614 615 <ul> 616 <li class='Contents'><a class='Href' href= 617 '#A-File-name-extension'>A.1 File name extension</a></li> 618 619 <li class='Contents'><a class='Href' href='#A-Media-type'>A.2 620 Internet media type</a></li> 621 622 <li class='Contents'><a class='Href' href= 623 '#A-Macintosh-file-layout'>A.3 Macintosh file layout</a></li> 624 </ul> 625 </li> 626 627 <li class='Contents'><a class='Href' href= 628 '#B-NewChunksAppendix'>Annex B Guidelines for new chunk 629 types</a></li> 630 631 <li class='Contents'><a class='Href' href= 632 '#C-GammaAppendix'>Annex C Gamma and chromaticity</a></li> 633 634 <li class='Contents'><a class='Href' href='#D-CRCAppendix'>Annex 635 D Sample Cyclic Redundancy Code implementation</a></li> 636 637 <li class='Contents'><a class='Href' href='#E-Resources'>Annex E 638 Online resources</a> 639 640 <ul> 641 <li class='Contents'><a class='Href' href= 642 '#E-Intro'>Introduction</a></li> 643 644 <li class='Contents'><a class='Href' href= 645 '#E-Archive-sites'>Archive sites</a></li> 646 647 <li class='Contents'><a class='Href' href= 648 '#E-icc-profile-specs'>ICC profile specifications</a></li> 649 650 <li class='Contents'><a class='Href' href='#E-PNG-home-page'>PNG 651 web site</a></li> 652 653 <li class='Contents'><a class='Href' href= 654 '#E-Sample-implementation'>Sample implementation and test 655 images</a></li> 656 657 <li class='Contents'><a class='Href' href='#E-Email'>Electronic 658 mail</a></li> 659 </ul> 660 </li> 661 662 <li class='Contents'><a class='Href' href='#F-Relationship'>Annex 663 F Relationship to W3C PNG</a> 664 665 <ul> 666 <li class='Contents'><a class='Href' href='#F-Editor10'>Editor 667 (Version 1.0)</a></li> 668 669 <li class='Contents'><a class='Href' href='#F-Editor12'>Editor 670 (Versions 1.1 and 1.2)</a></li> 671 672 <li class='Contents'><a class='Href' href= 673 '#F-ContribEditor10'>Contributing Editor (Version 1.0)</a></li> 674 675 <li class='Contents'><a class='Href' href= 676 '#F-ContribEditor12'>Contributing Editor (Versions 1.1 and 1.2)</a></li> 677 678 <li class='Contents'><a class='Href' href='#F-Authors'>Authors 679 (Versions 1.0, 1.1, and 1.2 combined)</a></li> 680 681 <li class='Contents'><a class='Href' href='#F-ChangeList'>List of 682 changes between W3C Recommendation PNG Specification Version 1.0 683 and this International Standard</a> 684 685 <ul> 686 <li class='Contents'><a class='Href' href= 687 '#F-EditorialChanges'>Editorial changes</a></li> 688 689 <li class='Contents'><a class='Href' href= 690 '#F-TechnicalChanges'>Technical changes</a></li> 691 </ul> 692 </li> 693 </ul> 694 </li> 695 696 <li class='Contents'><a class='Href' href= 697 '#G-References'>Bibliography</a></li> 698 </ul> 699 </div> 700 701 <!-- ********************************************************************* 702 703 FROM HERE ON THIS FILE IS IDENTICAL TO THE ISO VERSION 704 with these exceptions: 705 706 - id added to any headings that did not have one, to comply with pubrules and allow indexing into the document 707 - URL for this document updated in Annex E and the words " [to be completed when published]" removed 708 709 ************************************************************************** --> 710 711 <h1><a name="Introduction">Introduction</a></h1> 712 713 <p></p> 714 715 <p>The design goals for this International Standard were:</p> 716 717 <ol> 718 <li>Portability: encoding, decoding, and transmission should be 719 software and hardware platform independent.</li> 720 721 <li>Completeness: it should be possible to represent truecolour, 722 indexed-colour, and greyscale images, in each case with the 723 option of transparency, colour space information, and ancillary 724 information such as textual comments.</li> 725 726 <li>Serial encode and decode: it should be possible for 727 datastreams to be generated serially and read serially, allowing 728 the datastream format to be used for on-the-fly generation and 729 display of images across a serial communication channel.</li> 730 731 <li>Progressive presentation: it should be possible to transmit 732 datastreams so that an approximation of the whole image can be 733 presented initially, and progressively enhanced as the datastream 734 is received.</li> 735 736 <li>Robustness to transmission errors: it should be possible to 737 detect datastream transmission errors reliably.</li> 738 739 <li>Losslessness: filtering and compression should preserve all 740 information.</li> 741 742 <li>Performance: any filtering, compression, and progressive 743 image presentation should be aimed at efficient decoding and 744 presentation. Fast encoding is a less important goal than fast 745 decoding. Decoding speed may be achieved at the expense of 746 encoding speed.</li> 747 748 <li>Compression: images should be compressed effectively, 749 consistent with the other design goals.</li> 750 751 <li>Simplicity: developers should be able to implement the 752 standard easily.</li> 753 754 <li>Interchangeability: any standard-conforming PNG decoder shall 755 be capable of reading all conforming PNG datastreams.</li> 756 757 <li>Flexibility: future extensions and private additions should 758 be allowed for without compromising the interchangeability of 759 standard PNG datastreams.</li> 760 761 <li>Freedom from legal restrictions: no algorithms should be used 762 that are not freely available.</li> 763 </ol> 764 765 766 <h1><a name="1Scope">1 Scope</a></h1> 767 768 <p>This International Standard specifies a datastream and an 769 associated file format, Portable Network Graphics (PNG, 770 pronounced "ping"), for a lossless, portable, compressed 771 individual computer graphics image transmitted across the 772 Internet. Indexed-colour, greyscale, and truecolour images are 773 supported, with optional transparency. Sample depths range from 1 774 to 16 bits. PNG is fully streamable with a progressive display 775 option. It is robust, providing both full file integrity checking 776 and simple detection of common transmission errors. PNG can store 777 gamma and chromaticity data as well as a full ICC colour profile 778 for accurate colour matching on heterogenous platforms. This 779 Standard defines the Internet Media type "image/png". The 780 datastream and associated file format have value outside of the 781 main design goal.</p> 782 783 <!-- ************Page Break******************* --> 784 <!-- ************Page Break******************* --> 785 <h1><a name="2NormRefs">2 Normative references</a></h1> 786 787 <p>The following normative documents contain provisions which, 788 through reference in this text, constitute provisions of this 789 International Standard. For dated references, subsequent 790 amendments to, or revisions of, any of these publications do not 791 apply. However, parties to agreements based on this International 792 Standard are encouraged to investigate the possibility of 793 applying the most recent editions of the normative documents 794 indicated below. For undated references, the latest edition of 795 the normative document referred to applies. Members of ISO and 796 IEC maintain registers of currently valid International 797 Standards.</p> 798 799 <p class="NormRefDef"><a name="2-ISO-639">ISO 639:1988</a>, 800 <i>Code for the representation of names of languages</i>.</p> 801 802 <p class="NormRefDef"><a name="2-ISO-646">ISO/IEC 646:1991</a>, 803 <i>International Organization for Standardization, Information 804 technology — ISO 7-bit coded character set for information 805 interchange</i>.</p> 806 807 <p class="NormRefDef"><a name="2-ISO-3309">ISO/IEC 3309:1993</a>, 808 <i>Information Technology — Telecommunications and 809 information exchange between systems — High-level data link 810 control (HDLC) procedures — Frame structure</i>.</p> 811 812 <p class="NormRefDef"><a name="2-ISO-8859-1">ISO/IEC 813 8859-1:1998</a>, <i>Information technology — 8-bit 814 single-byte coded graphic character sets — Part 1: Latin 815 alphabet No. 1</i>.<br class="xhtml" /> 816 For convenience, here is a non-normative <a href="iso_8859-1.txt">sample text file</a> 817 describing the codes and associated character names.</p> 818 819 <p class="NormRefDef"><a name="2-ISO-9899">ISO/IEC 820 9899:1990(R1997)</a>, <i>Programming languages — C</i>.</p> 821 822 <p class="NormRefDef"><a name="2-ISO-10646-1">ISO/IEC 823 10646-1:1993/AMD.2</a>, <i>Information technology — 824 Universal Multiple-Octet Coded Character Sets (UCS) — Part 825 1: Architecture and Basic Multilingual Plane</i>.</p> 826 827 <p class="NormRefDef"><a name="2-IEC-61966-2-1">IEC 828 61966-2-1</a>, <i>Multimedia systems and equipment — Colour 829 measurement and management — Part 2-1: Default RGB colour 830 space — sRGB,</i> available at <code><a href= 831 "http://www.iec.ch">http://www.iec.ch/</a></code>.</p> 832 833 <p class="NormRefDef"><a name="2-CIE-15.2">CIE-15.2</a>, CIE, 834 "Colorimetry, Second Edition". CIE Publication 15.2-1986. ISBN 835 3-900-734-00-3.</p> 836 837 <p class="NormRefDef"><a name="2-ICC-1">ICC-1</a>, International 838 Color Consortium, "Specification ICC.1: 1998-09, File Format for 839 Color Profiles", 1998, available at <code><a href= 840 "http://www.color.org/">http://www.color.org/</a></code></p> 841 842 <p class="NormRefDef"><a name="2-ICC-1A">ICC-1A</a>, 843 International Color Consortium, "Specification ICC.1A: 1999-04, 844 Addendum 2 to ICC.1: 1998-09", 1999, available at <code><a href= 845 "http://www.color.org/">http://www.color.org/</a></code></p> 846 847 <p class="NormRefDef"><a name="2-RFC-1123">RFC-1123</a>, Braden, 848 R., Editor, "Requirements for Internet Hosts — Application 849 and Support", STD 3, RFC 1123, USC/Information Sciences 850 Institute, October 1989.<br class="xhtml" /> 851 <code><a href= 852 "http://www.ietf.org/rfc/rfc1123.txt">http://www.ietf.org/rfc/rfc1123.txt</a></code></p> 853 854 <p class="NormRefDef"><a name="2-RFC-1950">RFC-1950</a>, Deutsch, 855 P. and Gailly, J-L., "ZLIB Compressed Data Format Specification 856 version 3.3", RFC 1950, Aladdin Enterprises, May 1996.<br class="xhtml" /> 857 <code><a href= 858 "http://www.ietf.org/rfc/rfc1950.txt">http://www.ietf.org/rfc/rfc1950.txt</a></code></p> 859 860 <p class="NormRefDef"><a name="2-RFC-1951">RFC-1951</a>, Deutsch, 861 P., "DEFLATE Compressed Data Format Specification version 1.3", 862 RFC 1951, Aladdin Enterprises, May 1996.<br class="xhtml" /> 863 <code><a href= 864 "http://www.ietf.org/rfc/rfc1951.txt">http://www.ietf.org/rfc/rfc1951.txt</a></code></p> 865 866 <p class="NormRefDef"><a name="2-RFC-2045">RFC-2045</a>, Freed, 867 N. and Borenstein, N. , "MIME (Multipurpose Internet Mail 868 Extensions) Part One: Format of Internet Message Bodies", RFC 869 2045, Innosoft, First Virtual, November 1996.<br class="xhtml" /> 870 <code><a href= 871 "http://www.ietf.org/rfc/rfc2045.txt">http://www.ietf.org/rfc/rfc2045.txt</a></code></p> 872 873 <p class="NormRefDef"><a name="2-RFC-2048">RFC-2048</a>, Freed, 874 N., Klensin, J. and Postel, J., "Multipurpose Internet Mail 875 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 876 Innosoft, MCI, ISI, November 1996.<br class="xhtml" /> 877 <code><a href= 878 "http://www.ietf.org/rfc/rfc2048.txt">http://www.ietf.org/rfc/rfc2048.txt</a></code></p> 879 880 <p class="NormRefDef"><a name="2-RFC-3066">RFC-3066</a>, 881 Alvestrand, H., "Tags for the Identification of Languages", RFC 882 3066, Cisco Systems, January 2001. (Obsoletes RFC 1766.)<br class="xhtml" /> 883 <code><a href= 884 "http://www.ietf.org/rfc/rfc3066.txt">http://www.ietf.org/rfc/rfc3066.txt</a></code></p> 885 886 <!-- ************Page Break******************* --> 887 <!-- ************Page Break******************* --> 888 <h1><a name="3Defsandabbrevs">3 Terms, definitions, and 889 abbreviated terms</a></h1> 890 891 <h2><a name="3Definitions">3.1 Definitions</a></h2> 892 893 <p>For the purposes of this International Standard the following 894 definitions apply.</p> 895 896 <dl> 897 <dt><a name="3alpha">3.1.1 alpha</a></dt> 898 899 <dd>a value representing a <a href="#3pixel"><span class= 900 "Definition">pixel's</span></a> degree of opacity. The more 901 opaque a pixel, the more it hides the background against which 902 the image is presented. Zero alpha represents a completely 903 transparent pixel, maximum alpha represents a completely opaque 904 pixel.</dd> 905 906 <dt><a name="3alphaCompaction">3.1.2 alpha compaction</a></dt> 907 908 <dd>an implicit representation of transparent <a href= 909 "#3pixel"><span class="Definition">pixels</span></a>. If every 910 pixel with a specific colour or <a href="#3greyscale"><span 911 class="Definition">greyscale</span></a> value is fully 912 transparent and all other pixels are fully opaque, the <a href= 913 "#3alpha"><span class="Definition">alpha</span></a> <a href= 914 "#3channel"><span class="Definition">channel</span></a> may be 915 represented implicitly.</dd> 916 917 <dt><a name="3alphaSeparation">3.1.3 alpha separation</a></dt> 918 919 <dd>separating an <a href="#3alpha"><span class= 920 "Definition">alpha</span></a> <a href="#3channel"><span class= 921 "Definition">channel</span></a> in which every <a href= 922 "#3pixel"><span class="Definition">pixel</span></a> is fully 923 opaque; all alpha values are the maximum value. 924 The fact that all pixels are fully opaque is represented implicitly. 925 </dd> 926 927 <dt><a name="3alphaTable">3.1.4 alpha table</a></dt> 928 929 <dd>indexed table of <a href="#3alpha"><span class= 930 "Definition">alpha</span></a> <a href="#3sample"><span class= 931 "Definition">sample</span></a> values, which in an <a href= 932 "#3indexedColour"><span class= 933 "Definition">indexed-colour</span></a> image defines the alpha 934 sample values of the <a href="#3referenceImage"><span class= 935 "Definition">reference image</span></a>. The alpha table has the 936 same number of entries as the <a href="#3palette"><span class= 937 "Definition">palette</span></a>.</dd> 938 939 <dt><a name="3ancillaryChunk">3.1.5 ancillary chunk</a></dt> 940 941 <dd>class of <a href="#3chunk"><span class= 942 "Definition">chunk</span></a> that provides additional 943 information. A <a href="#3PNGdecoder"><span class= 944 "Definition">PNG decoder</span></a>, without processing an 945 ancillary chunk, can still produce a meaningful image, though not 946 necessarily the best possible image. 947 <!-- agreed: don't need to define a bit --> 948 </dd> 949 950 <dt><a name="3bitDepth">3.1.6 bit depth</a></dt> 951 952 <dd>for <a href="#3indexedColour"><span class= 953 "Definition">indexed-colour</span></a> images, the number of bits 954 per <a href="#3palette"><span class= 955 "Definition">palette</span></a> index. For other images, the 956 number of bits per <a href="#3sample"><span class= 957 "Definition">sample</span></a> in the image. This is the value 958 that appears in the <a href="#11IHDR"><span class= 959 "chunk">IHDR</span></a> <a href="#3chunk"><span class= 960 "Definition">chunk</span></a>.</dd> 961 962 <dt><a name="3byte">3.1.7 byte</a></dt> 963 964 <dd>8 bits; also called an octet. The highest bit (value 128) of 965 a byte is numbered bit 7; the lowest bit (value 1) is numbered 966 bit 0.</dd> 967 968 <dt><a name="3byteOrder">3.1.8 byte order</a></dt> 969 970 <dd>ordering of <a href="#3byte"><span class= 971 "Definition">bytes</span></a> for multi-byte data values within a 972 <a href="#3PNGfile"><span class="Definition">PNG file</span></a> 973 or <a href="#3PNGdatastream"><span class="Definition">PNG 974 datastream</span></a>. PNG uses <a href= 975 "#3networkByteOrder"><span class="Definition">network byte 976 order</span></a>.</dd> 977 978 <dt><a name="3channel">3.1.9 channel</a></dt> 979 980 <dd>array of all per-<a href="#3pixel"><span class= 981 "Definition">pixel</span></a> information of a particular kind 982 within a <a href="#3referenceImage"><span class= 983 "Definition">reference image</span></a>. There are five kinds of 984 information: red, green, blue, <a href="#3greyscale"><span class= 985 "Definition">greyscale</span></a>, and <a href="#3alpha"><span 986 class="Definition">alpha</span></a>. For example the alpha 987 channel is the array of alpha values within a reference 988 image.</dd> 989 990 <dt><a name="3chromaticity">3.1.10 chromaticity (CIE)</a></dt> 991 992 <dd>pair of values <i>x,y</i> that precisely specify a colour, 993 except for the brightness information.</dd> 994 995 <dt><a name="3chunk">3.1.11 chunk</a></dt> 996 997 <dd>section of a <a href="#3PNGdatastream"><span class= 998 "Definition">PNG datastream</span></a>. Each chunk has a chunk 999 type. Most chunks also include data. The format and meaning of 1000 the data within the chunk are determined by the chunk type. 1001 Each chunk is either a 1002 <a href="#3criticalChunk"><span class= 1003 "Definition">critical chunk</span></a> or an <a href= 1004 "#3ancillaryChunk"><span class= 1005 "Definition">ancillary chunk</span></a>. 1006 </dd> 1007 1008 <dt><a name="3colourType">3.1.12 colour type</a></dt> 1009 1010 <dd>value denoting how colour and <a href="#3alpha"><span class= 1011 "Definition">alpha</span></a> are specified in the <a href= 1012 "#3PNGimage"><span class="Definition">PNG image</span></a>. 1013 Colour types are sums of the following values: 1 (<a href= 1014 "#3palette"><span class="Definition">palette</span></a> used), 2 1015 (<a href="#3truecolour"><span class= 1016 "Definition">truecolour</span></a> used), 4 (alpha used). The 1017 permitted values of colour type are 0, 2, 3, 4, and 6.</dd> 1018 1019 <dt><a name="3composite">3.1.13 composite (verb)</a></dt> 1020 1021 <dd>to form an image by merging a foreground image and a 1022 background image, using transparency information to determine 1023 where and to what extent the background should be visible. The 1024 foreground image is said to be "composited against" the 1025 background.</dd> 1026 1027 <dt><a name="3criticalChunk">3.1.14 critical chunk</a></dt> 1028 1029 <dd><a href="#3chunk"><span class="Definition">chunk</span></a> 1030 that <!--must be understood and processed by the decoder--> 1031 shall be understood and processed by the decoder in order to 1032 produce a meaningful image from a <a href="#3PNGdatastream"><span 1033 class="Definition">PNG datastream</span></a>.</dd> 1034 1035 <dt><a name="3datastream">3.1.15 datastream</a></dt> 1036 1037 <dd>sequence of <a href="#3byte"><span class= 1038 "Definition">bytes</span></a>. This term is used rather than 1039 "file" to describe a byte sequence that may be only a portion of 1040 a file. It is also used to emphasize that the sequence of bytes 1041 might be generated and consumed "on the fly", never appearing in 1042 a stored file at all.</dd> 1043 1044 <dt><a name="3deflate">3.1.16 deflate</a></dt> 1045 1046 <dd>name of a particular compression algorithm. This algorithm is 1047 used, in compression mode 0, in conforming <a href= 1048 "#3PNGdatastream"><span class="Definition">PNG 1049 datastreams</span></a>. Deflate is a member of the <a href= 1050 "#3LZ77"><span class="Definition">LZ77</span></a> family of 1051 compression methods. It is defined in <a href="#2-RFC-1951"><span 1052 class="NormRef">[RFC-1951]</span></a>.</dd> 1053 1054 1055 <!-- ************Page Break******************* --> 1056 <!-- ************Page Break******************* --> 1057 1058 <dt><a name="3deliveredImage">3.1.17 delivered image</a></dt> 1059 1060 <dd>image constructed from a decoded <a href= 1061 "#3PNGdatastream"><span class="Definition">PNG 1062 datastream</span></a>.</dd> 1063 1064 <dt><a name="3filter">3.1.18 filter</a></dt> 1065 1066 <dd>transformation applied to an array of <a href= 1067 "#3scanline"><span class="Definition">scanlines</span></a> with 1068 the aim of improving their compressibility. PNG uses only 1069 lossless (reversible) filter algorithms.</dd> 1070 1071 <dt><a name="3frameBuffer">3.1.19 frame buffer</a></dt> 1072 1073 <dd>the final digital storage area for the image shown by most 1074 types of computer display. Software causes an image to appear on 1075 screen by loading the image into the frame buffer.</dd> 1076 1077 <dt><a name="3gamma">3.1.20 gamma</a></dt> 1078 1079 <dd>exponent that describes approximations to certain non-linear 1080 transfer functions encountered in image capture and reproduction. 1081 Within this International Standard, gamma is the exponent in the 1082 transfer function from <tt>display_output</tt> to 1083 <tt>image_sample</tt> 1084 <pre> 1085 <tt>image_sample = display_output<sup>gamma</sup></tt> 1086 </pre> 1087 where both <tt>display_output</tt> and <tt>image_sample</tt> 1088 are scaled to the range 0 to 1. 1089 </dd> 1090 1091 <dt><a name="3greyscale">3.1.21 greyscale</a></dt> 1092 1093 <dd>image representation in which each <a href="#3pixel"><span 1094 class="Definition">pixel</span></a> is defined by a single <a 1095 href="#3sample"><span class="Definition">sample</span></a> of 1096 colour information, representing overall <a href= 1097 "#3luminance"><span class="Definition">luminance</span></a> (on a 1098 scale from black to white), and optionally an <a href= 1099 "#3alpha"><span class="Definition">alpha</span></a> sample (in 1100 which case it is called greyscale with alpha).</dd> 1101 1102 <dt><a name="3imageData">3.1.22 image data</a></dt> 1103 1104 <dd>1-dimensional array of <a href="#3scanline"><span class= 1105 "Definition">scanlines</span></a> within an image.</dd> 1106 1107 <dt><a name="3indexedColour">3.1.23 indexed-colour</a></dt> 1108 1109 <dd>image representation in which each <a href="#3pixel"><span 1110 class="Definition">pixel</span></a> of the original image is 1111 represented by a single index into a <a href="#3palette"><span 1112 class="Definition">palette</span></a>. The selected palette entry 1113 defines the actual colour of the pixel.</dd> 1114 1115 <dt><a name="3indexing">3.1.24 indexing</a></dt> 1116 1117 <dd>representing an image by a <a href="#3palette"><span class= 1118 "Definition">palette</span></a>, an <a href="#3alphaTable"><span 1119 class="Definition">alpha table</span></a>, and an array of 1120 indices pointing to entries in the palette and alpha table.</dd> 1121 1122 <dt><a name="3interlacedPNGimage">3.1.25 interlaced PNG 1123 image</a></dt> 1124 1125 <dd>sequence of <a href="#3reducedImage"><span class= 1126 "Definition">reduced images</span></a> generated from the <a 1127 href="#3PNGimage"><span class="Definition">PNG image</span></a> 1128 by <a href="#3passExtraction"><span class="Definition">pass 1129 extraction</span></a>.</dd> 1130 1131 <dt><a name="3losslessCompression">3.1.26 lossless 1132 compression</a></dt> 1133 1134 <dd>method of data compression that permits reconstruction of the 1135 original data exactly, bit-for-bit.</dd> 1136 1137 <dt><a name="3lossyCompression">3.1.27 lossy compression</a></dt> 1138 1139 <dd>method of data compression that permits reconstruction of the 1140 original data approximately, rather than exactly.</dd> 1141 1142 <dt><a name="3luminance">3.1.28 luminance</a></dt> 1143 1144 <dd>formal definition of luminance is in <a href= 1145 "#2-CIE-15.2"><span class="NormRef">[CIE-15.2]</span></a>. 1146 Informally it is the perceived brightness, or <a href= 1147 "#3greyscale"><span class="Definition">greyscale</span></a> 1148 level, of a colour. Luminance and <a href="#3chromaticity"><span 1149 class="Definition">chromaticity</span></a> together fully define 1150 a perceived colour.</dd> 1151 1152 <dt><a name="3LZ77">3.1.29 LZ77</a></dt> 1153 1154 <dd>data compression algorithm described by Ziv and Lempel in 1155 their 1977 paper <a href="#G-ZL"><span class= 1156 "bibref">[ZL]</span></a>.</dd> 1157 1158 <dt><a name="3networkByteOrder">3.1.30 network byte 1159 order</a></dt> 1160 1161 <dd><a href="#3byteOrder"><span class="Definition">byte 1162 order</span></a> in which the most significant byte comes first, 1163 then the less significant bytes in descending order of 1164 significance (<a href="#3MSB"><span class= 1165 "Definition">MSB</span></a> <a href="#3LSB"><span class= 1166 "Definition">LSB</span></a> for two-byte integers, <a href= 1167 "#3MSB"><span class="Definition">MSB</span></a> B2 B1 <a href= 1168 "#3LSB"><span class="Definition">LSB</span></a> for four-byte 1169 integers).</dd> 1170 1171 <dt><a name="3palette">3.1.31 palette</a></dt> 1172 1173 <dd>indexed table of three 8-bit <a href="#3sample"><span class= 1174 "Definition">sample</span></a> values, red, green, and blue, 1175 which with an <a href="#3indexedColour"><span class= 1176 "Definition">indexed-colour</span></a> image defines the red, 1177 green, and blue sample values of the <a href= 1178 "#3referenceImage"><span class="Definition">reference 1179 image</span></a>. In other cases, the palette may be a suggested 1180 palette that viewers may use to present the image on 1181 indexed-colour display hardware. <a href="#3alpha"><span class= 1182 "Definition">Alpha</span></a> samples may be defined for palette 1183 entries via the <a href="#3alphaTable"><span class= 1184 "Definition">alpha table</span></a> and may be used to 1185 reconstruct the alpha sample values of the reference image.</dd> 1186 1187 <dt><a name="3passExtraction">3.1.32 pass extraction</a></dt> 1188 1189 <dd>organizing a <a href="#3PNGimage"><span class= 1190 "Definition">PNG image</span></a> as a sequence of <a href= 1191 "#3reducedImage"><span class="Definition">reduced 1192 images</span></a> to change the order of transmission and enable 1193 progressive display.</dd> 1194 1195 <dt><a name="3pixel">3.1.33 pixel</a></dt> 1196 1197 <dd>information stored for a single grid point in an image. A 1198 pixel consists of (or points to) a sequence of <a href="#3sample"><span class= 1199 "Definition">samples</span></a> from all <a href= 1200 "#3channel"><span class="Definition">channels</span></a>. The 1201 complete image is a rectangular array of pixels.</dd> 1202 1203 1204 <!-- ************Page Break******************* --> 1205 <!-- ************Page Break******************* --> 1206 1207 <dt><a name="3PNGdatastream">3.1.34 PNG datastream</a></dt> 1208 1209 <dd>result of encoding a <a href="#3PNGimage"><span class= 1210 "Definition">PNG image</span></a>. A PNG <a href= 1211 "#3datastream"><span class="Definition">datastream</span></a> 1212 consists of a <a href="#3PNGsignature"><span class= 1213 "Definition">PNG signature</span></a> followed by a sequence of 1214 <a href="#3chunk"><span class= 1215 "Definition">chunks</span></a>.</dd> 1216 1217 <dt><a name="3PNGdecoder">3.1.35 PNG decoder</a></dt> 1218 1219 <dd>process or device which reconstructs the <a href= 1220 "#3referenceImage"><span class="Definition">reference 1221 image</span></a> from a <a href="#3PNGdatastream"><span class= 1222 "Definition">PNG datastream</span></a> and generates a 1223 corresponding delivered image.</dd> 1224 1225 <dt><a name="3PNGeditor">3.1.36 PNG editor</a></dt> 1226 1227 <dd>process or device which creates a modification of an existing 1228 <a href="#3PNGdatastream"><span class="Definition">PNG 1229 datastream</span></a>, preserving unmodified ancillary 1230 information wherever possible, and obeying the <a href= 1231 "#3chunk"><span class="Definition">chunk</span></a> ordering 1232 rules, even for unknown chunk types.</dd> 1233 1234 <dt><a name="3PNGencoder">3.1.37 PNG encoder</a></dt> 1235 1236 <dd>process or device which constructs a <a href= 1237 "#3referenceImage"><span class="Definition">reference 1238 image</span></a> from a <a href="#3sourceImage"><span class= 1239 "Definition">source image</span></a>, and generates a <a href= 1240 "#3PNGdatastream"><span class="Definition">PNG 1241 datastream</span></a> representing the reference image.</dd> 1242 1243 <dt><a name="3PNGfile">3.1.38 PNG file</a></dt> 1244 1245 <dd><a href="#3PNGdatastream"><span class="Definition">PNG 1246 datastream</span></a> stored as a file.</dd> 1247 1248 <dt><a name="3PNGfourByteSignedInteger">3.1.39 PNG four-byte 1249 signed integer</a></dt> 1250 1251 <dd>a four-byte signed integer limited to the range 1252 -(2<sup>31</sup>-1) to 2<sup>31</sup>-1. The restriction is 1253 imposed in order to accommodate languages that have difficulty 1254 with the value -2<sup>31</sup>.</dd> 1255 1256 <dt><a name="3PNGfourByteUnSignedInteger">3.1.40 PNG four-byte 1257 unsigned integer</a></dt> 1258 1259 <dd>a four-byte unsigned integer limited to the range 0 to 1260 2<sup>31</sup>-1. The restriction is imposed in order to 1261 accommodate languages that have difficulty with unsigned 1262 four-byte values.</dd> 1263 1264 <dt><a name="3PNGimage">3.1.41 PNG image</a></dt> 1265 1266 <dd>result of transformations applied by a <a href= 1267 "#3PNGencoder"><span class="Definition">PNG encoder</span></a> to 1268 a <a href="#3referenceImage"><span class="Definition">reference 1269 image</span></a>, in preparation for encoding as a <a href= 1270 "#3PNGdatastream"><span class="Definition">PNG 1271 datastream</span></a>, and the result of decoding a PNG 1272 datastream.</dd> 1273 1274 <dt><a name="3PNGsignature">3.1.42 PNG signature</a></dt> 1275 1276 <dd>sequence of <a href="#3byte"><span class= 1277 "Definition">bytes</span></a> appearing at the start of every <a 1278 href="#3PNGdatastream"><span class="Definition">PNG 1279 datastream</span></a>. It differentiates a PNG datastream from 1280 other types of <a href="#3datastream"><span class= 1281 "Definition">datastream</span></a> and allows early detection of 1282 some transmission errors.</dd> 1283 1284 <dt><a name="3reducedImage">3.1.43 reduced image</a></dt> 1285 1286 <dd>pass of the <a href="#3interlacedPNGimage"><span class= 1287 "Definition">interlaced PNG image</span></a> extracted from the 1288 <a href="#3PNGimage"><span class="Definition">PNG 1289 image</span></a> by <a href="#3passExtraction"><span class= 1290 "Definition">pass extraction</span></a>.</dd> 1291 1292 <dt><a name="3referenceImage">3.1.44 reference image</a></dt> 1293 1294 <dd>rectangular array of rectangular <a href="#3pixel"><span 1295 class="Definition">pixels</span></a>, each having the same number 1296 of <a href="#3sample"><span class= 1297 "Definition">samples</span></a>, either three (red, green, blue) 1298 or four (red, green, blue, <a href="#3alpha"><span class= 1299 "Definition">alpha</span></a>). Every reference image can be 1300 represented exactly by a <a href="#3PNGdatastream"><span class= 1301 "Definition">PNG datastream</span></a> and every PNG datastream 1302 can be converted into a reference image. Each <a href= 1303 "#3channel"><span class="Definition">channel</span></a> has a <a 1304 href="#3sampleDepth"><span class="Definition">sample 1305 depth</span></a> in the range 1 to 16. All samples in the same 1306 channel have the same sample depth. Different channels may have 1307 different sample depths.</dd> 1308 1309 <dt><a name="3RGBmerging">3.1.45 RGB merging</a></dt> 1310 1311 <dd>converting an image in which the red, green, and blue <a 1312 href="#3sample"><span class="Definition">samples</span></a> for 1313 each <a href="#3pixel"><span class="Definition">pixel</span></a> 1314 have the same value, and the same <a href="#3sampleDepth"><span 1315 class="Definition">sample depth</span></a>, into an image with a 1316 single <a href="#3greyscale"><span class= 1317 "Definition">greyscale</span></a> <a href="#3channel"><span 1318 class="Definition">channel</span></a>.</dd> 1319 1320 <dt><a name="3sample">3.1.46 sample</a></dt> 1321 1322 <dd>intersection of a <a href="#3channel"><span class= 1323 "Definition">channel</span></a> and a <a href="#3pixel"><span 1324 class="Definition">pixel</span></a> in an image.</dd> 1325 1326 <dt><a name="3sampleDepth">3.1.47 sample depth</a></dt> 1327 1328 <dd>number of bits used to represent a <a href="#3sample"><span 1329 class="Definition">sample</span></a> value. In an <a href= 1330 "#3indexedColour"><span class= 1331 "Definition">indexed-colour</span></a> <a href="#3PNGimage"><span 1332 class="Definition">PNG image</span></a>, samples are stored in 1333 the <a href="#3palette"><span class= 1334 "Definition">palette</span></a> and thus the sample depth is 1335 always 8 by definition of the palette. In other types of PNG 1336 image it is the same as the <a href="#3bitDepth"><span class= 1337 "Definition">bit depth</span></a>.</dd> 1338 1339 <dt><a name="3sampleDepthScaling">3.1.48 sample depth 1340 scaling</a></dt> 1341 1342 <dd>mapping of a range of <a href="#3sample"><span class= 1343 "Definition">sample</span></a> values onto the full range of a <a 1344 href="#3sampleDepth"><span class="Definition">sample 1345 depth</span></a> allowed in a <a href="#3PNGimage"><span class= 1346 "Definition">PNG image</span></a>.</dd> 1347 1348 <dt><a name="3scanline">3.1.49 scanline</a></dt> 1349 1350 <dd>row of <a href="#3pixel"><span class= 1351 "Definition">pixels</span></a> within an image or <a href= 1352 "#3interlacedPNGimage"><span class="Definition">interlaced PNG 1353 image</span></a>.</dd> 1354 1355 <dt><a name="3sourceImage">3.1.50 source image</a></dt> 1356 1357 <dd>image which is presented to a <a href="#3PNGencoder"><span 1358 class="Definition">PNG encoder</span></a>.</dd> 1359 1360 <dt><a name="3truecolour">3.1.51 truecolour</a></dt> 1361 1362 <dd>image representation in which each <a href="#3pixel"><span 1363 class="Definition">pixel</span></a> is defined by <a href= 1364 "#3sample"><span class="Definition">samples</span></a>, 1365 representing red, green, and blue intensities and optionally an 1366 <a href="#3alpha"><span class="Definition">alpha</span></a> 1367 sample (in which case it is referred to as truecolour with 1368 alpha).</dd> 1369 1370 <dt><a name="3whitePoint">3.1.52 white point</a></dt> 1371 1372 <dd><a href="#3chromaticity"><span class= 1373 "Definition">chromaticity</span></a> of a computer display's 1374 nominal white value.</dd> 1375 1376 <dt><a name="3zlib">3.1.53 zlib</a></dt> 1377 1378 <dd>particular format for data that have been compressed using <a 1379 href="#3deflate"><span class= 1380 "Definition">deflate</span></a>-style compression. Also the name 1381 of a library containing a sample implementation of this method. 1382 The format is defined in <a href="#2-RFC-1950"><span class= 1383 "NormRef">[RFC-1950]</span></a>.</dd> 1384 </dl> 1385 1386 <!-- ************Page Break******************* --> 1387 <!-- ************Page Break******************* --> 1388 <h2><a name="3Abbreviations">3.2 Abbreviated terms</a></h2> 1389 1390 <dl> 1391 <dt><a name="3CRC">3.2.1 CRC</a></dt> 1392 1393 <dd>Cyclic Redundancy Code. A CRC is a type of check value 1394 designed to detect most transmission errors. A decoder calculates 1395 the CRC for the received data and checks by comparing it to the 1396 CRC calculated by the encoder and appended to the data. 1397 A mismatch 1398 indicates that the data or the CRC were corrupted in 1399 transit.</dd> 1400 1401 <dt><a name="3CRT">3.2.2 CRT</a></dt> 1402 1403 <dd>Cathode Ray Tube: a common type of computer display 1404 hardware.</dd> 1405 1406 <dt><a name="3LSB">3.2.2 LSB</a></dt> 1407 1408 <dd>Least Significant Byte of a multi-<a href="#3byte"><span 1409 class="Definition">byte</span></a> value.</dd> 1410 1411 <dt><a name="3LUT">3.2.3 LUT</a></dt> 1412 1413 <dd>Look Up Table. In <a href="#3frameBuffer"><span class= 1414 "Definition">frame buffer</span></a> hardware, a LUT can be used 1415 to map <a href="#3indexedColour"><span class= 1416 "Definition">indexed-colour</span></a> <a href="#3pixel"><span 1417 class="Definition">pixels</span></a> into a selected set of <a 1418 href="#3truecolour"><span class= 1419 "Definition">truecolour</span></a> values, or to perform <a href= 1420 "#3gamma"><span class="Definition">gamma</span></a> correction. 1421 In software, a LUT can often be used as a fast way of 1422 implementing any mathematical function of a single integer 1423 variable.</dd> 1424 1425 <dt><a name="3MSB">3.2.4 MSB</a></dt> 1426 1427 <dd>Most Significant Byte of a multi-<a href="#3byte"><span 1428 class="Definition">byte</span></a> value.</dd> 1429 </dl> 1430 1431 <!-- ************Page Break******************* --> 1432 <!-- ************Page Break******************* --> 1433 <h1><a name="4Concepts">4 Concepts</a></h1> 1434 1435 <h2><a name="4Concepts.Sourceimage">4.1 Images</a></h2> 1436 1437 <p>This International Standard specifies the PNG datastream, and 1438 places some requirements on PNG encoders, which generate PNG 1439 datastreams, PNG decoders, which interpret PNG datastreams, and 1440 PNG editors, which transform one PNG datastream into another. It 1441 does not specify the interface between an application and either 1442 a PNG encoder, decoder, or editor. The precise form in which an 1443 image is presented to an encoder or delivered by a decoder is not 1444 specified. Four kinds of image are distinguished.</p> 1445 1446 <ol> 1447 <li>The <i>source image</i> is the image presented to a PNG 1448 encoder.</li> 1449 1450 <li>The <i>reference image</i>, which only exists conceptually, 1451 is a rectangular array of rectangular pixels, all having the same 1452 width and height, and all containing the same number of unsigned 1453 integer samples, either three (red, green, blue) or four (red, 1454 green, blue, alpha). The array of all samples of a particular 1455 kind (red, green, blue, or alpha) is called a channel. Each 1456 channel has a sample depth in the range 1 to 16, which is the 1457 number of bits used by every sample in the channel. Different 1458 channels may have different sample depths. The red, green, and 1459 blue samples determine the intensities of the red, green, and 1460 blue components of the pixel's colour; if they are all zero, the 1461 pixel is black, and if they all have their maximum values 1462 (2<sup>sampledepth</sup>-1), the pixel is white. The alpha sample 1463 determines a pixel's degree of opacity, where zero means fully 1464 transparent and the maximum value means fully opaque. In a 1465 three-channel reference image all pixels are fully opaque. (It is 1466 also possible for a four-channel reference image to have all 1467 pixels fully opaque; the difference is that the latter has a 1468 specific alpha sample depth, whereas the former does not.) Each 1469 horizontal row of pixels is called a scanline. Pixels are ordered 1470 from left to right within each scanline, and scanlines are 1471 ordered from top to bottom. A PNG encoder may transform the source 1472 image directly into a PNG image, but conceptually it first 1473 transforms the source image into a reference image, then 1474 transforms the reference image into a PNG image. Depending on the 1475 type of source image, the transformation from the source image to 1476 a reference image may require the loss of information. That 1477 transformation is beyond the scope of this International 1478 Standard. The reference image, however, can always be recovered 1479 exactly from a PNG datastream.</li> 1480 1481 <li>The <i>PNG image</i> is obtained from the reference image by 1482 a series of transformations: alpha separation, indexing, RGB 1483 merging, alpha compaction, and sample depth scaling. Five types 1484 of PNG image are defined (see 6.1: <a href= 1485 "#6Colour-values"><span class="xref">Colour types and 1486 values</span></a>). (If the PNG encoder actually transforms the 1487 source image directly into the PNG image, and the source image 1488 format is already similar to the PNG image format, the encoder 1489 may be able to avoid doing some of these transformations.) 1490 Although not all sample depths in the range 1 to 16 bits are 1491 explicitly supported in the PNG image, the number of significant 1492 bits in each channel of the reference image may be recorded. All 1493 channels in the PNG image have the same sample depth. A PNG 1494 encoder generates a PNG datastream from the PNG image. A PNG 1495 decoder takes the PNG datastream and recreates the PNG 1496 image.</li> 1497 1498 <li>The <i>delivered image</i> is constructed from the PNG image 1499 obtained by decoding a PNG datastream. No specific format is 1500 specified for the delivered image. A viewer presents an image to 1501 the user as close to the appearance of the original source image 1502 as it can achieve.</li> 1503 </ol> 1504 1505 <p>The relationships between the four kinds of image are 1506 illustrated in <a href="#figure41"><span class="figref">figure 1507 4.1</span></a>.</p> 1508 1509 <p><a name="figure41"> 1510 <object data="figures/fig41.svg" type="image/svg+xml" width="640" height="290"> 1511 <img height="280" width="640" src="png-figures/fig41.png" alt="Figure 4.1: Relationships between 1512 source, reference, PNG, and display images" /> 1513 </object> 1514 </a></p> 1515 1516 <p class="Figuretitle">Figure 4.1 — Relationships between 1517 source, reference, PNG, and display images</p> 1518 1519 <!-- ************Page Break******************* --> 1520 <!-- ************Page Break******************* --> 1521 <p>The relationships between samples, channels, pixels, and 1522 sample depth are illustrated in <a href="#figure42"><span class= 1523 "figref">figure 4.2</span></a>.</p> 1524 1525 <p><a name="figure42"> 1526 <object data="figures/fig42.svg" type="image/svg+xml" width="640" height="290"> 1527 <img height="290" width="640" src="png-figures/fig42.png" alt="Figure 4.2: Relationships between 1528 sample, sample depth, pixel, and channel" /> 1529 </object> 1530 </a></p> 1531 1532 <p class="Figuretitle">Figure 4.2 — Relationships between 1533 sample, sample depth, pixel, and channel</p> 1534 1535 <h2><a name="4Concepts.ColourSpaces">4.2 Colour spaces</a></h2> 1536 1537 <p>The RGB colour space in which colour samples are situated may 1538 be specified in one of three ways:</p> 1539 1540 <!-- <ol start="1"> --><ol> 1541 <li>by an ICC profile;</li> 1542 1543 <li>by specifying explicitly that the colour space is sRGB when 1544 the samples conform to this colour space;</li> 1545 1546 <li>by specifying the value of gamma and the 1931 CIE <i>x,y</i> 1547 chromaticities of the red, green, and blue primaries used in the 1548 image and the reference white point.</li> 1549 </ol> 1550 1551 <p>For high-end applications the first method provides the most 1552 flexibility and control. The second method enables one particular 1553 colour space to be indicated. The third method enables the exact 1554 chromaticities of the RGB data to be specified, along with the 1555 gamma correction (the power function relating the desired display 1556 output with the image samples) to be applied (see Annex C: <a 1557 href="#C-GammaAppendix"><span class="xref">Gamma and 1558 chromaticity</span></a>). It is recommended that explicit gamma 1559 information also be provided when either the first or second 1560 method is used, for use by PNG decoders that do not support full 1561 ICC profiles or the sRGB colour space. Such PNG decoders can 1562 still make sensible use of gamma information. PNG decoders are 1563 strongly encouraged to use this information, plus information 1564 about the display system, in order to present the image to the 1565 viewer in a way that reproduces as closely as possible what the image's original author 1566 saw .</p> 1567 1568 <p>Gamma correction is not applied to the alpha channel, if 1569 present. Alpha samples always represent a linear fraction of full 1570 opacity.</p> 1571 1572 <h2><a name="4Concepts.PNGImageTransformation">4.3 Reference 1573 image to PNG image transformation</a></h2> 1574 1575 <h3><a name="4Concepts.Introduction">4.3.1 Introduction</a></h3> 1576 1577 <p>A number of transformations are applied to the reference image 1578 to create the PNG image to be encoded (see <a href= 1579 "#figure43"><span class="figref">figure 4.3</span></a>). The 1580 transformations are applied in the following sequence, where 1581 square brackets mean the transformation is optional:</p> 1582 1583 <pre> 1584 [alpha separation] 1585 indexing or ( [RGB merging] [alpha compaction] ) 1586 sample depth scaling 1587 </pre> 1588 1589 <p>When every pixel is either fully transparent or fully opaque, 1590 the alpha separation, alpha compaction, and indexing 1591 transformations can cause the recovered reference image to have 1592 an alpha sample depth different from the original reference 1593 image, or to have no alpha channel. This has no effect on the 1594 degree of opacity of any pixel. The two reference images are 1595 considered equivalent, and the transformations are considered 1596 lossless. Encoders that nevertheless wish to preserve the alpha 1597 sample depth may elect not to perform transformations that would 1598 alter the alpha sample depth.</p> 1599 1600 <!-- ************Page Break******************* --> 1601 <!-- ************Page Break******************* --> 1602 <p><a name="figure43"> 1603 <object data="figures/fig43.svg" type="image/svg+xml" height="525" width="640"> 1604 <img height="525" width="640" src="png-figures/fig43.png" alt="Figure 4.3: Reference image to PNG 1605 image transformation" /> 1606 </object> 1607 </a></p> 1608 1609 <p class="Figuretitle">Figure 4.3 — Reference image to PNG 1610 image transformation</p> 1611 1612 <h3><a name="4Concepts.Implied-alpha">4.3.2 Alpha 1613 separation</a></h3> 1614 1615 <p>If all alpha samples in a reference image have the maximum 1616 value, then the alpha channel may be omitted, resulting in an 1617 equivalent image that can be encoded more compactly.</p> 1618 1619 <h3><a name="4Concepts.Indexing">4.3.3 Indexing</a></h3> 1620 1621 <p>If the number of distinct pixel values is 256 or less, and the 1622 RGB sample depths are not greater than 8, and the alpha channel 1623 is absent or exactly 8 bits deep or every pixel is either fully 1624 transparent or fully opaque, then an alternative representation 1625 called indexed-colour may be more efficient for encoding. 1626 Each pixel is replaced by an index into a palette. 1627 The palette is a list of entries each containing 1628 three 8-bit samples (red, green, blue). If an alpha channel is 1629 present, there is also a parallel table of 8-bit alpha 1630 samples.</p> 1631 1632 <!-- ************Page Break******************* --> 1633 <!-- ************Page Break******************* --> 1634 <p><a name="figure44"> 1635 <object height="450" width="660" data="figures/fig44.svg" type="image/svg+xml"> 1636 <img height="450" width="660" src="png-figures/fig44.png" alt="Figure 4.4: Indexed-colour 1637 image" /> 1638 </object> 1639 </a></p> 1640 1641 <p class="Figuretitle">Figure 4.4 — Indexed-colour 1642 image</p> 1643 1644 <p>A suggested palette or palettes may be constructed even when 1645 the PNG image is not indexed-colour in order to assist viewers 1646 that are capable of displaying only a limited number of 1647 colours.</p> 1648 1649 <p>For indexed-colour images, encoders can rearrange the palette 1650 so that the table entries with the maximum alpha value are 1651 grouped at the end. In this case the table can be encoded in a 1652 shortened form that does not include these entries.</p> 1653 1654 <h3><a name="4Concepts.RGBMerging">4.3.4 RGB merging</a></h3> 1655 1656 <p>If the red, green, and blue channels have the same sample 1657 depth, and for each pixel the values of the red, green, and blue 1658 samples are equal, then these three channels may be merged into a 1659 single greyscale channel.</p> 1660 1661 <h3><a name="4Concepts.Alpha-indexing">4.3.5 Alpha 1662 compaction</a></h3> 1663 1664 <p>For non-indexed images, if there exists an RGB (or greyscale) 1665 value such that all pixels with that value are fully transparent 1666 while all other pixels are fully opaque, then the alpha channel 1667 can be represented more compactly by merely identifying the RGB 1668 (or greyscale) value that is transparent.</p> 1669 1670 <h3><a name="4Concepts.Scaling">4.3.6 Sample depth 1671 scaling</a></h3> 1672 1673 <p>In the PNG image, not all sample depths are supported (see 1674 6.1: <a href="#6Colour-values"><span class="xref">Colour types 1675 and values</span></a>), and all channels shall have the same 1676 sample depth. All channels of the PNG image use the smallest 1677 allowable sample depth that is not less than any sample depth in 1678 the reference image, and the possible sample values in the 1679 reference image are linearly mapped into the next allowable range 1680 for the PNG image. <a href="#figure45"><span class= 1681 "figref">Figure 4.5</span></a> shows how samples of depth 3 might 1682 be mapped into samples of depth 4.</p> 1683 1684 <!-- ************Page Break******************* --> 1685 <!-- ************Page Break******************* --> 1686 <p><a name="figure45"> 1687 <object height="320" width="640" data="figures/fig45.svg" type="image/svg+xml"> 1688 <img height="320" width="640" src="png-figures/fig45.png" alt="Figure 4.5: Scaling sample 1689 values" /> 1690 </object> 1691 </a></p> 1692 1693 <p class="Figuretitle">Figure 4.5 — Scaling sample 1694 values</p> 1695 1696 <p>Allowing only a few sample depths reduces the number of cases 1697 that decoders have to cope with. Sample depth scaling is 1698 reversible with no loss of data, because the reference image 1699 sample depths can be recorded in the PNG datastream. In the 1700 absence of recorded sample depths, the reference image sample 1701 depth equals the PNG image sample depth. See 12.5: <a href= 1702 "#12Sample-depth-scaling"><span class="xref">Sample depth 1703 scaling</span></a> and 13.12: <a href= 1704 "#13Sample-depth-rescaling"><span class="xref">Sample depth 1705 rescaling</span></a>.</p> 1706 1707 <p><a name="figure46"> 1708 <object height="450" width="660" data="figures/fig46.svg" type="image/svg+xml"> 1709 <img height="450" width="660" src= "png-figures/fig46.png" alt="Figure 4.6: Possible PNG image 1710 pixel types" /> 1711 </object> 1712 </a></p> 1713 1714 <p class="Figuretitle">Figure 4.6 — Possible PNG image 1715 pixel types</p> 1716 1717 <!-- ************Page Break******************* --> 1718 <!-- ************Page Break******************* --> 1719 <h2><a name="4Concepts.PNGImage">4.4 PNG image</a></h2> 1720 1721 <p>The transformation of the reference image results in one of 1722 five types of PNG image (see <a href="#figure46"><span class= 1723 "figref">figure 4.6</span></a>) :</p> 1724 1725 <!-- <ol start="1"> --><ol> 1726 <li>Truecolour with alpha: each pixel consists of four samples: 1727 red, green, blue, and alpha.</li> 1728 1729 <li>Greyscale with alpha: each pixel consists of two samples: 1730 grey and alpha.</li> 1731 1732 <li>Truecolour: each pixel consists of three samples: red, green, 1733 and blue. The alpha channel may be represented by a single pixel 1734 value. Matching pixels are fully transparent, and all others are 1735 fully opaque. If the alpha channel is not represented in this 1736 way, all pixels are fully opaque.</li> 1737 1738 <li>Greyscale: each pixel consists of a single sample: grey. The 1739 alpha channel may be represented by a single pixel value as in 1740 the previous case. If the alpha channel is not represented in 1741 this way, all pixels are fully opaque.</li> 1742 1743 <li>Indexed-colour: each pixel consists of an index into a palette (and into an associated table of alpha values, if present).</li> 1744 </ol> 1745 1746 <p>The format of each pixel depends on the PNG image type and the 1747 bit depth. For PNG image types other than indexed-colour, 1748 the bit depth specifies the number of bits per sample, not the 1749 total number of bits per pixel. 1750 For indexed-colour images, the bit depth specifies the 1751 number of bits in each palette index, not the sample depth of the 1752 colours in the palette or alpha table. Within the pixel the 1753 samples appear in the following order, depending on the PNG image 1754 type.</p> 1755 1756 <!-- <ol start="6"> --><ol> 1757 <li>Truecolour with alpha: red, green, blue, alpha.</li> 1758 1759 <li>Greyscale with alpha: grey, alpha.</li> 1760 1761 <li>Truecolour: red, green, blue.</li> 1762 1763 <li>Greyscale: grey.</li> 1764 1765 <li>Indexed-colour: palette index.</li> 1766 </ol> 1767 1768 <h2><a name="4Concepts.Encoding">4.5 Encoding the PNG 1769 image</a></h2> 1770 1771 <h3><a name="4Concepts.EncodingIntro">4.5.1 Introduction</a></h3> 1772 1773 <p>A conceptual model of the process of encoding a PNG image is 1774 given in <a href="#figure47"><span class="figref">figure 1775 4.7</span></a>. The steps refer to the operations on the array of 1776 pixels or indices in the PNG image. The palette and alpha table 1777 are not encoded in this way.</p> 1778 1779 <!-- <ol start="1"> --><ol> 1780 <li>Pass extraction: to allow for progressive display, the PNG 1781 image pixels can be rearranged to form several smaller images 1782 called reduced images or passes.</li> 1783 1784 <li>Scanline serialization: the image is serialized a scanline at 1785 a time. Pixels are ordered left to right in a scanline and 1786 scanlines are ordered top to bottom.</li> 1787 1788 <li>Filtering: each scanline is transformed into a filtered 1789 scanline using one of the defined filter types to prepare the 1790 scanline for image compression.</li> 1791 1792 <li>Compression: occurs on all the filtered scanlines in the 1793 image.</li> 1794 1795 <li>Chunking: the compressed image is divided into conveniently 1796 sized chunks. An error detection code is added to each 1797 chunk.</li> 1798 1799 <li>Datastream construction: the chunks are inserted into the 1800 datastream.</li> 1801 </ol> 1802 1803 <h3><a name="4Concepts.EncodingPassAbs">4.5.2 Pass 1804 extraction</a></h3> 1805 1806 <p>Pass extraction (see <a href="#figure48"><span class= 1807 "figref">figure 4.8</span></a>) splits a PNG image into a 1808 sequence of reduced images where the first image defines a coarse 1809 view and subsequent images enhance this coarse view until the 1810 last image completes the PNG image. The set of reduced images is 1811 also called an interlaced PNG image. Two interlace methods are 1812 defined in this International Standard. The first method is a 1813 null method; pixels are stored sequentially from left to right 1814 and scanlines from top to bottom. The second method makes 1815 multiple scans over the image to produce a sequence of seven 1816 reduced images. The seven passes for a sample image are 1817 illustrated in <a href="#figure48"><span class="figref">figure 1818 4.8</span></a>. See clause 8: <a href="#8Interlace"><span class= 1819 "xref">Interlacing and pass extraction</span></a>.</p> 1820 1821 <!-- ************Page Break******************* --> 1822 <!-- ************Page Break******************* --> 1823 <p><a name="figure47"> 1824 <object height="575" width="645" data="figures/fig47.svg" type="image/svg+xml"> 1825 <img height="575" width="645" src="png-figures/fig47.png" alt="Figure 4.7: Encoding the PNG 1826 image" /> 1827 </object> 1828 </a></p> 1829 1830 <p class="Figuretitle">Figure 4.7 — Encoding the PNG 1831 image</p> 1832 1833 <p><a name="figure48"> 1834 <object height="450" width="645" data="figures/fig48.svg" type="image/svg+xml"> 1835 <img height="450" width="645" src="png-figures/fig48.png" alt="Figure 4.8: Pass extraction" /> 1836 </object> 1837 </a></p> 1838 1839 <p class="Figuretitle">Figure 4.8 — Pass extraction</p> 1840 1841 <!-- ************Page Break******************* --> 1842 <!-- ************Page Break******************* --> 1843 <h3><a name="4Concepts.EncodingScanlineAbs">4.5.3 Scanline 1844 serialization</a></h3> 1845 1846 <p>Each row of pixels, called a scanline, is represented as a 1847 sequence of bytes.</p> 1848 1849 <h3><a name="4Concepts.EncodingFiltering">4.5.4 1850 Filtering</a></h3> 1851 1852 <p>PNG standardizes one filter method and several filter types 1853 that may be used to prepare image data for compression. It 1854 transforms the byte sequence in a scanline to an equal length 1855 sequence of bytes preceded by a filter type byte (see <a href= 1856 "#figure49"><span class="figref">figure 4.9</span></a> for an 1857 example). The filter type byte defines 1858 the specific filtering to be applied to a specific 1859 scanline. The encoder shall use only a single filter method for 1860 an interlaced PNG image, but may use different filter types for 1861 each scanline in a reduced image. See clause 9: <a href= 1862 "#9Filters"><span class="xref">Filtering</span></a>.</p> 1863 1864 <p><a name="figure49"> 1865 <object height="340" width="710" data="figures/fig49.svg" type="image/svg+xml"> 1866 <img height="340" width="710" src="png-figures/fig49.png" alt="Figure 4.9: Serializing and 1867 filtering a scanline" /> 1868 </object> 1869 </a></p> 1870 1871 <p class="Figuretitle">Figure 4.9 — Serializing and 1872 filtering a scanline</p> 1873 1874 <h3><a name="4Concepts.EncodingCompression">4.5.5 1875 Compression</a></h3> 1876 1877 <p>The sequence of filtered scanlines in the pass or passes of 1878 the PNG image is compressed (see <a href="#figure410"><span 1879 class="figref">figure 4.10</span></a>) by one of the defined 1880 compression methods. The concatenated filtered scanlines form the 1881 input to the compression stage. The output from the compression 1882 stage is a single compressed datastream. See clause 10: <a href= 1883 "#10Compression"><span class="xref">Compression</span></a>.</p> 1884 1885 <h3><a name="4Concepts.EncodingChunking">4.5.6 Chunking</a></h3> 1886 1887 <p>Chunking provides a convenient breakdown of the compressed 1888 datastream into manageable chunks (see <span 1889 class="figref"><a href="#figure410">figure 4.10</a></span>). Each chunk has its own 1890 redundancy check. See clause 11: <a href="#11Chunks"><span class= 1891 "xref">Chunk specifications</span></a>.</p> 1892 1893 <!-- ************Page Break******************* --> 1894 <!-- ************Page Break******************* --> 1895 <p><a name="figure410"> 1896 <object height="450" width="700" data="figures/fig410.svg" type="image/svg+xml"> 1897 <img height="450" width="700" src="png-figures/fig410.png" alt="Figure 4.10: Compression" /> 1898 </object></a></p> 1899 <p class="Figuretitle">Figure 4.10 — Compression</p> 1900 1901 <h2><a name="4Concepts.AncillInfo">4.6 Additional 1902 information</a></h2> 1903 1904 <p>Ancillary information may be associated with an image. 1905 Decoders may ignore all or some of the ancillary information. The 1906 types of ancillary information provided are described in <a href= 1907 "#table41"><span class="tabref">Table 4.1</span></a>.</p> 1908 1909 <table class="Regular" summary= 1910 "This table lists the types of ancillary information that may be associated with an image"> 1911 <caption><a name="table41"><b>Table 4.1 — Types of 1912 ancillary information</b></a></caption> 1913 1914 <tr> 1915 <th>Type of information</th> 1916 <th>Description</th> 1917 </tr> 1918 1919 <tr> 1920 <td class="Regular">Background colour</td> 1921 <td class="Regular">Solid background colour to be used when presenting the image 1922 if no better option is available.</td> 1923 </tr> 1924 1925 <tr> 1926 <td class="Regular">Gamma and chromaticity</td> 1927 <td class="Regular">Gamma characteristic of the image with respect to the desired 1928 output intensity, and chromaticity characteristics of the RGB 1929 values used in the image.</td> 1930 </tr> 1931 1932 <tr> 1933 <td class="Regular">ICC profile</td> 1934 <td class="Regular">Description of the colour space (in the form of an 1935 International Color Consortium (ICC) profile) to which the 1936 samples in the image conform.</td> 1937 </tr> 1938 1939 <tr> 1940 <td class="Regular">Image histogram</td> 1941 <td class="Regular">Estimates of how frequently the image uses each palette entry.</td> 1942 </tr> 1943 1944 <tr> 1945 <td class="Regular">Physical pixel dimensions</td> 1946 <td class="Regular">Intended pixel size and aspect ratio to be used in presenting 1947 the PNG image.</td> 1948 </tr> 1949 1950 <tr> 1951 <td class="Regular">Significant bits</td> 1952 <td class="Regular">The number of bits that are significant in the samples.</td> 1953 </tr> 1954 1955 <tr> 1956 <td class="Regular">sRGB colour space</td> 1957 <td class="Regular">A rendering intent (as defined by the International Color 1958 Consortium) and an indication that the image samples conform to 1959 this colour space.</td> 1960 </tr> 1961 1962 <tr> 1963 <td class="Regular">Suggested palette</td> 1964 <td class="Regular">A reduced palette that may be used when the display device is 1965 not capable of displaying the full range of colours in the 1966 image.</td> 1967 </tr> 1968 1969 <tr> 1970 <td class="Regular">Textual data</td> 1971 <td class="Regular">Textual information (which may be compressed) associated with 1972 the image.</td> 1973 </tr> 1974 1975 <tr> 1976 <td class="Regular">Time</td> 1977 <td class="Regular">The time when the PNG image was last modified.</td> 1978 </tr> 1979 1980 <tr> 1981 <td class="Regular">Transparency</td> 1982 <td class="Regular">Alpha information that allows the reference image to be 1983 reconstructed when the alpha channel is not retained in the PNG 1984 image.</td> 1985 </tr> 1986 </table> 1987 1988 <!-- ************Page Break******************* --> 1989 <!-- ************Page Break******************* --> 1990 <h2><a name="4Concepts.Format">4.7 PNG datastream</a></h2> 1991 1992 <h3><a name="4Concepts.FormatChunks">4.7.1 Chunks</a></h3> 1993 1994 <p>The PNG datastream consists of a PNG signature (see 5.2: <a 1995 href="#5PNG-file-signature"><span class="xref">PNG 1996 signature</span></a>) followed by a sequence of chunks (see 1997 clause 11: <a href="#11Chunks"><span class="xref">Chunk 1998 specifications</span></a>). Each chunk has a chunk type which 1999 specifies its function.</p> 2000 2001 <h3><a name="4Concepts.FormatTypes">4.7.2 Chunk types</a></h3> 2002 2003 <p>There are 18 chunk types defined in this International 2004 Standard. Chunk types are four-byte sequences chosen so that they 2005 correspond to readable labels when interpreted in the ISO 646.IRV:1991 2006 character set. The first four are termed critical chunks, which 2007 shall be understood and correctly interpreted according to the 2008 provisions of this International Standard. These are:</p> 2009 2010 <!-- <ol start="1"> --><ol> 2011 <li><a href="#11IHDR"><span class="chunk">IHDR</span></a>: image 2012 header, which is the first chunk in a PNG datastream.</li> 2013 2014 <li><a href="#11PLTE"><span class="chunk">PLTE</span></a>: 2015 palette table associated with indexed PNG images.</li> 2016 2017 <li><a href="#11IDAT"><span class="chunk">IDAT</span></a>: image 2018 data chunks.</li> 2019 2020 <li><a href="#11IEND"><span class="chunk">IEND</span></a>: image 2021 trailer, which is the last chunk in a PNG datastream.</li> 2022 </ol> 2023 2024 <p>The remaining 14 chunk types are termed ancillary chunk types, 2025 which encoders may generate and decoders may interpret.</p> 2026 2027 <!-- <ol start="5"> --><ol> 2028 <li>Transparency information: <a href="#11tRNS"><span class= 2029 "chunk">tRNS</span></a> (see 11.3.2: <a class='Href' href= 2030 '#11transinfo'>Transparency information</a>).</li> 2031 2032 <li>Colour space information: <a href="#11cHRM"><span class= 2033 "chunk">cHRM</span></a>, <a href="#11gAMA"><span class= 2034 "chunk">gAMA</span></a>, <a href="#11iCCP"><span class= 2035 "chunk">iCCP</span></a>, <a href="#11sBIT"><span class= 2036 "chunk">sBIT</span></a>, <a href="#11sRGB"><span class= 2037 "chunk">sRGB</span></a> (see 11.3.3: <a class='Href' href= 2038 '#11addnlcolinfo'>Colour space information</a>).</li> 2039 2040 <li>Textual information: <a href="#11iTXt"><span class= 2041 "chunk">iTXt</span></a>, <a href="#11tEXt"><span class= 2042 "chunk">tEXt</span></a>, <a href="#11zTXt"><span class= 2043 "chunk">zTXt</span></a> (see 11.3.4: <a class='Href' href= 2044 '#11textinfo'>Textual information</a>).</li> 2045 2046 <li>Miscellaneous information: <a href="#11bKGD"><span class= 2047 "chunk">bKGD</span></a>, <a href="#11hIST"><span class= 2048 "chunk">hIST</span></a>, <a href="#11pHYs"><span class= 2049 "chunk">pHYs</span></a>, <a href="#11sPLT"><span class= 2050 "chunk">sPLT</span></a> (see 11.3.5: <a class='Href' href= 2051 '#11addnlsiinfo'>Miscellaneous information</a>).</li> 2052 2053 <li>Time information: <a href="#11tIME"><span class= 2054 "chunk">tIME</span></a> (see 11.3.6: <a class='Href' href= 2055 '#11timestampinfo'>Time stamp information</a>).</li> 2056 </ol> 2057 2058 <h2><a name="4Concepts.Errors">4.8 Error handling</a></h2> 2059 2060 <p>Errors in a PNG datastream fall into two general classes:</p> 2061 2062 <!-- <ol start="1"> --><ol> 2063 <li>transmission errors or damage to a computer file system, 2064 which tend to corrupt much or all of the datastream;</li> 2065 2066 <li>syntax errors, which appear as invalid values in chunks, or 2067 as missing or misplaced chunks. Syntax errors can be caused not 2068 only by encoding mistakes, but also by the use of registered or 2069 private values, if those values are unknown to the decoder.</li> 2070 </ol> 2071 2072 <p>PNG decoders should detect errors as early as possible, 2073 recover from errors whenever possible, and fail gracefully 2074 otherwise. The error handling philosophy is described in detail 2075 in 13.2: <a href="#13Decoders.Errors"><span class="xref">Error 2076 handling</span></a>.</p> 2077 2078 <h2><a name="4Concepts.Registration">4.9 Extension and 2079 registration</a></h2> 2080 2081 <p>For some facilities in PNG, there are a number of alternatives 2082 defined, and this International Standard allows other 2083 alternatives to be defined by registration. According to the 2084 rules for the designation and operation of registration 2085 authorities in the ISO/IEC Directives, the ISO and IEC Councils 2086 have designated the following as the registration authority:</p> 2087 2088 <address>The World-Wide Web Consortium Host at ERCIM</address> 2089 2090 <address>The Registration Authority for PNG</address> 2091 2092 <address>INRIA- Sophia Antipolis</address> 2093 2094 <address>BP 93</address> 2095 2096 <address>06902 Sophia Antipolis Cedex</address> 2097 2098 <address>FRANCE</address> 2099 2100 <address>Email:png-group@w3.org</address> 2101 2102 <p>To ensure timely processing the Registration Authority should be contacted by email.</p> 2103 2104 <p>The following entities may be registered:</p> 2105 2106 <!-- <ol start="1"> --><ol> 2107 <li>chunk type;</li> 2108 2109 <li>text keyword.</li> 2110 </ol> 2111 2112 <p>The following entities are reserved for future 2113 standardization:</p> 2114 2115 <!-- <ol start="4"> --><ol> 2116 <li>undefined field values less than 128;</li> 2117 2118 <li>filter method;</li> 2119 2120 <li>filter type;</li> 2121 2122 <li>interlace method;</li> 2123 2124 <li>compression method.</li> 2125 </ol> 2126 2127 <!-- ************Page Break******************* --> 2128 <!-- ************Page Break******************* --> 2129 <h1><a name="5DataRep">5 Datastream structure</a></h1> 2130 2131 <h2><a name="5Introduction">5.1 Introduction</a></h2> 2132 2133 <p>This clause defines the PNG signature and the basic properties 2134 of chunks. Individual chunk types are discussed in clause 11: <a 2135 href="#11Chunks"><span class="xref">Chunk 2136 specifications</span></a>.</p> 2137 2138 <h2><a name="5PNG-file-signature">5.2 PNG signature</a></h2> 2139 2140 <p>The first eight bytes of a PNG datastream always contain the 2141 following (decimal) values:</p> 2142 2143 <pre> 2144 137 80 78 71 13 10 26 10 2145 </pre> 2146 2147 <p>This signature indicates that the remainder of the datastream 2148 contains a single PNG image, consisting of a series of chunks 2149 beginning with an <a href="#11IHDR"><span class= 2150 "chunk">IHDR</span></a> chunk and ending with an <a href= 2151 "#11IEND"><span class="chunk">IEND</span></a> chunk.</p> 2152 2153 <h2><a name="5Chunk-layout">5.3 Chunk layout</a></h2> 2154 2155 <p>Each chunk consists of three or four fields (see figure 5.1). 2156 The meaning of the fields is described in 2157 <a href="#table51"><span class="tabref">Table 5.1</span></a>. 2158 The chunk data field may be empty.</p> 2159 2160 <p><a name="figure411"> 2161 <object height="160" width="480" data="figures/fig51.svg" type="image/svg+xml"> 2162 <img height="160" width="480" src="png-figures/fig51.png" alt="Figure 5.1: Chunk parts" /> 2163 </object> 2164 </a></p> 2165 2166 <p class="Figuretitle">Figure 5.1 — Chunk parts</p> 2167 2168 <table class="Regular" summary= 2169 "This table defines the chunk fields"> 2170 <caption><a name="table51"><b>Table 5.1 — Chunk fields</b></a></caption> 2171 <tr> 2172 <td class="Regular">Length</td> 2173 <td class="Regular">A four-byte unsigned integer giving the number of bytes in 2174 the chunk's data field. The length counts <strong>only</strong> 2175 the data field, <strong>not</strong> itself, the chunk type, or 2176 the CRC. Zero is a valid length. Although encoders and decoders 2177 should treat the length as unsigned, its value shall not exceed 2178 2<sup>31</sup>-1 bytes.</td> 2179 </tr> 2180 2181 <tr> 2182 <td class="Regular">Chunk Type</td> 2183 <td class="Regular">A sequence of four bytes defining the chunk type. Each byte 2184 of a chunk type is restricted to the decimal values 65 to 90 and 2185 97 to 122. These correspond to the uppercase and lowercase ISO 2186 646 letters (<tt>A</tt>-<tt>Z</tt> and <tt>a</tt>-<tt>z</tt>) 2187 respectively for convenience in description and examination of 2188 PNG datastreams. Encoders and decoders shall treat the chunk 2189 types as fixed binary values, not character strings. For example, 2190 it would not be correct to represent the chunk type <a href= 2191 "#11IDAT"><span class="chunk">IDAT</span></a> by the equivalents 2192 of those letters in the UCS 2 character set. Additional naming 2193 conventions for chunk types are discussed in 5.4: <a href= 2194 "#5Chunk-naming-conventions"><span class="xref">Chunk naming 2195 conventions</span></a>.</td> 2196 </tr> 2197 2198 <tr> 2199 <td class="Regular">Chunk Data</td> 2200 <td class="Regular">The data bytes appropriate to the chunk type, if any. This 2201 field can be of zero length.</td> 2202 </tr> 2203 2204 <tr> 2205 <td class="Regular">CRC</td> 2206 <td class="Regular">A four-byte CRC (Cyclic Redundancy Code) calculated on the 2207 preceding bytes in the chunk, including the chunk type field and 2208 chunk data fields, but <strong>not</strong> including the length 2209 field. The CRC can be used to check for corruption of the data. 2210 The CRC is always present, even for chunks containing no data. 2211 See 5.5: <a href="#5CRC-algorithm"><span class="xref">Cyclic 2212 Redundancy Code algorithm</span></a>.</td> 2213 </tr> 2214 </table> 2215 2216 <p>The chunk data length may be any number of bytes up to the 2217 maximum; therefore, implementors cannot assume that chunks are 2218 aligned on any boundaries larger than bytes.</p> 2219 2220 <!-- ************Page Break******************* --> 2221 <!-- ************Page Break******************* --> 2222 <h2><a name="5Chunk-naming-conventions">5.4 Chunk naming 2223 conventions</a></h2> 2224 2225 <p>Chunk types are chosen to be meaningful names when the bytes 2226 of the chunk type are interpreted as ISO 646 letters. Chunk types 2227 are assigned so that a decoder can determine some properties of a 2228 chunk even when the type is not recognized. These rules allow 2229 safe, flexible extension of the PNG format, by allowing a PNG 2230 decoder to decide what to do when it encounters an unknown chunk. 2231 (The chunk types standardized in this International Standard are 2232 defined in clause 11: <a href="#11Chunks"><span class= 2233 "xref">Chunk specifications</span></a>, and the way to add 2234 non-standard chunks is defined in clause 14: <a href= 2235 "#14EditorsExt"><span class="xref">Editors and 2236 extensions</span></a>.) The naming rules are normally of interest 2237 only when the decoder does not recognize the chunk's type.</p> 2238 2239 <p>Four bits of the chunk type, the property bits, namely bit 5 2240 (value 32) of each byte, are used to convey chunk properties. 2241 This choice means that a human can read off the assigned 2242 properties according to whether the letter corresponding to each 2243 byte of the chunk type is uppercase (bit 5 is 0) or lowercase 2244 (bit 5 is 1). However, decoders should test the properties of an 2245 unknown chunk type by numerically testing the specified bits; 2246 testing whether a character is uppercase or lowercase is 2247 inefficient, and even incorrect if a locale-specific case 2248 definition is used.</p> 2249 2250 <p>The property bits are an inherent part of the chunk type, and 2251 hence are fixed for any chunk type. Thus, <span class= 2252 "chunk">CHNK</span> and <span class="chunk">cHNk</span> would be 2253 unrelated chunk types, not the same chunk with different 2254 properties.</p> 2255 2256 <p>The semantics of the property bits are 2257 defined in 2258 <a href="#table52"><span class="tabref">Table 5.2</span></a>. 2259 </p> 2260 2261 <table class="Regular" summary= 2262 "This table defines the semantics of the property bits"> 2263 <caption><a name="table52"><b>Table 5.2 — Semantics of property bits</b></a></caption> 2264 <tr> 2265 <td class="Regular">Ancillary bit: first byte</td> 2266 <td class="Regular">0 (uppercase) = critical,<br class="xhtml" /> 2267 1 (lowercase) = ancillary.</td> 2268 <td class="Regular">Critical chunks are necessary for successful display of the 2269 contents of the datastream, for example the image header chunk 2270 (<a href="#11IHDR"><span class="chunk">IHDR</span></a>). A 2271 decoder trying to extract the image, upon encountering an unknown 2272 chunk type in which the ancillary bit is 0, shall indicate to the 2273 user that the image contains information it cannot safely 2274 interpret.<br class="xhtml" /> 2275 Ancillary chunks are not strictly necessary in order to 2276 meaningfully display the contents of the datastream, for example 2277 the time chunk (<a href="#11tIME"><span class= 2278 "chunk">tIME</span></a>). A decoder encountering an unknown chunk 2279 type in which the ancillary bit is 1 can safely ignore the chunk 2280 and proceed to display the image.</td> 2281 </tr> 2282 2283 <tr> 2284 <td class="Regular">Private bit: second byte</td> 2285 <td class="Regular">0 (uppercase) = public,<br class="xhtml" /> 2286 1 (lowercase) = private.</td> 2287 <td class="Regular">A public chunk is one that is defined in this International 2288 Standard or is registered in the list of PNG special-purpose 2289 public chunk types maintained by the Registration Authority (see 2290 4.9 <a href="#4Concepts.Registration"><span class= 2291 "xref">Extension and registration</span></a>). Applications can 2292 also define private (unregistered) chunk types for their own 2293 purposes. The names of private chunks have a lowercase second 2294 letter, while public chunks will always be assigned names with 2295 uppercase second letters. Decoders do not need to test the 2296 private-chunk property bit, since it has no functional 2297 significance; it is simply an administrative convenience to 2298 ensure that public and private chunk names will not conflict. See 2299 clause 14: <a href="#14EditorsExt"><span class="xref">Editors and 2300 extensions</span></a> and 12.10.2: <a href= 2301 "#12Use-of-private-chunks"><span class="xref">Use of private 2302 chunks</span></a>.</td> 2303 </tr> 2304 2305 <tr> 2306 <td class="Regular">Reserved bit: third byte</td> 2307 <td class="Regular">0 (uppercase) in this version of PNG.<br class="xhtml" /> 2308 If the reserved bit is 1, the datastream does not conform to 2309 this version of PNG.</td> 2310 <td class="Regular">The significance of the case of the third letter of the chunk 2311 name is reserved for possible future extension. In this 2312 International Standard, all chunk names shall have uppercase 2313 third letters.</td> 2314 </tr> 2315 2316 <tr> 2317 <td class="Regular">Safe-to-copy bit: fourth byte</td> 2318 <td class="Regular">0 (uppercase) = unsafe to copy,<br class="xhtml" /> 2319 1 (lowercase) = safe to copy.</td> 2320 <td class="Regular">This property bit is not of interest to pure decoders, but it 2321 is needed by PNG editors. This bit defines the proper handling of 2322 unrecognized chunks in a datastream that is being modified. Rules 2323 for PNG editors are discussed further in 14.2: <a href= 2324 "#14Ordering"><span class="xref">Behaviour of PNG 2325 editors</span></a>.</td> 2326 </tr> 2327 </table> 2328 2329 <p>EXAMPLE The hypothetical chunk type "<span class= 2330 "chunk">cHNk</span>" has the property bits:</p> 2331 2332 <pre> 2333 cHNk <-- 32 bit chunk type represented in text form 2334 |||| 2335 |||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1) 2336 ||+-- Reserved bit is 0 (upper case letter; bit 5 is 0) 2337 |+--- Private bit is 0 (upper case letter; bit 5 is 0) 2338 +---- Ancillary bit is 1 (lower case letter; bit 5 is 1) 2339 </pre> 2340 2341 <p>Therefore, this name represents an ancillary, public, 2342 safe-to-copy chunk.</p> 2343 2344 <h2><a name="5CRC-algorithm">5.5 Cyclic Redundancy Code 2345 algorithm</a></h2> 2346 2347 <p>CRC fields are calculated using standardized CRC methods with 2348 pre and post conditioning, as defined by ISO 3309 <a href= 2349 "#2-ISO-3309"><span class="NormRef">[ISO-3309]</span></a> and 2350 ITU-T V.42 <a href="#G-ITU-T-V42"><span class= 2351 "bibref">[ITU-T-V42]</span></a>. The CRC polynomial employed 2352 is</p> 2353 2354 <p>x<sup>32</sup> + x<sup>26</sup> + x<sup>23</sup> + 2355 x<sup>22</sup> + x<sup>16</sup> + x<sup>12</sup> + x<sup>11</sup> 2356 + x<sup>10</sup> + x<sup>8</sup> + x<sup>7</sup> + x<sup>5</sup> 2357 + x<sup>4</sup> + x<sup>2</sup> + x + 1</p> 2358 2359 <p>In PNG, the 32-bit CRC is initialized to all 1's, and then the 2360 data from each byte is processed from the least significant bit 2361 (1) to the most significant bit (128). After all the data bytes 2362 are processed, the CRC is inverted (its ones complement is 2363 taken). This value is transmitted (stored in the datastream) MSB 2364 first. For the purpose of separating into bytes and ordering, the 2365 least significant bit of the 32-bit CRC is defined to be the 2366 coefficient of the <tt>x<sup>31</sup></tt> term.</p> 2367 2368 <p>Practical calculation of the CRC often employs a precalculated 2369 table to accelerate the computation. See Annex D: <a href= 2370 "#D-CRCAppendix"><span class="xref">Sample Cyclic Redundancy Code 2371 implementation</span></a>.</p> 2372 2373 <h2><a name="5ChunkOrdering">5.6 Chunk ordering</a></h2> 2374 2375 <p>The constraints on the positioning of the individual chunks 2376 are listed in <a href="#table53"><span class="tabref">Table 2377 5.3</span></a> and illustrated diagrammatically in <a href= 2378 "#figure52"><span class="figref">figure 5.2</span></a> and <a 2379 href="#figure53"><span class="figref">figure 5.3</span></a>. 2380 These lattice diagrams represent the constraints on positioning 2381 imposed by this International Standard. The lines in the diagrams 2382 define partial ordering relationships. Chunks higher up shall 2383 appear before chunks lower down. Chunks which are horizontally 2384 aligned and appear between two other chunk types (higher and 2385 lower than the horizontally aligned chunks) may appear in any 2386 order between the two higher and lower chunk types to which they 2387 are connected. The superscript associated with the chunk type is 2388 defined in <a href="#table54"><span class="tabref">Table 2389 5.4</span></a>. It indicates whether the chunk is mandatory, 2390 optional, or may appear more than once. A vertical bar between 2391 two chunk types indicates alternatives.</p> 2392 2393 <!-- ************Page Break******************* --> 2394 <!-- ************Page Break******************* --> 2395 <table class="Regular" summary= 2396 "This table lists the chunk ordering rules"> 2397 <caption><a name="table53"><b>Table 5.3 — Chunk ordering 2398 rules</b></a></caption> 2399 2400 <tr> 2401 <th colspan="3">Critical chunks<br class="xhtml" /> 2402 (shall appear in this order, except <a href="#11PLTE"><span 2403 class="chunk">PLTE</span></a> is optional)</th> 2404 </tr> 2405 2406 <tr> 2407 <th>Chunk name</th> 2408 <th>Multiple allowed</th> 2409 <th>Ordering constraints</th> 2410 </tr> 2411 2412 <tr> 2413 <td class="Regular"><a href="#11IHDR"><span class="chunk">IHDR</span></a> </td> 2414 <td class="Regular">No</td> 2415 <td class="Regular">Shall be first</td> 2416 </tr> 2417 2418 <tr> 2419 <td class="Regular"><a href="#11PLTE"><span class="chunk">PLTE</span></a> </td> 2420 <td class="Regular">No</td> 2421 <td class="Regular">Before first <a href="#11IDAT"><span class= 2422 "chunk">IDAT</span></a> </td> 2423 </tr> 2424 2425 <tr> 2426 <td class="Regular"><a href="#11IDAT"><span class="chunk">IDAT</span></a> </td> 2427 <td class="Regular">Yes</td> 2428 <td class="Regular">Multiple <a href="#11IDAT"><span class= 2429 "chunk">IDAT</span></a> chunks shall be consecutive</td> 2430 </tr> 2431 2432 <tr> 2433 <td class="Regular"><a href="#11IEND"><span class="chunk">IEND</span></a> </td> 2434 <td class="Regular">No</td> 2435 <td class="Regular">Shall be last</td> 2436 </tr> 2437 2438 <tr> 2439 <th colspan="3">Ancillary chunks<br class="xhtml" /> 2440 (need not appear in this order)</th> 2441 </tr> 2442 2443 <tr> 2444 <th>Chunk name</th> 2445 <th>Multiple allowed</th> 2446 <th>Ordering constraints</th> 2447 </tr> 2448 2449 <tr> 2450 <td class="Regular"><a href="#11cHRM"><span class="chunk">cHRM</span></a> </td> 2451 <td class="Regular">No</td> 2452 <td class="Regular">Before <a href="#11PLTE"><span class="chunk">PLTE</span></a> 2453 and <a href="#11IDAT"><span class="chunk">IDAT</span></a> </td> 2454 </tr> 2455 2456 <tr> 2457 <td class="Regular"><a href="#11gAMA"><span class="chunk">gAMA</span></a> </td> 2458 <td class="Regular">No</td> 2459 <td class="Regular">Before <a href="#11PLTE"><span class="chunk">PLTE</span></a> 2460 and <a href="#11IDAT"><span class="chunk">IDAT</span></a> </td> 2461 </tr> 2462 2463 <tr> 2464 <td class="Regular"><a href="#11iCCP"><span class="chunk">iCCP</span></a> </td> 2465 <td class="Regular">No</td> 2466 <td class="Regular">Before <a href="#11PLTE"><span class="chunk">PLTE</span></a> 2467 and <a href="#11IDAT"><span class="chunk">IDAT</span></a>. If the 2468 <a href="#11iCCP"><span class="chunk">iCCP</span></a> chunk is 2469 present, the <a href="#11sRGB"><span class= 2470 "chunk">sRGB</span></a> chunk should not be present.</td> 2471 </tr> 2472 2473 <tr> 2474 <td class="Regular"><a href="#11sBIT"><span class="chunk">sBIT</span></a> </td> 2475 <td class="Regular">No</td> 2476 <td class="Regular">Before <a href="#11PLTE"><span class="chunk">PLTE</span></a> 2477 and <a href="#11IDAT"><span class="chunk">IDAT</span></a> </td> 2478 </tr> 2479 2480 <tr> 2481 <td class="Regular"><a href="#11sRGB"><span class="chunk">sRGB</span></a> </td> 2482 <td class="Regular">No</td> 2483 <td class="Regular">Before <a href="#11PLTE"><span class="chunk">PLTE</span></a> 2484 and <a href="#11IDAT"><span class="chunk">IDAT</span></a>. If the 2485 <a href="#11sRGB"><span class="chunk">sRGB</span></a> chunk is 2486 present, the <a href="#11iCCP"><span class= 2487 "chunk">iCCP</span></a> chunk should not be present.</td> 2488 </tr> 2489 2490 <tr> 2491 <td class="Regular"><a href="#11bKGD"><span class="chunk">bKGD</span></a> </td> 2492 <td class="Regular">No</td> 2493 <td class="Regular">After <a href="#11PLTE"><span class="chunk">PLTE</span></a>; 2494 before <a href="#11IDAT"><span class="chunk">IDAT</span></a> 2495 </td> 2496 </tr> 2497 2498 <tr> 2499 <td class="Regular"><a href="#11hIST"><span class="chunk">hIST</span></a> </td> 2500 <td class="Regular">No</td> 2501 <td class="Regular">After <a href="#11PLTE"><span class="chunk">PLTE</span></a>; 2502 before <a href="#11IDAT"><span class="chunk">IDAT</span></a> 2503 </td> 2504 </tr> 2505 2506 <tr> 2507 <td class="Regular"><a href="#11tRNS"><span class="chunk">tRNS</span></a> </td> 2508 <td class="Regular">No</td> 2509 <td class="Regular">After <a href="#11PLTE"><span class="chunk">PLTE</span></a>; 2510 before <a href="#11IDAT"><span class="chunk">IDAT</span></a> 2511 </td> 2512 </tr> 2513 2514 <tr> 2515 <td class="Regular"><a href="#11pHYs"><span class="chunk">pHYs</span></a> </td> 2516 <td class="Regular">No</td> 2517 <td class="Regular">Before <a href="#11IDAT"><span class="chunk">IDAT</span></a> 2518 </td> 2519 </tr> 2520 2521 <tr> 2522 <td class="Regular"><a href="#11sPLT"><span class="chunk">sPLT</span></a> </td> 2523 <td class="Regular">Yes</td> 2524 <td class="Regular">Before <a href="#11IDAT"><span class="chunk">IDAT</span></a> 2525 </td> 2526 </tr> 2527 2528 <tr> 2529 <td class="Regular"><a href="#11tIME"><span class="chunk">tIME</span></a> </td> 2530 <td class="Regular">No</td> 2531 <td class="Regular">None</td> 2532 </tr> 2533 2534 <tr> 2535 <td class="Regular"><a href="#11iTXt"><span class="chunk">iTXt</span></a> </td> 2536 <td class="Regular">Yes</td> 2537 <td class="Regular">None</td> 2538 </tr> 2539 2540 <tr> 2541 <td class="Regular"><a href="#11tEXt"><span class="chunk">tEXt</span></a> </td> 2542 <td class="Regular">Yes</td> 2543 <td class="Regular">None</td> 2544 </tr> 2545 2546 <tr> 2547 <td class="Regular"><a href="#11zTXt"><span class="chunk">zTXt</span></a> </td> 2548 <td class="Regular">Yes</td> 2549 <td class="Regular">None</td> 2550 </tr> 2551 </table> 2552 2553 <table class="Regular" summary= 2554 "This table lists the symbols used in lattice diagrams"> 2555 <caption><a name="table54"><b>Table 5.4 — Meaning of 2556 symbols used in lattice diagrams</b></a></caption> 2557 2558 <tr> 2559 <th>Symbol</th> 2560 <th>Meaning</th> 2561 </tr> 2562 2563 <tr> 2564 <td class="Regular">+</td> 2565 <td class="Regular">One or more</td> 2566 </tr> 2567 2568 <tr> 2569 <td class="Regular">1</td> 2570 <td class="Regular">Only one</td> 2571 </tr> 2572 2573 <tr> 2574 <td class="Regular">?</td> 2575 <td class="Regular">Zero or one</td> 2576 </tr> 2577 2578 <tr> 2579 <td class="Regular">*</td> 2580 <td class="Regular">Zero or more</td> 2581 </tr> 2582 <tr> 2583 <td class="Regular">|</td> 2584 <td class="Regular">Alternative</td> 2585 </tr> 2586 </table> 2587 2588 <!-- ************Page Break******************* --> 2589 <!-- ************Page Break******************* --> 2590 <p> 2591 <object height="540" width="800" data="figures/fig52.svg" type="image/svg+xml"> 2592 <img height="540" width="800" src="png-figures/fig52.png" alt="Figure 5.2: Lattice diagram: PNG images with PLTE in datastream" /> 2593 </object> 2594 </p> 2595 2596 <p class="Figuretitle"><a name="figure52">Figure 5.2 —</a> 2597 Lattice diagram: PNG images with <a href="#11PLTE"><span class= 2598 "chunk">PLTE</span></a> in datastream</p> 2599 2600 <p> 2601 <object height="540" width="900" data="figures/fig53.svg" 2602 type="image/svg+xml"> 2603 <img height="540" width="900" src="png-figures/fig53.png" alt="Figure 5.3: Lattice diagram: PNG images without PLTE in datastream" /> 2604 </object> 2605 </p> 2606 2607 <p class="Figuretitle"><a name="figure53">Figure 5.3 —</a> 2608 Lattice diagram: PNG images without <a href="#11PLTE"><span 2609 class="chunk">PLTE</span></a> in datastream</p> 2610 2611 <!-- ************Page Break******************* --> 2612 <!-- ************Page Break******************* --> 2613 <h1><a name="6Transformation">6 Reference image to PNG image 2614 transformation</a></h1> 2615 2616 <h2><a name="6Colour-values">6.1 Colour types and values</a></h2> 2617 2618 <p>As explained in 4.4: <a href="#4Concepts.PNGImage"><span 2619 class="xref">PNG image</span></a> there are five types of PNG 2620 image. Corresponding to each type is a colour type, which is the 2621 sum of the following values: 1 (palette used), 2 (truecolour 2622 used) and 4 (alpha used). Greyscale and truecolour images may 2623 have an explicit alpha channel. The PNG image types and 2624 corresponding colour types are listed in <a href= 2625 "#table6.1"><span class="tabref">Table 6.1</span></a>.</p> 2626 2627 <table class="Regular" summary= 2628 "This table lists the PNG image and colour types"> 2629 <caption><a name="table6.1"><b>Table 6.1 — PNG image types 2630 and colour types</b></a></caption> 2631 2632 <tr> 2633 <th>PNG image type</th> 2634 <th>Colour type</th> 2635 </tr> 2636 2637 <tr> 2638 <td class="Regular">Greyscale</td> 2639 <td class="Regular">0</td> 2640 </tr> 2641 2642 <tr> 2643 <td class="Regular">Truecolour</td> 2644 <td class="Regular">2</td> 2645 </tr> 2646 2647 <tr> 2648 <td class="Regular">Indexed-colour</td> 2649 <td class="Regular">3</td> 2650 </tr> 2651 2652 <tr> 2653 <td class="Regular">Greyscale with alpha</td> 2654 <td class="Regular">4</td> 2655 </tr> 2656 2657 <tr> 2658 <td class="Regular">Truecolour with alpha</td> 2659 <td class="Regular">6</td> 2660 </tr> 2661 </table> 2662 2663 <p>The allowed bit depths and sample depths for each PNG image 2664 type are listed in 11.2.2: <a href="#11IHDR"><span class= 2665 "xref"><span class="chunk">IHDR</span> Image 2666 header</span></a>.</p> 2667 2668 <p>Greyscale samples represent luminance if the transfer curve is 2669 indicated (by <a href="#11gAMA"><span class= 2670 "chunk">gAMA</span></a>, <a href="#11sRGB"><span class= 2671 "chunk">sRGB</span></a>, or <a href="#11iCCP"><span class= 2672 "chunk">iCCP</span></a>) or device-dependent greyscale if not. 2673 RGB samples represent calibrated colour information if the colour 2674 space is indicated (by <a href="#11gAMA"><span class= 2675 "chunk">gAMA</span></a> and <a href="#11cHRM"><span class= 2676 "chunk">cHRM</span></a>, or <a href="#11sRGB"><span class= 2677 "chunk">sRGB</span></a>, or <a href="#11iCCP"><span class= 2678 "chunk">iCCP</span></a>) or uncalibrated device-dependent colour 2679 if not.</p> 2680 2681 <p>Sample values are not necessarily proportional to light 2682 intensity; the <a href="#11gAMA"><span class= 2683 "chunk">gAMA</span></a> chunk specifies the relationship between 2684 sample values and display output intensity. Viewers are strongly 2685 encouraged to compensate properly. See 4.2: <a href= 2686 "#4Concepts.ColourSpaces"><span class="xref">Colour 2687 spaces</span></a>, 13.13: <a href= 2688 "#13Decoder-gamma-handling"><span class="xref">Decoder gamma 2689 handling</span></a> and Annex C: <a href="#C-GammaAppendix"><span 2690 class="xref">Gamma and chromaticity</span></a>.</p> 2691 2692 <h2><a name="6AlphaRepresentation">6.2 Alpha 2693 representation</a></h2> 2694 2695 <p>In a PNG datastream transparency may be represented in one of 2696 four ways, depending on the PNG image type (see 4.3.2: <a href= 2697 "#4Concepts.Implied-alpha"><span class="xref">Alpha 2698 separation</span></a> and 4.3.5: <a href= 2699 "#4Concepts.Alpha-indexing"><span class="xref">Alpha 2700 compaction</span></a>).</p> 2701 2702 <!-- <ol start="1"> --><ol> 2703 <li>Truecolour with alpha, greyscale with alpha: an alpha channel 2704 is part of the image array.</li> 2705 2706 <li>Truecolour, greyscale: A <a href="#11tRNS"><span class= 2707 "chunk">tRNS</span></a> chunk contains a single pixel value 2708 distinguishing the fully transparent pixels from the fully opaque 2709 pixels.</li> 2710 2711 <li>Indexed-colour: A <a href="#11tRNS"><span class= 2712 "chunk">tRNS</span></a> chunk contains the alpha table that 2713 associates an alpha sample with each palette entry.</li> 2714 2715 <li>Truecolour, greyscale, indexed-colour: there is no <a href= 2716 "#11tRNS"><span class="chunk">tRNS</span></a> chunk present and 2717 all pixels are fully opaque.</li> 2718 </ol> 2719 2720 <p>An alpha channel included in the image array has 8-bit or 2721 16-bit samples, the same size as the other samples. The alpha 2722 sample for each pixel is stored immediately following the 2723 greyscale or RGB samples of the pixel. An alpha value of zero 2724 represents full transparency, and a value of 2725 2<sup>sampledepth</sup> - 1 represents full opacity. Intermediate 2726 values indicate partially transparent pixels that can be 2727 composited against a background image to yield the delivered 2728 image.</p> 2729 2730 <p>The colour values in a pixel are not premultiplied by the 2731 alpha value assigned to the pixel. This rule is sometimes called 2732 "unassociated" or "non-premultiplied" alpha. (Another common 2733 technique is to store sample values premultiplied by the alpha 2734 value; in effect, such an image is already composited against a 2735 black background. PNG does <strong>not</strong> use premultiplied alpha. 2736 In consequence an image editor can take a PNG image and easily 2737 change its transparency.) See 12.4: <a href= 2738 "#12Alpha-channel-creation"><span class="xref">Alpha channel 2739 creation</span></a> and 13.16: <a href= 2740 "#13Alpha-channel-processing"><span class="xref">Alpha channel 2741 processing</span></a>.</p> 2742 2743 <!-- ************Page Break******************* --> 2744 <!-- ************Page Break******************* --> 2745 <h1><a name="7Transformation">7 Encoding the PNG image as a PNG 2746 datastream</a></h1> 2747 2748 <h2><a name="7Integers-and-byte-order">7.1 Integers and byte 2749 order</a></h2> 2750 2751 <p>All integers that require more than one byte shall be in 2752 network byte order (as illustrated in <a href="#figure71"><span 2753 class="figref">figure 7.1</span></a>): the most significant byte 2754 comes first, then the less significant bytes in descending order 2755 of significance (MSB LSB for two-byte integers, MSB B2 B1 LSB for 2756 four-byte integers). The highest bit (value 128) of a byte is 2757 numbered bit 7; the lowest bit (value 1) is numbered bit 0. 2758 Values are unsigned unless otherwise noted. Values explicitly 2759 noted as signed are represented in two's complement notation.</p> 2760 2761 <p>PNG four-byte unsigned integers are limited to the range 0 to 2762 2<sup>31</sup>-1 to accommodate languages that have difficulty 2763 with unsigned four-byte values. Similarly PNG four-byte signed 2764 integers are limited to the range -(2<sup>31</sup>-1) to 2765 2<sup>31</sup>-1 to accommodate languages that have difficulty 2766 with the value -2<sup>31</sup>.</p> 2767 2768 <p> 2769 <object height="310" width="810" data="figures/fig71.svg" type="image/svg+xml"> 2770 <img height="310" width="810" src="png-figures/fig71.png" alt="Figure 7.1: Integer representation in PNG" /> 2771 </object> 2772 </p> 2773 2774 <p class="Figuretitle"><a name="figure71">Figure 7.1</a> — 2775 Integer representation in PNG</p> 2776 2777 <h2><a name="7Scanline">7.2 Scanlines</a></h2> 2778 2779 <p>A PNG image (or pass, see clause 8: <a href= 2780 "#8Interlace"><span class="xref">Interlacing and pass 2781 extraction</span></a>) is a rectangular pixel array, with pixels 2782 appearing left-to-right within each scanline, and scanlines 2783 appearing top-to-bottom. The size of each pixel is determined by 2784 the number of bits per pixel.</p> 2785 2786 <p>Pixels within a scanline are always packed into a sequence of 2787 bytes with no wasted bits between pixels. Scanlines always begin 2788 on byte boundaries. Permitted bit depths and colour types are 2789 restricted so that in all cases the packing is simple and 2790 efficient.</p> 2791 2792 <p> 2793 In PNG images of colour type 0 (greyscale) each pixel is a single sample, which may have precision less than a byte (1, 2, or 4 bits). These samples are packed into bytes with the leftmost sample in the high-order bits of a byte followed by the other samples for the scanline. 2794 </p> 2795 <p> 2796 In PNG images of colour type 3 (indexed-colour) each pixel is a single palette index. These indices are packed into bytes in the same way as the samples for colour type 0.</p> 2797 <p>When there are multiple pixels per byte, some low-order bits 2798 of the last byte of a scanline may go unused. The contents of 2799 these unused bits are not specified.</p> 2800 2801 <p>PNG images that are not indexed-colour images may have sample 2802 values with a bit depth of 16. Such sample values are in network 2803 byte order (MSB first, LSB second). PNG permits multi-sample 2804 pixels only with 8 and 16-bit samples, so multiple samples of a 2805 single pixel are never packed into one byte.</p> 2806 2807 <!-- ************Page Break******************* --> 2808 <!-- ************Page Break******************* --> 2809 <h2><a name="7Filtering">7.3 Filtering</a></h2> 2810 2811 <p>PNG allows the scanline data to be <strong>filtered</strong> before it 2812 is compressed. Filtering can improve the compressibility of the 2813 data. The filter step itself results in a sequence of bytes of 2814 the same size as the incoming sequence, but in a different 2815 representation, preceded by a filter type byte. Filtering does 2816 not reduce the size of the actual scanline data. All PNG filters 2817 are strictly lossless.</p> 2818 2819 <p>Different filter types can be used for different scanlines, 2820 and the filter algorithm is specified for each scanline by a 2821 filter type byte. The filter type byte is not considered part of 2822 the image data, but it is included in the datastream sent to the 2823 compression step. An intelligent encoder can switch filters from 2824 one scanline to the next. The method for choosing which filter to 2825 employ is left to the encoder.</p> 2826 2827 <p>See clause 9: <a href="#9Filters"><span class= 2828 "xref">Filtering</span></a>.</p> 2829 2830 <!-- ************Page Break******************* --> 2831 <!-- ************Page Break******************* --> 2832 <h1><a name="8Interlace">8 Interlacing and pass 2833 extraction</a></h1> 2834 2835 <h2><a name="8InterlaceIntro">8.1 Introduction</a></h2> 2836 2837 <p>Pass extraction (see <a href="#figure48"><span class= 2838 "figref">figure 4.8</span></a>) splits a PNG image into a 2839 sequence of reduced images (the interlaced PNG image) where the 2840 first image defines a coarse view and subsequent images enhance 2841 this coarse view until the last image completes the PNG image. 2842 This allows progressive display of the interlaced PNG image by 2843 the decoder and allows images to "fade in" when they are being 2844 displayed on-the-fly. On average, interlacing slightly expands 2845 the datastream size, but it can give the user a meaningful 2846 display much more rapidly.</p> 2847 2848 <h2><a name="8InterlaceMethods">8.2 Interlace methods</a></h2> 2849 2850 <p>Two interlace methods are defined in this International 2851 Standard, methods 0 and 1. Other values of interlace method are 2852 reserved for future standardization (see 4.9: <a href= 2853 "#4Concepts.Registration"><span class="xref">Extension and 2854 registration</span></a>).</p> 2855 2856 <p>With interlace method 0, the null method, pixels are extracted 2857 sequentially from left to right, and scanlines sequentially from 2858 top to bottom. The interlaced PNG image is a single reduced 2859 image.</p> 2860 2861 <p>Interlace method 1, known as Adam7, defines seven distinct 2862 passes over the image. Each pass transmits a subset of the pixels 2863 in the reference image. The pass in which each pixel is 2864 transmitted (numbered from 1 to 7) is defined by replicating the 2865 following 8-by-8 pattern over the entire image, starting at the 2866 upper left corner:</p> 2867 2868 <pre> 2869 1 6 4 6 2 6 4 6 2870 7 7 7 7 7 7 7 7 2871 5 6 5 6 5 6 5 6 2872 7 7 7 7 7 7 7 7 2873 3 6 4 6 3 6 4 6 2874 7 7 7 7 7 7 7 7 2875 5 6 5 6 5 6 5 6 2876 7 7 7 7 7 7 7 7 2877 </pre> 2878 2879 <p><a href="#figure48"><span class="figref">Figure 4.8</span></a> 2880 shows the seven passes of interlace method 1. Within each pass, 2881 the selected pixels are transmitted left to right within a 2882 scanline, and selected scanlines sequentially from top to bottom. 2883 For example, pass 2 contains pixels 4, 12, 20, etc. of scanlines 2884 0, 8, 16, etc. (where scanline 0, pixel 0 is the upper left 2885 corner). The last pass contains all of scanlines 1, 3, 5, etc. 2886 The transmission order is defined so that all the scanlines 2887 transmitted in a pass will have the same number of pixels; this 2888 is necessary for proper application of some of the filters. The 2889 interlaced PNG image consists of a sequence of seven reduced 2890 images. For example, if the PNG image is 16 by 16 pixels, then 2891 the third pass will be a reduced image of two scanlines, each 2892 containing four pixels (see <a href="#figure48"><span class= 2893 "figref">figure 4.8</span></a>).</p> 2894 2895 <p>Scanlines that do not completely fill an integral number of 2896 bytes are padded as defined in 7.2: <a href="#7Scanline"><span 2897 class="xref">Scanlines</span></a>.</p> 2898 2899 <p class="Note">NOTE If the reference image contains fewer than 2900 five columns or fewer than five rows, some passes will be 2901 empty.</p> 2902 2903 <!-- ************Page Break******************* --> 2904 <!-- ************Page Break******************* --> 2905 <h1><a name="9Filters">9 Filtering</a></h1> 2906 2907 <h2><a name="9FtIntro">9.1 Filter methods and filter 2908 types</a></h2> 2909 2910 <p>Filtering transforms the PNG image with the goal of 2911 improving compression. PNG allows for a number of filter methods. 2912 All the reduced 2913 images in an interlaced image shall use a single filter method. 2914 Only filter method 0 2915 is defined by this International Standard. Other filter methods 2916 are reserved for future standardization (see 4.9 <a href= 2917 "#4Concepts.Registration"><span class="xref">Extension and 2918 registration</span></a>). 2919 Filter method 0 provides a set of five filter types, 2920 and individual scanlines in each reduced image may use 2921 different filter types.</p> 2922 2923 <p>PNG imposes no additional restriction on which filter types 2924 can be applied to an interlaced PNG image. However, the filter 2925 types are not equally effective on all types of data. See 12.8: 2926 <a href="#12Filter-selection"><span class="xref">Filter 2927 selection</span></a>.</p> 2928 2929 <p>Filtering transforms the byte sequence in a scanline to an 2930 equal length sequence of bytes preceded by the filter type. 2931 Filter type bytes are associated only with non-empty scanlines. 2932 No filter type bytes are present in an empty pass. See 13.8: <a 2933 href="#13Progressive-display"><span class="xref">Interlacing and 2934 progressive display</span></a>.</p> 2935 2936 <h2><a name="9Filter-types">9.2 Filter types for filter method 2937 0</a></h2> 2938 2939 <p>Filters are applied to <strong>bytes</strong>, not to pixels, 2940 regardless of the bit depth or colour type of the image. The 2941 filters operate on the byte sequence formed by a scanline that 2942 has been represented as described in 7.2: <a href= 2943 "#7Scanline"><span class="xref">Scanlines</span></a>. If the image 2944 includes an alpha channel, the alpha data is filtered in the same 2945 way as the image data.</p> 2946 2947 <p>Filters may use the original values of the following bytes to 2948 generate the new byte value:</p> 2949 2950 <table class="Regular" summary= 2951 "This table defines the variables usedin table 9.1"> 2952 <tr> 2953 <td class="Regular"><tt>x</tt> </td> 2954 <td class="Regular">the byte being filtered;</td> 2955 </tr> 2956 2957 <tr> 2958 <td class="Regular"><tt>a</tt> </td> 2959 <td class="Regular">the byte corresponding to x in the pixel immediately before the pixel containing x (or the byte immediately before x, when the bit depth is less than 8);</td> 2960 </tr> 2961 2962 <tr> 2963 <td class="Regular"><tt>b</tt> </td> 2964 <td class="Regular">the byte corresponding to x in the previous scanline;</td> 2965 </tr> 2966 2967 <tr> 2968 <td class="Regular"><tt>c</tt> </td> 2969 <td class="Regular">the byte corresponding to b in the pixel immediately before the pixel containing b (or the byte immediately before b, when the bit depth is less than 8).</td> 2970 </tr> 2971 </table> 2972 2973 <p><a href="#9-figure91"><span class="figref">Figure 2974 9.1</span></a> shows the relative positions of the bytes <tt>x</tt>, 2975 <tt>a</tt>, <tt>b</tt>, 2976 and <tt>c</tt>.</p> 2977 2978 <p>PNG filter method 0 defines five basic filter types as listed 2979 in <a href="#9-table91"><span class="tabref">Table 2980 9.1</span></a>. <tt>Orig(y)</tt> denotes the orginal (unfiltered) 2981 value of byte <tt>y</tt>. <tt>Filt(y)</tt> denotes the value 2982 after a filter has been applied. <tt>Recon(y)</tt> denotes the 2983 value after the corresponding reconstruction function has been 2984 applied. The filter function for the Paeth type 2985 <tt>PaethPredictor</tt> is defined below.</p> 2986 2987 <p>Filter method 0 specifies exactly this set of five filter 2988 types and this shall not be extended. 2989 This ensures that decoders need not decompress the data 2990 to determine whether it contains unsupported filter types: 2991 it is sufficient to check the filter method in <a href="#11IHDR"><span class= 2992 "chunk">IHDR</span></a>.</p> 2993 2994 <!-- ************Page Break******************* --> 2995 <!-- ************Page Break******************* --> 2996 <table class="Regular" summary= 2997 "This table lists the filter types"> 2998 <caption><a name="9-table91"><b>Table 9.1 — Filter 2999 types</b></a></caption> 3000 3001 <tr> 3002 <th>Type</th> 3003 <th>Name</th> 3004 <th>Filter Function</th> 3005 <th>Reconstruction Function</th> 3006 </tr> 3007 3008 <tr> 3009 <td class="Regular" align="center">0</td> 3010 <td class="Regular">None</td> 3011 <td class="Regular"><tt>Filt(x) = Orig(x)</tt> </td> 3012 <td class="Regular"><tt>Recon(x) = Filt(x)</tt> </td> 3013 </tr> 3014 3015 <tr> 3016 <td class="Regular" align="center">1</td> 3017 <td class="Regular">Sub</td> 3018 <td class="Regular"><tt>Filt(x) = Orig(x) - Orig(a)</tt> </td> 3019 <td class="Regular"><tt>Recon(x) = Filt(x) + Recon(a)</tt> </td> 3020 </tr> 3021 3022 <tr> 3023 <td class="Regular" align="center">2</td> 3024 <td class="Regular">Up</td> 3025 <td class="Regular"><tt>Filt(x) = Orig(x) - Orig(b)</tt> </td> 3026 <td class="Regular"><tt>Recon(x) = Filt(x) + Recon(b)</tt> </td> 3027 </tr> 3028 3029 <tr> 3030 <td class="Regular" align="center">3</td> 3031 <td class="Regular">Average</td> 3032 <td class="Regular"><tt>Filt(x) = Orig(x) - floor((Orig(a) + Orig(b)) / 3033 2)</tt> </td> 3034 <td class="Regular"><tt>Recon(x) = Filt(x) + floor((Recon(a) + Recon(b)) / 3035 2)</tt> </td> 3036 </tr> 3037 3038 <tr> 3039 <td class="Regular" align="center">4</td> 3040 <td class="Regular">Paeth</td> 3041 <td class="Regular"><tt>Filt(x) = Orig(x) - PaethPredictor(Orig(a), 3042 Orig(b), Orig(c))</tt> </td> 3043 <td class="Regular"><tt>Recon(x) = Filt(x) + PaethPredictor(Recon(a), Recon(b), 3044 Recon(c))</tt> </td> 3045 </tr> 3046 </table> 3047 3048 <p>For all filters, the bytes "to the left of" the first pixel in 3049 a scanline shall be treated as being zero. For filters that refer 3050 to the prior scanline, the entire prior scanline and bytes "to 3051 the left of" the first pixel in the prior scanline shall be 3052 treated as being zeroes for the first scanline of a reduced 3053 image.</p> 3054 3055 <p>To reverse the effect of a filter requires the decoded values 3056 of the prior pixel on the same scanline, the pixel immediately 3057 above the current pixel on the prior scanline, and the pixel just 3058 to the left of the pixel above.</p> 3059 3060 <p>Unsigned arithmetic modulo 256 is used, so that both the 3061 inputs and outputs fit into bytes. Filters are applied to each 3062 byte regardless of bit depth. The sequence of <tt>Filt</tt> 3063 values is transmitted as the filtered scanline.</p> 3064 3065 <h2><a name="9Filter-type-3-Average">9.3 Filter type 3: 3066 Average</a></h2> 3067 3068 <p>The sum <tt>Orig(a) + Orig(b)</tt> shall be performed without 3069 overflow (using at least nine-bit arithmetic). <tt>floor()</tt> 3070 indicates that the result of the division is rounded to the next 3071 lower integer if fractional; in other words, it is an integer 3072 division or right shift operation.</p> 3073 3074 <h2><a name="9Filter-type-4-Paeth">9.4 Filter type 4: 3075 Paeth</a></h2> 3076 3077 <p>The Paeth filter function computes a simple linear function of 3078 the three neighbouring pixels (left, above, upper left), then 3079 chooses as predictor the neighbouring pixel closest to the 3080 computed value. The algorithm used in this International Standard 3081 is an adaptation of the technique due to Alan W. Paeth <a href= 3082 "#G-PAETH"><span class="bibref">[PAETH]</span></a>.</p> 3083 3084 <p>The PaethPredictor function is defined in the code below. The 3085 logic of the function and the locations of the bytes <tt>a</tt>, 3086 <tt>b</tt>, <tt>c</tt>, and <tt>x</tt> are shown in <a href= 3087 "#9-figure91"><span class="figref">figure 9.1</span></a>. 3088 <tt>Pr</tt> is the predictor for byte <tt>x</tt>.</p> 3089 3090 <pre> 3091 p = a + b - c 3092 pa = abs(p - a) 3093 pb = abs(p - b) 3094 pc = abs(p - c) 3095 if pa <= pb and pa <= pc then Pr = a 3096 else if pb <= pc then Pr = b 3097 else Pr = c 3098 return Pr 3099 </pre> 3100 3101 <!-- ************Page Break******************* --> 3102 <!-- ************Page Break******************* --> 3103 <p><a name="9-figure91"> 3104 <object height="360" width="640" data="figures/fig91.svg" type="image/svg+xml"> 3105 <img height="360" width="640" src="png-figures/fig91.png" alt="Figure 9.1: The PaethPredictor 3106 function" /> 3107 </object> 3108 </a></p> 3109 3110 <p class="Figuretitle"><b>Figure 9.1: The PaethPredictor 3111 function</b></p> 3112 3113 <p>The calculations within the PaethPredictor function shall be 3114 performed exactly, without overflow.</p> 3115 3116 <p><strong>The order in which the comparisons are performed is 3117 critical and shall not be altered.</strong> The function tries to 3118 establish in which of the three directions (vertical, horizontal, 3119 or diagonal) the gradient of the image is smallest.</p> 3120 3121 <p>Exactly the same PaethPredictor function is used by both 3122 encoder and decoder.</p> 3123 3124 <!-- ************Page Break******************* --> 3125 <!-- ************Page Break******************* --> 3126 <h1><a name="10Compression">10 Compression</a></h1> 3127 3128 <h2><a name="10CompressionCM0">10.1 Compression method 0</a></h2> 3129 3130 <p>Only PNG compression method 0 is defined by this International 3131 Standard. Other values of compression method are reserved for 3132 future standardization (see 4.9: <a href= 3133 "#4Concepts.Registration"><span class="xref">Extension and 3134 registration</span></a>). PNG compression method 0 is 3135 deflate/inflate compression with a sliding window 3136 (which is an upper bound on the distances appearing in the 3137 deflate stream) of at most 3138 32768 bytes. Deflate compression is an LZ77 derivative <a href= 3139 "#G-ZL"><span class="bibref">[ZL]</span></a>.</p> 3140 3141 <p>Deflate-compressed datastreams within PNG are stored in the 3142 "zlib" format, which has the structure:</p> 3143 3144 <table class="Regular" summary= 3145 "This table gives the structure of the zlib format"> 3146 <tr> 3147 <td class="Regular">zlib compression method/flags code</td> 3148 <td class="Regular">1 byte</td> 3149 </tr> 3150 3151 <tr> 3152 <td class="Regular">Additional flags/check bits</td> 3153 <td class="Regular">1 byte</td> 3154 </tr> 3155 3156 <tr> 3157 <td class="Regular">Compressed data blocks</td> 3158 <td class="Regular">n bytes</td> 3159 </tr> 3160 3161 <tr> 3162 <td class="Regular">Check value</td> 3163 <td class="Regular">4 bytes</td> 3164 </tr> 3165 </table> 3166 3167 <p>Further details on this format are given in the zlib 3168 specification <a href="#2-RFC-1950"><span class= 3169 "NormRef">[RFC-1950]</span></a>.</p> 3170 3171 <p>For PNG compression method 0, the zlib compression 3172 method/flags code shall specify method code 8 (deflate 3173 compression) and an LZ77 window size of not more than 32768 3174 bytes. The zlib compression method number is not the same as the 3175 PNG compression method number in the <a href= 3176 "#11IHDR"><span class="chunk">IHDR</span></a> chunk (see 11.2.2 3177 <a href="#11IHDR"><span class="xref"><span class= 3178 "chunk">IHDR</span> Image header</span></a>). The additional 3179 flags shall not specify a preset dictionary.</p> 3180 3181 <p>If the data to be compressed contain 16384 bytes or fewer, the 3182 PNG encoder may set the window size by rounding up to a power of 3183 2 (256 minimum). This decreases the memory required for both 3184 encoding and decoding, without adversely affecting the 3185 compression ratio.</p> 3186 3187 <p>The compressed data within the zlib datastream are stored as a 3188 series of blocks, each of which can represent raw (uncompressed) 3189 data, LZ77-compressed data encoded with fixed Huffman codes, or 3190 LZ77-compressed data encoded with custom Huffman codes. A marker 3191 bit in the final block identifies it as the last block, allowing 3192 the decoder to recognize the end of the compressed datastream. 3193 Further details on the compression algorithm and the encoding are 3194 given in the deflate specification <a href="#2-RFC-1951"><span 3195 class="NormRef">[RFC-1951]</span></a>.</p> 3196 3197 <p>The check value stored at the end of the zlib datastream is 3198 calculated on the uncompressed data represented by the 3199 datastream. The algorithm used to calculate this is not the same 3200 as the CRC calculation used for PNG chunk CRC field values. The 3201 zlib check value is useful mainly as a cross-check that the 3202 deflate and inflate algorithms are implemented correctly. 3203 Verifying the individual PNG chunk CRCs provides confidence that 3204 the PNG datastream has been transmitted undamaged.</p> 3205 3206 <h2><a name="10CompressionFSL">10.2 Compression of the sequence 3207 of filtered scanlines</a></h2> 3208 3209 <p>The sequence of filtered scanlines is compressed and the 3210 resulting data stream is split into <a href="#11IDAT"><span 3211 class="chunk">IDAT</span></a> chunks. The concatenation of the 3212 contents of all the <a href="#11IDAT"><span class= 3213 "chunk">IDAT</span></a> chunks makes up a zlib datastream. This 3214 datastream decompresses to filtered image data.</p> 3215 3216 <p>It is important to emphasize that the boundaries between <a 3217 href="#11IDAT"><span class="chunk">IDAT</span></a> chunks are 3218 arbitrary and can fall anywhere in the zlib datastream. There is 3219 not necessarily any correlation between <a href="#11IDAT"><span 3220 class="chunk">IDAT</span></a> chunk boundaries and deflate block 3221 boundaries or any other feature of the zlib data. For example, it 3222 is entirely possible for the terminating zlib check value to be 3223 split across <a href="#11IDAT"><span class= 3224 "chunk">IDAT</span></a> chunks.</p> 3225 3226 <p>Similarly, there is no required correlation between the 3227 structure of the image data (i.e., scanline boundaries) and 3228 deflate block boundaries or <a href="#11IDAT"><span class= 3229 "chunk">IDAT</span></a> chunk boundaries. The complete filtered 3230 PNG image is represented by a single zlib datastream that is 3231 stored in a number of <a href="#11IDAT"><span class= 3232 "chunk">IDAT</span></a> chunks.</p> 3233 3234 <!-- ************Page Break******************* --> 3235 <!-- ************Page Break******************* --> 3236 <h2><a name="10CompressionOtherUses">10.3 Other uses of 3237 compression</a></h2> 3238 3239 <p>PNG also uses compression method 0 in <a href="#11iTXt"><span 3240 class="chunk">iTXt</span></a>, <a href="#11iCCP"><span class= 3241 "chunk">iCCP</span></a>, and <a href="#11zTXt"><span class= 3242 "chunk">zTXt</span></a> chunks. Unlike the image data, such 3243 datastreams are not split across chunks; each such chunk contains 3244 an independent zlib datastream (see 10.1: <a href= 3245 "#10CompressionCM0"><span class="xref">Compression method 3246 0</span></a>).</p> 3247 3248 <!-- ************Page Break******************* --> 3249 <!-- ************Page Break******************* --> 3250 <h1><a name="11Chunks">11 Chunk specifications</a></h1> 3251 3252 <h2><a name="11Introduction">11.1 Introduction</a></h2> 3253 3254 <p>The PNG datastream consists of a PNG signature (see 5.2: <a 3255 href="#5PNG-file-signature"><span class="xref">PNG 3256 signature</span></a>) followed by a sequence of chunks. Each 3257 chunk has a chunk type which specifies its function. This clause 3258 defines the PNG chunk types standardized in this International 3259 Standard. The PNG datastream structure is defined in clause 5: <a 3260 href="#5DataRep"><span class="xref">Datastream 3261 structure</span></a>. This also defines the order in which chunks 3262 may appear. For details specific to encoders see 12.11: <a href= 3263 "#12Chunk-processing"><span class="xref">Chunking</span></a>. 3264 For details specific to decoders see 13.5: <a href= 3265 "#13Chunking"><span class="xref">Chunking</span></a>.</p> 3266 3267 <h2><a name="11Critical-chunks">11.2 Critical chunks</a></h2> 3268 3269 <h3><a name="11CcGen">11.2.1 General</a></h3> 3270 3271 <p>Critical chunks are those chunks that are absolutely required 3272 in order to successfully decode a PNG image from a PNG 3273 datastream. Extension chunks may be defined as critical chunks 3274 (see clause 14: <a href="#14EditorsExt"><span class= 3275 "xref">Editors and extensions</span></a>), though this practice 3276 is strongly discouraged.</p> 3277 3278 <p>A valid PNG datastream shall begin with a PNG signature, 3279 immediately followed by an <a href="#11IHDR"><span class= 3280 "chunk">IHDR</span></a> chunk, then one or more <a href= 3281 "#11IDAT"><span class="chunk">IDAT</span></a> chunks, and shall 3282 end with an <a href="#11IEND"><span class="chunk">IEND</span></a> 3283 chunk. Only one <a href="#11IHDR"><span class= 3284 "chunk">IHDR</span></a> chunk and one <a href="#11IEND"><span 3285 class="chunk">IEND</span></a> chunk are allowed in a PNG 3286 datastream.</p> 3287 3288 <h3><a name="11IHDR">11.2.2 <span class="chunk">IHDR</span> Image 3289 header</a></h3> 3290 3291 <p>The four-byte chunk type field contains the decimal values</p> 3292 3293 <pre> 3294 73 72 68 82 3295 </pre> 3296 3297 <p>The <span class="chunk">IHDR</span> chunk shall be the first 3298 chunk in the PNG datastream. It contains:</p> 3299 3300 <table class="Regular" summary= 3301 "This table defines the IHDR chunk"> 3302 <tr> 3303 <td class="Regular">Width</td> 3304 <td class="Regular">4 bytes</td> 3305 </tr> 3306 3307 <tr> 3308 <td class="Regular">Height</td> 3309 <td class="Regular">4 bytes</td> 3310 </tr> 3311 3312 <tr> 3313 <td class="Regular">Bit depth</td> 3314 <td class="Regular">1 byte</td> 3315 </tr> 3316 3317 <tr> 3318 <td class="Regular">Colour type</td> 3319 <td class="Regular">1 byte</td> 3320 </tr> 3321 3322 <tr> 3323 <td class="Regular">Compression method</td> 3324 <td class="Regular">1 byte</td> 3325 </tr> 3326 3327 <tr> 3328 <td class="Regular">Filter method</td> 3329 <td class="Regular">1 byte</td> 3330 </tr> 3331 3332 <tr> 3333 <td class="Regular">Interlace method</td> 3334 <td class="Regular">1 byte</td> 3335 </tr> 3336 </table> 3337 3338 <p>Width and height give the image dimensions in pixels. They are 3339 PNG four-byte unsigned integers. Zero is an invalid 3340 value.</p> 3341 3342 <p>Bit depth is a single-byte integer giving the number of bits 3343 per sample or per palette index (not per pixel). Valid values are 3344 1, 2, 4, 8, and 16, although not all values are allowed for all 3345 colour types. See 6.1: <a href="#6Colour-values"><span class= 3346 "xref">Colour types and values</span></a>.</p> 3347 3348 <p>Colour type is a single-byte integer that defines the PNG 3349 image type. Valid values are 0, 2, 3, 4, and 6.</p> 3350 3351 <p>Bit depth restrictions for each colour type are imposed to 3352 simplify implementations and to prohibit combinations that do not 3353 compress well. The allowed combinations are defined in <a href= 3354 "#table111"><span class="tabref">Table 11.1</span></a>.</p> 3355 3356 <table class="Regular" summary= 3357 "This table defines the colour types"> 3358 <caption><a name="table111"><b>Table 11.1 — Allowed 3359 combinations of colour type and bit depth</b></a></caption> 3360 3361 <tr> 3362 <th>PNG image type</th> 3363 <th>Colour type</th> 3364 <th>Allowed bit depths</th> 3365 <th>Interpretation</th> 3366 </tr> 3367 3368 <tr> 3369 <td class="Regular">Greyscale</td> 3370 <td class="Regular" align="center">0</td> 3371 <td class="Regular">1, 2, 4, 8, 16</td> 3372 <td class="Regular">Each pixel is a greyscale sample</td> 3373 </tr> 3374 3375 <tr> 3376 <td class="Regular">Truecolour</td> 3377 <td class="Regular" align="center">2</td> 3378 <td class="Regular">8, 16</td> 3379 <td class="Regular">Each pixel is an R,G,B triple</td> 3380 </tr> 3381 3382 <tr> 3383 <td class="Regular">Indexed-colour</td> 3384 <td class="Regular" align="center">3</td> 3385 <td class="Regular">1, 2, 4, 8</td> 3386 <td class="Regular">Each pixel is a palette index; a <a href="#11PLTE"><span 3387 class="chunk">PLTE</span></a> chunk shall appear.</td> 3388 </tr> 3389 3390 <tr> 3391 <td class="Regular">Greyscale with alpha</td> 3392 <td class="Regular" align="center">4</td> 3393 <td class="Regular">8, 16</td> 3394 <td class="Regular">Each pixel is a greyscale sample followed by an alpha 3395 sample.</td> 3396 </tr> 3397 3398 <tr> 3399 <td class="Regular">Truecolour with alpha</td> 3400 <td class="Regular" align="center">6</td> 3401 <td class="Regular">8, 16</td> 3402 <td class="Regular">Each pixel is an R,G,B triple followed by an alpha 3403 sample.</td> 3404 </tr> 3405 </table> 3406 3407 <p>The sample depth is the same as the bit depth except in the 3408 case of indexed-colour PNG images (colour type 3), in which the 3409 sample depth is always 8 bits (see 4.4: <a href= 3410 "#4Concepts.PNGImage"><span class="xref">PNG image</span></a>).</p> 3411 3412 <p>Compression method is a single-byte integer that indicates the 3413 method used to compress the image data. Only compression method 0 3414 (deflate/inflate compression with a sliding window of at most 3415 32768 bytes) is defined in this International Standard. All 3416 conforming PNG images shall be compressed with this scheme.</p> 3417 3418 <p>Filter method is a single-byte integer that indicates the 3419 preprocessing method applied to the image data before 3420 compression. Only filter method 0 (adaptive filtering with five 3421 basic filter types) is defined in this International Standard. 3422 See clause 9: <a href="#9Filters"><span class= 3423 "xref">Filtering</span></a> for details.</p> 3424 3425 <p>Interlace method is a single-byte integer that indicates the 3426 transmission order of the image data. Two values are defined in 3427 this International Standard: 0 (no interlace) or 1 (Adam7 3428 interlace). See clause 8: <a href="#8Interlace"><span class= 3429 "xref">Interlacing and pass extraction</span></a> for 3430 details.</p> 3431 3432 <h3><a name="11PLTE">11.2.3 <span class="chunk">PLTE</span> 3433 Palette</a></h3> 3434 3435 <p>The four-byte chunk type field contains the decimal values</p> 3436 3437 <pre> 3438 80 76 84 69 3439 </pre> 3440 3441 <p>The <span class="chunk">PLTE</span> chunk contains from 1 to 3442 256 palette entries, each a three-byte series of the form:</p> 3443 3444 <table class="Regular" summary= 3445 "This table defines the PLTE palette table entries"> 3446 <tr> 3447 <td class="Regular">Red</td> 3448 <td class="Regular">1 byte</td> 3449 </tr> 3450 3451 <tr> 3452 <td class="Regular">Green</td> 3453 <td class="Regular">1 byte</td> 3454 </tr> 3455 3456 <tr> 3457 <td class="Regular">Blue</td> 3458 <td class="Regular">1 byte</td> 3459 </tr> 3460 </table> 3461 3462 <p>The number of entries is determined from the chunk length. A 3463 chunk length not divisible by 3 is an error.</p> 3464 3465 <p>This chunk shall appear for colour type 3, and may appear for 3466 colour types 2 and 6; it shall not appear for colour types 0 and 3467 4. There shall not be more than one <span class= 3468 "chunk">PLTE</span> chunk.</p> 3469 3470 <p>For colour type 3 (indexed-colour), the <span class= 3471 "chunk">PLTE</span> chunk is required. The first entry in <span 3472 class="chunk">PLTE</span> is referenced by pixel value 0, the 3473 second by pixel value 1, etc. The number of palette entries shall 3474 not exceed the range that can be represented in the image bit 3475 depth (for example, 2<sup>4</sup> = 16 for a bit depth of 4). It 3476 is permissible to have fewer entries than the bit depth would 3477 allow. In that case, any out-of-range pixel value found in the 3478 image data is an error.</p> 3479 3480 <p>For colour types 2 and 6 (truecolour and truecolour with 3481 alpha), the <span class="chunk">PLTE</span> chunk is optional. If 3482 present, it provides a suggested set of colours (from 1 to 256) 3483 to which the truecolour image can be quantized if it cannot be 3484 displayed directly. It is, however, recommended that the <a href= 3485 "#11sPLT"><span class="chunk">sPLT</span></a> chunk be used for 3486 this purpose, rather than the <span class="chunk">PLTE</span> 3487 chunk. If neither <span class="chunk">PLTE</span> nor <a href= 3488 "#11sPLT"><span class="chunk">sPLT</span></a> chunks are present 3489 and the image cannot be displayed directly, quantization has to 3490 be done by the viewing system. However, it is often preferable 3491 for the selection of colours to be done once by the PNG encoder. 3492 (See 12.6: <a href="#12Suggested-palettes"><span class= 3493 "xref">Suggested palettes</span></a>.)</p> 3494 3495 <p>Note that the palette uses 8 bits (1 byte) per sample 3496 regardless of the image bit depth. In particular, 3497 the palette is 8 bits deep even when it is a suggested 3498 quantization of a 16-bit truecolour image.</p> 3499 3500 <p>There is no requirement that the palette entries all be used 3501 by the image, nor that they all be different.</p> 3502 3503 <h3><a name="11IDAT">11.2.4 <span class="chunk">IDAT</span> Image 3504 data</a></h3> 3505 3506 <p>The four-byte chunk type field contains the decimal values</p> 3507 3508 <pre> 3509 73 68 65 84 3510 </pre> 3511 3512 <p>The <span class="chunk">IDAT</span> chunk contains the actual 3513 image data which is the output stream of the compression 3514 algorithm. See clause 9: <a href="#9Filters"><span class= 3515 "xref">Filtering</span></a> and clause 10: <a href= 3516 "#10Compression"><span class="xref">Compression</span></a> for 3517 details.</p> 3518 3519 <p>There may be multiple <span class="chunk">IDAT</span> chunks; 3520 if so, they shall appear consecutively with no other intervening 3521 chunks. The compressed datastream is then the concatenation of 3522 the contents of the data fields of all the <span class= 3523 "chunk">IDAT</span> chunks.</p> 3524 3525 <h3><a name="11IEND">11.2.5 <span class="chunk">IEND</span> Image 3526 trailer</a></h3> 3527 3528 <p>The four-byte chunk type field contains the decimal values</p> 3529 3530 <pre> 3531 73 69 78 68 3532 </pre> 3533 3534 <p>The <span class="chunk">IEND</span> chunk marks the end of the 3535 PNG datastream. The chunk's data field is empty.</p> 3536 3537 <h2><a name="11Ancillary-chunks">11.3 Ancillary chunks</a></h2> 3538 3539 <h3><a name="11AcGen">11.3.1 General</a></h3> 3540 3541 <p>The ancillary chunks defined in this International Standard 3542 are listed in the order in 4.7.2: <a href= 3543 "#4Concepts.FormatTypes"><span class="xref">Chunk 3544 types</span></a>. This is not the order in which they appear in a 3545 PNG datastream. Ancillary chunks may be ignored by a decoder. For 3546 each ancillary chunk, the actions described are under the 3547 assumption that the decoder is not ignoring the chunk.</p> 3548 3549 <h3><a name="11transinfo">11.3.2 Transparency 3550 information</a></h3> 3551 3552 <h4><a name="11tRNS">11.3.2.1 <span class="chunk">tRNS</span> 3553 Transparency</a></h4> 3554 3555 <p>The four-byte chunk type field contains the decimal values</p> 3556 3557 <pre> 3558 116 82 78 83 3559 </pre> 3560 3561 <p>The <span class="chunk">tRNS</span> chunk specifies either 3562 alpha values that are associated with palette entries (for 3563 indexed-colour images) or a single transparent colour (for 3564 greyscale and truecolour images). The <span class= 3565 "chunk">tRNS</span> chunk contains: 3566 <!-- ************Page Break******************* --> 3567 </p> 3568 3569 <!-- ************Page Break******************* --> 3570 <table class="Regular" summary= 3571 "This table defines the tRNS chunk"> 3572 <tr> 3573 <th colspan="2">Colour type 0</th> 3574 </tr> 3575 3576 <tr> 3577 <td class="Regular">Grey sample value</td> 3578 <td class="Regular">2 bytes</td> 3579 </tr> 3580 3581 <tr> 3582 <th colspan="2">Colour type 2</th> 3583 </tr> 3584 3585 <tr> 3586 <td class="Regular">Red sample value</td> 3587 <td class="Regular">2 bytes</td> 3588 </tr> 3589 3590 <tr> 3591 <td class="Regular">Blue sample value</td> 3592 <td class="Regular">2 bytes</td> 3593 </tr> 3594 3595 <tr> 3596 <td class="Regular">Green sample value</td> 3597 <td class="Regular">2 bytes</td> 3598 </tr> 3599 3600 <tr> 3601 <th colspan="2">Colour type 3</th> 3602 </tr> 3603 3604 <tr> 3605 <td class="Regular">Alpha for palette index 0</td> 3606 <td class="Regular">1 byte</td> 3607 </tr> 3608 3609 <tr> 3610 <td class="Regular">Alpha for palette index 1</td> 3611 <td class="Regular">1 byte</td> 3612 </tr> 3613 3614 <tr> 3615 <td class="Regular">...etc...</td> 3616 <td class="Regular">1 byte</td> 3617 </tr> 3618 </table> 3619 3620 <p>For colour type 3 (indexed-colour), the <span class= 3621 "chunk">tRNS</span> chunk contains a series of one-byte alpha 3622 values, corresponding to entries in the <a href="#11PLTE"><span 3623 class="chunk">PLTE</span></a> chunk. Each entry indicates that 3624 pixels of the corresponding palette index shall be treated as 3625 having the specified alpha value. Alpha values have the same 3626 interpretation as in an 8-bit full alpha channel: 0 is fully 3627 transparent, 255 is fully opaque, regardless of image bit depth. 3628 The <span class="chunk">tRNS</span> chunk shall not contain more 3629 alpha values than there are palette entries, but a <span class= 3630 "chunk">tRNS</span> chunk may contain fewer values than there are 3631 palette entries. In this case, the alpha value for all remaining 3632 palette entries is assumed to be 255. In the common case in which 3633 only palette index 0 need be made transparent, only a one-byte 3634 <span class="chunk">tRNS</span> chunk is needed, and when all 3635 palette indices are opaque, the <span class="chunk">tRNS</span> 3636 chunk may be omitted.</p> 3637 3638 <p>For colour types 0 or 2, two bytes per sample are used 3639 regardless of the image bit depth (see 7.1: <a href= 3640 "#7Integers-and-byte-order"><span class="xref">Integers and byte 3641 order</span></a>). Pixels of the specified grey sample value or 3642 RGB sample values are treated as transparent (equivalent to alpha 3643 value 0); all other pixels are to be treated as fully opaque 3644 (alpha value 2<sup>bitdepth</sup>-1). If the image bit depth is 3645 less than 16, the least significant bits are used and the others 3646 are 0.</p> 3647 3648 <p>A <span class="chunk">tRNS</span> chunk shall not appear for 3649 colour types 4 and 6, since a full alpha channel is already 3650 present in those cases.</p> 3651 3652 <p class="Note">NOTE For 16-bit greyscale or truecolour data, 3653 only pixels matching the entire 16-bit values in <span class= 3654 "chunk">tRNS</span> chunks are transparent. Decoders have to 3655 postpone any sample depth rescaling until after the pixels have 3656 been tested for transparency.</p> 3657 3658 <h3><a name="11addnlcolinfo">11.3.3 Colour space 3659 information</a></h3> 3660 3661 <h4><a name="11cHRM">11.3.3.1 <span class="chunk">cHRM</span> 3662 Primary chromaticities and white point</a></h4> 3663 3664 <p>The four-byte chunk type field contains the decimal values</p> 3665 3666 <pre> 3667 99 72 82 77 3668 </pre> 3669 3670 <p>The <span class="chunk">cHRM</span> chunk may be used to 3671 specify the 1931 CIE <i>x,y</i> chromaticities of the red, 3672 green, and blue display primaries used in the image, and the referenced 3673 white point. See Annex C: <a href="#C-GammaAppendix"><span class= 3674 "xref">Gamma and chromaticity</span></a> for more information. 3675 The <a href="#11iCCP"><span class="chunk">iCCP</span></a> and <a 3676 href="#11sRGB"><span class="chunk">sRGB</span></a> chunks provide 3677 more sophisticated support for colour management and control.</p> 3678 3679 <p>The <span class="chunk">cHRM</span> chunk contains:</p> 3680 3681 <!-- ************Page Break******************* --> 3682 <!-- ************Page Break******************* --> 3683 <table class="Regular" summary= 3684 "This table defines the cHRM chunk"> 3685 <tr> 3686 <td class="Regular">White point x</td> 3687 <td class="Regular">4 bytes</td> 3688 </tr> 3689 3690 <tr> 3691 <td class="Regular">White point y</td> 3692 <td class="Regular">4 bytes</td> 3693 </tr> 3694 3695 <tr> 3696 <td class="Regular">Red x</td> 3697 <td class="Regular">4 bytes</td> 3698 </tr> 3699 3700 <tr> 3701 <td class="Regular">Red y</td> 3702 <td class="Regular">4 bytes</td> 3703 </tr> 3704 3705 <tr> 3706 <td class="Regular">Green x</td> 3707 <td class="Regular">4 bytes</td> 3708 </tr> 3709 3710 <tr> 3711 <td class="Regular">Green y</td> 3712 <td class="Regular">4 bytes</td> 3713 </tr> 3714 3715 <tr> 3716 <td class="Regular">Blue x</td> 3717 <td class="Regular">4 bytes</td> 3718 </tr> 3719 3720 <tr> 3721 <td class="Regular">Blue y</td> 3722 <td class="Regular">4 bytes</td> 3723 </tr> 3724 </table> 3725 3726 <p>Each value is encoded as a four-byte PNG unsigned integer, 3727 representing the <i>x</i> or <i>y</i> value times 100000.</p> 3728 3729 <p>EXAMPLE A value of 0.3127 would be stored as the integer 3730 31270.</p> 3731 3732 <p>The <span class="chunk">cHRM</span> chunk is allowed in all 3733 PNG datastreams, although it is of little value for greyscale 3734 images.</p> 3735 3736 <p>An <a href="#11sRGB"><span class="chunk">sRGB</span></a> chunk 3737 or <a href="#11iCCP"><span class="chunk">iCCP</span></a> chunk, 3738 when present and recognized, overrides the <span class= 3739 "chunk">cHRM</span> chunk.</p> 3740 3741 <h4><a name="11gAMA">11.3.3.2 <span class="chunk">gAMA</span> 3742 Image gamma</a></h4> 3743 3744 <p>The four-byte chunk type field contains the decimal values</p> 3745 3746 <pre> 3747 103 65 77 65 3748 </pre> 3749 3750 <p>The <span class="chunk">gAMA</span> chunk specifies the 3751 relationship between the image samples and the desired display 3752 output intensity. Gamma is defined in 3.1.20: <a href= 3753 "#3gamma">gamma</a>.</p> 3754 3755 <p>In fact specifying the desired display output intensity is 3756 insufficient. It is also necessary to specify the viewing 3757 conditions under which the output is desired. For <span class= 3758 "chunk">gAMA</span> these are the reference viewing conditions of 3759 the sRGB specification <a href="#2-IEC-61966-2-1"><span class= 3760 "NormRef">[IEC 61966-2-1]</span></a>, which are based on ISO 3664 3761 <a href="#G-ISO-3664"><span class="bibref">[ISO-3664]</span></a>. 3762 Adjustment for different viewing conditions is normally handled 3763 by a Colour Management System. If the adjustment is not 3764 performed, the error is usually small. Applications desiring high 3765 colour fidelity may wish to use an <a href="#11sRGB"><span class= 3766 "chunk">sRGB</span></a> chunk or <a href="#11iCCP"><span class= 3767 "chunk">iCCP</span></a> chunk.</p> 3768 3769 <p>The <span class="chunk">gAMA</span> chunk contains:</p> 3770 3771 <table class="Regular" summary= 3772 "This table defines the gAMA chunk"> 3773 <tr> 3774 <td class="Regular">Image gamma</td> 3775 <td class="Regular">4 bytes</td> 3776 </tr> 3777 </table> 3778 3779 <p>The value is encoded as a four-byte PNG unsigned integer, 3780 representing gamma times 100000.</p> 3781 3782 <p>EXAMPLE A gamma of 1/2.2 would be stored as the integer 3783 45455.</p> 3784 3785 <p>See 12.2: <a href="#12Encoder-gamma-handling"><span class= 3786 "xref">Encoder gamma handling</span></a> and 13.13: <a href= 3787 "#13Decoder-gamma-handling"><span class="xref">Decoder gamma 3788 handling</span></a> for more information.</p> 3789 3790 <p>An <a href="#11sRGB"><span class="chunk">sRGB</span></a> chunk 3791 or <a href="#11iCCP"><span class="chunk">iCCP</span></a> chunk, 3792 when present and recognized, overrides the <span class= 3793 "chunk">gAMA</span> chunk.</p> 3794 3795 <h4><a name="11iCCP">11.3.3.3 <span class="chunk">iCCP</span> 3796 Embedded ICC profile</a></h4> 3797 3798 <p>The four-byte chunk type field contains the decimal values</p> 3799 3800 <pre> 3801 105 67 67 80 3802 </pre> 3803 3804 <p>The <span class="chunk">iCCP</span> chunk contains:</p> 3805 3806 <table class="Regular" summary= 3807 "This table defines the iCCP chunk"> 3808 <tr> 3809 <td class="Regular">Profile name</td> 3810 <td class="Regular">1-79 bytes (character string)</td> 3811 </tr> 3812 3813 <tr> 3814 <td class="Regular">Null separator</td> 3815 <td class="Regular">1 byte (null character)</td> 3816 </tr> 3817 3818 <tr> 3819 <td class="Regular">Compression method</td> 3820 <td class="Regular">1 byte</td> 3821 </tr> 3822 3823 <tr> 3824 <td class="Regular">Compressed profile</td> 3825 <td class="Regular">n bytes</td> 3826 </tr> 3827 </table> 3828 3829 <p>The profile name may be any convenient name for referring to 3830 the profile. It is case-sensitive. Profile names shall contain 3831 only printable Latin-1 characters and spaces (only character 3832 codes 32-126 and 161-255 decimal are allowed). Leading, trailing, 3833 and consecutive spaces are not permitted. The only compression 3834 method defined in this International Standard is method 0 (zlib 3835 datastream with deflate compression, see 10.3: <a href= 3836 '#10CompressionOtherUses'><span class="xref">Other uses of 3837 compression</span></a>). The compression method entry is followed 3838 by a compressed profile that makes up the remainder of the chunk. 3839 Decompression of this datastream yields the embedded ICC 3840 profile.</p> 3841 3842 <p>If the <span class="chunk">iCCP</span> chunk is present, the 3843 image samples conform to the colour space represented by the 3844 embedded ICC profile as defined by the International Color 3845 Consortium <a href="#G-ICC"><span class= 3846 "bibref">[ICC]</span></a>. The colour space of the ICC profile 3847 shall be an RGB colour space for colour images (PNG colour types 3848 2, 3, and 6), or a greyscale colour space for greyscale images 3849 (PNG colour types 0 and 4). A PNG encoder that writes the <span 3850 class="chunk">iCCP</span> chunk is encouraged to also write <a 3851 href="#11gAMA"><span class="chunk">gAMA</span></a> and <a href= 3852 "#11cHRM"><span class="chunk">cHRM</span></a> chunks that 3853 approximate the ICC profile, to provide compatibility with 3854 applications that do not use the <span class="chunk">iCCP</span> 3855 chunk. When the <span class="chunk">iCCP</span> chunk is present, 3856 PNG decoders that recognize it and are capable of colour 3857 management <a href="#G-ICC"><span class="bibref">[ICC]</span></a> 3858 shall ignore the <a href="#11gAMA"><span class= 3859 "chunk">gAMA</span></a> and <a href="#11cHRM"><span class= 3860 "chunk">cHRM</span></a> chunks and use the <span class= 3861 "chunk">iCCP</span> chunk instead and interpret it according to 3862 <a href="#2-ICC-1"><span class="NormRef">[ICC-1]</span></a> and 3863 <a href="#2-ICC-1A"><span class="NormRef">[ICC-1A]</span></a>. 3864 PNG decoders that are used in an environment that is incapable of 3865 full-fledged colour management should use the <a href= 3866 "#11gAMA"><span class="chunk">gAMA</span></a> and <a href= 3867 "#11cHRM"><span class="chunk">cHRM</span></a> chunks if 3868 present.</p> 3869 3870 <p>A PNG datastream should contain at most one embedded profile, 3871 whether specified explicitly with an <span class= 3872 "chunk">iCCP</span> chunk or implicitly with an <a href= 3873 "#11sRGB"><span class="chunk">sRGB</span></a> chunk.</p> 3874 3875 <h4><a name="11sBIT">11.3.3.4 <span class="chunk">sBIT</span> 3876 Significant bits</a></h4> 3877 3878 <p>The four-byte chunk type field contains the decimal values</p> 3879 3880 <pre> 3881 115 66 73 84 3882 </pre> 3883 3884 <p>To simplify decoders, PNG specifies that only certain sample 3885 depths may be used, and further specifies that sample values 3886 should be scaled to the full range of possible values at the 3887 sample depth. The <a href="#11sBIT"><span class= 3888 "chunk">sBIT</span></a> chunk defines the original number of 3889 significant bits (which can be less than or equal to the sample 3890 depth). This allows PNG decoders to recover the original data 3891 losslessly even if the data had a sample depth not directly 3892 supported by PNG.</p> 3893 3894 <p>The <span class="chunk">sBIT</span> chunk contains:</p> 3895 3896 <!-- ************Page Break******************* --> 3897 <!-- ************Page Break******************* --> 3898 <table class="Regular" summary= 3899 "This table defines the sBIT chunk"> 3900 <tr> 3901 <th colspan="2">Colour type 0</th> 3902 </tr> 3903 3904 <tr> 3905 <td class="Regular">significant greyscale bits</td> 3906 <td class="Regular">1 byte</td> 3907 </tr> 3908 3909 <tr> 3910 <th colspan="2">Colour types 2 and 3</th> 3911 </tr> 3912 3913 <tr> 3914 <td class="Regular">significant red bits</td> 3915 <td class="Regular">1 byte</td> 3916 </tr> 3917 3918 <tr> 3919 <td class="Regular">significant green bits</td> 3920 <td class="Regular">1 byte</td> 3921 </tr> 3922 3923 <tr> 3924 <td class="Regular">significant blue bits</td> 3925 <td class="Regular">1 byte</td> 3926 </tr> 3927 3928 <tr> 3929 <th colspan="2">Colour type 4</th> 3930 </tr> 3931 3932 <tr> 3933 <td class="Regular">significant greyscale bits</td> 3934 <td class="Regular">1 byte</td> 3935 </tr> 3936 3937 <tr> 3938 <td class="Regular">significant alpha bits</td> 3939 <td class="Regular">1 byte</td> 3940 </tr> 3941 3942 <tr> 3943 <th colspan="2">Colour type 6</th> 3944 </tr> 3945 3946 <tr> 3947 <td class="Regular">significant red bits</td> 3948 <td class="Regular">1 byte</td> 3949 </tr> 3950 3951 <tr> 3952 <td class="Regular">significant green bits</td> 3953 <td class="Regular">1 byte</td> 3954 </tr> 3955 3956 <tr> 3957 <td class="Regular">significant blue bits</td> 3958 <td class="Regular">1 byte</td> 3959 </tr> 3960 3961 <tr> 3962 <td class="Regular">significant alpha bits</td> 3963 <td class="Regular">1 byte</td> 3964 </tr> 3965 </table> 3966 3967 <p>Each depth specified in <span class="chunk">sBIT</span> shall 3968 be greater than zero and less than or equal to the sample depth 3969 (which is 8 for indexed-colour images, and the bit depth given in 3970 <a href="#11IHDR"><span class="chunk">IHDR</span></a> for other 3971 colour types). 3972 Note that <span class="chunk">sBIT</span> does not provide a sample depth 3973 for the alpha channel that is implied by a 3974 <a href="#11tRNS"><span class= 3975 "chunk">tRNS</span></a> chunk; in that case, all of the sample bits of 3976 the alpha channel are to be treated as significant. If the <span 3977 class="chunk">sBIT</span> chunk is not present, then all of the 3978 sample bits of all channels are to be treated as significant.</p> 3979 3980 <h4><a name="11sRGB">11.3.3.5 <span class="chunk">sRGB</span> 3981 Standard RGB colour space</a></h4> 3982 3983 <p>The four-byte chunk type field contains the decimal values</p> 3984 3985 <pre> 3986 115 82 71 66 3987 </pre> 3988 3989 <p>If the <span class="chunk">sRGB</span> chunk is present, the 3990 image samples conform to the sRGB colour space <a href= 3991 "#2-IEC-61966-2-1"><span class="NormRef">[IEC 3992 61966-2-1]</span></a> and should be displayed using the specified 3993 rendering intent defined by the International Color Consortium <a 3994 href="#2-ICC-1"><span class="NormRef">[ICC-1]</span></a> and <a 3995 href="#2-ICC-1A"><span class="NormRef">[ICC-1A]</span></a>.</p> 3996 3997 <p>The <span class="chunk">sRGB</span> chunk contains:</p> 3998 3999 <table class="Regular" summary= 4000 "This table defines the sRGB chunk"> 4001 <tr> 4002 <td class="Regular">Rendering intent</td> 4003 <td class="Regular">1 byte</td> 4004 </tr> 4005 </table> 4006 4007 <p>The following values are defined for rendering intent:</p> 4008 4009 <table class="Regular" summary= 4010 "This table defines the values of rendering intent in the sRGB chunk"> 4011 <tr> 4012 <td class="Regular">0</td> 4013 <td class="Regular">Perceptual</td> 4014 <td class="Regular">for images preferring good adaptation to the output device 4015 gamut at the expense of colorimetric accuracy, such as 4016 photographs.</td> 4017 </tr> 4018 4019 <tr> 4020 <td class="Regular">1</td> 4021 <td class="Regular">Relative colorimetric</td> 4022 <td class="Regular">for images requiring colour appearance matching (relative to 4023 the output device white point), such as logos.</td> 4024 </tr> 4025 4026 <tr> 4027 <td class="Regular">2</td> 4028 <td class="Regular">Saturation</td> 4029 <td class="Regular">for images preferring preservation of saturation at the 4030 expense of hue and lightness, such as charts and graphs.</td> 4031 </tr> 4032 4033 <tr> 4034 <td class="Regular">3</td> 4035 <td class="Regular">Absolute colorimetric</td> 4036 <td class="Regular">for images requiring preservation of absolute colorimetry, 4037 such as previews of images destined for a different output device 4038 (proofs).</td> 4039 </tr> 4040 </table> 4041 4042 <p>It is recommended that a PNG encoder that writes the <span 4043 class="chunk">sRGB</span> chunk also write a <a href= 4044 "#11gAMA"><span class="chunk">gAMA</span></a> chunk (and 4045 optionally a <a href="#11cHRM"><span class= 4046 "chunk">cHRM</span></a> chunk) for compatibility with decoders 4047 that do not use the <span class="chunk">sRGB</span> chunk. Only 4048 the following values shall be used.</p> 4049 4050 <table class="Regular" summary= 4051 "This table defines the gAMA and cHRM values for sRGB"> 4052 <tr> 4053 <th colspan="2"><a href="#11gAMA"><span class= 4054 "chunk">gAMA</span></a> </th> 4055 </tr> 4056 4057 <tr> 4058 <td class="Regular">Gamma</td> 4059 <td class="Regular">45455</td> 4060 </tr> 4061 4062 <tr> 4063 <th colspan="2"><a href="#11cHRM"><span class= 4064 "chunk">cHRM</span></a> </th> 4065 </tr> 4066 4067 <tr> 4068 <td class="Regular">White point x</td> 4069 <td class="Regular">31270</td> 4070 </tr> 4071 4072 <tr> 4073 <td class="Regular">White point y</td> 4074 <td class="Regular">32900</td> 4075 </tr> 4076 4077 <tr> 4078 <td class="Regular">Red x</td> 4079 <td class="Regular">64000</td> 4080 </tr> 4081 4082 <tr> 4083 <td class="Regular">Red y</td> 4084 <td class="Regular">33000</td> 4085 </tr> 4086 4087 <tr> 4088 <td class="Regular">Green x</td> 4089 <td class="Regular">30000</td> 4090 </tr> 4091 4092 <tr> 4093 <td class="Regular">Green y</td> 4094 <td class="Regular">60000</td> 4095 </tr> 4096 4097 <tr> 4098 <td class="Regular">Blue x</td> 4099 <td class="Regular">15000</td> 4100 </tr> 4101 4102 <tr> 4103 <td class="Regular">Blue y</td> 4104 <td class="Regular">6000</td> 4105 </tr> 4106 </table> 4107 4108 <p>When the <span class="chunk">sRGB</span> chunk is present, it 4109 is recommended that decoders that recognize it and are capable of 4110 colour management <a href="#G-ICC"><span class= 4111 "bibref">[ICC]</span></a> ignore the <a href="#11gAMA"><span 4112 class="chunk">gAMA</span></a> and <a href="#11cHRM"><span class= 4113 "chunk">cHRM</span></a> chunks and use the <span class= 4114 "chunk">sRGB</span> chunk instead. Decoders that recognize the 4115 <span class="chunk">sRGB</span> chunk but are not capable of 4116 colour management <a href="#G-ICC"><span class= 4117 "bibref">[ICC]</span></a> are recommended to ignore the <a href= 4118 "#11gAMA"><span class="chunk">gAMA</span></a> and <a href= 4119 "#11cHRM"><span class="chunk">cHRM</span></a> chunks, and use the 4120 values given above as if they had appeared in <a href= 4121 "#11gAMA"><span class="chunk">gAMA</span></a> and <a href= 4122 "#11cHRM"><span class="chunk">cHRM</span></a> chunks.</p> 4123 4124 <p>It is recommended that the <span class="chunk">sRGB</span> and 4125 <a href="#11iCCP"><span class="chunk">iCCP</span></a> chunks do 4126 not both appear in a PNG datastream.</p> 4127 4128 <h3><a name="11textinfo">11.3.4 Textual information</a></h3> 4129 4130 <h4><a name="11textIntro">11.3.4.1 Introduction</a></h4> 4131 4132 <p>PNG provides the <a href="#11tEXt"><span class= 4133 "chunk">tEXt</span></a>, <a href="#11iTXt"><span class= 4134 "chunk">iTXt</span></a>, and <a href="#11zTXt"><span class= 4135 "chunk">zTXt</span></a> chunks for storing text strings 4136 associated with the image, such as an image description or 4137 copyright notice. Keywords are used to indicate what each text 4138 string represents. Any number of such text chunks may appear, and 4139 more than one with the same keyword is permitted.</p> 4140 4141 <h4><a name="11keywords">11.3.4.2 Keywords and text 4142 strings</a></h4> 4143 4144 <p>The following keywords are predefined and should be used where 4145 appropriate.</p> 4146 4147 <table class="Regular" summary= 4148 "This table defines the keywords defined for tEXt, iTXt and zTXt chunks"> 4149 <tr> 4150 <td class="Regular">Title</td> 4151 <td class="Regular">Short (one line) title or caption for image</td> 4152 </tr> 4153 4154 <tr> 4155 <td class="Regular">Author</td> 4156 <td class="Regular">Name of image's creator</td> 4157 </tr> 4158 4159 <tr> 4160 <td class="Regular">Description</td> 4161 <td class="Regular">Description of image (possibly long)</td> 4162 </tr> 4163 4164 <tr> 4165 <td class="Regular">Copyright</td> 4166 <td class="Regular">Copyright notice</td> 4167 </tr> 4168 4169 <tr> 4170 <td class="Regular">Creation Time</td> 4171 <td class="Regular">Time of original image creation</td> 4172 </tr> 4173 4174 <tr> 4175 <td class="Regular">Software</td> 4176 <td class="Regular">Software used to create the image</td> 4177 </tr> 4178 4179 <tr> 4180 <td class="Regular">Disclaimer</td> 4181 <td class="Regular">Legal disclaimer</td> 4182 </tr> 4183 4184 <tr> 4185 <td class="Regular">Warning</td> 4186 <td class="Regular">Warning of nature of content</td> 4187 </tr> 4188 4189 <tr> 4190 <td class="Regular">Source</td> 4191 <td class="Regular">Device used to create the image</td> 4192 </tr> 4193 4194 <tr> 4195 <td class="Regular">Comment</td> 4196 <td class="Regular">Miscellaneous comment</td> 4197 </tr> 4198 </table> 4199 4200 <p>Other keywords may be defined for other purposes. Keywords of 4201 general interest can be registered with the PNG Registration 4202 Authority (see 4.9 <a href="#4Concepts.Registration"><span class= 4203 "xref">Extension and registration</span></a>). It is also 4204 permitted to use private unregistered keywords. (Private keywords 4205 should be reasonably self-explanatory, in order to minimize the 4206 chance that the same keyword is used for incompatible purposes by 4207 different people.)</p> 4208 4209 <p>Keywords shall contain only printable Latin-1 <a href= 4210 "#2-ISO-8859-1"><span class="NormRef">[ISO-8859-1]</span></a> 4211 characters and spaces; that is, only character codes 32-126 and 4212 161-255 decimal are allowed. To reduce the chances for human 4213 misreading of a keyword, leading spaces, trailing spaces, 4214 and consecutive spaces are not permitted in keywords, nor is the 4215 non-breaking space (code 160) since it is visually 4216 indistinguishable from an ordinary space.</p> 4217 4218 <p>Keywords shall be spelled exactly as registered, so that 4219 decoders can use simple literal comparisons when looking for 4220 particular keywords. In particular, keywords are considered 4221 case-sensitive. Keywords are restricted to 1 to 79 bytes in 4222 length.</p> 4223 4224 <p>For the Creation Time keyword, the date format defined in 4225 section 5.2.14 of RFC 1123 is suggested, but not required <a 4226 href="#2-RFC-1123"><span class= 4227 "NormRef">[RFC-1123]</span></a>.</p> 4228 4229 <p>In the <a href="#11tEXt"><span class="chunk">tEXt</span></a> 4230 and <a href="#11zTXt"><span class="chunk">zTXt</span></a> chunks, 4231 the text string associated with a keyword is restricted to the 4232 Latin-1 character set plus the linefeed character. Text strings 4233 in <a href="#11zTXt"><span class="chunk">zTXt</span></a> are 4234 compressed into zlib datastreams using deflate compression (see 4235 10.3: <a href='#10CompressionOtherUses'><span class="xref">Other 4236 uses of compression</span></a>). The <a href="#11iTXt"><span 4237 class="chunk">iTXt</span></a> chunk can be used to convey 4238 characters outside the Latin-1 set. It uses the UTF-8 encoding of 4239 UCS <a href="#2-ISO-10646-1"><span class="NormRef">[ISO/IEC 4240 10646-1]</span></a> . There is an option to compress text strings 4241 in the <a href="#11iTXt"><span class="chunk">iTXt</span></a> 4242 chunk.</p> 4243 4244 <h4><a name="11tEXt">11.3.4.3 <span class="chunk">tEXt</span> 4245 Textual data</a></h4> 4246 4247 <p>The four-byte chunk type field contains the decimal values</p> 4248 4249 <pre> 4250 116 69 88 116 4251 </pre> 4252 4253 <p>Each <span class="chunk">tEXt</span> chunk contains a keyword 4254 and a text string, in the format:</p> 4255 4256 <table class="Regular" summary= 4257 "This table defines the tEXt chunk"> 4258 <tr> 4259 <td class="Regular">Keyword</td> 4260 <td class="Regular">1-79 bytes (character string)</td> 4261 </tr> 4262 4263 <tr> 4264 <td class="Regular">Null separator</td> 4265 <td class="Regular">1 byte (null character)</td> 4266 </tr> 4267 4268 <tr> 4269 <td class="Regular">Text string</td> 4270 <td class="Regular">0 or more bytes (character string)</td> 4271 </tr> 4272 </table> 4273 4274 <p> 4275 The keyword and text string are separated by a zero byte (null 4276 character). Neither the keyword nor the text string may contain a 4277 null character. 4278 The text string is <strong>not</strong> null-terminated (the length of 4279 the chunk defines the ending). The text string may be of any 4280 length from zero bytes up to the maximum permissible chunk size 4281 less the length of the keyword and null character separator.</p> 4282 4283 <p>The keyword indicates the type of information represented by 4284 the text string as described in 11.3.4.2: <a href= 4285 "#11keywords"><span class="xref">Keywords and text 4286 strings</span></a>.</p> 4287 4288 <p>Text is interpreted according to the Latin-1 character set <a 4289 href="#2-ISO-8859-1"><span class= 4290 "NormRef">[ISO-8859-1]</span></a>. The text string may contain 4291 any Latin-1 character. Newlines in the text string should be 4292 represented by a single linefeed character (decimal 10). 4293 Characters other than those defined in Latin-1 plus the linefeed 4294 character have no defined meaning in <span class="chunk">tEXt</span> chunks. 4295 Text containing characters outside the repertoire of ISO/IEC 4296 8859-1 should be encoded using the <a href="#11iTXt"><span class= 4297 "chunk">iTXt</span></a> chunk.</p> 4298 4299 <h4><a name="11zTXt">11.3.4.4 <span class="chunk">zTXt</span> 4300 Compressed textual data</a></h4> 4301 4302 <p>The four-byte chunk type field contains the decimal values</p> 4303 4304 <pre> 4305 122 84 88 116 4306 </pre> 4307 4308 <p>The <span class="chunk">zTXt</span> and <a href= 4309 "#11tEXt"><span class="chunk">tEXt</span></a> chunks are 4310 semantically equivalent, but the <span class="chunk">zTXt</span> 4311 chunk is recommended for storing large blocks of text.</p> 4312 4313 <p>A <span class="chunk">zTXt</span> chunk contains:</p> 4314 4315 <table class="Regular" summary= 4316 "This table defines the zTXt chunk"> 4317 <tr> 4318 <td class="Regular">Keyword</td> 4319 <td class="Regular">1-79 bytes (character string)</td> 4320 </tr> 4321 4322 <tr> 4323 <td class="Regular">Null separator</td> 4324 <td class="Regular">1 byte (null character)</td> 4325 </tr> 4326 4327 <tr> 4328 <td class="Regular">Compression method</td> 4329 <td class="Regular">1 byte</td> 4330 </tr> 4331 4332 <tr> 4333 <td class="Regular">Compressed text datastream</td> 4334 <td class="Regular">n bytes</td> 4335 </tr> 4336 </table> 4337 4338 <p>The keyword and null character are the same as in the <a href= 4339 "#11tEXt"><span class="chunk">tEXt</span></a> chunk (see 4340 11.3.4.3: <a href="#11tEXt"><span class="xref"><span class= 4341 "chunk">tEXt</span> Textual data</span></a>). The keyword is not 4342 compressed. The compression method entry defines the compression 4343 method used. The only value defined in this International 4344 Standard is 0 (deflate/inflate compression). Other values are 4345 reserved for future standardization (see 4.9 <a href= 4346 "#4Concepts.Registration"><span class="xref">Extension and 4347 registration</span></a>). The compression method entry is 4348 followed by the compressed text datastream that makes up the 4349 remainder of the chunk. For compression method 0, this datastream 4350 is a zlib datastream with deflate compression (see 10.3: <a href= 4351 "#10CompressionOtherUses"><span class="xref">Other uses of 4352 compression</span></a>). Decompression of this datastream yields 4353 Latin-1 text that is identical to the text that would be stored 4354 in an equivalent <a href="#11tEXt"><span class= 4355 "chunk">tEXt</span></a> chunk.</p> 4356 4357 <h4><a name="11iTXt">11.3.4.5 <span class="chunk">iTXt</span> 4358 International textual data</a></h4> 4359 4360 <p>The four-byte chunk type field contains the decimal values</p> 4361 4362 <pre> 4363 105 84 88 116 4364 </pre> 4365 4366 <p>An <span class="chunk">iTXt</span> chunk contains:</p> 4367 4368 <table class="Regular" summary= 4369 "This table defines the iTXt chunk"> 4370 <tr> 4371 <td class="Regular">Keyword</td> 4372 <td class="Regular">1-79 bytes (character string)</td> 4373 </tr> 4374 4375 <tr> 4376 <td class="Regular">Null separator</td> 4377 <td class="Regular">1 byte (null character)</td> 4378 </tr> 4379 4380 <tr> 4381 <td class="Regular">Compression flag</td> 4382 <td class="Regular">1 byte</td> 4383 </tr> 4384 4385 <tr> 4386 <td class="Regular">Compression method</td> 4387 <td class="Regular">1 byte</td> 4388 </tr> 4389 4390 <tr> 4391 <td class="Regular">Language tag</td> 4392 <td class="Regular">0 or more bytes (character string)</td> 4393 </tr> 4394 4395 <tr> 4396 <td class="Regular">Null separator</td> 4397 <td class="Regular">1 byte (null character)</td> 4398 </tr> 4399 4400 <tr> 4401 <td class="Regular">Translated keyword</td> 4402 <td class="Regular">0 or more bytes</td> 4403 </tr> 4404 4405 <tr> 4406 <td class="Regular">Null separator</td> 4407 <td class="Regular">1 byte (null character)</td> 4408 </tr> 4409 4410 <tr> 4411 <td class="Regular">Text</td> 4412 <td class="Regular">0 or more bytes</td> 4413 </tr> 4414 </table> 4415 4416 <p>The keyword is described in 11.3.4.2: <a href= 4417 "#11keywords"><span class="xref">Keywords and text 4418 strings</span></a>.</p> 4419 4420 <p>The compression flag is 0 for uncompressed text, 1 for 4421 compressed text. Only the text field may be compressed. The 4422 compression method entry defines the compression method used. The 4423 only compression method defined in this International Standard is 4424 0 (zlib datastream with deflate compression, see 10.3: <a href= 4425 '#10CompressionOtherUses'><span class="xref">Other uses of 4426 compression</span></a>). For uncompressed text, encoders shall 4427 set the compression method to 0, and decoders shall ignore 4428 it.</p> 4429 4430 <p>The language tag defined in <a href="#2-RFC-3066"><span class= 4431 "NormRef">[RFC-3066]</span></a> 4432 indicates the human language used by the translated keyword and 4433 the text. Unlike the keyword, the language tag is 4434 case-insensitive. It is an ISO 646.IRV:1991 <a href="#2-ISO-646"><span 4435 class="NormRef">[ISO 646]</span></a> string consisting of 4436 hyphen-separated words of 1-8 alphanumeric characters each (for example cn, 4437 en-uk, no-bok, x-klingon, x-KlInGoN). If the first word is two or three 4438 letters long, it is an ISO language code <a href= 4439 "#2-ISO-639"><span class="NormRef">[ISO-639]</span></a>. If the 4440 language tag is empty, the language is unspecified.</p> 4441 4442 <p>The translated keyword and text both use the UTF-8 encoding of 4443 UCS <a href="#2-ISO-10646-1"><span class="NormRef">[ISO/IEC 4444 10646-1]</span></a>, and neither shall contain a zero byte (null 4445 character). The text, unlike other textual data in this chunk, is 4446 not null-terminated; its length is derived from the chunk 4447 length.</p> 4448 4449 <p>Line breaks should not appear in the translated keyword. In 4450 the text, a newline should be represented by a single linefeed 4451 character (decimal 10). The remaining control characters (1-9, 4452 11-31, 127-159) are discouraged in both the translated keyword 4453 and text. In UTF-8 there is a difference between the characters 4454 128-159 (which are discouraged) and the bytes 128-159 (which are 4455 often necessary).</p> 4456 4457 <p>The translated keyword, if not empty, should contain a 4458 translation of the keyword into the language indicated by the 4459 language tag, and applications displaying the keyword should 4460 display the translated keyword in addition.</p> 4461 4462 <!-- ************Page Break******************* --> 4463 <!-- ************Page Break******************* --> 4464 <h3><a name="11addnlsiinfo">11.3.5 Miscellaneous 4465 information</a></h3> 4466 4467 <h4><a name="11bKGD">11.3.5.1 <span class="chunk">bKGD</span> 4468 Background colour</a></h4> 4469 4470 <p>The four-byte chunk type field contains the decimal values</p> 4471 4472 <pre> 4473 98 75 71 68 4474 </pre> 4475 4476 <p>The <span class="chunk">bKGD</span> chunk specifies a default 4477 background colour to present the image against. If there is any 4478 other preferred background, either user-specified or part of a 4479 larger page (as in a browser), the <span class= 4480 "chunk">bKGD</span> chunk should be ignored. The <span class= 4481 "chunk">bKGD</span> chunk contains:</p> 4482 4483 <table class="Regular" summary= 4484 "This table defines the bKGD chunk"> 4485 <tr> 4486 <th colspan="2">Colour types 0 and 4</th> 4487 </tr> 4488 4489 <tr> 4490 <td class="Regular">Greyscale</td> 4491 <td class="Regular">2 bytes</td> 4492 </tr> 4493 4494 <tr> 4495 <th colspan="2">Colour types 2 and 6</th> 4496 </tr> 4497 4498 <tr> 4499 <td class="Regular">Red</td> 4500 <td class="Regular">2 bytes</td> 4501 </tr> 4502 4503 <tr> 4504 <td class="Regular">Green</td> 4505 <td class="Regular">2 bytes</td> 4506 </tr> 4507 4508 <tr> 4509 <td class="Regular">Blue</td> 4510 <td class="Regular">2 bytes</td> 4511 </tr> 4512 4513 <tr> 4514 <th colspan="2">Colour type 3</th> 4515 </tr> 4516 4517 <tr> 4518 <td class="Regular">Palette index</td> 4519 <td class="Regular">1 byte</td> 4520 </tr> 4521 </table> 4522 4523 <p>For colour type 3 (indexed-colour), the value is the palette 4524 index of the colour to be used as background.</p> 4525 4526 <p>For colour types 0 and 4 (greyscale, greyscale with alpha), 4527 the value is the grey level to be used as background in the range 4528 0 to (2<sup>bitdepth</sup>)-1. For colour types 2 and 6 4529 (truecolour, truecolour with alpha), the values are the colour to be 4530 used as background, given as RGB 4531 samples in the range 0 to (2<sup>bitdepth</sup>)-1. In each case, 4532 for consistency, two bytes per sample are used regardless of the 4533 image bit depth. If the image bit depth is less than 16, the 4534 least significant bits are used and the others are 0.</p> 4535 4536 <h4><a name="11hIST">11.3.5.2 <span class="chunk">hIST</span> 4537 Image histogram</a></h4> 4538 4539 <p>The four-byte chunk type field contains the decimal values</p> 4540 4541 <pre> 4542 104 73 83 84 4543 </pre> 4544 4545 <p>The <span class="chunk">hIST</span> chunk contains a series of 4546 two-byte (16-bit) unsigned integers:</p> 4547 4548 <table class="Regular" summary= 4549 "This table defines the hIST chunk"> 4550 <tr> 4551 <td class="Regular">Frequency</td> 4552 <td class="Regular">2 bytes (unsigned integer)</td> 4553 </tr> 4554 <tr> 4555 <td class="Regular">...etc...</td> 4556 <td class="Regular"> </td> 4557 </tr> 4558 </table> 4559 4560 <p>The <span class="chunk">hIST</span> chunk gives the 4561 approximate usage frequency of each colour in the palette. A 4562 histogram chunk can appear only when a <a href="#11PLTE"><span 4563 class="chunk">PLTE</span></a> chunk appears. If a viewer is 4564 unable to provide all the colours listed in the palette, the 4565 histogram may help it decide how to choose a subset of the 4566 colours for display.</p> 4567 4568 <p>There shall be exactly one 4569 entry for each entry in the <a href="#11PLTE"><span class= 4570 "chunk">PLTE</span></a> chunk. Each entry is proportional to the 4571 fraction of pixels in the image that have that palette index; the 4572 exact scale factor is chosen by the encoder.</p> 4573 4574 <p>Histogram entries are approximate, with the exception that a 4575 zero entry specifies that the corresponding palette entry is not 4576 used at all in the image. A histogram entry shall be nonzero if 4577 there are any pixels of that colour.</p> 4578 4579 <p class="Note">NOTE When the palette is a suggested quantization 4580 of a truecolour image, the histogram is necessarily approximate, 4581 since a decoder may map pixels to palette entries differently 4582 than the encoder did. In this situation, zero entries should not 4583 normally appear, because any entry might be used.</p> 4584 4585 <h4><a name="11pHYs">11.3.5.3 <span class="chunk">pHYs</span> 4586 Physical pixel dimensions</a></h4> 4587 4588 <p>The four-byte chunk type field contains the decimal values</p> 4589 4590 <pre> 4591 112 72 89 115 4592 </pre> 4593 4594 <p>The <span class="chunk">pHYs</span> chunk specifies the 4595 intended pixel size or aspect ratio for display of the image. It 4596 contains:</p> 4597 4598 <table class="Regular" summary= 4599 "This table defines the pHYs chunk"> 4600 <tr> 4601 <td class="Regular">Pixels per unit, X axis</td> 4602 <td class="Regular">4 bytes (PNG unsigned integer)</td> 4603 </tr> 4604 4605 <tr> 4606 <td class="Regular">Pixels per unit, Y axis</td> 4607 <td class="Regular">4 bytes (PNG unsigned integer)</td> 4608 </tr> 4609 4610 <tr> 4611 <td class="Regular">Unit specifier</td> 4612 <td class="Regular">1 byte</td> 4613 </tr> 4614 </table> 4615 4616 <p>The following values are defined for the unit specifier:</p> 4617 4618 <table class="Regular" summary= 4619 "This table defines the allowed values for the unit specifier in the pHYs chunk"> 4620 <tr> 4621 <td class="Regular">0</td> 4622 <td class="Regular">unit is unknown</td> 4623 </tr> 4624 4625 <tr> 4626 <td class="Regular">1</td> 4627 <td class="Regular">unit is the metre</td> 4628 </tr> 4629 </table> 4630 4631 <p>When the unit specifier is 0, the <span class= 4632 "chunk">pHYs</span> chunk defines pixel aspect ratio only; the 4633 actual size of the pixels remains unspecified.</p> 4634 4635 <p>If the <span class="chunk">pHYs</span> chunk is not present, 4636 pixels are assumed to be square, and the physical size of each 4637 pixel is unspecified.</p> 4638 4639 <h4><a name="11sPLT">11.3.5.4 <span class="chunk">sPLT</span> 4640 Suggested palette</a></h4> 4641 4642 <p>The four-byte chunk type field contains the decimal values</p> 4643 4644 <pre> 4645 115 80 76 84 4646 </pre> 4647 4648 <p>The <span class="chunk">sPLT</span> chunk contains:</p> 4649 4650 <table class="Regular" summary= 4651 "This table defines the sPLT chunk"> 4652 <tr> 4653 <td class="Regular">Palette name</td> 4654 <td class="Regular">1-79 bytes (character string)</td> 4655 </tr> 4656 4657 <tr> 4658 <td class="Regular">Null separator</td> 4659 <td class="Regular">1 byte (null character)</td> 4660 </tr> 4661 4662 <tr> 4663 <td class="Regular">Sample depth</td> 4664 <td class="Regular">1 byte</td> 4665 </tr> 4666 4667 <tr> 4668 <td class="Regular">Red</td> 4669 <td class="Regular">1 or 2 bytes</td> 4670 </tr> 4671 4672 <tr> 4673 <td class="Regular">Green</td> 4674 <td class="Regular">1 or 2 bytes</td> 4675 </tr> 4676 4677 <tr> 4678 <td class="Regular">Blue</td> 4679 <td class="Regular">1 or 2 bytes</td> 4680 </tr> 4681 4682 <tr> 4683 <td class="Regular">Alpha</td> 4684 <td class="Regular">1 or 2 bytes</td> 4685 </tr> 4686 4687 <tr> 4688 <td class="Regular">Frequency</td> 4689 <td class="Regular">2 bytes</td> 4690 </tr> 4691 4692 <tr> 4693 <td class="Regular">...etc...</td> 4694 <td class="Regular"> </td> 4695 </tr> 4696 </table> 4697 4698 <p>Each palette entry is six bytes or ten bytes containing five 4699 unsigned integers (red, blue, green, alpha, and frequency).</p> 4700 4701 <p>There may be any number of entries. A PNG decoder determines 4702 the number of entries from the length of the chunk remaining 4703 after the sample depth byte. This shall be divisible by 6 if the 4704 <span class="chunk">sPLT</span> sample depth is 8, or by 10 if 4705 the <span class="chunk">sPLT</span> sample depth is 16. Entries 4706 shall appear in decreasing order of frequency. There is no 4707 requirement that the entries all be used by the image, nor that 4708 they all be different.</p> 4709 4710 <p>The palette name can be any convenient name for referring to 4711 the palette (for example "256 colour including Macintosh 4712 default", "256 colour including Windows-3.1 default", "Optimal 4713 512"). The palette name may aid the choice of the appropriate 4714 suggested palette when more than one appears in a PNG 4715 datastream.</p> 4716 4717 <p>The palette name is case-sensitive, and subject to the same 4718 restrictions as the keyword parameter for the <a href= 4719 "#11tEXt"><span class="chunk">tEXt</span></a> chunk. Palette 4720 names shall contain only printable Latin-1 characters and spaces 4721 (only character codes 32-126 and 161-255 decimal are allowed). 4722 Leading, trailing, and consecutive spaces are not permitted.</p> 4723 4724 <p>The <span class="chunk">sPLT</span> sample depth shall be 8 or 4725 16.</p> 4726 4727 <p>The red, green, blue, and alpha samples are either one or two 4728 bytes each, depending on the <span class="chunk">sPLT</span> 4729 sample depth, regardless of the image bit depth. The colour 4730 samples are not premultiplied by alpha, nor are they 4731 precomposited against any background. An alpha value of 0 means 4732 fully transparent. An alpha value of 255 (when the <span class= 4733 "chunk">sPLT</span> sample depth is 8) or 65535 (when the <span 4734 class="chunk">sPLT</span> sample depth is 16) means fully opaque. 4735 The <span class="chunk">sPLT</span> chunk may appear for any PNG 4736 colour type. Entries in <span class="chunk">sPLT</span> use the 4737 same gamma and chromaticity values as the PNG image, but may fall 4738 outside the range of values used in the colour space of the PNG 4739 image; for example, in a greyscale PNG image, each <span class= 4740 "chunk">sPLT</span> entry would typically have equal red, green, 4741 and blue values, but this is not required. Similarly, <span 4742 class="chunk">sPLT</span> entries can have non-opaque alpha 4743 values even when the PNG image does not use transparency.</p> 4744 4745 <p>Each frequency value is proportional to the fraction of 4746 the pixels in the image for which that palette entry 4747 is the closest match in RGBA space, before the image has been composited against any 4748 background. The exact scale factor is chosen by the PNG encoder; 4749 it is recommended that the resulting range of individual values 4750 reasonably fills the range 0 to 65535. A PNG encoder may 4751 artificially inflate the frequencies for colours considered to be 4752 "important", for example the colours used in a logo or the facial 4753 features of a portrait. Zero is a valid frequency meaning that 4754 the colour is "least important" or that it is rarely, if ever, 4755 used. When all the frequencies are zero, they are meaningless, 4756 that is to say, nothing may be inferred about the actual 4757 frequencies with which the colours appear in the PNG image.</p> 4758 4759 <p>Multiple <span class="chunk">sPLT</span> chunks are permitted, 4760 but each shall have a different palette name.</p> 4761 4762 <h3><a name="11timestampinfo">11.3.6 Time stamp 4763 information</a></h3> 4764 4765 <h4><a name="11tIME">11.3.6.1 <span class="chunk">tIME</span> 4766 Image last-modification time</a></h4> 4767 4768 <p>The four-byte chunk type field contains the decimal values</p> 4769 4770 <pre> 4771 116 73 77 69 4772 </pre> 4773 4774 <p>The <span class="chunk">tIME</span> chunk gives the time of 4775 the last image modification (<strong>not</strong> the time of initial 4776 image creation). It contains:</p> 4777 4778 <table class="Regular" summary= 4779 "This table defines the tIME chunk"> 4780 <tr> 4781 <td class="Regular">Year</td> 4782 <td class="Regular">2 bytes (complete; for example, 1995, <strong>not</strong> 95)</td> 4783 </tr> 4784 4785 <tr> 4786 <td class="Regular">Month</td> 4787 <td class="Regular">1 byte (1-12)</td> 4788 </tr> 4789 4790 <tr> 4791 <td class="Regular">Day</td> 4792 <td class="Regular">1 byte (1-31)</td> 4793 </tr> 4794 4795 <tr> 4796 <td class="Regular">Hour</td> 4797 <td class="Regular">1 byte (0-23)</td> 4798 </tr> 4799 4800 <tr> 4801 <td class="Regular">Minute</td> 4802 <td class="Regular">1 byte (0-59)</td> 4803 </tr> 4804 4805 <tr> 4806 <td class="Regular">Second</td> 4807 <td class="Regular">1 byte (0-60) (to allow for leap seconds)</td> 4808 </tr> 4809 </table> 4810 4811 <p>Universal Time (UTC) should be specified rather than local 4812 time.</p> 4813 4814 <p>The <span class="chunk">tIME</span> chunk is intended for use 4815 as an automatically-applied time stamp that is updated whenever 4816 the image data are changed.</p> 4817 4818 <!-- ************Page Break******************* --> 4819 <!-- ************Page Break******************* --> 4820 <h1><a name="12Encoders">12 PNG Encoders</a></h1> 4821 4822 <h2><a name="12Introduction">12.1 Introduction</a></h2> 4823 4824 <p>This clause gives requirements and recommendations for encoder 4825 behaviour. A PNG encoder shall produce a PNG datastream from a 4826 PNG image that conforms to the format specified in the preceding 4827 clauses. Best results will usually be achieved by following the 4828 additional recommendations given here.</p> 4829 4830 <h2><a name="12Encoder-gamma-handling">12.2 Encoder gamma 4831 handling</a></h2> 4832 4833 <p>See Annex C: <a href="#C-GammaAppendix"><span class= 4834 "xref">Gamma and chromaticity</span></a> for a brief introduction 4835 to gamma issues.</p> 4836 4837 <p>PNG encoders capable of full colour management <a href= 4838 "#G-ICC"><span class="bibref">[ICC]</span></a> will perform more 4839 sophisticated calculations than those described here and may 4840 choose to use the <a href="#11iCCP"><span class= 4841 "chunk">iCCP</span></a> chunk. If it is known that the image 4842 samples conform to the sRGB specification <a href= 4843 "#2-IEC-61966-2-1"><span class="NormRef">[IEC 4844 61966-2-1]</span></a>, encoders are strongly encouraged to write 4845 the <a href="#11sRGB"><span class="chunk">sRGB</span></a> chunk 4846 without performing additional gamma handling. In both cases it is 4847 recommended that an appropriate <a href="#11gAMA"><span class= 4848 "chunk">gAMA</span></a> chunk be generated for use by PNG 4849 decoders that do not recognize the <a href="#11iCCP"><span class= 4850 "chunk">iCCP</span></a> chunk or <a href="#11sRGB"><span class= 4851 "chunk">sRGB</span></a> chunk.</p> 4852 4853 <p>A PNG encoder has to determine:</p> 4854 4855 <!-- <ol start="1"> --><ol> 4856 <li>what value to write in the <a href="#11gAMA"><span class= 4857 "chunk">gAMA</span></a> chunk;</li> 4858 4859 <li>how to transform the provided image samples into the values 4860 to be written in the PNG datastream.</li> 4861 </ol> 4862 4863 <p>The value to write in the <a href="#11gAMA"><span class= 4864 "chunk">gAMA</span></a> chunk is that value which causes a PNG 4865 decoder to behave in the desired way. See 13.13: <a class='Href' 4866 href='#13Decoder-gamma-handling'>Decoder gamma handling</a>.</p> 4867 4868 <p>The transform to be applied depends on the nature of the image 4869 samples and their precision. If the samples represent light 4870 intensity in floating-point or high precision integer form 4871 (perhaps from a computer graphics renderer), the encoder may 4872 perform "gamma encoding" (applying a power function with exponent 4873 less than 1) before quantizing the data to integer values for 4874 inclusion in the PNG datastream. This results in fewer banding 4875 artifacts at a given sample depth, or allows smaller samples 4876 while retaining the same visual quality. An intensity level 4877 expressed as a floating-point value in the range 0 to 1 can be 4878 converted to a datastream image sample by:</p> 4879 4880 <p><tt>integer_sample = 4881 floor((2<sup>sampledepth</sup>-1) * intensity<sup>encoding_exponent</sup> 4882 + 0.5)</tt></p> 4883 4884 <p>If the intensity in the equation is the desired output 4885 intensity, the encoding exponent is the gamma value to be used in 4886 the <a href="#11gAMA"><span class="chunk">gAMA</span></a> 4887 chunk.</p> 4888 4889 <p>If the intensity available to the PNG encoder is the original 4890 scene intensity, another transformation may be needed. There is 4891 sometimes a requirement for the displayed image to have higher 4892 contrast than the original source image. This corresponds to an 4893 end-to-end transfer function from original scene to display 4894 output with an exponent greater than 1. In this case:</p> 4895 4896 <pre> 4897 gamma = encoding_exponent/end_to_end_exponent 4898 </pre> 4899 4900 <p>If it is not known whether the conditions under which the 4901 original image was captured or calculated warrant such a contrast 4902 change, it may be assumed that the display intensities are 4903 proportional to original scene intensities, i.e. the end-to-end 4904 exponent is 1 and hence:</p> 4905 4906 <pre> 4907 gamma = encoding_exponent 4908 </pre> 4909 4910 <!-- ************Page Break******************* --> 4911 <!-- ************Page Break******************* --> 4912 <p>If the image is being written to a datastream only, the 4913 encoder is free to choose the encoding exponent. Choosing a value 4914 that causes the gamma value in the <a href="#11gAMA"><span class= 4915 "chunk">gAMA</span></a> chunk to be 1/2.2 is often a reasonable 4916 choice because it minimizes the work for a PNG decoder displaying 4917 on a typical video monitor.</p> 4918 4919 <p>Some image renderers may simultaneously write the image to a 4920 PNG datastream and display it on-screen. The displayed pixels 4921 should be gamma corrected for the display system and viewing 4922 conditions in use, so that the user sees a proper representation 4923 of the intended scene.</p> 4924 4925 <p>If the renderer wants to write the displayed sample values to 4926 the PNG datastream, avoiding a separate gamma encoding step for 4927 the datastream, the renderer should approximate the transfer 4928 function of the display system by a power function, and write the 4929 reciprocal of the exponent into the <a href="#11gAMA"><span 4930 class="chunk">gAMA</span></a> chunk. This will allow a PNG 4931 decoder to reproduce what was displayed on screen for the 4932 originator during rendering.</p> 4933 4934 <p>However, it is equally reasonable for a renderer to compute 4935 displayed pixels appropriate for the display device, and to 4936 perform separate gamma encoding for data storage and 4937 transmission, arranging to have a value in the <a href= 4938 "#11gAMA"><span class="chunk">gAMA</span></a> chunk more 4939 appropriate to the future use of the image.</p> 4940 4941 <p>Computer graphics renderers often do not perform gamma 4942 encoding, instead making sample values directly proportional to 4943 scene light intensity. If the PNG encoder receives sample values 4944 that have already been quantized into integer values, there is no 4945 point in doing gamma encoding on them; that would just result in 4946 further loss of information. The encoder should just write the 4947 sample values to the PNG datastream. This does not imply that the 4948 <a href="#11gAMA"><span class="chunk">gAMA</span></a> chunk 4949 should contain a gamma value of 1.0 because the desired 4950 end-to-end transfer function from scene intensity to display 4951 output intensity is not necessarily linear. However, the desired 4952 gamma value is probably not far from 1.0. It may depend on 4953 whether the scene being rendered is a daylight scene or an indoor 4954 scene, etc.</p> 4955 4956 <p>When the sample values come directly from a piece of hardware, 4957 the correct <a href="#11gAMA"><span class="chunk">gAMA</span></a> 4958 value can, in principle, be inferred from the transfer function 4959 of the hardware and lighting conditions of the scene. In the case 4960 of video digitizers ("frame grabbers"), the samples are probably 4961 in the sRGB colour space, because the sRGB specification was 4962 designed to be compatible with modern video standards. Image 4963 scanners are less predictable. Their output samples may be 4964 proportional to the input light intensity since CCD sensors 4965 themselves are linear, or the scanner hardware may have already 4966 applied a power function designed to compensate for dot gain in 4967 subsequent printing (an exponent of about 0.57), or the scanner 4968 may have corrected the samples for display on a monitor. It may 4969 be necessary to refer to the scanner's manual or to scan a 4970 calibrated target in order to determine the characteristics of a 4971 particular scanner. It should be remembered that gamma relates 4972 samples to desired display output, not to scanner input.</p> 4973 4974 <p>Datastream format converters generally should not attempt to 4975 convert supplied images to a different gamma. The data should be 4976 stored in the PNG datastream without conversion, and the gamma 4977 value should be deduced from information in the source datastream 4978 if possible. Gamma alteration at datastream conversion time 4979 causes re-quantization of the set of intensity levels that are 4980 represented, introducing further roundoff error with little 4981 benefit. It is almost always better to just copy the sample 4982 values intact from the input to the output file.</p> 4983 4984 <p>If the source datastream describes the gamma characteristics 4985 of the image, a datastream converter is strongly encouraged to 4986 write a <a href="#11gAMA"><span class="chunk">gAMA</span></a> 4987 chunk. Some datastream formats specify the display exponent (the 4988 exponent of the function which maps image samples to display 4989 output rather than the other direction). If the source file's 4990 gamma value is greater than 1.0, it is probably a display 4991 exponent, and the reciprocal of this value should be used for the 4992 PNG gamma value. If the source file format records the 4993 relationship between image samples and a quantity other than 4994 display output, it will be more complex than this to deduce the 4995 PNG gamma value.</p> 4996 4997 <p>If a PNG encoder or datastream converter knows that the image 4998 has been displayed satisfactorily using a display system whose 4999 transfer function can be approximated by a power function with 5000 exponent <tt>display_exponent</tt>, the image can be marked as 5001 having the gamma value:</p> 5002 5003 <pre> 5004 gamma = 1/display_exponent 5005 </pre> 5006 5007 <!-- ************Page Break******************* --> 5008 <!-- ************Page Break******************* --> 5009 <p>It is better to write a <a href="#11gAMA"><span class= 5010 "chunk">gAMA</span></a> chunk with a value that is approximately 5011 correct than to omit the chunk and force PNG decoders to guess an 5012 approximate gamma. If a PNG encoder is unable to infer the gamma 5013 value, it is preferable to omit the <a href="#11gAMA"><span 5014 class="chunk">gAMA</span></a> chunk. If a guess has to be made 5015 this should be left to the PNG decoder.</p> 5016 5017 <p>Gamma does not apply to alpha samples; alpha is always 5018 represented linearly.</p> 5019 5020 <p>See also 13.13: <a href="#13Decoder-gamma-handling"><span 5021 class="xref">Decoder gamma handling</span></a>.</p> 5022 5023 <h2><a name="12Encoder-colour-handling">12.3 Encoder colour 5024 handling</a></h2> 5025 5026 <p>See Annex C: <a href="#C-GammaAppendix"><span class= 5027 "xref">Gamma and chromaticity</span></a> for references to colour 5028 issues.</p> 5029 5030 <p>PNG encoders capable of full colour management <a href= 5031 "#G-ICC"><span class="bibref">[ICC]</span></a> will perform more 5032 sophisticated calculations than those described here and may 5033 choose to use the <a href="#11iCCP"><span class= 5034 "chunk">iCCP</span></a> chunk. If it is known that the image 5035 samples conform to the sRGB specification <a href= 5036 "#2-IEC-61966-2-1"><span class="NormRef">[IEC 5037 61966-2-1]</span></a>, PNG encoders are strongly encouraged to 5038 use the <a href="#11sRGB"><span class="chunk">sRGB</span></a> 5039 chunk.</p> 5040 5041 <p>If it is possible for the encoder to determine the 5042 chromaticities of the source display primaries, or to make a 5043 strong guess based on the origin of the image, or the hardware 5044 running it, the encoder is strongly encouraged to output the <a 5045 href="#11cHRM"><span class="chunk">cHRM</span></a> chunk. If this 5046 is done, the <a href="#11gAMA"><span class= 5047 "chunk">gAMA</span></a> chunk should also be written; decoders 5048 can do little with a <a href="#11cHRM"><span class= 5049 "chunk">cHRM</span></a> chunk if the <a href="#11gAMA"><span 5050 class="chunk">gAMA</span></a> chunk is missing.</p> 5051 5052 <p>There are a number of recommendations and standards for 5053 primaries and white points, some of which are linked to 5054 particular technologies, for example the CCIR 709 standard <a 5055 href="#G-ITU-R-BT709"><span class= 5056 "bibref">[ITU-R-BT709]</span></a> and the SMPTE-C standard <a 5057 href="#G-SMPTE-170M"><span class= 5058 "bibref">[SMPTE-170M]</span></a>.</p> 5059 5060 <p>There are three cases that need to be considered:</p> 5061 5062 <ol> 5063 <li>the encoder is part of the generation system;</li> 5064 5065 <li>the source image is captured by a camera or scanner;</li> 5066 5067 <li>the PNG datastream was generated by translation from some 5068 other format.</li> 5069 </ol> 5070 5071 <!-- deleted - comment PDG 31<p>Scanners that produce PNG datastreams as output should insert 5072 the filter chromaticities into a <a href="#11cHRM"><span class= 5073 "chunk">cHRM</span></a> chunk.</p>--> 5074 5075 <p>In the case of hand-drawn or digitally edited images, it is 5076 necessary to determine what monitor they were viewed on when 5077 being produced. Many image editing programs allow the type of 5078 monitor being used to be specified. This is often because they 5079 are working in some device-independent space internally. Such 5080 programs have enough information to write valid <a href= 5081 "#11cHRM"><span class="chunk">cHRM</span></a> and <a href= 5082 "#11gAMA"><span class="chunk">gAMA</span></a> chunks, and are 5083 strongly encouraged to do so automatically.</p> 5084 5085 <p>If the encoder is compiled as a portion of a computer image 5086 renderer that performs full-spectral rendering, the monitor 5087 values that were used to convert from the internal 5088 device-independent colour space to RGB should be written into the 5089 <a href="#11cHRM"><span class="chunk">cHRM</span></a> chunk. Any 5090 colours that are outside the gamut of the chosen RGB device 5091 should be mapped to be within the gamut; PNG does not store 5092 out-of-gamut colours.</p> 5093 5094 <p>If the computer image renderer performs calculations directly 5095 in device-dependent RGB space, a <a href="#11cHRM"><span class= 5096 "chunk">cHRM</span></a> chunk should not be written unless the 5097 scene description and rendering parameters have been adjusted for 5098 a particular monitor. In that case, the data for that monitor 5099 should be used to construct a <a href="#11cHRM"><span class= 5100 "chunk">cHRM</span></a> chunk.</p> 5101 5102 <p>A few image formats store calibration information, which can 5103 be used to fill in the <a href="#11cHRM"><span class= 5104 "chunk">cHRM</span></a> chunk. For example, TIFF 6.0 files <a 5105 href="#G-TIFF-6.0"><span class="bibref">[TIFF-6.0]</span></a> can 5106 optionally store calibration information, which if present should 5107 be used to construct the <a href="#11cHRM"><span class= 5108 "chunk">cHRM</span></a> chunk.</p> 5109 5110 <p>Video created with recent video equipment probably uses the 5111 CCIR 709 primaries and D65 white point <a href= 5112 "#G-ITU-R-BT709"><span class="bibref">[ITU-R-BT709]</span></a>, 5113 which are given in <a href="#12-table121"><span class= 5114 "tabref">Table 12.1</span></a>.</p> 5115 5116 <!-- ************Page Break******************* --> 5117 <!-- ************Page Break******************* --> 5118 <table class="Regular" summary= 5119 "CCIR 709 primaries and D65 whitepoint"> 5120 <caption><a name="12-table121"><b>Table 12.1 — CCIR 709 5121 primaries and D65 whitepoint</b></a></caption> 5122 5123 <tr> 5124 <th> </th> 5125 <th>R</th> 5126 <th>G</th> 5127 <th>B</th> 5128 <th>White</th> 5129 </tr> 5130 5131 <tr> 5132 <td class="Regular">x</td> 5133 <td class="Regular">0.640</td> 5134 <td class="Regular">0.300</td> 5135 <td class="Regular">0.150</td> 5136 <td class="Regular">0.3127</td> 5137 </tr> 5138 5139 <tr> 5140 <td class="Regular">y</td> 5141 <td class="Regular">0.330</td> 5142 <td class="Regular">0.600</td> 5143 <td class="Regular">0.060</td> 5144 <td class="Regular">0.3290</td> 5145 </tr> 5146 </table> 5147 5148 <p>An older but still very popular video standard is SMPTE-C <a 5149 href="#G-SMPTE-170M"><span class="bibref">[SMPTE-170M]</span></a> 5150 given in <a href="#12-table122"><span class="tabref">Table 5151 12.2</span></a>.</p> 5152 5153 <table class="Regular" summary= 5154 "CSMPTE-C video standard"> 5155 <caption><a name="12-table122"><b>Table 12.2 — SMPTE-C 5156 video standard</b></a></caption> 5157 5158 <tr> 5159 <th> </th> 5160 <th>R</th> 5161 <th>G</th> 5162 <th>B</th> 5163 <th>White</th> 5164 </tr> 5165 5166 <tr> 5167 <td class="Regular">x</td> 5168 <td class="Regular">0.630</td> 5169 <td class="Regular">0.310</td> 5170 <td class="Regular">0.155</td> 5171 <td class="Regular">0.3127</td> 5172 </tr> 5173 5174 <tr> 5175 <td class="Regular">y</td> 5176 <td class="Regular">0.340</td> 5177 <td class="Regular">0.595</td> 5178 <td class="Regular">0.070</td> 5179 <td class="Regular">0.3290</td> 5180 </tr> 5181 </table> 5182 5183 <p>It is <strong>not</strong> recommended that datastream format 5184 converters attempt to convert supplied images to a different RGB 5185 colour space. The data should be stored in the PNG datastream 5186 without conversion, and the source primary chromaticities should 5187 be recorded if they are known. Colour space transformation at 5188 datastream conversion time is a bad idea because of gamut 5189 mismatches and rounding errors. As with gamma conversions, it is 5190 better to store the data losslessly and incur at most one 5191 conversion when the image is finally displayed.</p> 5192 5193 <p>See also 13.14: <a href="#13Decoder-colour-handling"><span 5194 class="xref">Decoder colour handling</span></a>.</p> 5195 5196 <h2><a name="12Alpha-channel-creation">12.4 Alpha channel 5197 creation</a></h2> 5198 5199 <p>The alpha channel can be regarded either as a mask that 5200 temporarily hides transparent parts of the image, or as a means 5201 for constructing a non-rectangular image. In the first case, the 5202 colour values of fully transparent pixels should be preserved for 5203 future use. In the second case, the transparent pixels carry no 5204 useful data and are simply there to fill out the rectangular 5205 image area required by PNG. In this case, fully transparent 5206 pixels should all be assigned the same colour value for best 5207 compression.</p> 5208 5209 <p>Image authors should keep in mind the possibility that a 5210 decoder will not support transparency control in full (see 13.16: 5211 <a href="#13Alpha-channel-processing"><span class="xref">Alpha 5212 channel processing</span></a>). Hence, the colours assigned to 5213 transparent pixels should be reasonable background colours 5214 whenever feasible.</p> 5215 5216 <p>For applications that do not require a full alpha channel, or 5217 cannot afford the price in compression efficiency, the <a href= 5218 "#11tRNS"><span class="chunk">tRNS</span></a> transparency chunk 5219 is also available.</p> 5220 5221 <p>If the image has a known background colour, this colour should 5222 be written in the <a href="#11bKGD"><span class= 5223 "chunk">bKGD</span></a> chunk. Even decoders that ignore 5224 transparency may use the <a href="#11bKGD"><span class= 5225 "chunk">bKGD</span></a> colour to fill unused screen area.</p> 5226 5227 <p>If the original image has premultiplied (also called 5228 "associated") alpha data, it can be converted to PNG's 5229 non-premultiplied format by dividing each sample value by the 5230 corresponding alpha value, then multiplying by the maximum value 5231 for the image bit depth, and rounding to the nearest integer. In 5232 valid premultiplied data, the sample values never exceed their 5233 corresponding alpha values, so the result of the division should 5234 always be in the range 0 to 1. If the alpha value is zero, output 5235 black (zeroes).</p> 5236 5237 <!-- ************Page Break******************* --> 5238 <!-- ************Page Break******************* --> 5239 <h2><a name="12Sample-depth-scaling">12.5 Sample depth 5240 scaling</a></h2> 5241 5242 <p>When encoding input samples that have a sample depth that 5243 cannot be directly represented in PNG, the encoder shall scale 5244 the samples up to a sample depth that is allowed by PNG. The most 5245 accurate scaling method is the linear equation:</p> 5246 5247 <pre> 5248 output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5) 5249 </pre> 5250 5251 <p>where the input samples range from 0 to <tt>MAXINSAMPLE</tt> 5252 and the outputs range from 0 to <tt>MAXOUTSAMPLE</tt> (which is 5253 2<sup>sampledepth</sup>-1).</p> 5254 5255 <p>A close approximation to the linear scaling method is achieved 5256 by "left bit replication", which is shifting the valid bits to 5257 begin in the most significant bit and repeating the most 5258 significant bits into the open bits. This method is often faster 5259 to compute than linear scaling.</p> 5260 5261 <p>EXAMPLE Assume that 5-bit samples are being scaled up to 8 5262 bits. If the source sample value is 27 (in the range from 0-31), 5263 then the original bits are:</p> 5264 5265 <pre> 5266 4 3 2 1 0 5267 --------- 5268 1 1 0 1 1 5269 </pre> 5270 5271 <p>Left bit replication gives a value of 222:</p> 5272 5273 <pre> 5274 7 6 5 4 3 2 1 0 5275 ---------------- 5276 1 1 0 1 1 1 1 0 5277 |=======| |===| 5278 | Leftmost Bits Repeated to Fill Open Bits 5279 | 5280 Original Bits 5281 </pre> 5282 5283 <p>which matches the value computed by the linear equation. Left 5284 bit replication usually gives the same value as linear scaling, 5285 and is never off by more than one.</p> 5286 5287 <p>A distinctly less accurate approximation is obtained by simply 5288 left-shifting the input value and filling the low order bits with 5289 zeroes. This scheme cannot reproduce white exactly, since it does 5290 not generate an all-ones maximum value; the net effect is to 5291 darken the image slightly. This method is not recommended in 5292 general, but it does have the effect of improving compression, 5293 particularly when dealing with greater-than-8-bit sample depths. 5294 Since the relative error introduced by zero-fill scaling is small 5295 at high sample depths, some encoders may choose to use it. 5296 Zero-fill shall <strong>not</strong> be used for alpha channel 5297 data, however, since many decoders will treat alpha values of all 5298 zeroes and all ones as special cases. It is important to 5299 represent both those values exactly in the scaled data.</p> 5300 5301 <p>When the encoder writes an <a href="#11sBIT"><span class= 5302 "chunk">sBIT</span></a> chunk, it is required to do the scaling 5303 in such a way that the high-order bits of the stored samples 5304 match the original data. That is, if the <a href="#11sBIT"><span 5305 class="chunk">sBIT</span></a> chunk specifies a sample depth of 5306 S, the high-order S bits of the stored data shall agree with the 5307 original S-bit data values. This allows decoders to recover the 5308 original data by shifting right. The added low-order bits are not 5309 constrained. All the above scaling methods meet this 5310 restriction.</p> 5311 5312 <p>When scaling up source image data, it is recommended that the 5313 low-order bits be filled consistently for all samples; that is, 5314 the same source value should generate the same sample value at 5315 any pixel position. This improves compression by reducing the 5316 number of distinct sample values. This is not a mandatory 5317 requirement, and some encoders may choose not to follow it. For 5318 example, an encoder might instead dither the low-order bits, 5319 improving displayed image quality at the price of increasing file 5320 size.</p> 5321 5322 <p>In some applications the original source data may have a range 5323 that is not a power of 2. The linear scaling equation still works 5324 for this case, although the shifting methods do not. It is 5325 recommended that an <a href="#11sBIT"><span class= 5326 "chunk">sBIT</span></a> chunk not be written for such images, 5327 since <a href="#11sBIT"><span class="chunk">sBIT</span></a> 5328 suggests that the original data range was exactly 5329 0..2<sup>S</sup>-1.</p> 5330 5331 <!-- ************Page Break******************* --> 5332 <!-- ************Page Break******************* --> 5333 <h2><a name="12Suggested-palettes">12.6 Suggested 5334 palettes</a></h2> 5335 5336 <p>Suggested palettes may appear as <a href="#11sPLT"><span 5337 class="chunk">sPLT</span></a> chunks in any PNG datastream, or as 5338 a <a href="#11PLTE"><span class="chunk">PLTE</span></a> chunk in 5339 truecolour PNG datastreams. In either case, the suggested palette 5340 is not an essential part of the image data, but it may be used to 5341 present the image on indexed-colour display hardware. Suggested 5342 palettes are of no interest to viewers running on truecolour 5343 hardware.</p> 5344 5345 <p>When an <a href="#11sPLT"><span class="chunk">sPLT</span></a> 5346 chunk is used to provide a suggested palette, it is recommended 5347 that the encoder use the frequency fields to indicate the 5348 relative importance of the palette entries, rather than leave 5349 them all zero (meaning undefined). The frequency values are most 5350 easily computed as "nearest neighbour" counts, that is, the 5351 approximate usage of each RGBA palette entry if no dithering is 5352 applied. (These counts will often be available "for free" as a 5353 consequence of developing the suggested palette.) Because the 5354 suggested palette includes transparency information, it should be 5355 computed for the uncomposited image.</p> 5356 5357 <p>Even for indexed-colour images, <a href="#11sPLT"><span class= 5358 "chunk">sPLT</span></a> can be used to define alternative reduced 5359 palettes for viewers that are unable to display all the colours 5360 present in the <a href="#11PLTE"><span class= 5361 "chunk">PLTE</span></a> chunk. 5362 If the <a href="#11PLTE"><span class="chunk">PLTE</span></a> 5363 chunk appears without the <a href="#11bKGD"><span class= 5364 "chunk">bKGD</span></a> chunk in an image of colour type 6, the 5365 circumstances under which the palette was computed are 5366 unspecified.</p> 5367 5368 5369 <p>An older method for including a suggested palette in a 5370 truecolour PNG datastream uses the <a href="#11PLTE"><span class= 5371 "chunk">PLTE</span></a> chunk. If this method is used, the 5372 histogram (frequencies) should appear in a separate <a href= 5373 "#11hIST"><span class="chunk">hIST</span></a> chunk. The <a href= 5374 "#11PLTE"><span class="chunk">PLTE</span></a> chunk does not 5375 include transparency information. Hence for images of colour type 5376 6 (truecolour with alpha), it is recommended that a <a href= 5377 "#11bKGD"><span class="chunk">bKGD</span></a> chunk appear and 5378 that the palette and histogram be computed with reference to the 5379 image as it would appear after compositing against the specified 5380 background colour. This definition is necessary to ensure that 5381 useful palette entries are generated for pixels having fractional 5382 alpha values. The resulting palette will probably be useful only 5383 to viewers that present the image against the same background 5384 colour. It is recommended that PNG editors delete or recompute 5385 the palette if they alter or remove the <a href="#11bKGD"><span 5386 class="chunk">bKGD</span></a> chunk in an image of colour type 5387 6.</p> 5388 5389 <p>For images of colour type 2 (truecolour), it is recommended 5390 that the <a href="#11PLTE"><span class="chunk">PLTE</span></a> 5391 and <a href="#11hIST"><span class="chunk">hIST</span></a> chunks 5392 be computed with reference to the RGB data only, ignoring any 5393 transparent-colour specification. If the datastream uses 5394 transparency (has a <a href="#11tRNS"><span class= 5395 "chunk">tRNS</span></a> chunk), viewers can easily adapt the 5396 resulting palette for use with their intended background colour 5397 (see 13.17: <a href= 5398 "#13Histogram-and-suggested-palette-usage"><span class="xref"> 5399 Histogram and suggested palette usage</span></a>). 5400 </p> 5401 5402 <p>For providing suggested palettes, 5403 the <a href="#11sPLT"><span class="chunk">sPLT</span></a> 5404 chunk is more flexible than the <a href="#11PLTE"><span class= 5405 "chunk">PLTE</span></a> chunk in 5406 the following ways:</p> 5407 5408 <!-- <ol start="1"> --><ol> 5409 <li>With <a href="#11sPLT"><span class="chunk">sPLT</span></a> 5410 multiple suggested palettes may be provided. A PNG decoder may 5411 choose an appropriate palette based on name or number of 5412 entries.</li> 5413 5414 <li>In a PNG datastream of colour type 6 (truecolour with alpha 5415 channel), the <a href="#11PLTE"><span class= 5416 "chunk">PLTE</span></a> chunk represents a palette already 5417 composited against the <a href="#11bKGD"><span class= 5418 "chunk">bKGD</span></a> colour, so it is useful only for display 5419 against that background colour. The <a href="#11sPLT"><span 5420 class="chunk">sPLT</span></a> chunk provides an uncomposited 5421 palette, which is useful for display against backgrounds chosen 5422 by the PNG decoder.</li> 5423 5424 <li>Since the <a href="#11sPLT"><span class= 5425 "chunk">sPLT</span></a> chunk is an ancillary chunk, a PNG editor 5426 may add or modify suggested palettes without being forced to 5427 discard unknown unsafe-to-copy chunks.</li> 5428 5429 <li>Whereas the <a href="#11sPLT"><span class= 5430 "chunk">sPLT</span></a> chunk is allowed in PNG datastreams for 5431 colour types 0, 3, and 4 (greyscale and indexed), the <a href= 5432 "#11PLTE"><span class="chunk">PLTE</span></a> chunk cannot be 5433 used to provide reduced palettes in these cases.</li> 5434 5435 <li>More than 256 entries may appear in the <a href= 5436 "#11sPLT"><span class="chunk">sPLT</span></a> chunk.</li> 5437 </ol> 5438 5439 <p>A PNG encoder that uses the <a href="#11sPLT"><span class= 5440 "chunk">sPLT</span></a> chunk may choose to write a suggested 5441 palette represented by <a href="#11PLTE"><span class= 5442 "chunk">PLTE</span></a> and <a href="#11hIST"><span class= 5443 "chunk">hIST</span></a> chunks as well, for compatibility with 5444 decoders that do not recognize the <a href="#11sPLT"><span class= 5445 "chunk">sPLT</span></a> chunk.</p> 5446 5447 <!-- ************Page Break******************* --> 5448 <!-- ************Page Break******************* --> 5449 <h2><a name="12Interlacing">12.7 Interlacing</a></h2> 5450 5451 <p>This International Standard defines two interlace methods, 5452 one of which is no interlacing. Interlacing provides a convenient 5453 basis from which decoders can progressively display an image, as 5454 described in 13.8: <a href="#13Progressive-display"><span class= 5455 "xref">Interlacing and progressive display</span></a>.</p> 5456 5457 <h2><a name="12Filter-selection">12.8 Filter selection</a></h2> 5458 5459 <p>For images of colour type 3 (indexed-colour), filter type 0 5460 (None) is usually the most effective. Colour images with 256 or 5461 fewer colours should almost always be stored in indexed-colour 5462 format; truecolour format is likely to be much larger.</p> 5463 5464 <p>Filter type 0 is also recommended for images of bit depths 5465 less than 8. For low-bit-depth greyscale images, in rare cases, 5466 better compression may be obtained by first expanding the image 5467 to 8-bit representation and then applying filtering.</p> 5468 5469 <p>For truecolour and greyscale images, any of the five filters 5470 may prove the most effective. If an encoder uses a fixed filter, 5471 the Paeth filter is most likely to be the best.</p> 5472 5473 <p>For best compression of truecolour and greyscale images, 5474 the recommended approach is 5475 adaptive filtering in which a filter is 5476 chosen for each scanline. The following simple heuristic has 5477 performed well in early tests: compute the output scanline using 5478 all five filters, and select the filter that gives the smallest 5479 sum of absolute values of outputs. (Consider the output bytes as 5480 signed differences for this test.) This method usually 5481 outperforms any single fixed filter choice. However, it is likely 5482 that better heuristics will be found as more experience is 5483 gained with PNG.</p> 5484 5485 <p>Filtering according to these recommendations is effective in 5486 conjunction with either of the two interlace methods defined in 5487 this International Standard.</p> 5488 5489 <h2><a name="12Compression">12.9 Compression</a></h2> 5490 5491 <p>The encoder may divide the compressed datastream into <a href= 5492 "#11IDAT"><span class="chunk">IDAT</span></a> chunks however it 5493 wishes. (Multiple <a href="#11IDAT"><span class= 5494 "chunk">IDAT</span></a> chunks are allowed so that encoders may 5495 work in a fixed amount of memory; typically the chunk size will 5496 correspond to the encoder's buffer size.) A PNG datastream in 5497 which each <a href="#11IDAT"><span class="chunk">IDAT</span></a> 5498 chunk contains only one data byte is valid, though remarkably 5499 wasteful of space. (Zero-length <a href="#11IDAT"><span class= 5500 "chunk">IDAT</span></a> chunks are also valid, though even more 5501 wasteful.)</p> 5502 5503 <h2><a name="12Text-chunk-processing">12.10 Text chunk 5504 processing</a></h2> 5505 5506 <p>A nonempty keyword shall be provided for each text chunk. The 5507 generic keyword "Comment" can be used if no better description of 5508 the text is available. If a user-supplied keyword is used, 5509 encoders should check that it meets the restrictions on 5510 keywords.</p> 5511 5512 <p>For the <a href="#11tEXt"><span class="chunk">tEXt</span></a> 5513 and <a href="#11zTXt"><span class="chunk">zTXt</span></a> chunks, 5514 PNG text strings are expected to use the Latin-1 character set. 5515 Encoders should avoid storing characters that are not defined in 5516 Latin-1, and should provide character code remapping if the local 5517 system's character set is not Latin-1. The <a href= 5518 "#11iTXt"><span class="chunk">iTXt</span></a> chunk provides 5519 support for international text, represented using the UTF-8 5520 encoding of UCS. Encoders should discourage the creation of 5521 single lines of text longer than 79 characters, in order to 5522 facilitate easy reading. It is recommended that text items less 5523 than 1024 bytes in size should be output using uncompressed 5524 text chunks. It is 5525 recommended that the basic title and author keywords be output 5526 using uncompressed text chunks. 5527 Placing large text chunks after the 5528 image data (after the <a href="#11IDAT"><span class= 5529 "chunk">IDAT</span></a> chunks) can speed up image display in 5530 some situations, as the decoder will decode the image data first. 5531 It is recommended that small text chunks, such as the image 5532 title, appear before the <a href="#11IDAT"><span class= 5533 "chunk">IDAT</span></a> chunks.</p> 5534 5535 <!-- ************Page Break******************* --> 5536 <!-- ************Page Break******************* --> 5537 <h2><a name="12Chunk-processing">12.11 Chunking</a></h2> 5538 5539 <h3><a name="12Use-of-private-chunks">12.11.1 Use of private 5540 chunks</a></h3> 5541 5542 <p> 5543 Chunk types are classified as public or private depending on bit 5 5544 of the second byte (the private bit), and classified as critical or 5545 ancillary depending on bit 5 of the first byte (the ancillary bit). 5546 See 5.4: <a href= 5547 "#5Chunk-naming-conventions"><span class="xref">Chunk naming 5548 conventions</span></a>. 5549 </p> 5550 5551 <p>Applications can use PNG private chunks to carry information 5552 that need not be understood by other applications. Such chunks 5553 shall be given private chunk types, 5554 to ensure that they can never conflict 5555 with any future public chunk definition. However, there is no 5556 guarantee that some other application will not use the same 5557 private chunk type. If a private chunk type is used, it is 5558 prudent to store additional identifying information at the 5559 beginning of the chunk data.</p> 5560 5561 <p>An ancillary chunk type, not a critical chunk type, should be 5562 used for all private chunks that store information that is not 5563 absolutely essential to view the image. Creation of private 5564 critical chunks is discouraged because PNG datastreams containing 5565 such chunks are not portable. Such chunks should not be used in 5566 publicly available software or datastreams. If private critical 5567 chunks are essential for an application, it is recommended that 5568 one appear near the start of the datastream, so that a standard 5569 decoder need not read very far before discovering that it cannot 5570 handle the datastream.</p> 5571 5572 <p>If other organizations need to understand a new chunk type, it 5573 should be submitted to the Registration Authority (see 4.9: <a 5574 href="#4Concepts.Registration"><span class="xref">Extension and 5575 registration</span></a>). A proposed public chunk type 5576 shall not be used in publicly available software or 5577 datastreams until registration has been approved.</p> 5578 5579 <p>If an ancillary chunk contains textual information that might 5580 be of interest to a human user, a special chunk type should not 5581 be defined for it. Instead a <a href="#11tEXt"><span class= 5582 "chunk">tEXt</span></a> chunk should be used and a suitable 5583 keyword defined. The information will then be available to other 5584 users.</p> 5585 5586 <p>Keywords in <a href="#11tEXt"><span class= 5587 "chunk">tEXt</span></a> chunks should be reasonably 5588 self-explanatory, since the aim is to let other users understand 5589 what the chunk contains. If generally useful, new keywords should 5590 be registered with the Registration Authority (see 4.9: <a href= 5591 "#4Concepts.Registration"><span class="xref">Extension and 5592 registration</span></a>). However, it is permissible to use 5593 keywords without registering them first.</p> 5594 5595 <h3><a name="12Private-type-and-method-codes">12.11.2 Private 5596 type and method codes</a></h3> 5597 5598 <p>This specification defines the meaning of only some of the 5599 possible values of some fields. For example, only compression 5600 method 0 and filter types 0 through 4 are defined in this 5601 International Standard. Numbers greater than 127 shall be used 5602 when inventing experimental or private definitions of values for 5603 any of these fields. Numbers below 128 are reserved for possible 5604 public extensions of this specification through future 5605 standardization (see 4.9 <a href="#4Concepts.Registration"><span 5606 class="xref">Extension and registration</span></a>). The use of 5607 private type codes may render a datastream unreadable by standard 5608 decoders. Such codes are strongly discouraged except for 5609 experimental purposes, and should not appear in publicly 5610 available software or datastreams.</p> 5611 5612 <h3><a name="12Ancillary">12.11.3 Ancillary chunks</a></h3> 5613 5614 <p>All ancillary chunks are optional, encoders need not write 5615 them. However, encoders are encouraged to write the standard 5616 ancillary chunks when the information is available.</p> 5617 5618 <!-- ************Page Break******************* --> 5619 <!-- ************Page Break******************* --> 5620 <h1><a name="13Decoders">13 PNG decoders and viewers</a></h1> 5621 5622 <h2><a name="13Introduction">13.1 Introduction</a></h2> 5623 5624 <p>This clause gives some requirements and recommendations for PNG 5625 decoder behaviour and viewer behaviour. A viewer presents the 5626 decoded PNG image to the user. Since viewer and decoder behaviour 5627 are closely connected, decoders and viewers are treated together 5628 here. The only absolute requirement on a PNG decoder is that it 5629 successfully reads any datastream conforming to the format 5630 specified in the preceding chapters. However, best results will 5631 usually be achieved by following these additional 5632 recommendations.</p> 5633 5634 <p>PNG decoders shall support all valid combinations of bit 5635 depth, colour type, compression method, filter method, and 5636 interlace method that are explicitly defined in this 5637 International Standard.</p> 5638 5639 <p>All ancillary chunks are optional; decoders may ignore them. 5640 However, decoders are encouraged to interpret these chunks when 5641 appropriate and feasible.</p> 5642 5643 <h2><a name="13Decoders.Errors">13.2 Error handling</a></h2> 5644 5645 <p>Errors in a PNG datastream will fall into two general classes, 5646 transmission errors and syntax errors (see <a href= 5647 "#4Concepts.Errors"><span class="xref">4.8 Error 5648 handling</span></a>).</p> 5649 5650 <p>Examples of transmission errors are transmission in "text" or 5651 "ascii" mode, in which byte codes 13 and/or 10 may be added, 5652 removed, or converted throughout the datastream; unexpected 5653 termination, in which the datastream is truncated; or a physical 5654 error on a storage device, in which one or more blocks (typically 5655 512 bytes each) will have garbled or random values. Some examples 5656 of syntax errors are an invalid value for a row filter, an 5657 invalid compression method, an invalid chunk length, the absence 5658 of a <a href="#11PLTE"><span class="chunk">PLTE</span></a> chunk 5659 before the first <a href="#11IDAT"><span class= 5660 "chunk">IDAT</span></a> chunk in an indexed image, or the 5661 presence of multiple <a href="#11gAMA"><span class= 5662 "chunk">gAMA</span></a> chunks. A PNG decoder should handle 5663 errors as follows:</p> 5664 5665 <!-- <ol start="1"> --><ol> 5666 <li>Detect errors as early as possible using the PNG signature 5667 bytes and CRCs on each chunk. Decoders should verify that all 5668 eight bytes of the PNG signature are correct. A decoder can 5669 have additional confidence in the datastream's integrity if the 5670 next eight bytes begin an <a href="#11IHDR"><span class= 5671 "chunk">IHDR</span></a> chunk with the correct chunk length. A 5672 CRC should be checked before processing the chunk data. Sometimes 5673 this is impractical, for example when a streaming PNG decoder is 5674 processing a large <a href="#11IDAT"><span class= 5675 "chunk">IDAT</span></a> chunk. In this case the CRC should be 5676 checked when the end of the chunk is reached.</li> 5677 5678 <li>Recover from an error, if possible; otherwise fail 5679 gracefully. Errors that have little or no effect on the 5680 processing of the image may be ignored, while those that affect 5681 critical data shall be dealt with in a manner appropriate to the 5682 application.</li> 5683 5684 <li>Provide helpful messages describing errors, including 5685 recoverable errors.</li> 5686 </ol> 5687 5688 <p>Three classes of PNG chunks are relevant to this philosophy. 5689 For the purposes of this classification, an "unknown chunk" is 5690 either one whose type was genuinely unknown to the decoder's 5691 author, or one that the author chose to treat as unknown, because 5692 default handling of that chunk type would be sufficient for the 5693 program's purposes. Other chunks are called "known chunks". Given 5694 this definition, the three classes are as follows:</p> 5695 5696 <!-- <ol start="4"> --><ol> 5697 <li>known chunks, which necessarily includes all of the critical 5698 chunks defined in this International Standard (<a href= 5699 "#11IHDR"><span class="chunk">IHDR</span></a>, <a href= 5700 "#11PLTE"><span class="chunk">PLTE</span></a>, <a href= 5701 "#11IDAT"><span class="chunk">IDAT</span></a>, <a href= 5702 "#11IEND"><span class="chunk">IEND</span></a>)</li> 5703 5704 <li>unknown critical chunks (bit 5 of the first byte of the chunk 5705 type is 0)</li> 5706 5707 <li>unknown ancillary chunks (bit 5 of the first byte of the 5708 chunk type is 1)</li> 5709 </ol> 5710 5711 <p>See 5.4: <a href="#5Chunk-naming-conventions"><span class= 5712 "xref">Chunk naming conventions</span></a> for a full description 5713 of chunk naming conventions.</p> 5714 5715 <!-- ************Page Break******************* --> 5716 <!-- ************Page Break******************* --> 5717 <p>PNG chunk types are marked "critical" or "ancillary" according 5718 to whether the chunks are critical for the purpose of extracting 5719 a viewable image (as with <a href="#11IHDR"><span class= 5720 "chunk">IHDR</span></a>, <a href="#11PLTE"><span class= 5721 "chunk">PLTE</span></a>, and <a href="#11IDAT"><span class= 5722 "chunk">IDAT</span></a>) or critical to understanding the 5723 datastream structure (as with <a href="#11IEND"><span class= 5724 "chunk">IEND</span></a>). This is a specific kind of criticality 5725 and one that is not necessarily relevant to every conceivable 5726 decoder. For example, a program whose sole purpose is to extract 5727 text annotations (for example, copyright information) does not 5728 require a viewable image. Another decoder might consider the <a 5729 href="#11tRNS"><span class="chunk">tRNS</span></a> and <a href= 5730 "#11gAMA"><span class="chunk">gAMA</span></a> chunks essential to 5731 its proper execution.</p> 5732 5733 <p>Syntax errors always involve known chunks because syntax 5734 errors in unknown chunks cannot be detected. The PNG decoder has 5735 to determine whether a syntax error is fatal (unrecoverable) or 5736 not, depending on its requirements and the situation. For 5737 example, most decoders can ignore an invalid <a href= 5738 "#11IEND"><span class="chunk">IEND</span></a> chunk; a 5739 text-extraction program can ignore the absence of <a href= 5740 "#11IDAT"><span class="chunk">IDAT</span></a>; an image viewer 5741 cannot recover from an empty <a href="#11PLTE"><span class= 5742 "chunk">PLTE</span></a> chunk in an indexed image but it can 5743 ignore an invalid <a href="#11PLTE"><span class= 5744 "chunk">PLTE</span></a> chunk in a truecolour image; and a 5745 program that extracts the alpha channel can ignore an invalid <a 5746 href="#11gAMA"><span class="chunk">gAMA</span></a> chunk, but may 5747 consider the presence of two <a href="#11tRNS"><span class= 5748 "chunk">tRNS</span></a> chunks to be a fatal error. Anomalous 5749 situations other than syntax errors shall be treated as 5750 follows:</p> 5751 5752 <!-- <ol start="7"> --><ol> 5753 <li>Encountering an unknown ancillary chunk is never an error. 5754 The chunk can simply be ignored.</li> 5755 5756 <li>Encountering an unknown critical chunk is a fatal condition 5757 for any decoder trying to extract the image from the datastream. 5758 A decoder that ignored a critical chunk could not know whether 5759 the image it extracted was the one intended by the encoder.</li> 5760 5761 <li>A PNG signature mismatch, a CRC mismatch, or an unexpected 5762 end-of-stream indicates a corrupted datastream, and may be 5763 regarded as a fatal error. A decoder could try to salvage 5764 something from the datastream, but the extent of the damage will 5765 not be known.</li> 5766 </ol> 5767 5768 <p>When a fatal condition occurs, the decoder should fail 5769 immediately, signal an error to the user if appropriate, and 5770 optionally continue displaying any image data already visible to 5771 the user (i.e. "fail gracefully"). The application as a whole 5772 need not terminate.</p> 5773 5774 <p>When a non-fatal error occurs, the decoder should signal a 5775 warning to the user if appropriate, recover from the error, and 5776 continue processing normally.</p> 5777 5778 <p>Decoders that do not compute CRCs should interpret apparent 5779 syntax errors as indications of corruption (see also 13.3: <a 5780 href="#13Error-checking"><span class="xref">Error 5781 checking</span></a>).</p> 5782 5783 <p>Errors in compressed chunks (<a href="#11IDAT"><span class= 5784 "chunk">IDAT</span></a>, <a href="#11zTXt"><span class= 5785 "chunk">zTXt</span></a>, <a href="#11iTXt"><span class= 5786 "chunk">iTXt</span></a>, <a href="#11iCCP"><span class= 5787 "chunk">iCCP</span></a>) could lead to buffer overruns. 5788 Implementors of deflate decompressors should guard against this 5789 possibility.</p> 5790 5791 <h2><a name="13Error-checking">13.3 Error checking</a></h2> 5792 5793 <p>The PNG error handling philosophy is described in 13.2: <a 5794 href="#13Decoders.Errors"><span class="xref">Error 5795 handling</span></a>.</p> 5796 5797 <p>Unknown chunk types shall be handled as described in 5.4: <a 5798 href="#5Chunk-naming-conventions"><span class="xref">Chunk naming 5799 conventions</span></a>. An unknown chunk type is <strong>not</strong> to 5800 be treated as an error unless it is a critical chunk.</p> 5801 5802 <p>The chunk type can be checked for plausibility by seeing 5803 whether all four bytes are in the range codes 65-90 and 97-122 5804 (decimal); note that this need be done only for unrecognized 5805 chunk types. If the total datastream size is known (from file 5806 system information, HTTP protocol, etc), the chunk length can be 5807 checked for plausibility as well. If CRCs are not checked, 5808 dropped/added data bytes or an erroneous chunk length can cause 5809 the decoder to get out of step and misinterpret subsequent data 5810 as a chunk header.</p> 5811 5812 <p>For known-length chunks, such as <a href="#11IHDR"><span 5813 class="chunk">IHDR</span></a>, decoders should treat an 5814 unexpected chunk length as an error. Future extensions to this 5815 specification will not add new fields to existing chunks; 5816 instead, new chunk types will be added to carry new 5817 information.</p> 5818 5819 <p>Unexpected values in fields of known chunks (for example, an 5820 unexpected compression method in the <a href="#11IHDR"><span 5821 class="chunk">IHDR</span></a> chunk) shall be checked for and 5822 treated as errors. However, it is recommended that unexpected 5823 field values be treated as fatal errors only in <strong>critical</strong> 5824 chunks. An unexpected value in an ancillary chunk can be handled 5825 by ignoring the whole chunk as though it were an unknown chunk 5826 type. (This recommendation assumes that the chunk's CRC has been 5827 verified. In decoders that do not check CRCs, it is safer to 5828 treat any unexpected value as indicating a corrupted 5829 datastream.)</p> 5830 5831 <p>Standard PNG images shall be compressed with compression 5832 method 0. The compression method field of the <a href="#11IHDR"><span class= 5833 "chunk">IHDR</span></a> chunk is 5834 provided for possible future standardization or proprietary 5835 variants. Decoders shall check this byte and report an error if 5836 it holds an unrecognized code. See clause 10: <a href= 5837 "#10Compression"><span class="xref">Compression</span></a> for 5838 details.</p> 5839 5840 <h2><a name="13Security-considerations">13.4 Security 5841 considerations</a></h2> 5842 5843 <p>A PNG datastream is composed of a collection of explicitly 5844 typed chunks. Chunks whose contents are defined by the 5845 specification could actually contain anything, including 5846 malicious code. But there is no known risk that such malicious 5847 code could be executed on the recipient's computer as a result of 5848 decoding the PNG image.</p> 5849 5850 <p>The possible security risks associated with future chunk types 5851 cannot be specified at this time. Security issues will be 5852 considered by the Registration Authority when evaluating chunks 5853 proposed for registration as public chunks. There is no 5854 additional security risk associated with unknown or unimplemented 5855 chunk types, because such chunks will be ignored, or at most be 5856 copied into another PNG datastream.</p> 5857 5858 <p>The <a href="#11iTXt"><span class="chunk">iTXt</span></a>, <a 5859 href="#11tEXt"><span class="chunk">tEXt</span></a>, and <a href= 5860 "#11zTXt"><span class="chunk">zTXt</span></a> chunks contain keywords 5861 and data 5862 that are meant to be displayed as plain text. The <a href= 5863 "#11iCCP"><span class="chunk">iCCP</span></a> and <a href= 5864 "#11sPLT"><span class="chunk">sPLT</span></a> chunks contain 5865 keywords that are meant to be displayed as plain text. It is 5866 possible that if the decoder displays such text without filtering 5867 out control characters, especially the ESC (escape) character, 5868 certain systems or terminals could behave in undesirable and 5869 insecure ways. It is recommended that decoders filter out control 5870 characters to avoid this risk; see 13.5.3: <a href= 5871 "#13Text-chunk-processing"><span class="xref">Text chunk 5872 processing</span></a>.</p> 5873 5874 <p>Every chunk begins with a length field, which makes it easier 5875 to write decoders that are invulnerable to fraudulent chunks that 5876 attempt to overflow buffers. The CRC at the end of every chunk 5877 provides a robust defence against accidentally corrupted data. 5878 The PNG signature bytes provide early detection of common file 5879 transmission errors.</p> 5880 5881 <p>A decoder that fails to check CRCs could be subject to data 5882 corruption. The only likely consequence of such corruption is 5883 incorrectly displayed pixels within the image. Worse things might 5884 happen if the CRC of the <a href="#11IHDR"><span class= 5885 "chunk">IHDR</span></a> chunk is not checked and the width or 5886 height fields are corrupted. See 13.3: <a href= 5887 "#13Error-checking"><span class="xref">Error 5888 checking</span></a>.</p> 5889 5890 <p>A poorly written decoder might be subject to buffer overflow, 5891 because chunks can be extremely large, up to 2<sup>31</sup>-1 5892 bytes long. But properly written decoders will handle large 5893 chunks without difficulty.</p> 5894 5895 <h2><a name="13Chunking">13.5 Chunking</a></h2> 5896 5897 <p>Decoders shall recognize chunk types by a simple four-byte 5898 literal comparison; it is incorrect to perform case conversion on 5899 chunk types. A decoder encountering an unknown chunk in which the 5900 ancillary bit is 1 may safely ignore the chunk and proceed to 5901 display the image. A decoder trying to extract the image, upon 5902 encountering an unknown chunk in which the ancillary bit is 0, 5903 indicating a critical chunk, shall indicate to the user that the 5904 image contains information it cannot safely interpret.</p> 5905 5906 <p>(Decoders should not flag an error if the reserved bit is set 5907 to 1, however, as some future version of the PNG specification 5908 could define a meaning for this bit. It is sufficient to treat a 5909 chunk with this bit set in the same way as any other unknown 5910 chunk type.)</p> 5911 5912 <h2><a name="13Pixel-dimensions">13.6 Pixel dimensions</a></h2> 5913 5914 <p>Non-square pixels can be represented (see 11.3.5.3: <a href= 5915 "#11pHYs"><span class="xref"><span class="chunk">pHYs</span> 5916 Physical pixel dimensions</span></a>), but viewers are not 5917 required to account for them; a viewer can present any PNG 5918 datastream as though its pixels are square.</p> 5919 5920 <p>Where the pixel aspect ratio of the display differs from the 5921 aspect ratio of the physical pixel dimensions defined in the PNG 5922 datastream, viewers are strongly encouraged to rescale images for 5923 proper display.</p> 5924 5925 <p>When the <a href="#11pHYs"><span class="xref"><span class= 5926 "chunk">pHYs</span></span></a> chunk has a unit specifier of 0 5927 (unit is unknown), the behaviour of a decoder may depend on the 5928 ratio of the two pixels-per-unit values, but should not depend on 5929 their magnitudes. For example, a <a href="#11pHYs"><span class= 5930 "xref"><span class="chunk">pHYs</span></span></a> chunk 5931 containing <tt>(ppuX, ppuY, unit) = (2, 1, 0)</tt> is equivalent 5932 to one containing <tt>(1000, 500, 0)</tt>; both are equally valid 5933 indications that the image pixels are twice as tall as they are 5934 wide.</p> 5935 5936 <p>One reasonable way for viewers to handle a difference between 5937 the pixel aspect ratios of the image and the display is to expand 5938 the image either horizontally or vertically, but not both. The 5939 scale factors could be obtained using the following 5940 floating-point calculations:</p> 5941 5942 <pre> 5943 <tt>image_ratio = pHYs_ppuY / pHYs_ppuX 5944 display_ratio = display_ppuY / display_ppuX 5945 scale_factor_X = max(1.0, image_ratio/display_ratio) 5946 scale_factor_Y = max(1.0, display_ratio/image_ratio)</tt> 5947 </pre> 5948 5949 <p>Because other methods such as maintaining the image area are 5950 also reasonable, and because ignoring the <a href="#11pHYs"><span 5951 class="xref"><span class="chunk">pHYs</span></span></a> chunk is 5952 permissible, authors should not assume that all viewing 5953 applications will use this scaling method.</p> 5954 5955 <p>As well as making corrections for pixel aspect ratio, a viewer 5956 may have reasons to perform additional scaling both horizontally 5957 and vertically. For example, a viewer might want to shrink an 5958 image that is too large to fit on the display, or to expand 5959 images sent to a high-resolution printer so that they appear the 5960 same size as they did on the display.</p> 5961 5962 <h2><a name="13Text-chunk-processing">13.7 Text chunk 5963 processing</a></h2> 5964 5965 <p>If practical, PNG decoders should have a way to display to the 5966 user all the <a href="#11iTXt"><span class= 5967 "chunk">iTXt</span></a>, <a href="#11tEXt"><span class= 5968 "chunk">tEXt</span></a>, and <a href="#11zTXt"><span class= 5969 "chunk">zTXt</span></a> chunks found in the datastream. Even if 5970 the decoder does not recognize a particular text keyword, the 5971 user might be able to understand it.</p> 5972 5973 <p>When processing <a href="#11tEXt"><span class= 5974 "chunk">tEXt</span></a> and <a href="#11zTXt"><span class= 5975 "chunk">zTXt</span></a> chunks, decoders could encounter 5976 characters other than those permitted. Some can be safely 5977 displayed (e.g., TAB, FF, and CR, decimal 9, 12, and 13, 5978 respectively), but others, especially the ESC character (decimal 5979 27), could pose a security hazard (because unexpected actions may 5980 be taken by display hardware or software). Decoders should not 5981 attempt to directly display any non-Latin-1 characters (except 5982 for newline and perhaps TAB, FF, CR) encountered in a <a href= 5983 "#11tEXt"><span class="chunk">tEXt</span></a> or <a href= 5984 "#11zTXt"><span class="chunk">zTXt</span></a> chunk. Instead, 5985 they should be ignored or displayed in a visible notation such as 5986 "<tt>\</tt>nnn". See 13.4: <a href= 5987 "#13Security-considerations"><span class="xref">Security 5988 considerations</span></a>.</p> 5989 5990 <p>Even though encoders are recommended to represent newlines as 5991 linefeed (decimal 10), it is recommended that decoders not rely 5992 on this; it is best to recognize all the common newline 5993 combinations (CR, LF, and CR-LF) and display each as a single 5994 newline. TAB can be expanded to the proper number of spaces 5995 needed to arrive at a column multiple of 8.</p> 5996 5997 <p>Decoders running on systems with non-Latin-1 character set 5998 encoding should provide character code remapping so that Latin-1 5999 characters are displayed correctly. Some systems may not provide 6000 all the characters defined in Latin-1. Mapping unavailable 6001 characters to a visible notation such as "<tt>\</tt>nnn" is a 6002 good fallback. Character codes 127-255 should be displayed only 6003 if they are printable characters on the decoding system. Some 6004 systems may interpret such codes as control characters; for 6005 security, decoders running on such systems should not display 6006 such characters literally.</p> 6007 6008 <p>Decoders should be prepared to display text chunks that 6009 contain any number of printing characters between newline 6010 characters, even though it is recommended that encoders avoid 6011 creating lines in excess of 79 characters.</p> 6012 6013 <h2><a name="13Decompression">13.8 Decompression</a></h2> 6014 6015 <p>The compression technique used in this International Standard 6016 does not require the entire compressed datastream to be available 6017 before decompression can start. Display can therefore commence 6018 before the entire decompressed datastream is available. It is 6019 extremely unlikely that any general purpose compression methods 6020 in future versions of this International Standard will not have 6021 this property.</p> 6022 6023 <p>It is important to emphasize that <a href="#11IDAT"><span 6024 class="chunk">IDAT</span></a> chunk boundaries have no semantic 6025 significance and can occur at any point in the compressed 6026 datastream. There is no required correlation between the 6027 structure of the image data (for example, scanline boundaries) and 6028 deflate block boundaries or <a href="#11IDAT"><span class= 6029 "chunk">IDAT</span></a> chunk boundaries. The complete image data 6030 is represented by a single zlib datastream that is stored in some 6031 number of <a href="#11IDAT"><span class="chunk">IDAT</span></a> 6032 chunks; a decoder that assumes any more than this is incorrect. 6033 Some encoder implementations may emit datastreams in which some 6034 of these structures are indeed related, but decoders cannot rely 6035 on this.</p> 6036 6037 <h2><a name="13Filtering">13.9 Filtering</a></h2> 6038 6039 <p>To reverse the effect of a filter, the decoder may need 6040 to use the decoded values of the prior pixel on the same line, 6041 the pixel immediately above the current pixel on the prior line, 6042 and the pixel just to the left of the pixel above. This implies 6043 that at least one scanline's worth of image data needs to be 6044 stored by the decoder at all times. Even though some filter types 6045 do not refer to the prior scanline, the decoder will always need 6046 to store each scanline as it is decoded, since the next scanline 6047 might use a filter type that refers to it.</p> 6048 6049 <h2><a name="13Progressive-display">13.10 Interlacing and 6050 progressive display</a></h2> 6051 6052 <p>Decoders are required to be able to read interlaced images. If 6053 the reference image contains fewer than five columns or fewer 6054 than five rows, some passes will be empty. Encoders and decoders 6055 shall handle this case correctly. In particular, filter type 6056 bytes are associated only with nonempty scanlines; no filter type 6057 bytes are present in an empty reduced image.</p> 6058 6059 <p>When receiving images over slow transmission links, viewers 6060 can improve perceived performance by displaying interlaced images 6061 progressively. This means that as each reduced image is received, 6062 an approximation to the complete image is displayed based on the 6063 data received so far. One simple yet pleasing effect can be 6064 obtained by expanding each received pixel to fill a rectangle 6065 covering the yet-to-be-transmitted pixel positions below and to 6066 the right of the received pixel. This process can be described by 6067 the following ISO C code <a href="#2-ISO-9899"><span class= 6068 "NormRef">[ISO-9899]</span></a>:</p> 6069 6070 <pre> 6071 /* 6072 variables declared and initialized elsewhere in the code: 6073 height, width 6074 functions or macros defined elsewhere in the code: 6075 visit(), min() 6076 */ 6077 6078 int starting_row[7] = { 0, 0, 4, 0, 2, 0, 1 }; 6079 int starting_col[7] = { 0, 4, 0, 2, 0, 1, 0 }; 6080 int row_increment[7] = { 8, 8, 8, 4, 4, 2, 2 }; 6081 int col_increment[7] = { 8, 8, 4, 4, 2, 2, 1 }; 6082 int block_height[7] = { 8, 8, 4, 4, 2, 2, 1 }; 6083 int block_width[7] = { 8, 4, 4, 2, 2, 1, 1 }; 6084 6085 int pass; 6086 long row, col; 6087 6088 pass = 0; 6089 while (pass < 7) 6090 { 6091 row = starting_row[pass]; 6092 while (row < height) 6093 { 6094 col = starting_col[pass]; 6095 while (col < width) 6096 { 6097 visit(row, col, 6098 min(block_height[pass], height - row), 6099 min(block_width[pass], width - col)); 6100 col = col + col_increment[pass]; 6101 } 6102 row = row + row_increment[pass]; 6103 } 6104 pass = pass + 1; 6105 } 6106 </pre> 6107 6108 <p>The function <tt>visit(row,column,height,width)</tt> obtains 6109 the next transmitted pixel and paints a rectangle of the 6110 specified height and width, whose upper-left corner is at the 6111 specified row and column, using the colour indicated by the 6112 pixel. Note that row and column are measured from 0,0 at the 6113 upper left corner.</p> 6114 6115 <p>If the viewer is merging the received image with a background 6116 image, it may be more convenient just to paint the received pixel 6117 positions (the <tt>visit()</tt> function sets only the pixel at the 6118 specified row and column, not the whole rectangle). This produces 6119 a "fade-in" effect as the new image gradually replaces the old. 6120 An advantage of this approach is that proper alpha or 6121 transparency processing can be done as each pixel is replaced. 6122 Painting a rectangle as described above will overwrite 6123 background-image pixels that may be needed later, if the pixels 6124 eventually received for those positions turn out to be wholly or 6125 partially transparent. This is a problem only if the background 6126 image is not stored anywhere offscreen.</p> 6127 6128 <h2><a name="13Truecolour-image-handling">13.11 Truecolour image 6129 handling</a></h2> 6130 6131 <p>To achieve PNG's goal of universal interchangeability, 6132 decoders shall accept all types of PNG image: indexed-colour, 6133 truecolour, and greyscale. Viewers running on indexed-colour 6134 display hardware need to be able to reduce truecolour images to 6135 indexed-colour for viewing. This process is called "colour 6136 quantization".</p> 6137 6138 <p>A simple, fast method for colour quantization is to reduce the 6139 image to a fixed palette. Palettes with uniform colour spacing 6140 ("colour cubes") are usually used to minimize the per-pixel 6141 computation. For photograph-like images, dithering is recommended 6142 to avoid ugly contours in what should be smooth gradients; 6143 however, dithering introduces graininess that can be 6144 objectionable.</p> 6145 6146 <p>The quality of rendering can be improved substantially by 6147 using a palette chosen specifically for the image, since a colour 6148 cube usually has numerous entries that are unused in any 6149 particular image. This approach requires more work, first in 6150 choosing the palette, and second in mapping individual pixels to 6151 the closest available colour. PNG allows the encoder to supply 6152 suggested palettes, but not all encoders will do so, and the 6153 suggested palettes may be unsuitable in any case (they may have 6154 too many or too few colours). Therefore, high-quality viewers 6155 will need to have a palette selection routine at hand. A large 6156 lookup table is usually the most feasible way of mapping 6157 individual pixels to palette entries with adequate speed.</p> 6158 6159 <p>Numerous implementations of colour quantization are available. 6160 The PNG sample implementation, libpng (<a href= 6161 "http://www.libpng.org/pub/png/libpng.html"><code>http://www.libpng.org/pub/png/libpng.html</code></a>), 6162 includes code for the purpose.</p> 6163 6164 <h2><a name="13Sample-depth-rescaling">13.12 Sample depth 6165 rescaling</a></h2> 6166 6167 <p>Decoders may wish to scale PNG data to a lesser sample depth 6168 (data precision) for display. For example, 16-bit data will need 6169 to be reduced to 8-bit depth for use on most present-day display 6170 hardware. Reduction of 8-bit data to 5-bit depth is also 6171 common.</p> 6172 6173 <p>The most accurate scaling is achieved by the linear 6174 equation</p> 6175 6176 <p><tt>output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 6177 0.5)</tt></p> 6178 6179 <p>where</p> 6180 6181 <p><tt>MAXINSAMPLE = (2<sup>sampledepth</sup>)-1</tt><br class="xhtml" /> 6182 <tt>MAXOUTSAMPLE = (2<sup>desired_sampledepth</sup>)-1</tt></p> 6183 6184 <p>A slightly less accurate conversion is achieved by simply 6185 shifting right by <tt>(sampledepth - desired_sampledepth)</tt> 6186 places. For example, to reduce 16-bit samples to 8-bit, the 6187 low-order byte can be discarded. In many situations the shift 6188 method is sufficiently accurate for display purposes, and it is 6189 certainly much faster. (But if gamma correction is being done, 6190 sample rescaling can be merged into the gamma correction lookup 6191 table, as is illustrated in 13.13: <a href= 6192 "#13Decoder-gamma-handling"><span class="xref">Decoder gamma 6193 handling</span></a>.)</p> 6194 6195 <p>If the decoder needs to scale samples up (for example, if the 6196 frame buffer has a greater sample depth than the PNG image), it 6197 should use linear scaling or left-bit-replication as described in 6198 12.5: <a href="#12Sample-depth-scaling"><span class="xref">Sample 6199 depth scaling</span></a>.</p> 6200 6201 <p>When an <a href="#11sBIT"><span class="chunk">sBIT</span></a> 6202 chunk is present, the reference image data can be recovered by 6203 shifting right to the sample depth specified by <a href= 6204 "#11sBIT"><span class="chunk">sBIT</span></a>. Note that linear 6205 scaling will not necessarily reproduce the original data, because 6206 the encoder is not required to have used linear scaling to scale 6207 the data up. However, the encoder is required to have used a 6208 method that preserves the high-order bits, so shifting always 6209 works. This is the only case in which shifting might be said to 6210 be more accurate than linear scaling. A decoder need not pay 6211 attention to the <a href="#11sBIT"><span class= 6212 "chunk">sBIT</span></a> chunk; the stored image is a valid PNG 6213 datastream of the sample depth indicated by the <a href= 6214 "#11IHDR"><span class="chunk">IHDR</span></a> chunk; however, 6215 using <a href="#11sBIT"><span class="chunk">sBIT</span></a> to 6216 recover the original samples before scaling them to suit the 6217 display often yields a more accurate display than ignoring <a 6218 href="#11sBIT"><span class="chunk">sBIT</span></a>.</p> 6219 6220 <p>When comparing pixel values to <a href="#11tRNS"><span class= 6221 "chunk">tRNS</span></a> chunk values to detect transparent 6222 pixels, the comparison shall be done exactly. Therefore, 6223 transparent pixel detection shall be done before reducing sample 6224 precision.</p> 6225 6226 <h2><a name="13Decoder-gamma-handling">13.13 Decoder gamma 6227 handling</a></h2> 6228 6229 <p>See Annex C: <a href="#C-GammaAppendix"><span class= 6230 "xref">Gamma and chromaticity</span></a> for a brief introduction 6231 to gamma issues.</p> 6232 6233 <p>Viewers capable of full colour management <a href= 6234 "#G-ICC"><span class="bibref">[ICC]</span></a> will perform more 6235 sophisticated calculations than those described here.</p> 6236 6237 <p>For an image display program to produce correct tone 6238 reproduction, it is necessary to take into account the 6239 relationship between samples and display output, and the transfer 6240 function of the display system. This can be done by 6241 calculating:</p> 6242 6243 <p><tt>sample = integer_sample / (2<sup>sampledepth</sup> - 6244 1.0)<br class="xhtml" /> 6245 display_output = sample<sup>1.0/gamma</sup><br class="xhtml" /> 6246 display_input = inverse_display_transfer(display_output)<br class="xhtml" /> 6247 framebuf_sample = floor((display_input * 6248 MAX_FRAMEBUF_SAMPLE)+0.5)</tt></p> 6249 6250 <p>where <tt>integer_sample</tt> is the sample value from the 6251 datastream, <tt>framebuf_sample</tt> is the value to write into 6252 the frame buffer, and <tt>MAX_FRAMEBUF_SAMPLE</tt> is the maximum 6253 value of a frame buffer sample (255 for 8-bit, 31 for 5-bit, 6254 etc). The first line converts an integer sample into a normalized 6255 floating point value (in the range 0.0 to 1.0), the second 6256 converts to a value proportional to the desired display output 6257 intensity, the third accounts for the display system's transfer 6258 function, and the fourth converts to an integer frame buffer 6259 sample. Zero raised to any positive power is zero.</p> 6260 6261 <p>A step could be inserted between the second and third to 6262 adjust <tt>display_output</tt> to account for the difference 6263 between the actual viewing conditions and the reference viewing 6264 conditions. However, this adjustment requires accounting for 6265 veiling glare, black mapping, and colour appearance models, none 6266 of which can be well approximated by power functions. Such 6267 calculations are not described here. If viewing conditions are 6268 ignored, the error will usually be small.</p> 6269 6270 <p>The display transfer function can typically be approximated by 6271 a power function with exponent <tt>display_exponent</tt>, in 6272 which case the second and third lines can be merged into:</p> 6273 6274 <p><tt>display_input = sample<sup>1.0/(gamma * 6275 display_exponent)</sup> = 6276 sample<sup>decoding_exponent</sup></tt></p> 6277 6278 <p>so as to perform only one power calculation. For colour 6279 images, the entire calculation is performed separately for R, G, 6280 and B values.</p> 6281 6282 <p>The value of gamma can be taken directly from the <a href= 6283 "#11gAMA"><span class="chunk">gAMA</span></a> chunk. 6284 Alternatively, an application may wish to allow the user to 6285 adjust the appearance of the displayed image by influencing the 6286 value of gamma. For example, the user could manually set a 6287 parameter <tt>user_exponent</tt> which defaults to 1.0, and the 6288 application could set:</p> 6289 6290 <pre> 6291 <tt>gamma = gamma_from_file / user_exponent 6292 decoding_exponent = 1.0 / (gamma * display_exponent) 6293 = user_exponent / (gamma_from_file * display_exponent)</tt> 6294 </pre> 6295 6296 <p>The user would set <tt>user_exponent</tt> greater than 1 to 6297 darken the mid-level tones, or less than 1 to lighten them.</p> 6298 6299 <p>A <a href= 6300 "#11gAMA"><span class="chunk">gAMA</span></a> chunk containing zero is 6301 meaningless but could appear by mistake. 6302 Decoders should ignore it, 6303 and editors may discard it and issue a warning to the user.</p> 6304 6305 <p>It is <strong>not</strong> necessary to perform a transcendental 6306 mathematical computation for every pixel. Instead, a lookup table 6307 can be computed that gives the correct output value for every 6308 possible sample value. This requires only 256 calculations per 6309 image (for 8-bit accuracy), not one or three calculations per 6310 pixel. For an indexed-colour image, a one-time correction of the 6311 palette is sufficient, unless the image uses transparency and is 6312 being displayed against a nonuniform background.</p> 6313 6314 <p>If floating-point calculations are not possible, gamma 6315 correction tables can be computed using integer arithmetic and a 6316 precomputed table of logarithms. Example code appears in <a href= 6317 "#G-PNG-EXTENSIONS"><span class= 6318 "bibref">[PNG-EXTENSIONS]</span></a>.</p> 6319 6320 <p>When the incoming image has unknown gamma (<a href= 6321 "#11gAMA"><span class="chunk">gAMA</span></a>, <a href= 6322 "#11sRGB"><span class="chunk">sRGB</span></a>, and <a href= 6323 "#11iCCP"><span class="chunk">iCCP</span></a> all absent), choose 6324 a likely default gamma value, but allow the user to select a new 6325 one if the result proves too dark or too light. The default gamma 6326 may depend on other knowledge about the image, for example 6327 whether it came from the Internet or from the local system.</p> 6328 6329 <p>In practice, it is often difficult to determine what value of 6330 display exponent should be used. In systems with no built-in 6331 gamma correction, the display exponent is determined entirely by 6332 the CRT. A display exponent of 2.2 should be used unless detailed 6333 calibration measurements are available for the particular CRT 6334 used.</p> 6335 6336 <p>Many modern frame buffers have lookup tables that are used to 6337 perform gamma correction, and on these systems the display 6338 exponent value should be the exponent of the lookup table and CRT 6339 combined. It may not be possible to find out what the lookup 6340 table contains from within the viewer application, in which case 6341 it may be necessary to ask the user to supply the display 6342 system's exponent value. Unfortunately, different manufacturers 6343 use different ways of specifying what should go into the lookup 6344 table, so interpretation of the system "gamma" value is 6345 system-dependent.</p> 6346 6347 <p>The response of real displays is actually more complex than 6348 can be described by a single number (the display exponent). If 6349 actual measurements of the monitor's light output as a function 6350 of voltage input are available, the third and fourth lines of the 6351 computation above can be replaced by a lookup in these 6352 measurements, to find the actual frame buffer value that most 6353 nearly gives the desired brightness.</p> 6354 6355 <h2><a name="13Decoder-colour-handling">13.14 Decoder colour 6356 handling</a></h2> 6357 6358 <p>See Annex C: <a href="#C-GammaAppendix"><span class= 6359 "xref">Gamma and chromaticity</span></a> for references to colour 6360 issues.</p> 6361 6362 <p>In many cases, the image data in PNG datastreams will be 6363 treated as device-dependent RGB values and displayed without 6364 modification (except for appropriate gamma correction). This 6365 provides the fastest display of PNG images. But unless the viewer 6366 uses exactly the same display hardware as that used by the author 6367 of the original image, the colours will not be exactly the same 6368 as those seen by the original author, particularly for darker or 6369 near-neutral colours. The <a href="#11cHRM"><span class= 6370 "chunk">cHRM</span></a> chunk provides information that allows 6371 closer colour matching than that provided by gamma correction 6372 alone.</p> 6373 6374 <p>The <a href="#11cHRM"><span class="chunk">cHRM</span></a> data 6375 can be used to transform the image data from RGB to XYZ and 6376 thence into a perceptually linear colour space such as CIE LAB. 6377 The colours can be partitioned to generate an optimal palette, 6378 because the geometric distance between two colours in CIE LAB is 6379 strongly related to how different those colours appear (unlike, 6380 for example, RGB or XYZ spaces). The resulting palette of 6381 colours, once transformed back into RGB colour space, could be 6382 used for display or written into a <a href="#11PLTE"><span class= 6383 "chunk">PLTE</span></a> chunk.</p> 6384 6385 <p>Decoders that are part of image processing applications might 6386 also transform image data into CIE LAB space for analysis.</p> 6387 6388 <p>In applications where colour fidelity is critical, such as 6389 product design, scientific visualization, medicine, architecture, 6390 or advertising, PNG decoders can transform the image data from 6391 source RGB to the display RGB space of the monitor used to view 6392 the image. This involves calculating the matrix to go from source 6393 RGB to XYZ and the matrix to go from XYZ to display RGB, then 6394 combining them to produce the overall transformation. The PNG 6395 decoder is responsible for implementing gamut mapping.</p> 6396 6397 <p>Decoders running on platforms that have a Colour Management 6398 System (CMS) can pass the image data, <a href="#11gAMA"><span 6399 class="chunk">gAMA</span></a>, and <a href="#11cHRM"><span class= 6400 "chunk">cHRM</span></a> values to the CMS for display or further 6401 processing.</p> 6402 6403 <p>PNG decoders that provide colour printing facilities can use 6404 the facilities in Level 2 PostScript to specify image data in 6405 calibrated RGB space or in a device-independent colour space such 6406 as XYZ. This will provide better colour fidelity than a simple 6407 RGB to CMYK conversion. The PostScript Language Reference manual 6408 <a href="#G-POSTSCRIPT"><span class= 6409 "bibref">[POSTSCRIPT]</span></a> gives examples. Such decoders 6410 are responsible for implementing gamut mapping between source RGB 6411 (specified in the <a href="#11cHRM"><span class= 6412 "chunk">cHRM</span></a> chunk) and the target printer. The 6413 PostScript interpreter is then responsible for producing the 6414 required colours.</p> 6415 6416 <p>PNG decoders can use the <a href="#11cHRM"><span class= 6417 "chunk">cHRM</span></a> data to calculate an accurate greyscale 6418 representation of a colour image. Conversion from RGB to grey is 6419 simply a case of calculating the Y (luminance) component of XYZ, 6420 which is a weighted sum of R, G, and B values. The weights depend 6421 upon the monitor type, i.e. the values in the <a href= 6422 "#11cHRM"><span class="chunk">cHRM</span></a> chunk. PNG decoders 6423 may wish to do this for PNG datastreams with no <a href= 6424 "#11cHRM"><span class="chunk">cHRM</span></a> chunk. In this 6425 case, a reasonable default would be the CCIR 709 primaries <a 6426 href="#G-ITU-R-BT709"><span class= 6427 "bibref">[ITU-R-BT709]</span></a>. The original NTSC primaries 6428 should <strong>not</strong> be used unless the PNG image really 6429 was colour-balanced for such a monitor.</p> 6430 6431 <h2><a name="13Background-colour">13.15 Background 6432 colour</a></h2> 6433 6434 <p>The background colour given by the <a href="#11bKGD"><span 6435 class="chunk">bKGD</span></a> chunk will typically be used to 6436 fill unused screen space around the image, as well as any 6437 transparent pixels within the image. (Thus, <a href= 6438 "#11bKGD"><span class="chunk">bKGD</span></a> is valid and useful 6439 even when the image does not use transparency.) If no <a href= 6440 "#11bKGD"><span class="chunk">bKGD</span></a> chunk is present, 6441 the viewer will need to decide upon a suitable background colour. 6442 When no other information is available, a medium grey such as 153 6443 in the 8-bit sRGB colour space would be a reasonable choice. 6444 Transparent black or white text and dark drop shadows, which are 6445 common, would all be legible against this background.</p> 6446 6447 <p>Viewers that have a specific background against which to 6448 present the image (such as web browsers) should ignore the <a 6449 href="#11bKGD"><span class="chunk">bKGD</span></a> chunk, in 6450 effect overriding <a href="#11bKGD"><span class= 6451 "chunk">bKGD</span></a> with their preferred background colour or 6452 background image.</p> 6453 6454 <p>The background colour given by the <a href="#11bKGD"><span 6455 class="chunk">bKGD</span></a> chunk is not to be considered 6456 transparent, even if it happens to match the colour given by the 6457 <a href="#11tRNS"><span class="chunk">tRNS</span></a> chunk (or, 6458 in the case of an indexed-colour image, refers to a palette index 6459 that is marked as transparent by the <a href="#11tRNS"><span 6460 class="chunk">tRNS</span></a> chunk). Otherwise one would have to 6461 imagine something "behind the background" to composite against. 6462 The background colour is either used as background or ignored; it 6463 is not an intermediate layer between the PNG image and some other 6464 background.</p> 6465 6466 <p>Indeed, it will be common that the <a href="#11bKGD"><span 6467 class="chunk">bKGD</span></a> and <a href="#11tRNS"><span class= 6468 "chunk">tRNS</span></a> chunks specify the same colour, since 6469 then a decoder that does not implement transparency processing 6470 will give the intended display, at least when no 6471 partially-transparent pixels are present.</p> 6472 6473 <h2><a name="13Alpha-channel-processing">13.16 Alpha channel 6474 processing</a></h2> 6475 6476 <p>The alpha channel can be used to composite a foreground image 6477 against a background image. The PNG datastream defines the 6478 foreground image and the transparency mask, but not the 6479 background image. PNG decoders are <strong>not</strong> required to 6480 support this most general case. It is expected that most will be 6481 able to support compositing against a single background 6482 colour.</p> 6483 6484 <p>The equation for computing a composited sample value is:</p> 6485 6486 <pre> 6487 output = alpha * foreground + (1-alpha) * background 6488 </pre> 6489 6490 <p>where alpha and the input and output sample values are 6491 expressed as fractions in the range 0 to 1. This computation 6492 should be performed with intensity samples (not gamma-encoded 6493 samples). For colour images, the computation is done separately 6494 for R, G, and B samples.</p> 6495 6496 <p>The following code illustrates the general case of compositing 6497 a foreground image against a background image. It assumes that 6498 the original pixel data are available for the background image, 6499 and that output is to a frame buffer for display. Other variants 6500 are possible; see the comments below the code. The code allows 6501 the sample depths and gamma values of foreground image and 6502 background image all to be different and not necessarily suited 6503 to the display system. In practice no assumptions about equality 6504 should be made without first checking.</p> 6505 6506 <!-- ************Page Break******************* --> 6507 <!-- ************Page Break******************* --> 6508 <p>This code is ISO C <a href="#2-ISO-9899"><span class= 6509 "NormRef">[ISO-9899]</span></a>, with line numbers added for 6510 reference in the comments below.</p> 6511 6512 <pre> 6513 01 int foreground[4]; /* image pixel: R, G, B, A */ 6514 02 int background[3]; /* background pixel: R, G, B */ 6515 03 int fbpix[3]; /* frame buffer pixel */ 6516 04 int fg_maxsample; /* foreground max sample */ 6517 05 int bg_maxsample; /* background max sample */ 6518 06 int fb_maxsample; /* frame buffer max sample */ 6519 07 int ialpha; 6520 08 float alpha, compalpha; 6521 09 float gamfg, linfg, gambg, linbg, comppix, gcvideo; 6522 6523 /* Get max sample values in data and frame buffer */ 6524 10 fg_maxsample = (1 << fg_sample_depth) - 1; 6525 11 bg_maxsample = (1 << bg_sample_depth) - 1; 6526 12 fb_maxsample = (1 << frame_buffer_sample_depth) - 1; 6527 /* 6528 * Get integer version of alpha. 6529 * Check for opaque and transparent special cases; 6530 * no compositing needed if so. 6531 * 6532 * We show the whole gamma decode/correct process in 6533 * floating point, but it would more likely be done 6534 * with lookup tables. 6535 */ 6536 13 ialpha = foreground[3]; 6537 6538 14 if (ialpha == 0) { 6539 /* 6540 * Foreground image is transparent here. 6541 * If the background image is already in the frame 6542 * buffer, there is nothing to do. 6543 */ 6544 15 ; 6545 16 } else if (ialpha == fg_maxsample) { 6546 /* 6547 * Copy foreground pixel to frame buffer. 6548 */ 6549 17 for (i = 0; i < 3; i++) { 6550 18 gamfg = (float) foreground[i] / fg_maxsample; 6551 19 linfg = pow(gamfg, 1.0 / fg_gamma); 6552 20 comppix = linfg; 6553 21 gcvideo = pow(comppix, 1.0 / display_exponent); 6554 22 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5); 6555 23 } 6556 24 } else { 6557 /* 6558 * Compositing is necessary. 6559 * Get floating-point alpha and its complement. 6560 * Note: alpha is always linear; gamma does not 6561 * affect it. 6562 */ 6563 25 alpha = (float) ialpha / fg_maxsample; 6564 26 compalpha = 1.0 - alpha; 6565 6566 27 for (i = 0; i < 3; i++) { 6567 /* 6568 * Convert foreground and background to floating 6569 * point, then undo gamma encoding. 6570 */ 6571 28 gamfg = (float) foreground[i] / fg_maxsample; 6572 29 linfg = pow(gamfg, 1.0 / fg_gamma); 6573 30 gambg = (float) background[i] / bg_maxsample; 6574 </pre> 6575 6576 <!-- ************Page Break******************* --> 6577 <!-- ************Page Break******************* --> 6578 <pre> 6579 31 linbg = pow(gambg, 1.0 / bg_gamma); 6580 /* 6581 * Composite. 6582 */ 6583 32 comppix = linfg * alpha + linbg * compalpha; 6584 /* 6585 * Gamma correct for display. 6586 * Convert to integer frame buffer pixel. 6587 */ 6588 33 gcvideo = pow(comppix, 1.0 / display_exponent); 6589 34 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5); 6590 35 } 6591 36 } 6592 </pre> 6593 6594 <p>Variations:</p> 6595 6596 <!-- <ol start="1"> --><ol> 6597 <li>If output is to another PNG datastream instead of a frame 6598 buffer, lines 21, 22, 33, and 34 should be changed along the 6599 following lines 6600 6601 <pre> 6602 /* 6603 * Gamma encode for storage in output datastream. 6604 * Convert to integer sample value. 6605 */ 6606 gamout = pow(comppix, outfile_gamma); 6607 outpix[i] = (int) (gamout * out_maxsample + 0.5); 6608 </pre> 6609 6610 Also, it becomes necessary to process background pixels when 6611 alpha is zero, rather than just skipping pixels. Thus, line 15 6612 will need to be replaced by copies of lines 17-23, but processing 6613 background instead of foreground pixel values.</li> 6614 6615 <li>If the sample depths of the output file, foreground file, and 6616 background file are all the same, and the three gamma values also 6617 match, then the no-compositing code in lines 14-23 reduces to 6618 copying pixel values from the input file to the output file if 6619 alpha is one, or copying pixel values from background to output 6620 file if alpha is zero. Since alpha is typically either zero or 6621 one for the vast majority of pixels in an image, this is a 6622 significant saving. No gamma computations are needed for most 6623 pixels.</li> 6624 6625 <li>When the sample depths and gamma values all match, it may 6626 appear attractive to skip the gamma decoding and encoding (lines 6627 28-31, 33-34) and just perform line 32 using gamma-encoded sample 6628 values. Although this does not have too bad an effect on image 6629 quality, the time savings are small if alpha values of zero and 6630 one are treated as special cases as recommended here.</li> 6631 6632 <li>If the original pixel values of the background image are no 6633 longer available, only processed frame buffer pixels left by 6634 display of the background image, then lines 30 and 31 need to 6635 extract intensity from the frame buffer pixel values using code 6636 such as 6637 6638 <pre> 6639 /* 6640 * Convert frame buffer value into intensity sample. 6641 */ 6642 gcvideo = (float) fbpix[i] / fb_maxsample; 6643 linbg = pow(gcvideo, display_exponent); 6644 </pre> 6645 6646 However, some roundoff error can result, so it is better to have 6647 the original background pixels available if at all possible.</li> 6648 6649 <li>Note that lines 18-22 are performing exactly the same gamma 6650 computation that is done when no alpha channel is present. If the 6651 no-alpha case is handled with a lookup table, the same lookup 6652 table can be used here. Lines 28-31 and 33-34 can also be done 6653 with (different) lookup tables.</li> 6654 6655 <li>Integer arithmetic can be used instead of floating point, 6656 providing care is taken to maintain sufficient precision 6657 throughout.</li> 6658 </ol> 6659 6660 <p class="Note">NOTE In floating point, no overflow or underflow 6661 checks are needed, because the input sample values are guaranteed 6662 to be between 0 and 1, and compositing always yields a result 6663 that is in between the input values (inclusive). With integer 6664 arithmetic, some roundoff-error analysis might be needed to 6665 guarantee no overflow or underflow.</p> 6666 6667 <!-- ************Page Break******************* --> 6668 <!-- ************Page Break******************* --> 6669 <p>When displaying a PNG image with full alpha channel, it is 6670 important to be able to composite the image against some 6671 background, even if it is only black. Ignoring the alpha channel 6672 will cause PNG images that have been converted from an 6673 associated-alpha representation to look wrong. (Of course, if the 6674 alpha channel is a separate transparency mask, then ignoring 6675 alpha is a useful option: it allows the hidden parts of the image 6676 to be recovered.)</p> 6677 6678 <p>Even if the decoder does not implement true compositing logic, 6679 it is simple to deal with images that contain only zero and one 6680 alpha values. (This is implicitly true for greyscale and 6681 truecolour PNG datastreams that use a <a href="#11tRNS"><span 6682 class="chunk">tRNS</span></a> chunk; for indexed-colour PNG 6683 datastreams it is easy to check whether the <a href= 6684 "#11tRNS"><span class="chunk">tRNS</span></a> chunk contains any 6685 values other than 0 and 255.) In this simple case, transparent 6686 pixels are replaced by the background colour, while others are 6687 unchanged.</p> 6688 6689 <p>If a decoder contains only this much transparency capability, 6690 it should deal with a full alpha channel by treating all nonzero 6691 alpha values as fully opaque or by dithering. Neither approach 6692 will yield very good results for images converted from 6693 associated-alpha formats, but this is preferable to doing 6694 nothing. Dithering full alpha to binary alpha is very much like 6695 dithering greyscale to black-and-white, except that all fully 6696 transparent and fully opaque pixels should be left unchanged by 6697 the dither.</p> 6698 6699 <h2><a name="13Histogram-and-suggested-palette-usage">13.17 6700 Histogram and suggested palette usage</a></h2> 6701 6702 <p>For viewers running on indexed-colour hardware attempting to 6703 display a truecolour image, or an indexed-colour image whose 6704 palette is too large for the frame buffer, the encoder may have 6705 provided one or more suggested palettes in <a href= 6706 "#11sPLT"><span class="chunk">sPLT</span></a> chunks. If one of 6707 these is found to be suitable, based on size and perhaps name, 6708 the PNG decoder can use that palette. Suggested palettes with a 6709 sample depth different from what the decoder needs can be 6710 converted using sample depth rescaling (see 13.12: <a href= 6711 "#13Sample-depth-rescaling"><span class="xref">Sample depth 6712 rescaling</span></a>).</p> 6713 6714 <p>When the background is a solid colour, the viewer should 6715 composite the image and the suggested palette against that 6716 colour, then quantize the resulting image to the resulting RGB 6717 palette. When the image uses transparency and the background is 6718 not a solid colour, no suggested palette is likely to be 6719 useful.</p> 6720 6721 <p>For truecolour images, a suggested palette might also be 6722 provided in a <a href="#11PLTE"><span class= 6723 "chunk">PLTE</span></a> chunk. If the image has a <a href= 6724 "#11tRNS"><span class="chunk">tRNS</span></a> chunk and the 6725 background is a solid colour, the viewer will need to adapt the 6726 suggested palette for use with its desired background colour. To 6727 do this, the palette entry closest to the <a href="#11tRNS"><span 6728 class="chunk">tRNS</span></a> colour should be replaced with the 6729 desired background colour; or alternatively a palette entry for 6730 the background colour can be added, if the viewer can handle more 6731 colours than there are <a href="#11PLTE"><span class= 6732 "chunk">PLTE</span></a> entries.</p> 6733 6734 <p>For images of colour type 6 (truecolour with alpha), any <a 6735 href="#11PLTE"><span class="chunk">PLTE</span></a> chunk should 6736 have been designed for display of the image against a uniform 6737 background of the colour specified by the <a href="#11bKGD"><span 6738 class="chunk">bKGD</span></a> chunk. Viewers should probably 6739 ignore the palette if they intend to use a different background, 6740 or if the <a href="#11bKGD"><span class="chunk">bKGD</span></a> 6741 chunk is missing. Viewers can use a suggested palette for display 6742 against a different background than it was intended for, but the 6743 results may not be very good.</p> 6744 6745 <p>If the viewer presents a transparent truecolour image against 6746 a background that is more complex than a uniform colour, it is 6747 unlikely that the suggested palette will be optimal for the 6748 composite image. In this case it is best to perform a truecolour 6749 compositing step on the truecolour PNG image and background 6750 image, then colour-quantize the resulting image.</p> 6751 6752 <p>In truecolour PNG datastreams, if both <a href="#11PLTE"><span 6753 class="chunk">PLTE</span></a> and <a href="#11sPLT"><span class= 6754 "chunk">sPLT</span></a> chunks appear, the PNG decoder may choose 6755 from among the palettes suggested by both, bearing in mind the 6756 different transparency semantics described above.</p> 6757 6758 <p>The frequencies in the <a href="#11sPLT"><span class= 6759 "chunk">sPLT</span></a> and <a href="#11hIST"><span class= 6760 "chunk">hIST</span></a> chunks are useful when the viewer cannot 6761 provide as many colours as are used in the palette in the PNG 6762 datastream. If the viewer has a shortfall of only a few colours, 6763 it is usually adequate to drop the least-used colours from the 6764 palette. To reduce the number of colours substantially, it is 6765 best to choose entirely new representative colours, rather than 6766 trying to use a subset of the existing palette. This amounts to 6767 performing a new colour quantization step; however, the existing 6768 palette and histogram can be used as the input data, thus 6769 avoiding a scan of the image data in the <a href="#11IDAT"><span 6770 class="chunk">IDAT</span></a> chunks.</p> 6771 6772 <p>If no suggested palette is provided, a decoder can develop its 6773 own, at the cost of an extra pass over the image data in the <a 6774 href="#11IDAT"><span class="chunk">IDAT</span></a> chunks. 6775 Alternatively, a default palette (probably a colour cube) can be 6776 used.</p> 6777 6778 <p>See also 12.6: <a href="#12Suggested-palettes"><span class= 6779 "xref">Suggested palettes</span></a>.</p> 6780 6781 <!-- ************Page Break******************* --> 6782 <!-- ************Page Break******************* --> 6783 <h1><a name="14EditorsExt">14 Editors and extensions</a></h1> 6784 6785 <h2><a name="14Additional-chunk-types">14.1 Additional chunk 6786 types</a></h2> 6787 6788 <p>The provisions of this International Standard may be extended 6789 by adding new chunk types, which may be either private or public. 6790 Applications can use private chunk types to carry data that is 6791 not of interest to other people's applications.</p> 6792 6793 <p>Decoders shall be prepared to encounter unrecognized public or 6794 private chunk types. The chunk naming conventions (see 5.4: 6795 <a href="#5Chunk-naming-conventions"><span class="xref">Chunk 6796 naming conventions</span></a>) enable critical/ancillary, 6797 public/private, and safe/unsafe to copy chunks to be 6798 distinguished.</p> 6799 6800 <p>Additional public PNG chunk types are defined in the document 6801 Register of PNG Public Chunks and Keywords <a href= 6802 "#G-PNG-EXTENSIONS"><span class= 6803 "bibref">[PNG-REGISTER]</span></a>. Chunks described there are 6804 expected to be less widely supported than those defined in this 6805 International Standard. However, application authors are 6806 encouraged to use those chunk types whenever appropriate for 6807 their applications. Additional chunk types can be proposed for 6808 inclusion in that list by contacting the PNG Registration 6809 Authority (see 4.9: <a href="#4Concepts.Registration"><span 6810 class="xref">Extension and registration</span></a>).</p> 6811 6812 <p>New public chunks will be registered only if they are of use 6813 to others and do not violate the design philosophy of PNG. Chunk 6814 registration is not automatic, although it is the intent of the 6815 Registration Authority that it be straightforward when a new 6816 chunk of potentially wide application is needed. The creation of 6817 new critical chunk types is discouraged unless absolutely 6818 necessary.</p> 6819 6820 <h2><a name="14Ordering">14.2 Behaviour of PNG editors</a></h2> 6821 6822 <p>A "PNG editor" is defined as a program that reads a PNG 6823 datastream, makes modifications, and writes a new PNG datastream 6824 while preserving as much ancillary information as possible. Two 6825 examples of PNG editors are a program that adds or modifies text 6826 chunks, and a program that adds a suggested palette to a 6827 truecolour PNG datastream. Ordinary image editors are not PNG 6828 editors because they usually discard all unrecognized information 6829 while reading in an image.</p> 6830 6831 <p>To allow new chunk types to be added to PNG, it is necessary 6832 to establish rules about the ordering requirements for all chunk 6833 types. Otherwise a PNG editor does not know what to do when it 6834 encounters an unknown chunk.</p> 6835 6836 <p>EXAMPLE Consider a hypothetical new ancillary chunk type that 6837 is safe-to-copy and is required to appear after <a href= 6838 "#11PLTE"><span class="chunk">PLTE</span></a> if <a href= 6839 "#11PLTE"><span class="chunk">PLTE</span></a> is present. If a 6840 program attempts to add a <a href="#11PLTE"><span class= 6841 "chunk">PLTE</span></a> chunk and does not recognize the new 6842 chunk, it may insert the <a href="#11PLTE"><span class= 6843 "chunk">PLTE</span></a> chunk in the wrong place, namely after 6844 the new chunk. Such problems could be prevented by requiring PNG 6845 editors to discard all unknown chunks, but that is a very 6846 unattractive solution. Instead, PNG requires ancillary chunks not 6847 to have ordering restrictions like this.</p> 6848 6849 <p>To prevent this type of problem while allowing for future 6850 extension, constraints are placed on both the behaviour of PNG 6851 editors and the allowed ordering requirements for chunks. The 6852 safe-to-copy bit defines the proper handling of unrecognized 6853 chunks in a datastream that is being modified.</p> 6854 6855 <!-- <ol start="1"> --><ol> 6856 <li>If a chunk's safe-to-copy bit is 1, the chunk may be copied 6857 to a modified PNG datastream whether or not the PNG editor 6858 recognizes the chunk type, and regardless of the extent of the 6859 datastream modifications.</li> 6860 6861 <li>If a chunk's safe-to-copy bit is 0, it indicates that the 6862 chunk depends on the image data. If the program has made 6863 <strong>any</strong> changes to <strong>critical</strong> chunks, including 6864 addition, modification, deletion, or reordering of critical 6865 chunks, then unrecognized unsafe chunks shall 6866 <strong>not</strong> be copied to the output PNG datastream. (Of 6867 course, if the program <strong>does</strong> recognize the chunk, 6868 it can choose to output an appropriately modified version.)</li> 6869 6870 <li>A PNG editor is always allowed to copy all unrecognized 6871 ancillary chunks if it has only added, deleted, modified, or 6872 reordered <strong>ancillary</strong> chunks. This implies that it is not 6873 permissible for ancillary chunks to depend on other ancillary 6874 chunks.</li> 6875 6876 <li>PNG editors shall terminate on encountering an unrecognized 6877 critical chunk type, because there is no way to be certain that a 6878 valid datastream will result from modifying a datastream 6879 containing such a chunk. (Simply discarding the chunk is not good 6880 enough, because it might have unknown implications for the 6881 interpretation of other chunks.) The safe/unsafe mechanism is 6882 intended for use with ancillary chunks. The safe-to-copy bit will 6883 always be 0 for critical chunks.</li> 6884 </ol> 6885 6886 <p>The rules governing ordering of chunks are as follows.</p> 6887 6888 <!-- <ol start="5"> --><ol> 6889 <li>When copying an unknown <strong>unsafe-to-copy</strong> ancillary 6890 chunk, a PNG editor shall not move the chunk relative to any 6891 critical chunk. It may relocate the chunk freely relative to 6892 other ancillary chunks that occur between the same pair of 6893 critical chunks. (This is well defined since the editor shall not 6894 add, delete, modify, or reorder critical chunks if it is 6895 preserving unknown unsafe-to-copy chunks.)</li> 6896 6897 <li>When copying an unknown <strong>safe-to-copy</strong> ancillary 6898 chunk, a PNG editor shall not move the chunk from before <a href= 6899 "#11IDAT"><span class="chunk">IDAT</span></a> to after <a href= 6900 "#11IDAT"><span class="chunk">IDAT</span></a> or vice versa. 6901 (This is well defined because <a href="#11IDAT"><span class= 6902 "chunk">IDAT</span></a> is always present.) Any other reordering 6903 is permitted.</li> 6904 6905 <li>When copying a <strong>known</strong> ancillary chunk type, an editor 6906 need only honour the specific chunk ordering rules that exist for 6907 that chunk type. However, it may always choose to apply the above 6908 general rules instead.</li> 6909 </ol> 6910 6911 <p>These rules are expressed in terms of copying chunks from an 6912 input datastream to an output datastream, but they apply in the 6913 obvious way if a PNG datastream is modified in place.</p> 6914 6915 <p>See also 5.4: <a href="#5Chunk-naming-conventions"><span 6916 class="xref">Chunk naming conventions</span></a>.</p> 6917 6918 <p>PNG editors that do not change the image data should not 6919 change the <a href="#11tIME"><span class="chunk">tIME</span></a> 6920 chunk. The Creation Time keyword in the <a href="#11tEXt"><span 6921 class="chunk">tEXt</span></a>, <a href="#11zTXt"><span class= 6922 "chunk">zTXt</span></a>, and <a href="#11iTXt"><span class= 6923 "chunk">iTXt</span></a> chunks may be used for a user-supplied 6924 time.</p> 6925 6926 <h2><a name="14Ordering-of-chunks">14.3 Ordering of 6927 chunks</a></h2> 6928 6929 <h3><a name="14Ordering-of-critical-chunks">14.3.1 Ordering of 6930 critical chunks</a></h3> 6931 6932 <p>Critical chunks may have arbitrary ordering requirements, 6933 because PNG editors are required to terminate if they encounter 6934 unknown critical chunks. For example <a href="#11IHDR"><span 6935 class="chunk">IHDR</span></a> has the specific ordering rule that 6936 it shall always appear first. A PNG editor, or indeed any 6937 PNG-writing program, shall know and follow the ordering rules for 6938 any critical chunk type that it can generate.</p> 6939 6940 <h3><a name="14Ordering-of-ancillary-chunks">14.3.2 Ordering of 6941 ancillary chunks</a></h3> 6942 6943 <p>The strictest ordering rules for an ancillary chunk type 6944 are:</p> 6945 6946 <!-- <ol start="1"> --><ol> 6947 <li>Unsafe-to-copy chunks may have ordering requirements relative 6948 to critical chunks.</li> 6949 6950 <li>Safe-to-copy chunks may have ordering requirements relative 6951 to <a href="#11IDAT"><span class="chunk">IDAT</span></a>.</li> 6952 </ol> 6953 6954 <p>The actual ordering rules for any particular ancillary chunk 6955 type may be weaker. See for example the ordering rules for the 6956 standard ancillary chunk types in 5.6: <a href= 6957 "#5ChunkOrdering"><span class="xref">Chunk 6958 ordering</span></a>.</p> 6959 6960 <p>Decoders shall not assume more about the positioning of any 6961 ancillary chunk than is specified by the chunk ordering rules. In 6962 particular, it is never valid to assume that a specific ancillary 6963 chunk type occurs with any particular positioning relative to 6964 other ancillary chunks.</p> 6965 6966 <p>EXAMPLE It is unsafe to assume that a particular private 6967 ancillary chunk occurs immediately before <a href="#11IEND"><span 6968 class="chunk">IEND</span></a>. Even if it is always written in 6969 that position by a particular application, a PNG editor might 6970 have inserted some other ancillary chunk after it. But it is safe 6971 to assume that the chunk will remain somewhere between <a href= 6972 "#11IDAT"><span class="chunk">IDAT</span></a> and <a href= 6973 "#11IEND"><span class="chunk">IEND</span></a>.</p> 6974 6975 <!-- ************Page Break******************* --> 6976 <!-- ************Page Break******************* --> 6977 <h1><a name="15Conformance">15 Conformance</a></h1> 6978 6979 <h2><a name="15ConfIntro">15.1 Introduction</a></h2> 6980 6981 <h3><a name="15ConfObjectives">15.1.1 Objectives</a></h3> 6982 6983 <p>This clause addresses conformance of PNG datastreams, PNG 6984 encoders, PNG decoders, and PNG editors.</p> 6985 6986 <p>The primary objectives of the specifications in this clause 6987 are:</p> 6988 6989 <!-- <ol start="1"> --><ol> 6990 <li>to promote interoperability by eliminating arbitrary subsets 6991 of, or extensions to, this International Standard;</li> 6992 6993 <li>to promote uniformity in the development of conformance 6994 tests;</li> 6995 6996 <li>to promote consistent results across PNG encoders, decoders, 6997 and editors;</li> 6998 6999 <li>to facilitate automated test generation.</li> 7000 </ol> 7001 7002 <h3><a name="15ConfScope">15.1.2 Scope</a></h3> 7003 7004 <p>Conformance is defined for PNG datastreams and for PNG 7005 encoders, decoders, and editors.</p> 7006 7007 <p>This clause addresses the PNG datastream and implementation 7008 requirements including the range of allowable differences for PNG 7009 encoders, PNG decoders, and PNG editors. This clause does not 7010 directly address the environmental, performance, or resource 7011 requirements of the encoder, decoder, or editor.</p> 7012 7013 <p>The scope of this clause is limited to rules for the open 7014 interchange of PNG datastreams.</p> 7015 7016 <h2><a name="15ConformanceConf">15.2 Conformance conditions</a></h2> 7017 7018 <h3><a name="15FileConformance">15.2.1 Conformance of PNG 7019 datastreams</a></h3> 7020 <p>A PNG datastream conforms to this International Standard if 7021 the following conditions are met.</p> 7022 <ol> 7023 <li>The PNG datastream contains a PNG signature as the first 7024 content (see 5.2: <a href="#5PNG-file-signature"><span class= 7025 "xref">PNG file signature</span></a>).</li> 7026 7027 <li>With respect to the chunk types defined in this International 7028 Standard: 7029 7030 <ul> 7031 <li>the PNG datastream contains as its first chunk, an <a href= 7032 "#11IHDR"><span class="chunk">IHDR</span></a> chunk, immediately 7033 following the PNG signature;</li> 7034 7035 <li>the PNG datastream contains as its last chunk, an <a href= 7036 "#11IEND"><span class="chunk">IEND</span></a> chunk.</li> 7037 </ul> 7038 </li> 7039 7040 <li>No chunks or other content follow the <a href="#11IEND"><span 7041 class="chunk">IEND</span></a> chunk.</li> 7042 7043 <li>All chunks contained therein match the specification of the 7044 corresponding chunk types of this International Standard. 7045 The PNG datastream shall obey the relationships among chunk types 7046 defined in this International Standard.</li> 7047 7048 <li>The sequence of chunks in the PNG datastream obeys the 7049 ordering relationship specified in this International 7050 Standard.</li> 7051 7052 <li>All field values in the PNG datastream obey the relationships 7053 specified in this International Standard producing the structure 7054 specified in this International Standard.</li> 7055 7056 <li>No chunks appear in the PNG datastream other than those 7057 specified in this International Standard or those defined 7058 according to the rules for creating new chunk types as defined in 7059 this International Standard.</li> 7060 7061 <li>The PNG datastream is encoded according to the rules of this 7062 International Standard.</li> 7063 </ol> 7064 7065 <!-- ************Page Break******************* --> 7066 <!-- ************Page Break******************* --> 7067 <h3><a name="15ConformanceEncoder">15.2.2 Conformance of PNG 7068 encoders</a></h3> 7069 7070 <p>A PNG encoder conforms to this International Standard if it 7071 satisfies the following conditions.</p> 7072 7073 <!-- <ol start="1"> --><ol> 7074 <li>All PNG datastreams that are generated by the PNG encoder are 7075 conforming PNG datastreams.</li> 7076 7077 <li>When encoding input samples that have a sample depth that 7078 cannot be directly represented in PNG, the encoder scales the 7079 samples up to the next higher sample depth that is allowed by 7080 PNG. The data are scaled in such a way that the high-order bits 7081 match the original data.</li> 7082 7083 <li>Numbers greater than 127 are used when encoding experimental 7084 or private definitions of values for any of the method or type 7085 fields.</li> 7086 </ol> 7087 7088 <h3><a name="15ConformanceDecoder">15.2.3 Conformance of PNG 7089 decoders</a></h3> 7090 7091 <p>A PNG decoder conforms to this International Standard if it 7092 satisfies the following conditions.</p> 7093 7094 <!-- <ol start="1"> --><ol> 7095 <li>It is able to read any PNG datastream that conforms to this 7096 International Standard, including both public and private chunks 7097 whose types may not be recognized.</li> 7098 7099 <li>It supports all the standardized critical chunks, and all the 7100 standardized compression, filter, and interlace methods and types 7101 in any PNG datastream that conforms to this International 7102 Standard.</li> 7103 7104 <li>Unknown chunk types are handled as described in <a href= 7105 "#5Chunk-naming-conventions"><span class="xref">5.4 Chunk naming 7106 conventions</span></a>. An unknown chunk type is <strong>not</strong> 7107 treated as an error unless it is a critical chunk.</li> 7108 7109 <li>Unexpected values in fields of known chunks (for example, an 7110 unexpected compression method in the <a href="#11IHDR"><span 7111 class="chunk">IHDR</span></a> chunk) are treated as errors.</li> 7112 7113 <li>All types of PNG images (indexed-colour, truecolour, 7114 greyscale, truecolour with alpha, and greyscale with alpha) are 7115 processed. For example, decoders which are part of viewers 7116 running on indexed-colour display hardware shall reduce 7117 truecolour images to indexed format for viewing.</li> 7118 7119 <li>Encountering an unknown chunk in which the ancillary bit is 0 7120 generates an error if the decoder is attempting to extract the 7121 image.</li> 7122 7123 <li>A chunk type in which the reserved bit is set is treated as 7124 an unknown chunk type.</li> 7125 7126 <li>All valid combinations of bit depth and colour type as 7127 defined in 11.2.2: <a href="#11IHDR"><span class="xref"><span 7128 class="chunk">IHDR</span> Image header</span></a> are 7129 supported.</li> 7130 7131 <li>An error is reported if an unrecognized value is encountered 7132 in the bit depth, colour type, compression method, filter method, 7133 or interlace method bytes of the <a href="#11IHDR"><span class= 7134 "chunk">IHDR</span></a> chunk.</li> 7135 7136 <li>When processing 16-bit greyscale or truecolour data in the <a 7137 href="#11tRNS"><span class="chunk">tRNS</span></a> chunk, both 7138 bytes of the sample values are evaluated to determine whether a 7139 pixel is transparent.</li> 7140 7141 <li>When processing an image compressed by compression method 0, 7142 the decoder assumes no more than that the complete image data is 7143 represented by a single compressed datastream that is stored in 7144 some number of <a href="#11IDAT"><span class= 7145 "chunk">IDAT</span></a> chunks.</li> 7146 7147 <li>No assumptions are made concerning the positioning of any 7148 ancillary chunk other than those that are specified by the chunk 7149 ordering rules.</li> 7150 </ol> 7151 7152 <h3><a name="15ConformanceEditor">15.2.4 Conformance of PNG 7153 editors</a></h3> 7154 7155 <p>A PNG editor conforms to this International Standard if it satisfies the following conditions.</p> 7156 7157 <ol> 7158 <li>It conforms to the requirements for PNG encoders.</li> 7159 7160 <li>It conforms to the requirements for PNG decoders.</li> 7161 7162 <li>It is able to encode all chunks that it decodes.</li> 7163 7164 <li>It preserves the ordering of the chunks presented within the 7165 rules in 5.6: <a href="#5ChunkOrdering"><span class="xref">Chunk 7166 ordering</span></a>.</li> 7167 7168 <li>It properly processes the safe-to-copy bit information and 7169 preserves unknown chunks when the safe-to-copy rules permit 7170 it.</li> 7171 7172 <li>Unless the user specifically permits lossy operations or the 7173 editor issues a warning, it preserves all information required to 7174 reconstruct the reference image exactly, except that the sample 7175 depth of the alpha channel need not be preserved if it contains 7176 only zero and maximum values. Operations such as changing the 7177 colour type or rearranging the palette in an indexed-colour 7178 datastream are permitted provided that the new datastream 7179 losslessly represents the same reference image.</li> 7180 </ol> 7181 7182 <!-- ************Page Break******************* --> 7183 <!-- ************Page Break******************* --> 7184 <h1 class="Annex"><a name="A-Conventions">Annex A</a></h1> 7185 7186 <p class="Annex">(informative)</p> 7187 7188 <h1 id="filemedia" class="Annex">File conventions and Internet media type</h1> 7189 7190 <h2><a name="A-File-name-extension">A.1 File name 7191 extension</a></h2> 7192 7193 <p>On systems where file names customarily include an extension 7194 signifying file type, the extension "<tt>.png</tt>" is 7195 recommended for PNG files. Lower case "<tt>.png</tt>" is 7196 preferred if file names are case-sensitive.</p> 7197 7198 <h2><a name="A-Media-type">A.2 Internet media type</a></h2> 7199 7200 <p>The internet media type "<tt>image/png</tt>" is the Internet 7201 Media Type for PNG <a href="#2-RFC-2045"><span class= 7202 "NormRef">[RFC-2045]</span></a>, <a href="#2-RFC-2048"><span 7203 class="NormRef">[RFC-2048]</span></a>. It is recommended that 7204 implementations also recognize the media type 7205 "<tt>image/x-png</tt>".</p> 7206 7207 <h2><a name="A-Macintosh-file-layout">A.3 Macintosh file 7208 layout</a></h2> 7209 7210 <p>In the Apple Computer Inc. Macintosh system, the following 7211 conventions are recommended.</p> 7212 7213 <ol> 7214 <li>The four-byte file type code for PNG files is 7215 "<tt>PNGf</tt>". (This code has been registered with Apple 7216 Computer Inc. for PNG files.) The creator code will vary 7217 depending on the creating application.</li> 7218 7219 <li>The contents of the data fork is a PNG file exactly as 7220 described in this International Standard.</li> 7221 7222 <li>The contents of the resource fork are unspecified. It may be 7223 empty or may contain application-dependent resources.</li> 7224 7225 <li>When transferring a Macintosh PNG file to a non-Macintosh 7226 system, only the data fork should be transferred.</li> 7227 </ol> 7228 7229 <!-- ************Page Break******************* --> 7230 <!-- ************Page Break******************* --> 7231 <h1 class="Annex"><a name="B-NewChunksAppendix">Annex B</a></h1> 7232 7233 <p class="Annex">(informative)</p> 7234 7235 <h1 id="newchunks" class="Annex">Guidelines for new chunk types</h1> 7236 7237 <p>This International Standard allows extension through the 7238 addition of new chunk types and new interlace, filter, and 7239 compression methods. Such extensions might be made to the 7240 standard either for experimental purposes or by organizations for 7241 internal use.</p> 7242 7243 <p>Chunk types that are intended for general public use, or are 7244 required for specific application domains, should be standardized 7245 through registration (see 4.9 <a href= 7246 "#4Concepts.Registration"><span class="xref">Extension and 7247 registration</span></a>). The process for registration is defined 7248 by the Registration Authority. The conventions for naming chunks 7249 are given in 5.4: <a href="#5Chunk-naming-conventions"><span 7250 class="xref">Chunk naming conventions</span></a>.</p> 7251 7252 <p>Some guidelines for defining private chunks are given 7253 below.</p> 7254 7255 <!-- <ol start="1"> --><ol> 7256 <li>Do not define new chunks that redefine the meaning of 7257 existing chunks or change the interpretation of an existing 7258 standardized chunk, e.g., do not add a new chunk to say that RGB 7259 and alpha values actually mean CMYK.</li> 7260 7261 <li>Minimize the use of private chunks to aid portability.</li> 7262 7263 <li>Avoid defining chunks that depend on total datastream 7264 contents. If such chunks have to be defined, make them critical 7265 chunks.</li> 7266 7267 <li>For textual information that is representable in Latin-1 7268 avoid defining a new chunk type. Use a <a href="#11tEXt"><span 7269 class="chunk">tEXt</span></a> or <a href="#11zTXt"><span class= 7270 "chunk">zTXt</span></a> chunk with a suitable keyword to identify 7271 the type of information. For textual information that is not 7272 representable in Latin-1 but which can be represented in UTF-8, 7273 use an <a href="#11iTXt"><span class="chunk">iTXt</span></a> 7274 chunk with a suitable keyword.</li> 7275 7276 <li>Group mutually dependent ancillary information into a single 7277 chunk. This avoids the need to introduce chunk ordering 7278 relationships.</li> 7279 7280 <li>Avoid defining private critical chunks.</li> 7281 </ol> 7282 7283 <!-- ************Page Break******************* --> 7284 <!-- ************Page Break******************* --> 7285 <h1 class="Annex"><a name="C-GammaAppendix">Annex C</a></h1> 7286 7287 <p class="Annex">(informative)</p> 7288 7289 <h1 id="gammachromaticity" class="Annex">Gamma and chromaticity</h1> 7290 7291 <p>Gamma is a numerical parameter used to describe approximations 7292 to certain non-linear transfer functions encountered in image 7293 capture and reproduction. Gamma is the exponent in a power law 7294 function. For example the function:</p> 7295 7296 <p><tt>intensity = (voltage + 7297 constant)<sup>exponent</sup></tt></p> 7298 7299 <p>which is used to model the non-linearity of cathode ray tube 7300 (CRT) displays. It is often assumed, as in this International 7301 Standard, that the constant is zero.</p> 7302 7303 <p>For the purposes of this International Standard, it is 7304 convenient to consider five places in a general image pipeline at 7305 which non-linear transfer functions may occur and which may be 7306 modelled by power laws. The characteristic exponent associated 7307 with each is given a specific name.</p> 7308 7309 <table class="Regular" summary= 7310 "This table describes characteristic exponents"> 7311 <tr> 7312 <td class="Regular"><tt>input_exponent</tt> </td> 7313 <td class="Regular">the exponent of the image sensor.</td> 7314 </tr> 7315 7316 <tr> 7317 <td class="Regular"><tt>encoding_exponent</tt> </td> 7318 <td class="Regular">the exponent of any transfer function performed by the 7319 process or device writing the datastream.</td> 7320 </tr> 7321 7322 <tr> 7323 <td class="Regular"><tt>decoding_exponent</tt> </td> 7324 <td class="Regular">the exponent of any transfer function performed by the 7325 software reading the image datastream.</td> 7326 </tr> 7327 7328 <tr> 7329 <td class="Regular"><tt>LUT_exponent</tt> </td> 7330 <td class="Regular">the exponent of the transfer function applied between the 7331 frame buffer and the display device (typically this is applied by 7332 a Look Up Table).</td> 7333 </tr> 7334 7335 <tr> 7336 <td class="Regular"><tt>output_exponent</tt> </td> 7337 <td class="Regular">the exponent of the display device. For a CRT, this is 7338 typically a value close to 2.2.</td> 7339 </tr> 7340 </table> 7341 7342 <p>It is convenient to define some additional entities that 7343 describe some composite transfer functions, or combinations of 7344 stages.</p> 7345 7346 <table class="Regular" summary= 7347 "This table characterises additional entities that are used to describe transfer functions"> 7348 <tr> 7349 <td class="Regular"><tt>display_exponent</tt> </td> 7350 <td class="Regular">exponent of the transfer function applied between the frame 7351 buffer and the display surface of the display device.<br class="xhtml" /> 7352 <tt>display_exponent = LUT_exponent * output_exponent</tt> </td> 7353 </tr> 7354 7355 <tr> 7356 <td class="Regular"><tt>gamma</tt> </td> 7357 <td class="Regular">exponent of the function mapping display output intensity to 7358 samples in the PNG datastream.<br class="xhtml" /> 7359 <tt>gamma = 1.0 / (decoding_exponent * display_exponent)</tt> 7360 </td> 7361 </tr> 7362 7363 <tr> 7364 <td class="Regular"><tt>end_to_end_exponent</tt> </td> 7365 <td class="Regular">the exponent of the function mapping image sensor input 7366 intensity to display output intensity. This is generally a value 7367 in the range 1.0 to 1.5.</td> 7368 </tr> 7369 </table> 7370 7371 <p>The PNG <a href="#11gAMA"><span class="chunk">gAMA</span></a> 7372 chunk is used to record the gamma value. This information may be 7373 used by decoders together with additional information about the 7374 display environment in order to achieve, or approximate, the 7375 desired display output.</p> 7376 7377 <p>Additional information about this subject may be found in the 7378 references <a href="#G-GAMMA-TUTORIAL"><span class= 7379 "bibref">[GAMMA-TUTORIAL]</span></a>, <a href= 7380 "#G-GAMMA-FAQ"><span class="bibref">[GAMMA-FAQ]</span></a>, and 7381 <a href="#G-POYNTON"><span class="bibref">[POYNTON]</span></a> 7382 (especially chapter 6).</p> 7383 7384 <p>Background information about chromaticity and colour spaces 7385 may be found in references <a href="#G-COLOUR-TUTORIAL"><span 7386 class="bibref">[COLOUR-TUTORIAL]</span></a>, <a href= 7387 "#G-COLOUR-FAQ"><span class="bibref">[COLOUR-FAQ]</span></a>, <a 7388 href="#G-HALL"><span class="bibref">[HALL]</span></a>, <a href= 7389 "#G-KASSON"><span class="bibref">[KASSON]</span></a>, <a href= 7390 "#G-LILLEY"><span class="bibref">[LILLEY]</span></a>, <a href= 7391 "#G-STONE"><span class="bibref">[STONE]</span></a>, and <a href= 7392 "#G-TRAVIS"><span class="bibref">[TRAVIS]</span></a>.</p> 7393 7394 <!-- ************Page Break******************* --> 7395 <!-- ************Page Break******************* --> 7396 <h1 class="Annex"><a name="D-CRCAppendix">Annex D</a></h1> 7397 7398 <p class="Annex">(informative)</p> 7399 7400 <h1 id="samplecrc" class="Annex">Sample Cyclic Redundancy Code 7401 implementation</h1> 7402 7403 <p>The following sample code represents a practical 7404 implementation of the CRC (Cyclic Redundancy Check) employed in 7405 PNG chunks. (See also ISO 3309 <a href="#2-ISO-3309"><span class= 7406 "NormRef">[ISO-3309]</span></a> or ITU-T V.42 <a href= 7407 "#G-ITU-T-V42"><span class="bibref">[ITU-T-V42]</span></a> for a 7408 formal specification.)</p> 7409 7410 <p>The sample code is in the ISO C <a href="#2-ISO-9899"><span 7411 class="NormRef">[ISO-9899]</span></a> programming language. The 7412 hints in <a href="#D-tabled1"><span class="tabref">Table 7413 D.1</span></a> may help non-C users to read the code more 7414 easily.</p> 7415 7416 <table class="Regular" summary= 7417 "This table gives hints for reading the CRC code"> 7418 <caption><a name="D-tabled1"><b>Table D.1 — Hints for 7419 reading ISO C code</b></a></caption> 7420 7421 <tr> 7422 <td class="Regular"><tt>&</tt> </td> 7423 <td class="Regular">Bitwise AND operator.</td> 7424 </tr> 7425 7426 <tr> 7427 <td class="Regular"><tt>^</tt> </td> 7428 <td class="Regular">Bitwise exclusive-OR operator.</td> 7429 </tr> 7430 7431 <tr> 7432 <td class="Regular"><tt>>></tt> </td> 7433 <td class="Regular">Bitwise right shift operator. When applied to an unsigned 7434 quantity, as here, right shift inserts zeroes at the left.</td> 7435 </tr> 7436 7437 <tr> 7438 <td class="Regular"><tt>!</tt> </td> 7439 <td class="Regular">Logical NOT operator.</td> 7440 </tr> 7441 7442 <tr> 7443 <td class="Regular"><tt>++</tt> </td> 7444 <td class="Regular">"<tt>n++</tt>" increments the variable <tt>n</tt>. In "for" 7445 loops, it is applied after the variable is tested.</td> 7446 </tr> 7447 7448 <tr> 7449 <td class="Regular"><tt>0xNNN</tt> </td> 7450 <td class="Regular"><tt>0x</tt> introduces a hexadecimal (base 16) constant. 7451 Suffix <tt>L</tt> indicates a long value (at least 32 bits).</td> 7452 </tr> 7453 </table> 7454 7455 <hr class="xhtml" /> 7456 <pre> 7457 /* Table of CRCs of all 8-bit messages. */ 7458 unsigned long crc_table[256]; 7459 7460 /* Flag: has the table been computed? Initially false. */ 7461 int crc_table_computed = 0; 7462 7463 /* Make the table for a fast CRC. */ 7464 void make_crc_table(void) 7465 { 7466 unsigned long c; 7467 int n, k; 7468 7469 for (n = 0; n < 256; n++) { 7470 c = (unsigned long) n; 7471 for (k = 0; k < 8; k++) { 7472 if (c & 1) 7473 c = 0xedb88320L ^ (c >> 1); 7474 else 7475 c = c >> 1; 7476 } 7477 crc_table[n] = c; 7478 } 7479 crc_table_computed = 1; 7480 } 7481 7482 </pre> 7483 7484 <!-- ************Page Break******************* --> 7485 <!-- ************Page Break******************* --> 7486 <pre> 7487 /* Update a running CRC with the bytes buf[0..len-1]--the CRC 7488 should be initialized to all 1's, and the transmitted value 7489 is the 1's complement of the final running CRC (see the 7490 crc() routine below). */ 7491 7492 unsigned long update_crc(unsigned long crc, unsigned char *buf, 7493 int len) 7494 { 7495 unsigned long c = crc; 7496 int n; 7497 7498 if (!crc_table_computed) 7499 make_crc_table(); 7500 for (n = 0; n < len; n++) { 7501 c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8); 7502 } 7503 return c; 7504 } 7505 7506 /* Return the CRC of the bytes buf[0..len-1]. */ 7507 unsigned long crc(unsigned char *buf, int len) 7508 { 7509 return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL; 7510 } 7511 </pre> 7512 7513 <!-- ************Page Break******************* --> 7514 <!-- ************Page Break******************* --> 7515 <h1 class="Annex"><a name="E-Resources">Annex E</a></h1> 7516 7517 <p class="Annex">(informative)</p> 7518 7519 <h1 id="onlineresources" class="Annex">Online resources</h1> 7520 7521 <h2><a name="E-Intro">Introduction</a></h2> 7522 7523 <p>This annex gives the locations of some Internet resources for 7524 PNG software developers. By the nature of the Internet, the list 7525 is incomplete and subject to change.</p> 7526 7527 <h2><a name="E-Archive-sites">Archive sites</a></h2> 7528 7529 <p>This International Standard can be found at 7530 <a href="http://www.w3.org/TR/2003/REC-PNG-20031110/index.html" 7531 ><code>http://www.w3.org/TR/2003/REC-PNG-20031110/index.html</code></a>.</p> 7532 7533 <h2><a name="E-icc-profile-specs">ICC profile 7534 specifications</a></h2> 7535 7536 <p>ICC profile specifications are available at: <a href= 7537 "http://www.color.org/"><code>http://www.color.org/</code></a></p> 7538 7539 <h2><a name="E-PNG-home-page">PNG web site</a></h2> 7540 7541 <p>There is a World Wide Web site for PNG at <a href= 7542 "http://www.libpng.org/pub/png/"><code>http://www.libpng.org/pub/png/</code></a>. 7543 This page is a central location for current information about PNG 7544 and PNG-related tools.</p> 7545 7546 <p>Additional documentation and portable C code for deflate, 7547 inflate, and an optimized implementation of the CRC algorithm are 7548 available from the zlib web site, 7549 <a href= 7550 "http://www.zlib.org/"><code>http://www.zlib.org/</code></a>.</p> 7551 7552 <h2><a name="E-Sample-implementation">Sample implementation and 7553 test images</a></h2> 7554 7555 <p>A sample implementation in portable C, <strong>libpng</strong>, is 7556 available at <a href= 7557 "http://www.libpng.org/pub/png/libpng.html"><code>http://www.libpng.org/pub/png/libpng.html</code></a>. 7558 Sample viewer and encoder applications of libpng are available at 7559 <a href= 7560 "http://www.libpng.org/pub/png/book/sources.html"><code>http://www.libpng.org/pub/png/book/sources.html</code></a> 7561 and are described in detail in <i>PNG: The Definitive Guide</i> 7562 <a href="#G-ROELOFS">[ROELOFS]</a>. Test images can also be 7563 accessed from the PNG web site.</p> 7564 7565 <h2><a name="E-Email">Electronic mail</a></h2> 7566 7567 <p>Queries concerning PNG developments may be addressed to <a href= 7568 "mailto:png-group@w3.org"><tt>png-group@w3.org</tt></a>. 7569 <!-- ************Page Break******************* --> 7570 </p> 7571 7572 <!-- ************Page Break******************* --> 7573 <h1 class="Annex"><a name="F-Relationship">Annex F</a></h1> 7574 7575 <p class="Annex">(informative)</p> 7576 7577 <h1 id="relationshiptofirstedition" class="Annex">Relationship to W3C PNG</h1> 7578 7579 <p>This International Standard is strongly based on W3C 7580 Recommendation PNG Specification Version 1.0 <a href= 7581 "#G-PNG-1.0">[PNG-1.0]</a> which was reviewed by W3C members, 7582 approved as a W3C Recommendation, and published in October 1996 7583 according to the established W3C process. Subsequent amendments 7584 to the PNG Specification have also been incorporated into this 7585 International Standard <a href="#G-PNG-1.0">[PNG-1.1]</a>, <a 7586 href="#G-PNG-1.0">[PNG-1.2]</a>.</p> 7587 7588 <p>A complete review of the document has been done by ISO/IEC/JTC 7589 1/SC 24 in collaboration with W3C in order to transform this 7590 recommendation into an ISO/IEC international standard. A major 7591 design goal during this review was to avoid changes that will 7592 invalidate existing files, editors, or viewers that conform to 7593 W3C Recommendation PNG Specification Version 1.0.</p> 7594 7595 <p>The W3C PNG Recommendation was developed with major 7596 contribution from the following people.</p> 7597 7598 <h2><a name="F-Editor10">Editor (Version 1.0)</a></h2> 7599 7600 <p>Thomas Boutell, <span class="email">boutell @ boutell.com</span></p> 7601 7602 <h2><a name="F-Editor12">Editor (Versions 1.1 and 1.2)</a></h2> 7603 7604 <p>Glenn Randers-Pehrson, <span class="email">randeg @ alum.rpi.edu</span></p> 7605 7606 <h2><a name="F-ContribEditor10">Contributing Editor (Version 7607 1.0)</a></h2> 7608 7609 <p>Tom Lane, <span class="email">tgl @ sss.pgh.pa.us</span></p> 7610 7611 <h2><a name="F-ContribEditor12">Contributing Editor (Versions 1.1 7612 and 1.2)</a></h2> 7613 7614 <p>Adam M. Costello, <span class="email">png-spec.amc @ nicemice.net</span></p> 7615 7616 <h2><a name="F-Authors">Authors (Versions 1.0, 1.1, and 1.2 7617 combined)</a></h2> 7618 7619 <p><strong>Authors' names are presented in alphabetical 7620 order.</strong></p> 7621 7622 <ul> 7623 <li><a href="http://www.alumni.caltech.edu/~madler/">Mark Adler</a>, 7624 <span class="email">madler @ alumni.caltech.edu</span></li> 7625 7626 <li><a href="http://www.boutell.com/boutell/">Thomas Boutell</a>, 7627 <span class="email">boutell @ boutell.com</span></li> 7628 7629 <li>John Bowler, <span class="mail">jbowler @ acm.org</span></li> 7630 7631 <li><a href="http://www.df.lth.se/~cb/">Christian Brunschen</a>, 7632 <span class="email">cb @ brunschen.com</span></li> 7633 7634 <li><a href="http://www.nicemice.net/amc/">Adam M. 7635 Costello</a>, <span class= 7636 "email">png-spec.amc @ nicemice.net</span></li> 7637 7638 <li><a href="http://www.piclab.com/">Lee Daniel Crocker</a>, 7639 <span class="email">lee @ piclab.com</span></li> 7640 7641 <li><a href= 7642 "http://www-mddsp.enel.ucalgary.ca/People/adilger/">Andreas 7643 Dilger</a>, <span class= 7644 "email">adilger @ turbolabs.com</span></li> 7645 7646 <li><a href="http://www.fromme.com/">Oliver Fromme</a>, <span 7647 class="email">oliver @ fromme.com</span></li> 7648 7649 <li><a href="http://www.teaser.fr/~jlgailly/">Jean-loup 7650 Gailly</a>, <span class="email">jloup @ gzip.org</span></li> 7651 7652 <li>Chris Herborth, <span class= 7653 "email">chrish @ pobox.com</span></li> 7654 7655 <li>Alex Jakulin, <span class= 7656 "email">jakulin @ acm.org</span></li> 7657 7658 <li>Neal Kettler, <span class= 7659 "email">neal @ westwood.com</span></li> 7660 7661 <li>Tom Lane, <span class="email">tgl @ sss.pgh.pa.us</span></li> 7662 7663 <li>Alexander Lehmann, <span class= 7664 "email">lehmann @ usa.net</span></li> 7665 7666 7667 <!-- ************Page Break******************* --> 7668 <!-- ************Page Break******************* --> 7669 7670 <li><a href="http://www.w3.org/People/chris/">Chris Lilley</a>, 7671 <span class="email">chris @ w3.org</span></li> 7672 7673 <li>Dave Martindale, <span class= 7674 "email">davem @ cs.ubc.ca</span></li> 7675 7676 <li>Owen Mortensen, <span class="email">ojm @ acm.org</span></li> 7677 7678 <li>Keith S. Pickens, <span class= 7679 "email">ksp @ rice.edu</span></li> 7680 7681 <li><a href="http://www.users.qwest.net/~lionlad/">Robert P. Poole</a>, <span class= 7682 "email">lionlad @ qwest.net</span></li> 7683 7684 <li>Glenn Randers-Pehrson, <span class= 7685 "email">randeg @ alum.rpi.edu</span></li> 7686 7687 <li><a href="http://pobox.com/~newt/">Greg Roelofs</a>, <span 7688 class="email">newt @ pobox.com</span></li> 7689 7690 <li><a href="http://www.schaik.com/">Willem van Schaik</a>, <span 7691 class="email">willem @ schaik.com</span></li> 7692 7693 <li>Guy Schalnat, <span class= 7694 "email">gschal @ infinet.com</span></li> 7695 7696 <li>Paul Schmidt, <span class= 7697 "email">pschmidt @ photodex.com</span></li> 7698 7699 <li>Michael Stokes, <span class= 7700 "email">mistokes @ microsoft.com</span></li> 7701 7702 <li>Tim Wegner, <span class= 7703 "email">twegner @ phoenix.net</span></li> 7704 7705 <li>Jeremy Wohl, <span class= 7706 "email">jeremyw @ evantide.com</span></li> 7707 </ul> 7708 7709 <h2><a name="F-ChangeList">List of changes between W3C 7710 Recommendation PNG Specification Version 1.0 and this 7711 International Standard</a></h2> 7712 7713 <h3><a name="F-EditorialChanges">Editorial changes</a></h3> 7714 7715 <p>The document has been reformatted according to the 7716 requirements of ISO.</p> 7717 7718 <!-- <ol start="1"> --><ol> 7719 <li>A concepts clause has been introduced.</li> 7720 7721 <li>Conformance for datastreams, encoders, decoders, and editors 7722 has been defined in a conformance clause.</li> 7723 </ol> 7724 7725 <h3><a name="F-TechnicalChanges">Technical changes</a></h3> 7726 7727 <!-- <ol start="1"> --><ol> 7728 <li>New chunk types introduced in PNG version 1.1 and 1.2 have 7729 been incorporated (<a href="#11iCCP"><span class= 7730 "chunk">iCCP</span></a>, <a href="#11iTXt"><span class= 7731 "chunk">iTXt</span></a>, <a href="#11sRGB"><span class= 7732 "chunk">sRGB</span></a>, <a href="#11sPLT"><span class= 7733 "chunk">sPLT</span></a>). 7734 In the 7735 <a href="#11iTXt"><span class= 7736 "chunk">iTXt</span></a> 7737 chunk, the language tag has been updated from RFC 1766 to RFC 3066.</li> 7738 7739 <li>In accord with version 1.1, the scope of the 31-bit limit on 7740 chunk lengths and image dimensions has been extended to apply to 7741 all four-byte unsigned integers. The value -2<sup>31</sup> is not 7742 allowed in signed integers.</li> 7743 7744 <li>The redefinition of <a href="#11gAMA"><span class= 7745 "chunk">gAMA</span></a> to be in terms of the desired display 7746 output rather than the original scene, introduced in PNG version 7747 1.1, has been incorporated.</li> 7748 7749 <li>The use of the <a href="#11PLTE"><span class= 7750 "chunk">PLTE</span></a> and <a href="#11hIST"><span class= 7751 "chunk">hIST</span></a> chunks in non-indexed-colour images has 7752 been discouraged in favour of the <a href="#11sPLT"><span class= 7753 "chunk">sPLT</span></a> chunk.</li> 7754 7755 <li>Some recommendations for PNG encoders, decoders, and editors 7756 have been strengthened to requirements. These changes do not 7757 affect the conformance of PNG datastreams, and do not compromise 7758 interoperability.</li> 7759 7760 <li>The sample depth of channels not mentioned in the <a href= 7761 "#11sBIT"><span class="chunk">sBIT</span></a> chunk has been 7762 clarified.</li> 7763 </ol> 7764 7765 <!-- ************Page Break******************* --> 7766 <!-- ************Page Break******************* --> 7767 <h1 class="Annex"><a name="G-References">Bibliography</a></h1> 7768 7769 <dl> 7770 <dt><a name="G-COLOUR-FAQ">[COLOUR-FAQ]</a></dt> 7771 7772 <dd>Poynton, C., "Colour FAQ".<br class="xhtml" /> 7773 <a href= 7774 "http://www.poynton.com/ColorFAQ.html"><code>http://www.poynton.com/ColorFAQ.html</code></a></dd> 7775 7776 <dt><a name="G-COLOUR-TUTORIAL">[COLOUR-TUTORIAL]</a></dt> 7777 7778 <dd>PNG Group, "Colour tutorial".<br class="xhtml" /> 7779 <a href= 7780 "http://www.libpng.org/pub/png/spec/1.2/PNG-ColorAppendix.html"><code>http://www.libpng.org/pub/png/spec/1.2/PNG-ColorAppendix.html</code></a></dd> 7781 7782 <dt><a name="G-GAMMA-TUTORIAL">[GAMMA-TUTORIAL]</a></dt> 7783 7784 <dd>PNG Group, "Gamma tutorial".<br class="xhtml" /> 7785 <a href= 7786 "http://www.libpng.org/pub/png/spec/1.2/PNG-GammaAppendix.html"><code>http://www.libpng.org/pub/png/spec/1.2/PNG-GammaAppendix.html</code></a></dd> 7787 7788 <dt><a name="G-GAMMA-FAQ">[GAMMA-FAQ]</a></dt> 7789 7790 <dd>Poynton, C., "Gamma FAQ".<br class="xhtml" /> 7791 <a href= 7792 "http://www.poynton.com/Poynton-color.html"> 7793 <code>http://www.poynton.com/Poynton-color.html</code></a></dd> 7794 7795 <dt><a name="G-HALL">[HALL]</a></dt> 7796 7797 <dd>Hall, Roy, <i>Illumination and Color in Computer Generated 7798 Imagery</i>. Springer-Verlag, New York, 1989. ISBN 7799 0-387-96774-5.</dd> 7800 7801 <dt><a name="G-ICC">[ICC]</a></dt> 7802 7803 <dd>The International Color Consortium.<br class="xhtml" /> 7804 <a href= 7805 "http://www.color.org/"><code>http://www.color.org/</code></a></dd> 7806 7807 <dt><a name="G-ISO-3664">[ISO-3664]</a></dt> 7808 7809 <dd>ISO 3664:2000, <i>Viewing conditions — Graphic 7810 technology and photography</i>.</dd> 7811 7812 <dt><a name="G-ITU-R-BT709">[ITU-R-BT709]</a></dt> 7813 7814 <dd>International Telecommunications Union, <i>Basic Parameter 7815 Values for the HDTV Standard for the Studio and for International 7816 Programme Exchange</i>, ITU-R Recommendation BT.709 (formerly CCIR 7817 Rec. 709), 1990.</dd> 7818 7819 <dt><a name="G-ITU-T-V42">[ITU-T-V42]</a></dt> 7820 7821 <dd>International Telecommunications Union, <i>Error-correcting 7822 Procedures for DCEs Using Asynchronous-to-Synchronous 7823 Conversion</i>, ITU-T Recommendation V.42, 1994, Rev. 1.</dd> 7824 7825 <dt><a name="G-KASSON">[KASSON]</a></dt> 7826 7827 <dd>Kasson, J., and W. Plouffe, "An Analysis of Selected Computer 7828 Interchange Color Spaces", <i>ACM Transactions on Graphics</i>, 7829 vol. 11, no. 4 , pp. 373-405, 1992.</dd> 7830 7831 <dt><a name="G-LILLEY">[LILLEY]</a></dt> 7832 7833 <dd>Lilley, C., F. Lin, W.T. Hewitt, and T.L.J. Howard, <i>Colour 7834 in Computer Graphics</i>. CVCP, Sheffield, 1993. ISBN 7835 1-85889-022-5.<br class="xhtml" /> 7836 <!-- Also available from<br class="xhtml" /> 7837 <a href= 7838 "http://www.man.ac.uk/MVC/training/gravigs/colour/"><code>http://www.man.ac.uk/MVC/training/gravigs/colour/</code></a> 7839 --></dd> 7840 7841 <dt><a name="G-ROELOFS">[ROELOFS]</a></dt> 7842 7843 <dd>Roelofs, G., <i>PNG: The Definitive Guide</i>, O'Reilly & 7844 Associates Inc, Sebastopol, CA, 1999. ISBN 1-56592-542-4. 7845 See also <a href="http://www.libpng.org/pub/png/pngbook.html"><code>http://www.libpng.org/pub/png/pngbook.html</code></a></dd> 7846 7847 <dt><a name="G-PAETH">[PAETH]</a></dt> 7848 7849 <dd>Paeth, A.W., "Image File Compression Made Easy", in 7850 <i>Graphics Gems II</i>, James Arvo, editor. Academic Press, San 7851 Diego, 1991. ISBN 0-12-064480-0.</dd> 7852 7853 <dt><a name="G-PNG-1.0">[PNG-1.0]</a></dt> 7854 7855 <dd>W3C Recommendation, "PNG (Portable Network Graphics) 7856 Specification, Version 1.0", 1996. Available in several formats 7857 from<br class="xhtml" /> 7858 <a href= 7859 "http://www.w3.org/TR/REC-png-961001"><code>http://www.w3.org/TR/REC-png-961001</code></a> 7860 and from<br class="xhtml" /> 7861 <a href= 7862 "http://www.libpng.org/pub/png/spec/1.0/"><code>http://www.libpng.org/pub/png/spec/1.0/</code></a></dd> 7863 7864 <dt><a name="G-PNG-1.1">[PNG-1.1]</a></dt> 7865 7866 <dd>PNG Development Group, "PNG (Portable Network Graphics) 7867 Specification, Version 1.1", 1998. Available 7868 from<br class="xhtml" /> 7869 <a href= 7870 "http://www.libpng.org/pub/png/spec/1.1/"><code>http://www.libpng.org/pub/png/spec/1.1/</code></a></dd> 7871 7872 <dt><a name="G-PNG-1.2">[PNG-1.2]</a></dt> 7873 7874 <dd>PNG Development Group, "PNG (Portable Network Graphics) 7875 Specification, Version 1.2", 1999. Available from<br class="xhtml" /> 7876 <a href= 7877 "http://www.libpng.org/pub/png/spec/1.2/"><code>http://www.libpng.org/pub/png/spec/1.2/</code></a></dd> 7878 7879 <dt><a name="G-PNG-EXTENSIONS">[PNG-REGISTER]</a></dt> 7880 7881 <dd>PNG Development Group, "Register of PNG Public Chunks and Keywords". 7882 Available in several formats from:<br class="xhtml" /> 7883 <a href= 7884 "http://www.libpng.org/pub/png/spec/register/"><code>http://www.libpng.org/pub/png/spec/register/</code></a></dd> 7885 7886 <dt><a name="G-POSTSCRIPT">[POSTSCRIPT]</a></dt> 7887 7888 <dd>Adobe Systems Incorporated, <i>PostScript Language Reference 7889 Manual</i>, 2nd edition. Addison-Wesley, Reading, 1990. ISBN 7890 0-201-18127-4.</dd> 7891 7892 <dt><a name="G-POYNTON">[POYNTON]</a></dt> 7893 7894 <dd>Poynton, Charles A., <i>A Technical Introduction to Digital 7895 Video</i>. John Wiley and Sons, Inc., New York, 1996. ISBN 7896 0-471-12253-X.</dd> 7897 7898 <dt><a name="G-SMPTE-170M">[SMPTE-170M]</a></dt> 7899 7900 <dd>Society of Motion Picture and Television Engineers, 7901 <i>Television — Composite Analog Video Signal — NTSC 7902 for Studio Applications</i>, SMPTE-170M, 1994.</dd> 7903 7904 <dt><a name="G-STONE">[STONE]</a></dt> 7905 7906 <dd>Stone, M.C., W.B. Cowan, and J.C. Beatty, "Color gamut 7907 mapping and the printing of digital images", <i>ACM Transactions on 7908 Graphics</i>, vol. 7, no. 3, pp. 249-292, 1988.</dd> 7909 7910 <dt><a name="G-TIFF-6.0">[TIFF-6.0]</a></dt> 7911 7912 <dd>TIFF<sup>TM</sup> Revision 6.0, Aldus Corporation, June 7913 1992.</dd> 7914 7915 <dt><a name="G-TRAVIS">[TRAVIS]</a></dt> 7916 7917 <dd>Travis, David, <i>Effective Color Displays — Theory and 7918 Practice</i>. Academic Press, London, 1991. ISBN 7919 0-12-697690-2.</dd> 7920 7921 <dt><a name="G-ZL">[ZL]</a></dt> 7922 7923 <dd>J. Ziv and A. Lempel, "A Universal Algorithm for Sequential 7924 Data Compression", <i>IEEE Transactions on Information 7925 Theory</i>, vol. IT-23, no. 3, pp. 337 - 343, 1977.</dd> 7926 </dl> 7927 7928 <p>Additional documentation and portable C code for deflate, 7929 inflate, and an optimized implementation of the CRC algorithm are 7930 available from the zlib web site, 7931 <a href= 7932 "http://www.zlib.org/"><code>http://www.zlib.org/</code></a>.</p> 7933 </body> 7934 </html>