-
Notifications
You must be signed in to change notification settings - Fork 11
/
index.html
7808 lines (6167 loc) · 367 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<title>Portable Network Graphics (PNG) Specification (Third Edition)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
span.chunk { color: #622;}
</style>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove" defer></script>
<script class="remove">
var respecConfig = {
group: "png",
specStatus: "CRD",
crEnd: "2024-09-18",
implementationReportURI: "https://w3c.github.io/png/Implementation_Report_3e/",
shortName: "png-3",
publishDate: "2024-07-18",
copyrightStart: "1996",
previousPublishDate: "2023-07-20",
previousMaturity: "CR",
edDraftURI: "https://w3c.github.io/png/",
github: {
repoURL : "https://github.com/w3c/png",
branch : "main"
},
extraCSS: ["https://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
editors: [
{ name: "Chris Blume", url: "https://www.programmax.net", company: "W3C Invited Experts", w3cid: 127631 },
{ name: "Pierre-Anthony Lemieux", company: "MovieLabs", companyURL: "https://movielabs.com/", url: "mailto:pal@palemieux.com", w3cid: 57073 },
{ name: "Chris Lilley", url: "https://svgees.us", company: "W3C", companyURL: "https://www.w3.org", w3cid: 1438 },
{ name: "Leonard Rosenthol", company: "Adobe Inc.", companyURL: "https://www.adobe.com", w3cid: 42485 },
{ name: "Chris Arley Seeger", company: "NBCUniversal, LLC a subsidiary of Comcast Corporation", companyURL: "https://www.xfinity.com", w3cid: 125844 }
],
formerEditors: [
{ name: "Thomas Boutell" },
{ name: "Adam M. Costello" },
{ name: "David Duce" },
{ name: "Tom Lane" },
{ name: "Glenn Randers-Pehrson" },
],
authors: [
{ name: "Mark Adler", url: "https://en.wikipedia.org/wiki/Mark_Adler" },
{ name: "Thomas Boutell", url: "https://boutell.dev/" },
{ name: "Christian Brunschen" },
{ name: "Adam M. Costello", url: "http://www.nicemice.net/amc/" },
{ name: "Lee Daniel Crocker" },
{ name: "Andreas Dilger", url: "http://www-mddsp.enel.ucalgary.ca/People/adilger/" },
{ name: "Oliver Fromme", url: "https://www.fromme.com/" },
{ name: "Jean-loup Gailly", url: "http://gailly.net/" },
{ name: "Chris Herborth" },
{ name: "Alex Jakulin" },
{ name: "Neal Kettler" },
{ name: "Tom Lane" },
{ name: "Alexander Lehmann" },
{ name: "Chris Lilley", url: "https://svgees.us", company: "W3C", companyURL: "https://www.w3.org" },
{ name: "Dave Martindale" },
{ name: "Owen Mortensen" },
{ name: "Chris Needham", url: "https://chrisneedham.com/about" },
{ name: "Stuart Parmenter"},
{ name: "Keith S. Pickens" },
{ name: "Robert P. Poole" },
{ name: "Glenn Randers-Pehrson" },
{ name: "Greg Roelofs", url: "http://www.gregroelofs.com/" },
{ name: "Willem van Schaik", url: "http://www.schaik.com/" },
{ name: "Guy Schalnat" },
{ name: "Paul Schmidt" },
{ name: "Andrew Smith" },
{ name: "Michael Stokes" },
{ name: "Simon Thompson", company: "British Broadcasting Corporation", companyURL: "https://www.bbc.co.uk" },
{ name: "Vladimir Vukicevic" },
{ name: "Tim Wegner" },
{ name: "Jeremy Wohl" }
],
wg: "Portable Network Graphics (PNG) Working Group",
wgURI: "https://www.w3.org/groups/wg/png",
wgPublicList: "public-png",
wgPatentURI: "https://www.w3.org/groups/wg/png/ipr",
lint: { "informative-dfn": false },
xref: ["i18n-glossary"],
localBiblio: {
"CIPA-DC-008": {
title: "Exchangeable image file format for digital still cameras: Exif Version 2.32",
href: "https://www.cipa.jp/std/documents/download_e.html?DC-008-Translation-2019-E",
date: "2019-05-17",
publisher: "Camera & Imaging Products Association"
},
"COLOR-FAQ": {
title: "Color FAQ",
authors: ["Poynton, C."],
href: "https://poynton.ca/ColorFAQ.html",
date: "2009-10-19"
},
"CTA-861.3-A": {
title: "HDR Static Metadata Extensions (CTA-861.3-A)",
publisher: "Consumer Technology Association",
date: "2015-01",
href: "https://shop.cta.tech/products/hdr-static-metadata-extensions"
},
"Display-P3": {
title: "Display P3",
authors: ["Apple, Inc"],
date: "2022-02",
publisher: "ICC",
href: "https://www.color.org/chardata/rgb/DisplayP3.xalter"
},
"ICC-2": {
title: "Specification ICC.2:2019 (Profile version 5.0.0 - iccMAX)",
date: "2019",
href: "https://www.color.org/specification/ICC.2-2019.pdf",
publisher: "International Color Consortium"
},
"GAMMA-FAQ": {
title: "Gamma FAQ",
authors: ["Poynton, C."],
href: "https://poynton.ca/GammaFAQ.html",
date: "1998-08-04"
},
"HDR10": {
title: "HDR10 Media Profile",
href: "https://en.wikipedia.org/wiki/HDR10"
},
"HDR-Static-Meta": {
title: "On the Calculation and Usage of HDR Static Content Metadata",
authors: ["Smith, Michael D.", "Zink, Michael"],
publisher: "Society of Motion Picture and Television Engineers",
date: "2021-08-05",
href: "https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9508136"
},
"Hill": {
title: "Comparative analysis of the quantization of color spaces on the basis of the CIELAB color-difference formula",
authors: ["Hill, B.", "Roger, Th.", "Vorhagen, F.W."],
journal: "ACM Transactions on Graphics, Volume 16, Issue 2, pp. 109–154",
date: "1997-04",
href: "https://dl.acm.org/doi/10.1145/248210.248212"
},
"ISO-3309": {
title: "ISO/IEC 3309:1993, Information Technology — Telecommunications and information exchange between systems — High-level data link control (HDLC) procedures — Frame structure.",
date: "1993",
publisher: "ISO"
},
"ISO_8859-1": {
title: "ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1.",
date: "1998",
publisher: "ISO"
},
"ISO_9899": {
title: "ISO/IEC 9899:2018 Information technology — Programming languages — C",
href: "https://www.iso.org/standard/74528.html",
date: "2018-6",
publisher: "ISO"
},
"ISO_15076-1": {
title: "ISO 15076-1:2010 Image technology colour management — Architecture, profile format and data structure — Part 1: Based on ICC.1:2010",
href: "https://www.iso.org/standard/54754.html",
date: "2010-12",
publisher: "ISO"
},
"ISO_20677-1": {
title: "ISO 20677:2019 Image technology colour management — Extensions to architecture, profile format and data structure",
href: "https://www.iso.org/standard/68806.html",
date: "2019-02",
publisher: "ISO"
},
"ITU-R-BT.709": {
title: "ITU-R BT.709, SERIES BT: BROADCASTING SERVICE (TELEVISION). Parameter values for the HDTV standards for production and international programme exchange",
publisher: "ITU",
date: "2015-06",
href: "https://www.itu.int/rec/R-REC-BT.709"
},
"ITU-R-BT.2020": {
title: "Parameter values for ultra-high definition television systems for production and international programme exchange",
publisher: "ITU",
href: "https://www.itu.int/rec/R-REC-BT.2020"
},
"ITU-R-BT.2100": {
title: "ITU-R BT.2100, SERIES BT: BROADCASTING SERVICE (TELEVISION). Image parameter values for high dynamic range television for use in production and international programme exchange",
publisher: "ITU",
date: "2018-07",
href: "https://www.itu.int/rec/R-REC-BT.2100"
},
"ITU-R-BT.2390": {
title: "High dynamic range television for production and international programme exchange",
publisher: "ITU",
href: "https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-11-2023-PDF-E.pdf"
},
"ITU-T-H.273": {
title: "ITU-T H.273, SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services – Coding of moving video. Coding-independent code points for video signal type identification",
publisher: "ITU",
date: "2021-07",
href: "https://www.itu.int/rec/T-REC-H.273"
},
"ITU-T-V.42": {
title: "ITU-T V.42, SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK. Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion",
href: "https://www.itu.int/rec/T-REC-V.42-200203-I/en",
date: "2002-03-29",
publisher: "ITU"
},
"Kasson": {
title: "An Analysis of Selected Computer Interchange Color Spaces",
authors: ["Kasson, J.", "W. Plouffe"],
journal: "ACM Transactions on Graphics, vol. 11, no. 4, pp. 373-405",
date: "1992",
href: "https://dl.acm.org/doi/abs/10.1145/146443.146479"
},
"Luminance-Chromaticity": {
title: "Luminance and Chromaticity",
href: "https://colorusage.arc.nasa.gov/lum_and_chrom.php",
publisher: "Color Usage Research Lab, NASA Ames Research Center"
},
"Paeth": {
authors: ["Paeth, A.W"],
title: "Image File Compression Made Easy, in Graphics Gems II, pp. 93-100",
publisher: "Academic Press",
date: "1991",
isbn: "0-12-064481-9",
href: "https://www.sciencedirect.com/science/article/pii/B9780080507545500293"
},
"PNG-EXTENSIONS": {
title: "Extensions to the PNG Third Edition Specification, Version 1.6.0",
publisher: "W3C",
date: "2021",
href: "https://w3c.github.io/png/extensions/Overview.html"
},
"PostScript": {
title: "PostScript Language Reference Manual",
authors: ["Adobe Systems Incorporated"],
publisher: "Addison-Wesley",
date: "1990",
edition: "2",
isbn: "0-201-18127-4"
},
"ROELOFS": {
title: "PNG: The Definitive Guide",
authors: ["Roelofs, G."],
publisher: "O'Reilly & Associates Inc",
isbn: "1-56592-542-4",
href: "http://www.libpng.org/pub/png/pngbook.html",
date: "1999-06-11"
},
"SMPTE-170M": {
title: "Television — Composite Analog Video Signal — NTSC for Studio Applications",
publisher: "Society of Motion Picture and Television Engineers",
date: "2004-11-30",
href: "https://standards.globalspec.com/std/892300/SMPTE%20ST%20170M"
},
"SMPTE-RP-177": {
title: "Derivation of Basic Television Color Equations",
publisher: "Society of Motion Picture and Television Engineers",
date: "1 November 1993",
href: "https://standards.globalspec.com/std/1284890/smpte-rp-177"
},
"SMPTE-ST-2067-21": {
title: "Interoperable Master Format — Application #2E",
publisher: "Society of Motion Picture and Television Engineers",
date: "2023-02-20",
href: "https://doi.org/10.5594/SMPTE.ST2067-21.2023"
},
"SMPTE-RP-2077": {
title: "Full-Range Image Mapping",
publisher: "Society of Motion Picture and Television Engineers",
date: "2013-01-01",
href: "https://doi.org/10.5594/SMPTE.RP2077.2013"
},
"SMPTE-ST-2086": {
title: "Mastering Display Color Volume Metadata Supporting High Luminance and Wide Color Gamut Images",
publisher: "Society of Motion Picture and Television Engineers",
date: "27 April 2018",
href: "https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8353899"
},
"TIFF-6.0": {
href: "https://www.loc.gov/preservation/digital/formats/fdd/fdd000022.shtml",
title: "TIFF Revision 6.0",
date: "3 June 1992"
},
"Ziv-Lempel": {
authors: ["J. Ziv", "A. Lempel"],
title: "A Universal Algorithm for Sequential Data Compression, IEEE Transactions on Information Theory, vol. IT-23, no. 3, pp. 337 - 343",
date: "1977-05",
publisher: "IEEE",
href: "https://ieeexplore.ieee.org/document/1055714",
},
"EBU-R-103": {
title: "Video Signal Tolerance in Digital Television Systems",
publisher: "EBU",
date: "2020-05",
href: "https://tech.ebu.ch/docs/r/r103.pdf"
},
"ITU-T-Series-H-Supplement-19": {
title: "Series H: Audio Visual and Multimedia Systems - Usage of video signal type code points",
publisher: "ITU",
date: "2021-04",
href: "https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14652"
}
}
}
</script>
</head>
<body>
<section id="abstract">
<p>This document describes PNG (Portable Network Graphics), an extensible file format for the <a>lossless</a>, portable,
well-compressed storage of static and animated raster images. PNG provides a patent-free replacement for GIF and can also
replace many common uses of TIFF. <a>Indexed-color</a>, <a>greyscale</a>, and <a>truecolor</a> images are supported, plus an optional alpha
channel. Sample depths range from 1 to 16 bits.</p>
<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 color space data for improved color matching on heterogeneous platforms.</p>
<p>This specification defines two Internet Media Types, image/png and image/apng.</p>
<!--
needs update, comment out for now
<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> -->
</section>
<section id="sotd">
<p>This specification is intended to become an International Standard, but is not yet one. It is inappropriate to refer to this
specification as an International Standard.</p>
</section>
<!-- *********************************************************************
FROM HERE ON THIS FILE IS IDENTICAL TO THE ISO VERSION
with these exceptions:
- id added to any headings that did not have one, to comply with pubrules and allow indexing into the document
- URL for this document updated in Annex E and the words " [to be completed when published]" removed
************************************************************************** -->
<h2 id="Introduction">Introduction</h2>
<p>The design goals for this specification were:</p>
<ol>
<li>Portability: encoding, decoding, and transmission should be software and hardware platform independent.</li>
<li>Completeness: it should be possible to represent <a>truecolor</a>, <a>indexed-color</a>, and <a>greyscale</a> images, in each case with
the option of transparency, color space information, and ancillary information such as textual comments.
</li>
<li>Serial encode and decode: it should be possible for datastreams to be generated serially and read serially, allowing the
datastream format to be used for on-the-fly generation and display of images across a serial communication channel.</li>
<li>Progressive presentation: it should be possible to transmit datastreams so that an approximation of the whole image can be
presented initially, and progressively enhanced as the datastream is received.</li>
<li>Robustness to transmission errors: it should be possible to detect datastream transmission errors reliably.</li>
<li>Losslessness: filtering and compression should preserve all information.</li>
<li>Performance: any filtering, compression, and progressive image presentation should be aimed at efficient decoding and
presentation. Fast encoding is a less important goal than fast decoding. Decoding speed may be achieved at the expense of
encoding speed.</li>
<li>Compression: images should be compressed effectively, consistent with the other design goals.</li>
<li>Simplicity: developers should be able to implement the standard easily.</li>
<li>Interchangeability: any standard-conforming PNG decoder shall be capable of reading all conforming PNG datastreams.</li>
<li>Flexibility: future extensions and private additions should be allowed for without compromising the interchangeability of
standard PNG datastreams.</li>
<li>Freedom from legal restrictions: no algorithms should be used that are not freely available.</li>
</ol>
<section>
<!-- Maintain a fragment named "1Scope" to preserve incoming links to it -->
<h2 id="1Scope">Scope</h2>
<p>This specification specifies a datastream and an associated file format, Portable Network Graphics (PNG, pronounced "ping"),
for a <a>lossless</a>, portable, compressed individual computer graphics image or frame-based animation, transmitted across the
Internet.
</section>
<section>
<!-- Maintain a fragment named "3Defsandabbrevs" to preserve incoming links to it -->
<h2 id="3Defsandabbrevs">Terms, definitions, and abbreviated terms</h2>
<p>For the purposes of this specification the following definitions apply.</p>
<dl>
<!-- Maintain a fragment named "3byte" to preserve incoming links to it -->
<dt id="3byte"><dfn>byte</dfn>
</dt>
<dt>octet</dt>
<dd>8-bit binary integer in the range [0, 255] where the most significant bit is bit 7 and the least significant
bit is bit 0.</dd>
<!-- Maintain a fragment named "3byteOrder" to preserve incoming links to it -->
<dt id="3byteOrder"><dfn>byte order</dfn>
</dt>
<dd>
ordering of <a>bytes</a> for multi-byte data values.
</dd>
<!-- Maintain a fragment named "3chromaticity" to preserve incoming links to it -->
<dt id="3chromaticity"><dfn>chromaticity</dfn>
</dt>
<dd>pair of <i>x</i> and <i>y</i> values in the <i>xyY</i> space specified at [[COLORIMETRY]].
<p class="note">Chromaticity is a measure of the quality of a color regardless of its luminance.</p></dd>
<!-- Maintain a fragment named "3composite" to preserve incoming links to it -->
<dt id="3composite"><dfn data-lt="composited|composite">composite (verb)</dfn>
</dt>
<dd>form an image by merging a foreground image and a background image, using transparency information to determine
where and to what extent the background should be visible.
<p class="note">The foreground image is said to be <a>composited</a> against the background.</p>
</dd>
<!-- Maintain a fragment named "3datastream" to preserve incoming links to it -->
<dt id="3datastream"><dfn>datastream</dfn>
</dt>
<dd>
sequence of <a>bytes</a>.
</dd>
<!-- Maintain a fragment named "3deflate" to preserve incoming links to it -->
<dt id="3deflate"><dfn>deflate</dfn>
</dt>
<dd>
member of the <a>LZ77</a> family of compression methods.
<p>SOURCE: [[RFC1951]]</p>
</dd>
<dt><dfn>frame</dfn></dt>
<dd>For static PNG, the <a>static image</a>
is considered to be the first (and only) frame.
For animated PNG, each image that forms part
of the <a href="#apng-frame-based-animation">frame-based animation</a> sequence
is a frame.
Thus, for animated PNG, when the static image is not the first frame,
the static image is not considered to be a frame.
</dd>
<!-- Maintain a fragment named "3frameBuffer" to preserve incoming links to it -->
<dt id="3frameBuffer"><dfn>frame buffer</dfn>
</dt>
<dd>
the final digital storage area for the image shown by most types of computer display.
<p class="note">Software causes an image to appear on screen by loading the image into the <a>frame buffer</a>.</p>
</dd>
<dt><dfn>fully transparent black</dfn>
</dt>
<dd>pixel where the red, green, blue and alpha components are all equal to zero.</dd>
<dt><dfn>gamma value</dfn>
</dt>
<dd>
value of the exponent of a <a>gamma</a> <a>transfer function</a>.
</dd>
<!-- Maintain a fragment named "3gamma" to preserve incoming links to it -->
<dt id="3gamma"><dfn>gamma</dfn>
</dt>
<dd>
power-law <a>transfer function</a>.
</dd>
<dt>high dynamic range (<dfn>HDR</dfn>)
</dt>
<dd>
an image format capable of storing images with a relatively high dynamic range similar to or in excess of the human visual system's instantaneous dynamic range (~12-14 <a>stops</a>). PNG allows the use of two <a>HDR</a> formats, <a>HLG</a> and <a>PQ</a> [[ITU-R-BT.2100]].
</dd>
<dt>hybrid log-gamma (<dfn>HLG</dfn>)
</dt>
<dd>
<a>transfer function</a> defined in [[ITU-R-BT.2100]] Table 5. (A relative scene-referred system.)
</dd>
<dt><dfn>full-range image</dfn>
</dt>
<dd>image where reference black and white correspond, respectively, to sample values <code>0</code> and <code>2<sup>bit depth</sup> -
1</code>.</dd>
<!-- Maintain a fragment named "3imageData" to preserve incoming links to it -->
<dt id="3imageData"><dfn>image data</dfn>
</dt>
<dd>
1-dimensional array of <a>scanlines</a> within an image.
</dd>
<!-- Maintain a fragment named "3interlacedPNGimage" to preserve incoming links to it -->
<dt id="3interlacedPNGimage"><dfn>interlaced PNG image</dfn>
</dt>
<dd>
sequence of <a>reduced images</a> generated from the <a>PNG image</a> by <a>pass extraction</a>.
</dd>
<!-- Maintain a fragment named "3losslessCompression" to preserve incoming links to it -->
<dt id="3losslessCompression"><dfn>lossless</dfn>
</dt>
<dd>method of data compression that permits reconstruction of the original data exactly, bit-for-bit.</dd>
<!-- Maintain a fragment named "3luminance" to preserve incoming links to it -->
<dt id="3luminance"><dfn>luminance</dfn>
</dt>
<dd>
an objective measurement of the visible light intensity, taking into account the sensitivity of the human eye to different wavelengths.
<p class="note">Luminance and <a>chromaticity</a> together fully define a measured color. See <a href="https://colorusage.arc.nasa.gov/lum_and_chrom.php">Luminance and Chromaticity</a>
or, for a formal definition [[COLORIMETRY]].</p>
</dd>
<!-- Maintain a fragment named "3LZ77" to preserve incoming links to it -->
<dt><dfn id="3LZ77">LZ77</dfn>
</dt>
<dd>data compression algorithm described in [[Ziv-Lempel]].</dd>
<dt><dfn>narrow-range image</dfn>
</dt>
<dd>Image where reference black and white do not correspond, respectively, to sample values <code>0</code> and
<code>2<sup>bit depth</sup> - 1</code>.</dd>
<!-- Maintain a fragment named "3networkByteOrder" to preserve incoming links to it -->
<dt id="3networkByteOrder"><dfn>network byte order</dfn>
</dt>
<dd>
<a>byte order</a> in which the most significant byte comes first, then the less significant bytes in descending order of
significance (MSB LSB for two-byte integers, MSB B2 B1 LSB for four-byte integers).
</dd>
<dt>perceptual quantizer (<dfn>PQ</dfn>)
</dt>
<dd>
<a>transfer function</a> defined in [[ITU-R-BT.2100]] Table 4. (An absolute display-referred system.)
<p class="note">
Only RGB may be used in PNG, ICtCp is NOT supported.
</p>
</dd>
<!-- Maintain a fragment named "3PNGdecoder" to preserve incoming links to it -->
<dt id="3PNGdecoder">PNG decoder</dt>
<dd>
process or device that reconstructs the <a>reference image</a> from a <a>PNG datastream</a> and generates a
corresponding <a>delivered image</a>.
</dd>
<!-- Maintain a fragment named "3PNGeditor" to preserve incoming links to it -->
<dt id="3PNGeditor"><dfn>PNG editor</dfn>
</dt>
<dd>
process or device that creates a modification of an existing <a>PNG datastream</a>, preserving unmodified ancillary
information wherever possible, and obeying the <a>chunk</a> ordering rules, even for unknown chunk types.
</dd>
<!-- Maintain a fragment named "3PNGencoder" to preserve incoming links to it -->
<dt id="3PNGencoder">PNG encoder
</dt>
<dd>
process or device which constructs a <a>reference image</a> from a <a>source image</a>, and generates a <a>PNG
datastream</a> representing the reference image.
</dd>
<!-- Maintain a fragment named "3PNGfile" to preserve incoming links to it -->
<dt id="3PNGfile">PNG file
</dt>
<dd>
<a>PNG datastream</a> stored as a file.
</dd>
<!-- Maintain a fragment named "3PNGfourByteUnSignedInteger" to preserve incoming links to it -->
<dt id="3PNGfourByteUnSignedInteger"><dfn>PNG four-byte unsigned integer</dfn>
</dt>
<dd>
<p>a four-byte unsigned integer limited to the range 0 to 2<sup>31</sup>-1.</p>
<p class="note">The restriction is imposed in order to accommodate languages that have difficulty with unsigned four-byte
values.</p>
</dd>
<dt id="3PNGtwoByteUnSignedInteger"><dfn>PNG two-byte unsigned integer</dfn>
</dt>
<dd>
<p>a two-byte unsigned integer in network byte order.</p>
</dd>
<!-- Maintain a fragment named "3sample" to preserve incoming links to it -->
<dt id="3sample"><dfn>sample</dfn>
</dt>
<dd>
intersection of a <a>channel</a> and a <a>pixel</a> in an image.
</dd>
<!-- Maintain a fragment named "3sampleDepth" to preserve incoming links to it -->
<dt id="3sampleDepth">sample depth</dt>
<dd>
number of bits used to represent a <a>sample</a> value.
</dd>
<!-- Maintain a fragment named "3scanline" to preserve incoming links to it -->
<dt id="3scanline"><dfn>scanline</dfn>
</dt>
<dd>
row of <a>pixels</a> within an image or <a>interlaced PNG image</a>.
</dd>
<dt>standard dynamic range (<dfn>SDR</dfn>)
</dt>
<dd>
an image format capable of storing images with a relatively low dynamic range of 5-8 <a>stops</a>. Examples include [[SRGB]], [[Display-P3]], [[ITU-R-BT.709]].
<p class="note">Standard dynamic range is independent of the primaries and hence, gamut. Wide color gamut <a>SDR</a> formats are supported by PNG.</p></dd>
<dt><dfn>stop</dfn>
</dt>
<dd>
a change in scene light luminance of a factor of 2.
</dd>
<dt><dfn>transfer function</dfn>
</dt>
<dd>function relating image luminance with image samples.</dd>
<!-- Maintain a fragment named "3whitePoint" to preserve incoming links to it -->
<dt id="3whitePoint"><dfn>white point</dfn>
</dt>
<dd>
<a>chromaticity</a> of a computer display's nominal white value.
</dd>
<!-- Maintain a fragment named "3zlib" to preserve incoming links to it -->
<dt id="3zlib"><dfn>zlib</dfn>
</dt>
<dd>
<p><a>deflate</a>-style compression method.</p>
<p>SOURCE: [[rfc1950]]</p>
<p class="note">Also refers to the name of a library containing a sample implementation of this method.</p>
</dd>
<!-- Maintain a fragment named "3CRC" to preserve incoming links to it -->
<dt id="3CRC">Cyclic Redundancy Code</dt>
<dt><abbr title="Cyclic Redundancy Code">CRC</abbr></dt>
<dd>
<p>type of check value designed to detect most transmission errors.</p>
<p class="note">A decoder calculates the CRC for the received data and checks by comparing it to the CRC calculated by
the encoder and appended to the data. A mismatch indicates that the data or the CRC were corrupted in transit.</p>
</dd>
<!-- Maintain a fragment named "3CRT" to preserve incoming links to it -->
<dt id="3CRT">Cathode Ray Tube</dt>
<dt><abbr title="Cathode Ray Tube">CRT</abbr></dt>
<dd>vacuum tube containing one or more electron guns, which emit electron beams that are manipulated to display images on a
phosphorescent screen.</dd>
<dt>Electro-Optical Transfer Function</dt>
<dt>
<abbr title="Electro-Optical Transfer Function"><dfn>EOTF</dfn></abbr>
</dt>
<dd>The <a>transfer function</a> between the electrical or digital domain and light energy. It defines the amount of light emitted by a display for a given input signal.</dd>
<!-- Maintain a fragment named "3LSB" to preserve incoming links to it -->
<dt id="3LSB">Least Significant Byte</dt>
<dt><abbr title="Least Significant Byte">LSB</abbr></dt>
<dd>
Least significant byte of a multi-<a>byte</a> value.
</dd>
<!-- Maintain a fragment named "3MSB" to preserve incoming links to it -->
<dt id="3MSB">Most Significant Byte</dt>
<dt><abbr title="Most Significant Byte">MSB</abbr></dt>
<dd>
Most significant byte of a multi-<a>byte</a> value.
</dd>
<dt>Opto-Electrical Transfer Function</dt>
<dt>
<abbr title="Opto-Electrical Transfer Function"><dfn>OETF</dfn></abbr>
</dt>
<dd>The <a>transfer function</a> between light energy and the electrical or digital domain. It defines the amount of light in a scene required to produce a given output signal.</dd>
</dl>
</section>
<section>
<!-- Maintain a fragment named "4Concepts" to preserve incoming links to it -->
<h2 id="4Concepts">Concepts</h2>
<section>
<h2>Static and Animated images</h2>
<p>All PNG images contain a single <dfn>static image</dfn>.</p>
<p>Some PNG images — called <dfn class="lint-ignore">Animated PNG</dfn> (<abbr title="Animated PNG">APNG</abbr>) — also
contain a frame-based animation sequence, the <dfn>animated image</dfn>. The first frame of this may be — but need not be —
the <a>static image</a>. Non-animation-capable displays (such as printers) will display the <a>static image</a> rather than
the animation sequence.</p>
<p>The <a>static image</a>, and each individual frame of an <a>animated image</a>, corresponds to a <em>reference image</em>
and is stored as a <em>PNG image</em>.</p>
</section>
<section>
<!-- Maintain a fragment named "4Concepts.Sourceimage" to preserve incoming links to it -->
<h2 id="4Concepts.Sourceimage">Images</h2>
<p>This specification specifies the PNG datastream, and places some requirements on PNG encoders, which generate PNG
datastreams, PNG decoders, which interpret PNG datastreams, and <a>PNG editors</a>, which transform one PNG datastream into
another. It does not specify the interface between an application and either a PNG encoder, decoder, or editor. The precise
form in which an image is presented to an encoder or delivered by a decoder is not specified. Four kinds of image are
distinguished.</p>
<dl>
<!-- Maintain a fragment named "3sourceImage" to preserve incoming links to it -->
<dt><dfn id="3sourceImage">Source image</dfn></dt>
<dd>The <i>source image</i> is the image presented to a PNG encoder.</dd>
<!-- Maintain a fragment named "3referenceImage" to preserve incoming links to it -->
<!-- Maintain a fragment named "3pixel" to preserve incoming links to it -->
<dt><dfn id="3referenceImage">Reference image</dfn></dt>
<dd>The <a>reference image</a>, which only exists conceptually, is a rectangular array of rectangular <dfn id="3pixel">pixels</dfn>, all having
the same width and height, and all containing the same number of unsigned integer samples, either three (red, green, blue)
or four (red, green, blue, alpha). The array of all samples of a particular kind (red, green, blue, or alpha) is called a
<!-- Maintain a fragment named "3channel" to preserve incoming links to it -->
<dfn id="3channel">channel</dfn>. Each channel has a sample depth in the range 1 to 16, which is the number of bits used by every sample in the
channel. Different channels may have different sample depths. The red, green, and blue samples determine the intensities of
the red, green, and blue components of the pixel's color; if they are all zero, the pixel is black, and if they all have
<!-- Maintain a fragment named "3alpha" to preserve incoming links to it -->
their maximum values (2<sup>sampledepth</sup>-1), the pixel is white. The <dfn id="3alpha">alpha</dfn> sample determines a pixel's degree of
opacity, where zero means fully transparent and the maximum value means fully opaque. In a three-channel reference image
all pixels are fully opaque. (It is also possible for a four-channel reference image to have all pixels fully opaque; the
difference is that the latter has a specific alpha sample depth, whereas the former does not.) Each horizontal row of
pixels is called a scanline. Pixels are ordered from left to right within each scanline, and scanlines are ordered from top
to bottom. Every reference image can be represented exactly by a <a>PNG datastream</a> and every <a>PNG datastream</a> can be converted into a reference image. A PNG encoder may transform the source image directly into a PNG image, but conceptually it first transforms the
source image into a reference image, then transforms the reference image into a PNG image. Depending on the type of source
image, the transformation from the source image to a reference image may require the loss of information. That
transformation is beyond the scope of this International Standard. The reference image, however, can always be recovered
exactly from a PNG datastream.</dd>
<!-- Maintain a fragment named "3PNGimage" to preserve incoming links to it -->
<dt><dfn id="3PNGimage">PNG image</dfn></dt>
<dd>The <i>PNG image</i> is obtained from the reference image by a series of transformations: <a>alpha separation</a>,
<a>indexing</a>, <a>RGB merging</a>, <a>alpha compaction</a>, and <a>sample depth scaling</a>. Five types of PNG image are defined
(see <a href="#6Colour-values"></a>). (If the PNG encoder actually transforms the source image directly into the PNG image,
and the source image format is already similar to the PNG image format, the encoder may be able to avoid doing some of
these transformations.) Although not all sample depths in the range 1 to 16 bits are explicitly supported in the PNG image,
the number of significant bits in each channel of the reference image may be recorded. All channels in the PNG image have
the same sample depth. A PNG encoder generates a PNG datastream from the PNG image. A PNG decoder takes the PNG datastream
and recreates the PNG image.
</dd>
<!-- Maintain a fragment named "3deliveredImage" to preserve incoming links to it -->
<dt><dfn id="3deliveredImage">Delivered image</dfn></dt>
<dd>The <a>delivered image</a> is constructed from the PNG image obtained by decoding a PNG datastream. No specific format
is specified for the <a>delivered image</a>. A viewer presents an image to the user as close to the appearance of the
original source image as it can achieve.
</dd>
</dl>
<p>The relationships between the four kinds of image are illustrated in <a href="#image-relationship"></a>.</p>
<figure id="image-relationship">
<!-- Maintain a fragment named "figure41" to preserve incoming links to it -->
<object id="figure41" data="figures/image-relationships.svg" type="image/svg+xml">
</object>
<figcaption>
Relationships between source, reference, PNG, and display images
</figcaption>
</figure>
<p>The relationships between samples, channels, pixels, and sample depth are illustrated in <a href=
"#sample-pixel-channel-relationship"></a>.</p>
<figure id="sample-pixel-channel-relationship">
<!-- Maintain a fragment named "figure42" to preserve incoming links to it -->
<object id="figure42" data="figures/sample-pixel-channel-relationship.svg" type="image/svg+xml" width="640" height="290">
</object>
<figcaption>
Relationships between sample, sample depth, pixel, and channel
</figcaption>
</figure>
</section>
<!-- Maintain a fragment named "4Concepts.ColourSpaces" to preserve incoming links to it -->
<section id="4Concepts.ColourSpaces">
<h2>Color spaces</h2>
<p>The RGB color space in which color samples are situated may be specified in one of four ways:</p>
<!-- <ol start="1"> -->
<ol>
<li>by CICP image format signaling metadata;</li>
<li>by an ICC profile;</li>
<li>by specifying explicitly that the color space is sRGB when the samples conform to this color space;</li>
<li>by specifying a <a>gamma value</a> and the 1931 CIE <i>x,y</i> chromaticities of the red, green, and blue primaries
used in the image and the reference <a>white point</a>.
</li>
</ol>
<p>For high-end applications the first two methods provides the most flexibility and control. The third method enables one
particular, but extremely common, color space to be indicated. The fourth method, which was standardized before ICC profiles
were widely adopted, enables the exact chromaticities of the RGB data to be specified, along with the <a>gamma</a> correction
to be applied (see <a href="#C-GammaAppendix"></a>). However, color-aware applications will prefer one of the first three
methods, while color-unaware applications will typically ignore all four methods.</p>
<p><a href="#color-chunk-precendence"></a> is a list of chunk types that provide color space information,
each with an associated Priority number. If a single image contains more than one of these chunk types,
the chunk with the lowest Priority number should take precedence and any higher-numbered chunk types should be ignored.</p>
<table id="color-chunk-precendence" class="numbered simple">
<caption>
Color Chunk Priority
</caption>
<tr>
<th>Chunk Type</th>
<th>Priority</th>
</tr>
<tr>
<td><a href="#cICP-chunk" class="chunk">cICP</a></td>
<td>1</td>
</tr>
<tr>
<td><a class="chunk" href="#11iCCP">iCCP</a></td>
<td>2</td>
</tr>
<tr>
<td><a class="chunk" href="#11sRGB">sRGB</a></td>
<td>3</td>
</tr>
<tr>
<td><a class="chunk" href="#11cHRM">cHRM</a> and <a class="chunk" href="#11gAMA">gAMA</a></td>
<td>4</td>
</tr>
</table>
<p><a>Gamma</a> correction is not applied to the alpha channel, if present. Alpha samples are always full-range and represent
a linear fraction of full opacity.</p>
<p>Mastering metadata may also be provided.</p>
</section>
<!-- Maintain a fragment named "4Concepts.PNGImageTransformation" to preserve incoming links to it -->
<section id="4Concepts.PNGImageTransformation">
<h2>Reference image to PNG image transformation</h2>
<!-- Maintain a fragment named "4Concepts.Introduction" to preserve incoming links to it -->
<section class="introductory" id="4Concepts.Introduction">
<h3>Introduction</h3>
<p>A number of transformations are applied to the reference image to create the PNG image to be encoded (see <a href=
"#reference-to-png-transformation"></a>). The transformations are applied in the following sequence, where square brackets
mean the transformation is optional:</p>
<pre>
[alpha separation]
indexing or ( [RGB merging] [alpha compaction] )
sample depth scaling
</pre>
<p>When every pixel is either fully transparent or fully opaque, the <a>alpha separation</a>, <a>alpha compaction</a>, and
<a>indexing</a> transformations can cause the recovered reference image to have an alpha sample depth different from the
original reference image, or to have no alpha channel. This has no effect on the degree of opacity of any pixel. The two
reference images are considered equivalent, and the transformations are considered lossless. Encoders that nevertheless
wish to preserve the alpha sample depth may elect not to perform transformations that would alter the alpha sample
depth.</p>
<figure id="reference-to-png-transformation">
<!-- Maintain a fragment named "figure43" to preserve incoming links to it -->
<object id="figure43" data="figures/reference-to-png-transformation.svg" type="image/svg+xml" height="525" width="370">
</object>
<figcaption>
Reference image to PNG image transformation
</figcaption>
</figure>
</section>
<!-- Maintain a fragment named "4Concepts.Implied-alpha" to preserve incoming links to it -->
<section id="4Concepts.Implied-alpha">
<!-- Maintain a fragment named "3alphaSeparation" to preserve incoming links to it -->
<h2><dfn id="3alphaSeparation">Alpha separation</dfn></h2>
<p>If all alpha samples in a reference image have the maximum value, then the alpha channel may be omitted, resulting in an
equivalent image that can be encoded more compactly.</p>
</section>
<!-- Maintain a fragment named "4Concepts.Indexing" to preserve incoming links to it -->
<section id="4Concepts.Indexing">
<h2>Indexing</h2>
<p>If the number of distinct pixel values is 256 or less, and the RGB sample depths are not greater than 8, and the alpha
channel is absent or exactly 8 bits deep or every pixel is either fully transparent or fully opaque, then the alternative
<a>indexed-color</a> representation, achieved through an <dfn id="3indexing">indexing</dfn> transformation, may be more efficient for encoding.
<!-- Maintain a fragment named "3indexing" to preserve incoming links to it -->
<!-- Maintain a fragment named "3palette" to preserve incoming links to it -->
<!-- Maintain a fragment named "3alphaTable" to preserve incoming links to it -->
<!-- Maintain a fragment named "3indexedColour" to preserve incoming links to it -->
In the <dfn id="3indexedColour">indexed-color</dfn> representation, each pixel is replaced by an index into a palette. The <dfn id="3palette">palette</dfn>
is a list of entries each containing three 8-bit samples (red, green, blue). If an alpha channel is present, there is also
a parallel table of 8-bit alpha samples, called the <dfn id="3alphaTable">alpha table</dfn>.</p>
<figure id="indexed-colour-image">
<!-- Maintain a fragment named "figure44" to preserve incoming links to it -->
<object id="figure44" height="450" width="660" data="figures/indexed-colour-image.svg" type="image/svg+xml">
</object>
<figcaption>
Indexed-color image
</figcaption>
</figure>
<p>A suggested palette or palettes may be constructed even when the PNG image is not <a>indexed-color</a> in order to assist
viewers that are capable of displaying only a limited number of colors.</p>
<p>For <a>indexed-color</a> images, encoders can rearrange the palette so that the table entries with the maximum alpha value are
grouped at the end. In this case the table can be encoded in a shortened form that does not include these entries.</p>
<p>Encoders creating indexed-color PNG must not insert index values greater than the actual length of the palette table; to
do so is an error, and decoders will vary in their handling of this error.</p>
</section>
<!-- Maintain a fragment named "4Concepts.RGBMerging" to preserve incoming links to it -->
<section id="4Concepts.RGBMerging">
<!-- Maintain a fragment named "3RGBmerging" to preserve incoming links to it -->
<h2><dfn id="3RGBmerging">RGB merging</dfn>
</h2>
<p>If the red, green, and blue channels have the same sample depth, and, for each pixel, the values of the red, green, and
blue samples are equal, then these three channels may be merged into a single greyscale channel.</p>
</section>
<!-- Maintain a fragment named "4Concepts.Alpha-indexing" to preserve incoming links to it -->
<section id="4Concepts.Alpha-indexing">