This file is indexed.

/usr/share/doc/png-definitive-guide/html/chapter01.html is in png-definitive-guide 20060430-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>An Introduction to PNG (PNG: The Definitive Guide)</TITLE>
<!-- META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1" -->
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

<!-- http://www.w3.org/TR/REC-CSS2/box.html -->
<STYLE TYPE="text/css">
  P { margin-bottom: 0em }
  UL {
    margin-bottom: 0em;
    margin-top: 0em;
    list-style: disc;
  }
  LI {
    padding: 0px 0px 0px 0px;
    margin: 0px 0px 0px 0px;
  }
</STYLE>

<LINK REV="made" HREF="http://pobox.com/~newt/greg_contact.html">
<!--  Copyright (c) 1999 O'Reilly and Associates.  -->
<!--  Copyright (c) 2002-2006 Greg Roelofs.  -->
</HEAD>

<body bgcolor="#ffffff" text="#000000">


<hr> <!-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -->

<a href="preface.html"><img width=24 height=13 border=0 align="left"
 src="images/prev.png" alt="&lt;-"></a>

<a href="chapter02.html"><img width=24 height=13 border=0 align="right"
 src="images/next.png" alt="-&gt;"></a>

<div align="center">
  <a href="preface.html"><font size="-1" color="#000000"
   ><b>PREVIOUS</b></font></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
     href="toc.html"><font size="-1" color="#000000"
   ><b>CONTENTS</b></font></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
     href="chapter02.html"><font size="-1" color="#000000"
   ><b>NEXT</b></font></a>
</div>

<hr> <!-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -->


<h1 class="chapter">Chapter 1. An Introduction to PNG</h1>

<div class="htmltoc"><h4 class="tochead">Contents:</h4><p>
<a href="#png.ch01.div.1">1.1. Overview of Image Properties</a><br />
<a href="#png.ch01.div.2">1.2. What Is PNG Good For?</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.1">1.2.1. Alpha Channels</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.2">1.2.2. Gamma and Color Correction</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.3">1.2.3. Interlacing and Progressive Display</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.4">1.2.4. Compression</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.4.1">1.2.4.1. Compression filters</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.4.2">1.2.4.2. Compression oopers</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.2.5">1.2.5. Summary of Usage</a><br />
<a href="#png.ch01.div.3">1.3. Case Study of a PNG-Supporting Image Editor</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.3.1">1.3.1. PNG Feature Support in Fireworks</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.3.2">1.3.2. Invoking PNG Features in Fireworks</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.3.3">1.3.3. Analysis of Fireworks PNG Support</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch01.div.3.4">1.3.4. Concluding Thoughts on Fireworks</a><br />
</p></div>





<p>PNG,<a href="#FOOTNOTE-1">[1]</a>
short for ``Portable Network Graphics,'' is a computer file format for
storing, transmitting, and displaying images. Similar to the GIF and TIFF
image formats--in fact, designed to replace them in many applications--PNG
supports lossless compression, transparency information, and a range of color
depths. PNG also supports more advanced features such as gamma correction and
a standard color space for precise reproduction of image colors on a wide range
of systems and embedded textual information for storing such things as a title,
the author's name, and explicit copyright.
</p>

<blockquote class="footnote">
<a name="FOOTNOTE-1" />
<p>[1] PNG is officially pronounced ``ping'' (at least in English) but never
spelled that way. Yes, this was a major topic of discussion during its
design, and it is explicitly noted in the specification. Believe it or
not, in November 1998 the issue once again came under discussion, this
time with greater emphasis on non-English pronunciation. Though the
``three-letter'' approach (i.e., <em class="emphasis">P-N-G</em> spoken as
three separate letters) was not approved for inclusion in the spec, it may
be considered an acceptable unofficial alternative.</p>
</blockquote>


<p>In this chapter, we'll consider PNG from the perspective of a user who has
some familiarity with the process of creating and using computer images, but
insufficient knowledge of the technical differences between various formats
to be certain when to use what. I won't dwell on features that are mostly
of concern to developers; where I do bring up programming issues, it is
principally to explain to the <em class="emphasis">user</em> why some software may not perform
as well as expected. I'll concentrate on two areas to which PNG is particularly
well suited: as an intermediate editing format for repeatedly saving and
restoring images without loss, and as a final display format for the World
Wide Web. And I'll finish up with an in-depth look at one application that
has particularly good PNG support: Macromedia's Fireworks 1.0, an
image-editing program specifically designed for creating web images.</p>


<div class="sect1"><a name="png.ch01.div.1" />
<h2 class="sect1">1.1. Overview of Image Properties</h2>


<p><a name="INDEX-1" /><!-- image properties -->
Before we dive right into some of PNG's more interesting features, it might
be helpful to introduce (or review) some essential image concepts and take a
quick look at a few older image formats. Those who are already familiar
with the most basic features of computer images can skip directly to the
next section.</p>


<p><a name="INDEX-2" />
<a name="INDEX-3" />
There are two main formats for computer images: raster, based on colored dots,
which are almost always stored in a rectangular array and are usually packed
so close together that individual dots are no longer distinguishable, and vector, based on lines, circles, and other ``primitive'' elements that typically
cover a sizable area and are easily distinguishable from one another. Many images can be represented in either format; indeed, any
vector-based image can be approximated by a raster image (lots of dots), and
one could easily (though tediously) simulate a raster image in vector format
by converting each dot to a tiny box.</p>


<p>The whole point of having two classes of image formats--and, indeed,
of having numerous individual file formats--is implicit in the old saying,
``Use the best tool for the job.'' Vector formats are appropriate for simple
graphics and text, such as corporate logos, and their advantage is that they
can be extremely compact and yet maintain perfect sharpness regardless of
the size at which they are reproduced. But with the exception of pen-based
plotters and some ancient vector-based displays, the end result is almost
always a raster image.</p>


<p>For that reason, plus the fact that raster image formats are more common--and
because PNG is one of them--we'll take a closer look at raster features.
<a name="INDEX-4" />
As I just noted, a raster image is composed of an array of dots, more
commonly referred to as <em class="emphasis">pixels</em> (short for <em class="emphasis">picture elements</em>).
One generally refers to a computer image's dimensions in terms of pixels;
this is also often (though slightly imprecisely) known as its
<a name="INDEX-5" />
<em class="emphasis">resolution</em>. Some common image sizes are 640&nbsp;&times; 480, 800&nbsp;&times; 600,
and 1024&nbsp;&times; 768 pixels, which also happen to be common dimensions for
computer displays.</p>


<p><a name="INDEX-6" />
<a name="INDEX-7" />
<a name="INDEX-8" />
In addition to horizontal and vertical dimensions, a raster image is
characterized by depth. The deeper the image, the more colors (or shades
<a name="INDEX-9" />
of gray) it can have. Pixel depths are measured in <em class="emphasis">bits</em>, the tiniest
units of computer storage; a 1-bit image can represent two colors (often,
though not necessarily, black and white), a 2-bit image four colors, an
8-bit image 256 colors, and so on. To calculate the raw size of the
image data before any compression takes place, one needs only to know that
8 bits make a byte. Thus a 320&nbsp;&times; 240, 24-bit image has 76,800 pixels,
each of which is 3 bytes deep, so its total uncompressed size is
230,400 bytes.</p>


<p>I'll return to the topic of compression in just a moment; first, let's take a
closer look at the precise relationship between pixels and colors. Within the
broad class of raster formats, there are three main image types: indexed-color,
grayscale, and truecolor. The <em class="emphasis">indexed-color</em> method, also known as
<a name="INDEX-10" />
<a name="INDEX-11" />
<a name="INDEX-12" />
<a name="INDEX-13" />
<em class="emphasis">pseudocolor</em>, <em class="emphasis">colormapped</em>, or <em class="emphasis">palette-based</em>, stores a copy of
each color value
needed for the image in a palette. The main image is then composed of index
values referring to different entries in the palette. For example, imagine an
image composed entirely of red, white, and blue pixels; the palette would have
three entries corresponding to these colors, and each pixel would be
represented by the value 0, 1, or 2. (The natural starting point for numbers
on a computer is 0, not 1.) Since an image 2 bits deep
can represent up to four colors, each pixel in this example would require
only 2 bits, even though the precise shades of red, white, and blue might
ordinarily require 24 bits each.</p>


<p><a name="INDEX-14" />
Grayscale and truecolor images are simpler in concept; the bytes used by
each pixel correspond directly to shades of gray or to colors. In a
<em class="emphasis">grayscale</em> image of a particular pixel depth, a 0 pixel usually
(though not always) means black, while the maximum value at that depth
corresponds to white. Intermediate pixel values are smoothly interpolated
to shades of gray, though this is often not as straightforward as it might
<a name="INDEX-15" />
sound--<em class="emphasis">gamma correction</em>, a way of adjusting for differences in
computer display systems, comes in here. I'll give a brief overview of
gamma correction later in this chapter, and I'll discuss it at length in <a href="chapter10.html">Chapter 10, "Gamma Correction and Precision Color"</a>,
<em class="emphasis">Gamma Correction and Precision Color</em>;
for now, I'll merely note that it is a Good Thing, and image formats that
provide support for it can be viewed on different platforms without appearing
too light on one and too dark on another.</p>


<p><a name="INDEX-16" />
<a name="INDEX-17" />
A <em class="emphasis">truecolor</em> image uses three separate values for each pixel,
corresponding to shades of red, green, and blue. Such images are often
also referred to as <em class="emphasis">RGB</em>. In <a href="chapter08.html">Chapter 8, "PNG Basics"</a>, I'll talk
about human vision and the reasons why mixtures of just three colors can
appear to reproduce all colors, or at least a sufficiently large percentage
of them that one need not quibble over the difference. I'll also mention
some common alternatives to the RGB <em class="emphasis">color space</em>. To be
considered truly truecolor instead of merely ``high color,'' an image must contain at least 8 bits for each of the three colors in each
pixel; thus, at a minimum, a truecolor image has a depth of 24 bits.</p>


<p><a name="INDEX-18" />
<a name="INDEX-19" />
Two other concepts--samples and channels--are handy when speaking of images,
and RGB images are a good way to illustrate these concepts. A <em class="emphasis">sample</em> is one
component of a single color value. For example, each pixel in a truecolor
image consists of three samples: red, green, and blue. If the image is
24 bits deep, then each sample is 8 bits deep. A 256-shade grayscale image
also has 8-bit samples, which means that one can speak of the ``bits per
sample'' for either image type to indicate the level of precision of each
shade or color. Note that I have been careful to distinguish between
<a name="INDEX-20" />
<a name="INDEX-21" />
<a name="INDEX-22" />
<em class="emphasis">sample depth</em> and <em class="emphasis">pixel depth</em>. The two terms are directly related
in grayscale and truecolor images, but in indexed-color images they can be
independent of each other. This is because the sample depth refers to the
color values in the palette, while the pixel depth refers to the index values
of each pixel (which reference the palette colors). To put it more concretely,
the color values in the palette are usually 24-bit values (8 bits per
sample), but the pixel indices are usually 8 bits or less.
Our previous red, white, and blue example used only two bits per pixel.</p>


<p>A <em class="emphasis">channel</em>, on the other hand, refers to the collection of all
samples of a given type in an image--for example, the green
components of every RGB pixel. Thus a truecolor image has three
channels, while a grayscale image has only one. (Ordinarily one does
not speak of a palette-based image as having channels.) And when
discussing transparency, yet another channel type is often used: the
<a name="INDEX-23" />
<a name="INDEX-24" />
<a name="INDEX-25" />
<em class="emphasis">alpha channel</em>. This is a special kind of channel in that it does
not provide actual color information but rather a level of
transparency for each pixel--or, more precisely, a level of
<a name="INDEX-26" />
<a name="INDEX-27" />
<em class="emphasis">opacity</em>, since it is most common for the maximum sample value to
indicate that the pixel is completely opaque and for zero to indicate
complete transparency. A truecolor image with an alpha channel is
often called an RGBA image; grayscale images with alpha channels are
rarer and don't have a special abbreviation (although I may refer to
them as ``gray+alpha'').</p>


<p>Palette-based images almost never have a full alpha channel, but another
type of transparency is possible. Rather than associate alpha
information with every pixel, one can instead associate it with specific
palette entries. By far the most common approach is to specify that a single
palette entry represents complete transparency. Then when the image is
displayed against some sort of background, any pixel whose index refers to
this particular palette entry will be replaced by the background at the pixel's
location--or perhaps the pixel simply will not be drawn in the first place.
But there is no conceptual requirement that only one palette entry can have
transparency, nor that it must be fully transparent. As we'll see shortly,
PNG effectively allows any number of palette entries to have any level of
transparency.</p>


<p><a name="INDEX-28" />
<a name="INDEX-29" />
While we're on the subject of colormapped images, two other concepts are worth
mentioning: quantization and dithering. Suppose one has a 24-bit truecolor
image, but it must be displayed on a 256-color, palette-based display.
Since truecolor images typically use anywhere from 10,000 to 100,000
colors, the conversion to a colormapped image will involve substituting many
of the color values with a much smaller range of colors. This process is
known as <em class="emphasis">quantization</em>. Because the resulting images have such a limited
palette of colors available to them, they often are unable to represent fine
color gradients such as the different shades of blue seen in the sky or the
range of facial tones in a softly lit portrait. One way around this is to
<em class="emphasis">dither</em> the image, which is a means of mixing pixels of the available
colors together to give the appearance of other colors (though generally at
the cost of some sharpness). For example, a checkerboard pattern of
alternating red and yellow pixels might appear orange. This effect is
perhaps best illustrated with an example. 
<a href="#png.ch01.fig.1">Figure 1-1</a> shows a truecolor
photograph (here rendered in grayscale) together with two 256-color versions
of the same image--one simply quantized to 256 colors and the other both
quantized and dithered. The insets give a magnified view of one region,
showing the relative effects of the two procedures.
</p>


<!--
<a name="png.ch01.fig.1" />
<div class="figure">
<img src="figs/png.0101.png" alt="Figure 1-1" />
</div>
<h4 class="objtitle">Figure 1-1. Original, 24-bit image (a); same image after quantization (b) and after quantization and dithering (c)
</h4>
 -->

<a name="png.ch01.fig.1" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <img width=502 height=335 border=0
       src="figs/png.0101.edit.png" alt="Figure 1-1" usemap="#png.0101" /><br>
      <br>
      <b>Figure 1-1:</b>  <i>(a) Original, 24-bit image; (b) same image after
      quantization, and (c) after quantization and dithering.</i>
      <FONT SIZE="-1">(Click on images for full-scale, color versions.)</FONT>

    </td>
  </tr>
</table>
</p>
</div>

<map name="png.0101">
   <area shape="rect" coords="135,14,364,157" href="figs/png.0101a.big.png"
    alt="original, 24-bit image">
   <area shape="rect" coords="16,170,245,313" href="figs/png.0101b.big.png"
    alt="8-bit quantized image">
   <area shape="rect" coords="255,170,484,313" href="figs/png.0101c.big.png"
    alt="8-bit quantized and dithered image">
   <area shape="default" nohref>
</map>

<p><a name="INDEX-30" />
<a name="INDEX-31" />
I'll round out our review of image properties and concepts with
a quick look at compression. There are really only two flavors: lossless
and lossy. <em class="emphasis">Lossless</em> compression preserves the exact image data down
to the last bit, so that what you get out after uncompressing is exactly the
same as what you started with. In contrast, <em class="emphasis">lossy</em> compression throws
away some of the data in return for much better compression ratios. For
photographic images, the best lossless methods may only manage a factor of
two or three in compression, whereas lossy methods typically achieve anywhere
from 8 to 25 times reduction with very little visible loss of quality.
I'll discuss the details of compression, particularly the lossless variety,
at greater length in <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>.</p>


<p>Finally, in describing the advantages of PNG, I will necessarily compare
it with some older image formats. Although there are literally
hundreds of different formats, we will be most concerned with just three:
<a name="INDEX-32" />
<a name="INDEX-33" />
<a name="INDEX-34" />
GIF, JPEG, and TIFF. GIF, short for the Graphics Interchange Format,
and JPEG, short for the Joint Photographic Experts Group (which defined
the format), are both very common image types often seen on the 
Web. TIFF, on the other hand, short for Tagged Image File Format, is
almost never used on the Web but is quite popular as an output format from
scanners and as an intermediate ``save format'' while editing images. I'll
touch on the properties of each of these formats as we go.
<a name="INDEX-35" /></p>
</div>

















</div>
<div class="sect1"><a name="png.ch01.div.2" />
<h2 class="sect1">1.2. What Is PNG Good For?</h2>


<p><a name="INDEX-36" />
For image editing, either professional or otherwise, PNG provides a useful
format for storing the intermediate stages of an image. Since PNG's
compression is fully lossless--and since it supports up to 48-bit truecolor
or 16-bit grayscale--saving, restoring, and resaving an image will not
degrade its quality, unlike standard JPEG (even at its highest quality
settings). PNG also supports full transparency information, unlike JPEG
(no transparency at all), GIF (no partial transparency), or even TIFF (full
transparency is part of the specification but is not required for minimal
conformance). And unlike TIFF, which is probably the most popular intermediate
format today, the PNG specification leaves almost no room for implementors
to pick and choose what features they'll support. What allowances are
made, such as optional support for gamma correction, are tightly constrained.
The result is that a PNG image saved in one application is readable and
displayable in any other PNG-supporting program.</p>


<p><a name="INDEX-37" />
For the Web, as of early 1999, there are two image formats with ubiquitous
support: JPEG and GIF. JPEG is very well suited to the task for which it was
designed--namely, the storage, transmission, and display of photorealistic
8-bit grayscale and 24-bit truecolor images with good quality and
excellent compression--and PNG was never intended to compete with JPEG on
its own terms. But PNG, like GIF, is more appropriate than JPEG for images with
few colors or with lots of sharp edges, such as cartoons or bitmapped text.
PNG also provides direct support for gamma correction (loosely speaking, the
cross-platform control of image ``brightness'') and transparency. I'll
discuss these in more detail shortly.</p>


<p><a name="INDEX-38" />
GIF was the original cross-platform image format for the Web, and it is still
a good choice in many respects. But PNG was specifically designed to replace
GIF, and it has three main advantages over the older format: alpha channels
(variable transparency), gamma correction, and two-dimensional interlacing
(a method of displaying images at progressively higher levels of detail).
PNG also compresses better than GIF in almost every case, but the difference
is generally only around 5% to 25%, which is (usually) not a large enough factor to
encourage one to switch on that basis alone. One GIF feature that PNG does
<em class="emphasis">not</em> try to reproduce is multiple-image support, especially animations;
PNG was and is intended to be a single-image format only. A very PNG-like
extension format called MNG has been developed 
<?x-need 15?>to address this limitation; it
is discussed in <a href="chapter12.html">Chapter 12, "Multiple-Image Network Graphics"</a>.


</p>


<a name="png.ch01.div.2.1" /><div class="sect2">
<h3 class="sect2">1.2.1. Alpha Channels</h3>


<p><a name="INDEX-39" />
<a name="INDEX-40" />
<a name="INDEX-41" />
Also known as a <em class="emphasis">mask channel</em>, an alpha channel is simply a way to
associate variable levels of transparency (sometimes referred to as ``translucency,'' though that may imply a diffuseness not present with alpha
transparency) with an image.
Whereas GIF supports simple binary transparency--any given pixel can be
either fully transparent or fully opaque--PNG allows an additional 254
levels of partial transparency for ``normal'' images. It also supports a
total of 65,536 transparency levels for the special ``deeply insane'' image
types, but here we're concentrating on pixel depths that are useful on the Web.</p>


<p>All three of the basic PNG image types--RGB, grayscale, and
palette-based--can have alpha information, but currently it's most often
used with truecolor images. Instead of storing three bytes for every pixel,
now four are required: red, green, blue, and alpha, or RGBA. The variable
transparency allows one to create special effects that will look good
on <em class="emphasis">any</em> background, whether light, dark, or patterned. For
example, a photo-vignette effect can be created for a portrait by making a
central oval region fully opaque (i.e., for the face and shoulders of the
subject), the outer regions fully transparent, and a transition region that
varies smoothly between the two extremes. When viewed with a web browser
such as Acorn Browse or Arena, the portrait would fade smoothly to white
when viewed against a white background or smoothly to black if against a 
black background. Both cases are shown in 
<a href="#png.ch01.fig.2">Figure 1-2</a>. 
</p>

<a name="png.ch01.fig.2" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <img width=502 height=227 border=0
       src="figs/png.0102.png" alt="Figure 1-2" usemap="#png.0102" /><br>
      <br>
      <b>Figure 1-2:</b>  <i>Portrait with an oval alpha mask (a) against a
      white background and (b) against a black background.</i>
      <FONT SIZE="-1">(Click on images for full-scale versions.)</FONT>

    </td>
  </tr>
</table>
</p>
</div>

<map name="png.0102">
   <area shape="rect"
    coords="29,16,227,203" href="figs/png.0102a.big.png"
    alt="portrait with oval alpha mask against white background">
   <area shape="rect"
    coords="273,16,471,203" href="figs/png.0102b.big.png"
    alt="portrait with oval alpha mask against black background">
   <area shape="default" nohref>
</map>

<p>This feature is especially important for the small web graphics that are
typically used on web pages, such as colored (circular) bullets and fancy
text. To avoid the jagged artifacts that really stand out on such images,
<a name="INDEX-42" />
most applications support <em class="emphasis">anti-aliasing</em>, a method for creating the
illusion of smooth curves on a rectangular grid of pixels by smoothly varying
the pixels' colors. The problem with anti-aliasing in the absence of variable
transparency is that it must be done against a predetermined background color,
typically either white or black. Reusing the same images on a different
<a name="INDEX-43" />
background usually results in an unpleasant ``halo'' effect, as shown
in
<a href="#png.ch01.fig.3">Figure 1-3</a>. The standard approach is to create separate images for each background color used
on a site, but this has negative implications both for the designer, who wastes
time creating and maintaining multiple copies of each image, and for visitors
to the site, who must download those copies.


</p>

<a name="png.ch01.fig.3" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <img width=502 height=272 border=0
       src="figs/png.0103.edit2.png" alt="Figure 1-3" /><br>
      <br>
      <b>Figure 1-3:</b>  <i>Gray text anti-aliased against a white background,
      displayed against both white and black backgrounds.</i>

    </td>
  </tr>
</table>
</p>
</div>

<p>Alpha blending, on the other hand, effectively uses transparency as a
placeholder for the background color. Fully transparent regions will inherit
the background color as is; fully opaque regions will show up as the foreground
images. This is no different from the usual case, exemplified by transparent
GIFs. But the anti-aliased regions in between the fully transparent and fully
opaque areas are no longer pre-mixed with an assumed background color;
instead, they are partially transparent and can be mixed with whatever background
on which the image happens to be placed.</p>


<p>Of course, effective replacements for GIF buttons and icons must not only be
more useful but also of comparable or smaller size, and that mostly rules out
truecolor RGBA images. Fortunately, PNG supports alpha information with
palette images as well; it's just harder to implement in a smart way. A PNG
alpha-palette image is just that: an image whose palette also has alpha
information associated with it, not a palette image with a full alpha mask.
In other words, each pixel corresponds to an entry in the palette with red,
green, blue, <em class="emphasis">and</em> alpha components. So if you want to have bright red
pixels with four different levels of transparency, you must use four separate
palette entries to accommodate them--all four entries will have identical
RGB components, but the alpha values will differ. If you want all of
your colors to have four levels of transparency, you've effectively reduced
your total number of available colors from 256 to 64. In general, though,
only some of the colors need more than one level of transparency, and
recognizing which ones do is where things get tricky for the programmer.<a href="#FOOTNOTE-2">[2]</a>










<a name="INDEX-44" />
<a name="INDEX-45" />
</p><blockquote class="footnote">


<a name="FOOTNOTE-2" /><p>[2] As it happens, the same algorithm that allows one to quantize a 24-bit
truecolor image down to an 8-bit palette image also allows one to reduce a
32-bit RGBA image to an 8-bit palette-alpha image. So it's not really that
tricky for programmers; it's just not how they're used to thinking about
such things.</p>


</blockquote>
</div>








<a name="png.ch01.div.2.2" /><div class="sect2">
<h3 class="sect2">1.2.2. Gamma and Color Correction</h3>


<p><a name="INDEX-46" />
<a name="INDEX-47" />
Gamma correction basically refers to the ability to correct for differences
in how computers (and especially computer monitors) interpret color values.
Web authors in particular are probably aware that Macintosh-generated images
tend to look too dark on PCs, and PC-generated images tend to look too light
and washed out on Macs. An image that looks good on an SGI workstation won't
look right on either a Macintosh or a PC, and even a PC-created image won't
look right on all PCs.</p>


<p>Gamma information is a partial solution. It's a means of associating a 
single number with a computer display system, in an attempt to characterize
the tricky physics lurking within a graphics card's digital-to-analog
converter (RAMDAC) and within a monitor's high-voltage electron gun and
display phosphors. Gamma is only a first approximation that accounts for
overall ``brightness,'' but it is generally sufficient for casual users.
More demanding users will additionally want to adjust for differences in the
<a name="INDEX-48" />
individual red, green, and blue channels--the so-called <em class="emphasis">chromaticity</em>
values, which are also supported by PNG. Even this is merely a second
approximation, however.</p>


<p><a name="INDEX-49" />
The absolute best solution currently available is to use a complete <em class="emphasis">color
management system</em>, which allows one to take into account things like the
viewing environment (a ``dim surround,'' for example) and its interaction
with the human visual system. The International Color Consortium has defined
a profile format that describes the relationship between an input color space
(say, a digital camera or scanner) and the output color space that the user
sees. This is the most general way to account for cross-platform differences
(and, of course, PNG supports it via the iCCP chunk), but its flexibility
comes at a cost: it tends to add at least 250 bytes and often 2,000 bytes
or more to every image.


</p>


<p><a name="INDEX-50" />
<a name="INDEX-51" />
Fortunately, a new proposal for operating systems and physical devices avoids
the overhead of a complete ICC profile. Called <em class="emphasis">sRGB</em>, for Standard RGB
color space, it defines just that: a standard, unified color space that
devices can support, thereby allowing true color management with minimal
file overhead and no need for the user to wade through a complicated end-to-end
calibration procedure. As of January 1999, the sRGB proposal was in
``Committee Draft for Voting,'' and it should be approved as an international
standard<a href="#FOOTNOTE-3">[3]</a>


by mid-1999; conformant devices should start appearing shortly thereafter.
PNG supports sRGB via a chunk called, logically enough, sRGB.</p><blockquote class="footnote">


<a name="FOOTNOTE-3" /><p>[3] sRGB is Part 2 of IEC 61966 (<em class="emphasis">Colour Measurement and Management in Multimedia
Systems and Equipment</em>), a proposed standard of Technical Committee 100 of
<a name="INDEX-52" />
<a name="INDEX-53" />
the International Electrotechnical Commission. The IEC is a standards body
<a name="INDEX-54" />
similar to the International Organization for Standardization (ISO); in fact,
international standards such as MPEG, VRML97, and the Latin-1 character set
are all joint ISO/IEC standards, and PNG is on track to join them.</p>


</blockquote>


<p>Gamma, chromaticity, and color management are described in more detail in
<a href="chapter10.html">Chapter 10, "Gamma Correction and Precision Color"</a>; PNG's basic structure, including the means by which it can be
officially or unofficially extended, is covered in <a href="chapter08.html">Chapter 8, "PNG Basics"</a> and <a href="chapter11.html">Chapter 11, "PNG Options and Extensions"</a>.
































<a name="INDEX-55" />
<a name="INDEX-56" /></p>
</div>








<a name="png.ch01.div.2.3" /><div class="sect2">
<h3 class="sect2">1.2.3. Interlacing and Progressive Display</h3>


<p><a name="INDEX-57" />
<a name="INDEX-58" />
<a name="INDEX-59" />
By now, just about everyone has seen interlaced GIFs in action; they first
show up with a very stretched, blocky appearance and gradually get filled in
until the full-resolution image is displayed. Their big advantage is that
an overall impression of the image is visible after only one-eighth of the
image data has been transferred; gross features such as embedded buttons or
large text are often recognizable (and clickable) even at this stage.</p>


<p>But as useful as GIF's interlacing is, it has one big disadvantage: it
is not symmetric. In other words, while GIF's first pass consists of
one-eighth of the image data, that factor of eight comes entirely at
the expense of vertical resolution. Horizontally, every line is at
full resolution as soon as it is displayed, which means that each
pixel in the first pass is stretched by a factor of eight. Needless to
say, this does make text and other features much harder to recognize
than they really need to be.</p>


<p>PNG's approach to interlacing is two-dimensional and involves no
stretching at all on more than half of its passes. Even-numbered
passes are stretched, but only by a factor of two--similar to the
effect after GIF's third pass. Some applications display only the
odd-numbered PNG passes, so their pixels always appear square. In
addition, PNG's interlacing consists of seven passes, as opposed to
GIF's four. This means that the user will see an overall impression of the
image after only one-
<?x-break ?><?x-new-page ?>sixty-fourth of the data has arrived, eight times
faster than GIF.<a href="#FOOTNOTE-4">[4]</a>


In the time it takes GIF to display its first pass, PNG displays four
passes--and keep in mind that PNG's fourth pass is only one-quarter
as stretched as GIF's first pass, with ``pixels'' that are basically
2&nbsp;&times; 4 blocks instead of 1&nbsp;&times; 8. As a general rule, text
embedded in an interlaced PNG image becomes readable roughly twice as
fast as in the identical interlaced GIF, as shown in 
<a href="#png.ch01.fig.4">Figure 1-4</a>. The rows show the respective appearance after one-sixty-fourth,
one-thirty-second, one-sixteenth, one-eighth, one-fourth, half, and
all of the data has arrived. The first column shows GIF interlacing;
the others show PNG interlacing, rendered in various styles: standard
blocky rendering, interpolated rendering, and sparse rendering,
respectively. Note that the word <em class="emphasis">Interlacing</em> has roughly the
same readability in the fifth GIF row, the fourth blocky PNG row, and
the third interpolated PNG row. In other words, the GIF text takes
two to four times as long to become readable.
</p><blockquote class="footnote">


<a name="FOOTNOTE-4" /><p>[4] I am implicitly assuming that one-sixty-fourth of the compressed data (the
stuff that can be said to ``arrive'') corresponds to one-sixty-fourth of the
<em class="emphasis">uncompressed</em> image data (what the user actually sees). This is not
quite true for either PNG or GIF, though the difference is likely to be small
in most cases--and other factors, such as network buffering, will tend to
wash out any differences that do exist. See <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a> for more details.</p>


</blockquote>


<a name="png.ch01.fig.4" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <a href="figs/png.0104.big.png"><img width=502 height=293 border=0
       src="figs/png.0104.png" alt="Figure 1-4" /></a><br>
      <br>
      <b>Figure 1-4:</b>  <i>Comparison of GIF interlacing (far left), normal
      PNG interlacing (second from left), PNG with interpolation (second from
      right), and PNG with sparse display (far right).</i>
      <FONT SIZE="-1">(Click on image for full-scale version.)</FONT>

    </td>
  </tr>
</table>
</p>
</div>

<p><a name="INDEX-60" />
JPEG doesn't support interlacing, per se, but it does support a method
of progressive display that has been implemented in most browsers since late
1996. In fact, progressive JPEG is a two-dimensional scheme that is not only
visually similar to interlaced PNG but also somewhat superior. Loosely
speaking, progressive JPEG uses the ``average'' color for any given block of
pixels, whereas PNG uses the color of a single pixel in the corner of the
block. Early JPEG passes also tend to be somewhat softer (smoother) than
early PNG passes; 
<?x-need 10?>some users find that effect more pleasing.</p>


<p><a name="INDEX-61" />
Finally, I should at least mention TIFF's potential for interlacing. Although
no major browser supports TIFF as a native image format, it does offer a very
general, random-access approach to image layout. Based either on groups of
rows (``strips'') or on rectangular blocks of pixels (``tiles''), a properly
constructed TIFF could be used for some form of progressive display. But aside
from complete lack of browser support (and very little interest from users),
TIFF's compression works only within individual strips or tiles, not across
them. So either the interlacing effect would be horrible or the compression
would be (or quite possibly both), which is probably why no one seems to have
tried it.
<a name="INDEX-62" />
<a name="INDEX-63" />
</p>
</div>








<a name="png.ch01.div.2.4" /><div class="sect2">
<h3 class="sect2">1.2.4. Compression</h3>


<p><a name="INDEX-64" />
<a name="INDEX-65" />
<a name="INDEX-66" />
<a name="INDEX-67" />
PNG's compression is among the best that can be had <em class="emphasis">without losing image 
data</em> and without paying patent or other licensing fees.<a href="#FOOTNOTE-5">[5]</a>




Patents are primarily of concern
to application developers, not end users, but the decision to throw away
some of the information in an image is very much an end-user concern. This
information loss generally happens in two ways: in the use of a lesser pixel
depth than is required to represent all of the colors in the image, and in
the actual compression method (hence ``lossy'' compression).
<a name="INDEX-73" />
















































</p><blockquote class="footnote">


<a name="FOOTNOTE-5" /><p>[5] The ``Burrows-Wheeler block transform coding'' method used in the
<a name="INDEX-68" />
bzip2 utility is also unpatented and achieves somewhat better
compression than PNG's low-level engine, but it wasn't publicly known
at the time and is far, far slower for decoding. JPEG-LS, the new
<a name="INDEX-69" />
<a name="INDEX-70" />
lossless JPEG standard, is fairly fast and performs somewhat better
than PNG on natural images, but it does much worse on ``artistic''
ones. It's covered by patents held by Hewlett-Packard and Mitsubishi,
but both companies are waiving license fees (i.e., allowing free
<a name="INDEX-71" />
<a name="INDEX-72" />
use). And BitJazz has a new lossless technique called
``condensation''; it appears to compress images 25% to 30% better than
PNG, but it is patented and completely proprietary.</p>


</blockquote>


<p>PNG supports all three of the main image types discussed earlier:
truecolor, grayscale, and palette-based. TIFF likewise supports all three;
JPEG only the first two; and GIF only the third, although it can fake
grayscale by using a gray palette. Both GIF and PNG
palettes are limited to a maximum of 256 colors, which means that full-color
images--which usually have tens of thousands or even hundreds of thousands
of colors--cannot be stored as GIFs or palette-based PNGs without loss.<a href="#FOOTNOTE-6">[6]</a>


On the other hand, an image that does fit into a 256-color palette requires
only one byte per pixel, which leads to an immediate factor-of-three reduction
in file size over a full RGB image before any ``real'' compression is done
at all. This fact alone 
<?x-need 10?>is an important issue for PNG images, since PNG allows
an image to be stored either way.</p><blockquote class="footnote">


<a name="FOOTNOTE-6" /><p>[6] Technically that's not <em class="emphasis">quite</em> true in the case of GIF; it supports the
concept of multiple subimages, each of which may have its own palette and
may be tiled side by side with other subimages to form a truecolor mosaic.
This mode is not widely supported, however, particularly on 8-bit displays.
Even where it is supported as intended by its proponents, it is an incredibly
inefficient way to store and display truecolor image data.</p>


</blockquote>


<p><a name="INDEX-74" />
It is worth mentioning that TIFF palettes support up to 65,536 colors, which is
sufficient to handle many full-color images without loss. Any palette with
more than 256 colors will require two bytes per pixel, eliminating much of the
benefit of a palette-based image, but applications that support TIFF are
usually more concerned with reading and writing speed than with file sizes.</p>


<p>So let's assume that the image type has been decided; that brings us to the
compression method itself. Both GIF and PNG use completely lossless
compression engines, and all but the most recently specified forms of TIFF do
<a name="INDEX-75" />
so as well. Standard JPEG compression is always lossy, however, even at the
highest quality settings.<a href="#FOOTNOTE-7">[7]</a>


Because of this, JPEG images are usually three to ten
times smaller than the corresponding PNG or TIFF images. This makes JPEG a
very appealing choice for the Web, where small file sizes are important, but
JPEG's compression method can introduce visible artifacts such as blockiness,
color shifts, and ``ringing'' or ``echos'' near image features with sharp
edges. The upshot is that JPEG is a poor choice for intermediate saves during
editing, and for web use it is best suited to smoothly varying truecolor
images, especially photographic ones, at relatively high quality settings.
It is not well suited to simple computer graphics, cartoons, and many types
of synthetic images. <a href="fig_C3.html">Figure C-3</a> in the color insert demonstrates this:
notice the dirty (or ``noisy'') appearance of the blue-on-white text, the
faint yellow spots above and below it, the darker blue spots in the upper
half, and the hints of pink in the white-on-blue text.
</p><blockquote class="footnote">


<a name="FOOTNOTE-7" /><p>[7] There are two forms of truly lossless JPEG, which are discussed briefly in
<a href="chapter08.html">Chapter 8, "PNG Basics"</a>, but currently they are almost universally unsupported. There is
also a relatively new TIFF variant that uses ordinary (lossy) JPEG compression,
but it is likewise supported by very few applications.</p>


</blockquote>


<p>Among the popular lossless image-compression engines, PNG's engine is
demonstrably the most effective--even leaving aside the issue of
prefiltering, which I'll discuss in the next section. TIFF's best classic
compression method and GIF's (only) method are both based on an algorithm
<a name="INDEX-76" />
<a name="INDEX-77" />
known as <em class="emphasis">LZW</em> (Lempel-Ziv-Welch), 
which is quite fast and was used in the Unix utility
<a name="INDEX-78" />
<a name="INDEX-79" />
<a name="INDEX-80" />
<a name="INDEX-81" />
<em class="emphasis">compress</em> and in the early PC archiver ARC. PNG's method is called
<em class="emphasis">deflate</em>, and it is used in the Unix utility <em class="emphasis">gzip</em> (which
supplanted <em class="emphasis">compress</em> in the Unix world) and in PKZIP (which replaced
ARC in the early 1990s as the preeminent PC archiver). Unlike LZW, deflate
supports different levels of compression versus speed--a dial, if you will.
At its lowest setting,<a href="#FOOTNOTE-8">[8]</a>


deflate is as fast as or faster than LZW and compresses roughly the same; at its
highest setting, deflate is considerably slower but achieves noticeably better
compression. (Decompression speed is essentially unaffected by the compression
level, except insofar as a less compressed image may take more time to read
from network or disk.) The deflate algorithm is described in more detail in
<a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>.</p><blockquote class="footnote">


<a name="FOOTNOTE-8" /><p>[8] Actually I'm referring to deflate's second-lowest compression
setting (``level 1''); the very lowest setting (``level 0'') is
uncompressed. Sadly, the dial only goes to 9, not 11.</p>


</blockquote>


<a name="png.ch01.div.2.4.1" /><div class="sect3">
<h3 class="sect3">1.2.4.1. Compression filters</h3>


<p><a name="INDEX-82" />
<a name="INDEX-83" />
Compression filters are a way of transforming the image data (without loss of
information) so that it will compress better. Each row in the image can have
one of five filter types associated with it; choosing which of the five to use
for each row is almost more of a black art than a science. Nevertheless, at
least one reasonably good algorithm is not only known but is also described in
the PNG specification and is implemented in freely available software. Other
algorithms are likely to perform even better, but so far this has not been an
active area of research.</p>


<p>By way of example--admittedly an extreme case--a 512&nbsp;&times; 32,768 image
containing all 16,777,216 possible 24-bit colors compressed over 300 times
better with filtering than without. The uncompressed image was 48 MB in
size; the compressed but unfiltered version was around 36 MB; but the
filtered version (using the ``reasonably good algorithm'' referred to earlier)
was only 115,989 bytes (0.1 MB). And a version created by trying multiple
filtering approaches was a mere 91,569 bytes, for a total compression ratio
of 550:1 and an improvement over the unfiltered version of more than 400 times.
Keep in mind that we're talking about <em class="emphasis">completely lossless compression</em>
here. Yow.
</p>


<p>Filtering is also described in more detail in <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>.</p>
</div>




<a name="png.ch01.div.2.4.2" /><div class="sect3">
<h3 class="sect3">1.2.4.2. Compression oopers</h3>


<p><a name="INDEX-84" />
<a name="INDEX-85" />
Despite PNG's potential for excellent compression, not all implementations
take full advantage of the available power. Even those that do can be
thwarted by unwise choices on the part of the user.</p>


<p>The most harmful mistake from the perspective of file size and apparent
compression level is mixing up PNG image types. Specifically, forcing an
application to save an 8-bit (or smaller) palette image as a 24-bit truecolor
image is <em class="emphasis">not</em> going to result in a small file. This may be unavoidable
if the original has been modified to include more than 256 colors (for example,
if a continuous gradient background has been added or another image pasted in),
but many images intended for the Web have 256 or fewer colors. These should
almost always be saved as palette-based images. 




</p>


<p><a name="INDEX-86" />
Another simple mistake is creating interlaced images unnecessarily. Interlacing
is a great benefit to users waiting for large images to download, but on
small ones such as buttons and icons, it makes little difference. From a
compression perspective, on the other hand, interlacing can have a significant
impact, especially for small images. Compression works best where pixels
are similar or identical, which is often the case in localized regions, but
PNG's two-dimensional interlacing scheme mixes up pixels in an ``unnatural''
order that can destroy any compressor-friendly patterns.</p>


<p><a name="INDEX-87" />
Another ``unnatural'' image modification is standard JPEG compression.
The echoes (or ringing) I mentioned earlier are almost never a good thing
from PNG's point of view, regardless of their visual effect. For example,
a blue image with white text could be saved natively as a two-color (1-bit)
palette PNG. After JPEG compression, however, there will be a whole range
of blues and whites in the image, and possibly even hints of some other
colors. The image would then have to be saved as an 8-bit or even a 24-bit
PNG, with obvious consequences for the file size. Bottom line: don't
convert JPEGs to PNGs unless there is absolutely no alternative. Instead,
start over with the original truecolor or grayscale image and convert
<em class="emphasis">that</em> to PNG.</p>


<p>On the programmer's side, one common mistake is to include unused palette
entries in a PNG image, which again inflates the file size. This error is
most noticeable when converting tiny GIF images (bullets, buttons, and so on) to
PNG format; these images are typically only 1,000 bytes or so in size, and
storing 256 3-byte palette entries where only 50 are needed would result
in over 600 bytes of wasted space. PNG's support for transparent palette
images, which involves a secondary ``palette'' of transparency values that
mirrors the main color palette, can also be misused in this way. Because
all palette colors are assumed to be opaque unless explicitly given transparency,
well-written programs will reorder the palette so that any transparent entries
come first. That allows the remainder of the transparency chunk, containing
only opaque entries, to be omitted.</p>


<p>Another common programmer mistake is to use only one type of compression
filter, or to vary them incorrectly. As noted earlier, compression filters
can make a dramatic difference in the compressibility of the image. However, this is not a feature that users need to know much about. For applications
such as Adobe Photoshop that do allow users to play with filters, the best
approach is to turn off filters for palette-based images and to use dynamic
filters for all other types.</p>


<p>Finally, the low-level compression engine itself can be tweaked to compress
either better or faster. Usually ``best compression'' is the preferred 
setting, but an implementor may choose to use an intermediate level of 
compression in order to boost the interactive performance for the user.
In general, the difference in file size is negligible, but there are rare
cases in which such a choice can make a big difference.</p>


<p>A more detailed list of compression tips for both users and
programmers is presented in <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>.
<a name="INDEX-88" />
<a name="INDEX-89" />
<a name="INDEX-90" />
</p>
</div>
</div>








<a name="png.ch01.div.2.5" /><div class="sect2">
<h3 class="sect2">1.2.5. Summary of Usage</h3>


<p><a href="#png.ch01.tbl.1">Table 1-1</a> summarizes the sorts of tasks for which PNG, JPEG, GIF, and TIFF tend
to be best suited; question marks indicate debatable entries. (Keep in
mind that there are always exceptions, though.)</p>


<a name="png.ch01.tbl.1" />
<div class="table" align="center">

<p>
<table width="502" border="0">
  <tr>
    <td>
      <b class="emphasis-bold">Table 1-1.</b>
      <i>Comparison of Typical Usage for Four Image Formats</i>
    </td>
  </tr>
</table>
</p>

<p>
<table width="502" border="1">

  <tr>
    <td><b class="emphasis-bold" /></td>
    <td><b class="emphasis-bold">PNG</b></td>
    <td><b class="emphasis-bold">GIF</b></td>
    <td><b class="emphasis-bold">JPEG</b></td>
    <td><b class="emphasis-bold">TIFF
    <?x-space 2p?><?x-space 2p?></b></td>
  </tr>

  <tr>
    <td>Editing, palette image, fast saves</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
  </tr>

  <tr>
    <td>Editing, truecolor image, fast saves</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
  </tr>

  <tr>
    <td>``Final'' edit, best compression</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Editing, maximal editor portability</td>
    <td align="center">?</td>
    <td align="center">?</td>
    <td>&nbsp;</td>
    <td align="center">?</td>
  </tr>

  <tr>
    <td>Web, truecolor image, no transparency</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, palette image, no transparency</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, image with ``on/off'' transparency</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, image with partial transparency</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, cross-platform color consistency</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, animation</td>
    <td>&nbsp;</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, maximal browser portability</td>
    <td align="center">?</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
  </tr>

  <tr>
    <td>Web, smallest possible images</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
    <td align="center"><img width=10 height=10 src="images/check.png" alt="y" /></td>
    <td>&nbsp;</td>
  </tr>

<?x-space 5p?>
</table>
</p>
</div>



<p><a name="INDEX-91" />
Several things are worth noting here. The first is that TIFF is not at all
suited as a web format, simply because it is not supported by any major browser.
(This will not be a big surprise to the web designers in the audience.) Even
as an editing format, TIFF's main strength is its speed. With regard to
portability between image-editing apps, the facts are a little murkier, however.
GIF traditionally has been the best-supported format due to its simplicity,
but a number of shareware and freeware applications have dropped support due
to patent-licensing issues. TIFF has been widely supported, too, but it has
also been widely cursed for its incompatibilities among apps. And PNG, of
course, is still relatively new. By now it is supported by most of the main
image editors, but some of its features (such as 48-bit truecolor) are
often supported as read-only capabilities or ignored altogether.</p>


<p><a name="INDEX-92" />
The choice of a web format depends almost entirely on what features are
required in the image. Transparency automatically rules out JPEG; partial
transparency rules out GIF, as well. For animation, GIF is the only choice.
For opaque, photographic images, JPEG is the only reasonable choice--its
compression can't be beat. The truly critical issue, however, is portability
across browsers. GIF and JPEG are relatively safe bets, but what about PNG?
By late 1997, it was supported (at least minimally) in virtually all
<a name="INDEX-93" />
browsers; Microsoft's Internet Explorer 4.0 and Netscape's Navigator 4.04
finally got native PNG support in October and November 1997, respectively.<a href="#FOOTNOTE-9">[9]</a>


But gamma correction was supported only by Internet Explorer, and PNG
transparency was almost unusable. At the time of this writing,
Navigator 5.0 is still unreleased, and IE 5.0 for Windows is unchanged
from version 4.0. But there are strong indications that the Big Two
will finally support both gamma and full alpha-channel transparency in
their next major releases.</p><blockquote class="footnote">


<a name="FOOTNOTE-9" /><p>[9] Most other web browsers have supported PNG natively since 1995 or 1996.</p>


</blockquote>


<p><a name="INDEX-94" />
Of course, that begs the question of when it is safe to start
using PNG on the Web. In theory, the extended <b class="emphasis-bold">OBJECT</b> tag in
HTML 4.0 provides the means to do so immediately. <b class="emphasis-bold">OBJECT</b> is a
``container'' in HTML parlance, similar to <b class="emphasis-bold">FONT</b> tags or
<b class="emphasis-bold">BLOCKQUOTE</b>; it affects the stuff inside it, between the
<b class="emphasis-bold">&lt;OBJECT&gt;</b> and <b class="emphasis-bold">&lt;/OBJECT&gt;</b> tags--including other
(nested) <b class="emphasis-bold">OBJECT</b>s. Unlike most container tags, however,
<b class="emphasis-bold">OBJECT</b>s refer to their own data (as part of the
<b class="emphasis-bold">&lt;OBJECT&gt;</b> tag itself), and this can include images. In fact,
one can think of an <b class="emphasis-bold">OBJECT</b> as an extremely enhanced
<a name="INDEX-95" />
<b class="emphasis-bold">IMG</b> tag. Whereas <b class="emphasis-bold">IMG</b> refers to a single datatype
(just images) and can display a small amount of plain text if the
image can't be rendered (via the <b class="emphasis-bold">ALT</b> attribute),
<b class="emphasis-bold">OBJECT</b>s can refer to numerous datatypes (images, VRML,
Shockwave, Java applets, and so on) and can display arbitrary HTML if
their main datatype cannot be rendered (via the contents of the
<b class="emphasis-bold">OBJECT</b> container). Thus, browsers peel <b class="emphasis-bold">OBJECT</b> blocks
like onions, first trying to render the outermost layer and moving
inward until they find something they can handle. As soon as they find something to render, the remainder of the block is
discarded. (This is the sense in which the inner stuff is
``affected'': it may be completely ignored. Indeed, only one layer is
<em class="emphasis">not</em> ignored...at least according to the HTML 4.0 specification.)</p>


<p>So the preferred approach for PNG images is simply to wrap an <b class="emphasis-bold">OBJECT</b>
tag around an old-style <b class="emphasis-bold">IMG</b> tag, where the <b class="emphasis-bold">OBJECT</b> refers to
the PNG and the <b class="emphasis-bold">IMG</b> refers to a JPEG or GIF version of the same image.
I'll provide some concrete examples of this in <a href="chapter02.html">Chapter 2, "Applications: WWW Browsers and Servers"</a>,
<em class="emphasis">Applications: WWW Browsers and Servers</em>.


























Newer browsers that support both PNG and <b class="emphasis-bold">OBJECT</b> will render the PNG
in the outer <b class="emphasis-bold">OBJECT</b>, ignoring the <b class="emphasis-bold">IMG</b> tag. Older browsers will
either ignore <b class="emphasis-bold">OBJECT</b> as an unknown tag or else parse it but recognize
that they cannot render the PNG; either way, they will use the GIF


or JPEG from the inner <b class="emphasis-bold">IMG</b> tag, or the text in the ALT attribute if
they do not support images.
</p>


<p>At least, that's the theory. The main problem with this approach is that no
version of Navigator or Internet Explorer up through the latest 4.x releases
handles <b class="emphasis-bold">OBJECT</b> tags correctly. Both browsers will attempt to find a
plug-in to handle an <b class="emphasis-bold">OBJECT</b> image; lacking that, they will either
render the inner <b class="emphasis-bold">IMG</b> or fail entirely. I'll look at this in more
detail in <a href="chapter02.html">Chapter 2, "Applications: WWW Browsers and Servers"</a>.</p>


<p>But plug-in oddities notwithstanding, the <b class="emphasis-bold">IMG</b>-within-an-<b class="emphasis-bold">OBJECT</b>
approach works moderately well now and will only get better as browsers improve
their conformance with WWW standards and as the need for external PNG plug-ins
diminishes. Indeed, most of the images on the Portable Network Graphics home


site are referenced in this manner. As for referring to PNG images directly
in old-style <b class="emphasis-bold">IMG</b> tags, which is more commonly thought of as
``using PNG on the Web''--that depends on the images and on the target
audience. For example, the Acorn home site already uses PNG images in places;


their audience is largely Acorn users, and Acorn Browse has perhaps the best
PNG support of any browser in the world. But sites targeted at the average
user running Navigator or Internet Explorer must keep in mind that any given
release of the Big Two browsers achieves widespread use only after a year or
so, and even then, a large percentage of users continue to use
older versions. From a PNG perspective, this means that late 1998 was about
the earliest it would have been reasonable to begin using <b class="emphasis-bold">IMG</b>-tag PNGs
on general-purpose sites. Sites that would like to make use of PNG transparency
or gamma support will have to wait until about a year after the 5.0 releases
occur, which presumably means sometime in the year 2000. (PNG as the Image
Format of the New Millennium<a href="#FOOTNOTE-10">[10]</a>


has a nice ring to it, though.)
<a name="INDEX-96" />
</p><blockquote class="footnote">


<a name="FOOTNOTE-10" /><p>[10] That would be the millennium of four-digit years beginning with the
numeral ``2,'' which, of course, is what everyone will be celebrating
on New Year's Eve, 1999. (The Third Millennium is the one that starts
on January 1, 2001.)</p>


</blockquote>
</div>


















</div>
<div class="sect1"><a name="png.ch01.div.3" />
<h2 class="sect1">1.3. Case Study of a PNG-Supporting Image Editor</h2>


<p><a name="INDEX-97" />
<a name="INDEX-98" />
<a name="INDEX-99" />
Software development tends to be a dynamic and rapidly changing field,
and even periodicals have trouble keeping up with what is current.
To attempt to do so in a book--even one that uses the phrase ``at
the time of this writing'' as often as I have here--borders on the
ridiculous. Nevertheless, given PNG's unique feature set and its
unfamiliarity to many of those who could make the best use of those
features, I feel that it is worth the risk to explore in depth an
application that appears to have, as of early 1999, the best PNG
support of anything on the market: Macromedia's Fireworks 1.0,
available for 32-bit Windows and Macintosh. (Version 2.0 was released
while this book was in the final stages of production; information
about it is noted wherever possible, but I did not have time to test
it.)</p>


<p>Fireworks is an image editor with a feature set that rivals Adobe Photoshop
in many ways, but with far more emphasis on web graphics and less on high-end
printing support. In this, it is closer to Adobe ImageReady, a web-specific
application intended to tune image colors and optimize file sizes. I'll
come back to Photoshop and ImageReady in <a href="chapter04.html">Chapter 4, "Applications: Image Editors"</a>.</p>


<a name="png.ch01.div.3.1" /><div class="sect2">
<h3 class="sect2">1.3.1. PNG Feature Support in Fireworks</h3>


<p>Fireworks 1.0 supports a good range of PNG features and image types, and it
truly shines in its handling of transparency--indeed, its native internal
format is 32-bit RGBA (truecolor with a full 8-bit alpha channel) for all
images, and it can save this format, too. In addition, ordinary
single-color (GIF-like) transparency is supported in both palette-based and
RGB image types, and PNG's unique ``RGBA palette'' mode is also supported.
Nor is this support limited to recognizing when an image contains 256 or fewer
color-transparency combinations; with a suitable choice of export options,


Fireworks can (within limits) quantize and optionally dither even a truecolor
image with a nontrivial alpha channel to an 8-bit RGBA-palette image.</p>


<a name="INDEX-99.01-new" />
<p>There are a couple of notable omissions from Fireworks's list of PNG
features, however. The most painful is the lack of support for gamma
and color correction; images created by the application will vary in
appearance between different display systems just as much as any
old-style GIF or JPEG image would, appearing too bright and
washed out on Macintosh, SGI, and NeXT systems or too dark on just
about everything else. Version 1.0 also cannot write interlaced PNGs,
even though it provides a seemingly valid checkbox option for some PNG
output types. Version 2.0 addresses this problem, but only in a very
limited way: the original plans were to include a ``hidden'' preference that
can be changed so that all exported PNG images are interlaced
(instead of none of them).<a href="#FOOTNOTE-11">[11]</a>
</p><blockquote class="footnote">


<a name="FOOTNOTE-11" />
<p>[11] A tight release schedule was the main reason for the lack of a
real fix in version 2.0; Macromedia engineers were fully aware of
the deficiencies in the workaround and are expected to address
them in the next release.</p>


</blockquote>


<a name="INDEX-99.02-new" />
<a name="INDEX-99.03-new" />
<p>As one would expect of a graphics application targeted at the Web,
Fireworks doesn't preserve 16-bit samples, although it will read
16-bit PNG images (for example, from a medical scan) and convert the
samples to 8 bits. Slightly more surprising is its lack of support for
true grayscale PNGs; Fireworks saves these as palette-based files,
with a palette composed entirely of grayscale entries. This is a
perfectly valid type of PNG file, but the required palette adds up to
780 bytes of unnecessary overhead, a distinct liability for icons and
other tiny images. On the other hand, a palette-based grayscale image
with transparency can include a colored palette entry to be used as
the background color, something that PNG does not support for true
grayscale files.</p>


<p>In addition to supporting PNG as an output format, Fireworks actually
uses PNG as its native file format for day-to-day intermediate
saves. This is possible thanks to PNG's extensible ``chunk-based''
design, which allows programs to incorporate application-specific data
in a well-defined way. Macromedia has embraced this capability,
defining at least four custom chunk types that hold various things
pertinent to the editor. Unfortunately, one of them (pRVW) violates the
PNG naming rules by claiming to be an officially registered, public
chunk type, but this was an oversight and should be fixed in version
2.0.</p>


<a name="INDEX-99.04-new" />
<p>Although it is entirely possible to use the intermediate Fireworks PNG files
in other applications, including on the Web (in fact, one of the
``frequently asked questions'' on the Fireworks web site specifically mentions
Netscape, Internet Explorer, and Photoshop), they are not really appropriate
for such usage. One reason is that the native PNG format reflects Fireworks's
internal storage format, which, as mentioned earlier, is 32-bit RGBA.
Even if the image contains only two colors and no transparency, it is saved
as a 32-bit PNG file. That certainly doesn't help the old compression ratio
any, but the potential for expansion due to the image depth is often
overshadowed by that due to the custom chunks, several of which are huge.<a href="#FOOTNOTE-12">[12]</a>
Thanks to these chunks (which are meaningless to any application but
Fireworks), the intermediate PNG files can easily be larger than a
completely uncompressed RGBA image would be.


</p><blockquote class="footnote">


<a name="FOOTNOTE-12" /><p>[12] In a 590k tutorial image from Macromedia's web site, 230k is due to image
data; 360k is due to custom chunks.</p>


</blockquote>


<p>Of course, Macromedia never intended for users to treat the native Fireworks
PNG files as the final output format. The fully editable ``fat'' PNGs are
produced by the Save menu option; to make final, highly compressed PNGs


for web usage, use the Export option. While this might seem like an odd
approach to someone unfamiliar with modern image editors, its only real
difference from that of applications like Photoshop or Paint Shop Pro is the
fact that the intermediate format is widely readable even by low-end apps and
browsers (which is not the case for Photoshop's native <em class="emphasis">.psd</em> format
or Paint Shop Pro's <em class="emphasis">.psp</em> format). For an in-house network with
high-speed links--for example, in a design studio--this allows images to
be easily browsable over the intranet, yet retain all of their object-level
editing attributes.</p>
</div>








<a name="png.ch01.div.3.2" /><div class="sect2">
<h3 class="sect2">1.3.2. Invoking PNG Features in Fireworks</h3>


<a name="INDEX-99.05-new" />
<p>Because Fireworks's internal format is 32-bit (i.e., truecolor plus a full
alpha channel), working with transparency is as easy as opening an image and 
applying the Eraser tool to its background. For example, suppose you
have a photograph of someone and want to focus on the face by making 
everything else transparent, leaving behind an oval (or at least roundish)
portrait shot with a soft border. There are several ways to accomplish this,
but the following prescription is one of the simplest:
<?x-need 15?></p>


<ol>
   <li><p>Open the original image (<b class="emphasis-bold">File &#8594;
       Open</b>).</p></li>
   <li><p>Pick the background image (<b class="emphasis-bold">Modify &#8594;
       Background Image</b>).</p></li>
   <li><p>Double-click on the <b class="emphasis-bold">Lasso</b> tool (right
       side of tool palette, second from top).</p></li>
   <li><p>In the <b class="emphasis-bold">Tool Options</b> pop-up, pick
       <b class="emphasis-bold">Feather</b> and a radius, perhaps 25.</p></li>
   <li><p>Draw a loop around the face of the subject.</p></li>
   <li><p>Invert the lasso selection so that the part
       <em class="emphasis">outside</em> the loop gets erased
       (<b class="emphasis-bold">Select &#8594; Inverse</b>).</p></li>
   <li><p>Erase everything outside the loop via <b class="emphasis-bold">Edit
       &#8594; Clear</b> (or do so manually with the Eraser tool).</p></li>
</ol>

<p>Note that the Lasso tool's feathering radius is subtly different from that
available via the Select menu. The latter is a smoothing factor for
the Lasso's <em class="emphasis">boundaries</em>/; in this example, with an inverted selection
so that the image's rectangular boundary is also lassoed, changing the
value through the menu will round off the corners of the dashed Lasso
boundary and may merge separated parts of it together. The feathering radius
on the Tool Options pop-up affects only the width of the partially transparent
region generated along the Lasso's boundary.</p>


<p>In any case, that's all there is to creating an image with transparency. The
next step is to save it as a PNG file. As I just noted, the Save and Save
As... menu items save the complete Fireworks ``project,'' retaining information
about the objects in the image and the steps used to create them, at a
considerable cost in file size. It is generally worthwhile to save a copy
that way in case further editing is needed later. But for publishing the
image on the Web, it must be exported, and this is where it can be
converted into a palette-based image with or without transparency--or left
as a 32-bit RGBA image, but without all of the extra editing information included.</p>


<p>First let's consider the case of exporting the image as a full RGBA
file. Here are the available options in the Export dialog box:</p>


<ul>
   <li><p><b class="emphasis-bold">Format:</b> PNG</p></li>
   <li><p><b class="emphasis-bold">Bit Depth:</b> Millions +Alpha (32
       bit)</p></li>
</ul>

<p>Fireworks 1.0 provides no option to interlace the image, so the
preceding steps represent the complete list of possibilities for this
case. Things get more interesting when it comes to palette-based (or
<em class="emphasis">indexed-color</em>) images. Then one has the option of
choosing either single-color transparency or the nicer RGBA-palette
transparency, in addition to a number of other palette-related
options. Here are the options for the RGBA-palette case:</p>


<ul>
   <li><p><b class="emphasis-bold">Format:</b> PNG</p></li>
   <li><p><b class="emphasis-bold">Bit Depth:</b> Indexed (8 bit) (this is the
       default)</p></li>
   <li><p><b class="emphasis-bold">Palette:</b> WebSnap Adaptive (default) or
       Adaptive</p></li>
   <li><p><b class="emphasis-bold">Dither:</b> Check on or off</p></li>
   <li><p><b class="emphasis-bold">Transparency:</b> Alpha Channel</p></li>
   <li><p><b class="emphasis-bold">Interlaced:</b> Checkbox may be checked but
       does nothing in version 1.0</p></li>
</ul>

<a name="png.ch01.fig.5" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <a href="figs/png.0105.big.png"><img width=502 height=338 border=0
       src="figs/png.0105.edit.png" alt="Figure 1-5" /></a><br>
      <br>
      <b>Figure 1-5:</b>  <i>Fireworks Export Preview window showing
      RGBA-palette options.</i>
      <FONT SIZE="-1">(Click on image for full-scale version.)</FONT>

    </td>
  </tr>
</table>
</p>
</div>

<p>Note that the effects of the current options are reflected in the preview
image to the right (as in <a href="#png.ch01.fig.5">Figure 1-5</a>), which
shows a limitation in Macromedia's
original implementation of RGBA-palette mode. In particular, only four levels
of alpha are used, two of which are either complete transparency or complete
opacity (the other two represent one-third and two-thirds transparency), which results
in very noticeable banding effects in 
<a href="#png.ch01.fig.6">Figure 1-6</a>. 
</p>


<a name="png.ch01.fig.6" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <img width=502 height=264 border=0
       src="figs/png.0106.edit2.png" alt="Figure 1-6" /><br>
      <br>
      <b>Figure 1-6:</b>  <i>Example of Fireworks RGBA-palette image showing
      strong banding.</i>

    </td>
  </tr>
</table>
</p>
</div>

<p>The four-level approach works quite well for anti-aliasing (that is,
preventing ``jaggies'' on curved elements such as circles or text),
which effectively involves a one-pixel-wide band of variable
transparency lying between regions of complete transparency and
complete opacity. But the previous example uses a 25-pixel-wide
feathering radius, and the two partial-transparency bands both show up
extremely well and have sharply defined edges even if dithering is
turned on. Unfortunately, that rather defeats the purpose of alpha
transparency in this case; the 32-bit version is the only
alternative. Fortunately this was one of the areas that got fixed in
version 2.0, and judging by one test image, the results are
spectacular.</p>


<p>Very nearly the same procedure works if you want to save the image with
single-color, GIF-like transparency; instead of picking Alpha Channel
from the list of options in the Transparency pull-down box, this time
pick <b class="emphasis-bold">Index Color</b>. Doing so once will allocate a single palette entry,
not used elsewhere in the image, to act as the fully transparent color. A
strange feature of version 1.0 is that the Transparency pull-down
will still indicate Alpha Channel the first time Index Color is
chosen. Choosing it again will cause it to ``stick,'' but at a cost: the 
entry chosen for transparency, which generally seems to be the last one
(usually black), may now be used in the opaque parts of the image as well
as the transparent regions. It is not clear whether this is a bug or an
intentional feature of some sort, but it is fully reproducible.  
<a href="#png.ch01.fig.7">Figure 1-7</a> shows an example.
</p>


<a name="png.ch01.fig.7" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <a href="figs/png.0107.big.png"><img width=502 height=336 border=0
       src="figs/png.0107.edit.png" alt="Figure 1-7" /></a><br>
      <br>
      <b>Figure 1-7:</b>  <i>Fireworks Export Preview after choosing Index
      Color transparency twice, showing transparency (white artifacts) in
      opaque regions.</i>
      <FONT SIZE="-1">(Click on image for full-scale version.)</FONT>

    </td>
  </tr>
</table>
</p>
</div>

<p>As with transparent GIFs, single-color PNG transparency requires that the
image be displayed against a suitable background color--white, in our
example--to look good. The opposite case, displaying against
black, is shown in 
<a href="#png.ch01.fig.8">Figure 1-8</a>. 
</p>


<a name="png.ch01.fig.8" />
<div class="figure" align="center">
<p>
<table width=502>
  <tr>
    <td>

      <img width=502 height=271 border=0
       src="figs/png.0108.edit2.png" alt="Figure 1-8" /><br>
      <br>
      <b>Figure 1-8:</b>  <i>Example of a Fireworks image with single-color
      transparency, displayed against the ``wrong'' background.</i>

    </td>
  </tr>
</table>
</p>
</div>



<a name="png.ch01.div.3.3" /><div class="sect2">
<h3 class="sect2">1.3.3. Analysis of Fireworks PNG Support</h3>


<p>I should note a few caveats about the implementation of indexed-color
images and transparency in Fireworks 1.0. For example, the dither
checkbox seems to have very little effect in any of the palette
examples, and no effect at all on the alpha channel in RGBA images; in
fact, the export ``wizard'' explicitly notes this and actually
recommends against its use. And the palette-size pull-down seems to
have been borrowed from the GIF user interface--it allows only
power-of-two palette sizes (e.g., 64, 128, 256) even though PNG's
palette chunk can have any number of entries from 1 to 256. The final
jump is particularly abrupt; it may happen that 160 colors is the
perfect trade-off between quality and image size, but such an image
would have to be saved with either 128 or 256 colors.</p>


<a name="INDEX-99.06-new" />
<p>With regard to transparency, the placement of transparent
entries in the Export window's palette view is directly reflected in the PNG
file's palette, whether Alpha Channel or Index Color is selected. 
This is regrettable, since the transparent colors are scattered all over the
palette in the alpha case. The single-color case is even worse--the
transparent color is the very last entry in the palette. As noted earlier,
the preferred approach is to put all of the transparent entries at the
beginning of the palette so that the redundant information about opaque
colors can be eliminated from the transparency chunk. For a photographic
image saved in palette format with single-color transparency, the cost is
127 or 255 bytes of wasted space.</p>


<a name="INDEX-99.07-new" />
<p>PNG also supports a single-color (or single-shade), ``cheap'' transparency
mode that
works with truecolor and grayscale images and avoids the need for a full
alpha channel, but there is no way to invoke this feature in Fireworks. The
lack of any grayscale support other than palette-based means that a gray
image with an alpha channel must be saved either as RGBA, doubling its size,
or as an indexed image with transparent palette entries, generally with some
data loss. (The loss comes about because there are only 256 possible
gray+alpha combinations in palette mode, whereas a full gray+alpha image
supports up to 65,536 combinations.) There is also no support for a PNG
background-color chunk.</p>


<p>Images that already have transparency are preserved quite well (recall that everything is stored internally as 32-bit RGBA), and Fireworks
provides quite a number of options beyond what described earlier for adding
or modifying transparency. One in particular that could be used for unsharp
masking and other special effects is invoked via the <b class="emphasis-bold">Xtras</b> menu. With
the background image selected, choose <b class="emphasis-bold">Other</b> &#8594; <b class="emphasis-bold">Convert to
Alpha</b>, which first converts the image to grayscale and then to an alpha
mask. The lightest parts of the image become the most transparent, while
the black parts remain opaque.
</p>


<a name="INDEX-99.08-new" />
<p>Fireworks's compression is reasonably good. Even though there are no user
options to adjust the compression level, the default level is a good trade-off
between speed and size. Truecolor images tend to be compressed within a few
percent of the best possible size, while indexed-color images may see upward
of 15% improvement when run through an optimization tool such as <em class="emphasis">pngcrush</em>
(discussed in <a href="chapter05.html">Chapter 5, "Applications: Image Converters"</a>).</p>


<a name="INDEX-99.09-new" />
<p>Fireworks also does a good job preserving PNG text annotations, albeit with
a quirk: it removes all of the line breaks (``newlines''), for some reason.
(Oddly enough, GIF and JPEG comments are not preserved.) The program
adds its own Software text chunk; as one might expect, any incoming image
that already includes such a chunk will find it replaced. This is a minor
breach of PNG etiquette, but one that helps keep tiny image files from
getting noticeably bigger because of text comments.</p>


<a name="INDEX-99.10-new" />
<p>Fireworks 1.0 also adds a Creation Time text chunk to most images it
exports. This is not really a problem, per se; what is unusual is that
the chunk's contents are invariably ``Thu, May 7, 1998''--a date
that has nothing to do with any of the images or even with the release
of Fireworks 1.0. See also
<a href="chapter11.html">Chapter 11, "PNG Options and Extensions"</a>
for a discussion of why ``creation time'' is a fuzzy concept.
<a name="INDEX-99.11-new" />
Version 2.0 was to have corrected this, replacing the Creation Time text
chunk with PNG's officially defined timestamp chunk, tIME, but I did not
have a chance to verify that. The tIME chunk indicates the time of last
modification, which is a more precisely defined concept and one that is
appropriate for an image editor.</p>


<a name="INDEX-99.12-new" />
<p>As noted earlier, the ability to save interlaced PNG images will
first be implemented as a global preference setting. As of January
1999, the plan was for this to require editing version 2.0's
preferences file. Under Windows, this file is called <em class="emphasis">Fireworks
Preferences.txt</em> and is in the Fireworks installation directory
(<em class="emphasis">C:\Program Files\Macromedia\Fireworks</em>, by default); on the
Macintosh, it is called <em class="emphasis">Fireworks Preferences</em> and is found in the
<em class="emphasis">System Folder:Preferences</em> folder. Open the file in any text
editor and find the line:</p>


<blockquote><pre class="code">(ExportPngWithAdam7Interlacing) (false)</pre></blockquote>


<p>Change this to the following to make all exported images interlaced:</p>


<blockquote><pre class="code">(ExportPngWithAdam7Interlacing) (true)</pre></blockquote>


<p>This change will take effect only after Fireworks 2.0 is restarted.
Fortunately, later releases are expected to have a normal checkbox option.</p>
</div>








<a name="png.ch01.div.3.4" /><div class="sect2">
<h3 class="sect2">1.3.4. Concluding Thoughts on Fireworks</h3>


<p>Lest the preceding detailed list of caveats and oddities leave the
reader with the impression that Fireworks's PNG support is not as good
as I initially suggested, let me reiterate that it is, in fact, quite
good overall. Version 2.0's improved support for RGBA-palette images
puts Fireworks far ahead of any other image editor. The inability to
set PNG interlacing is regrettable but is being addressed; lack of
gamma support is the only truly unfortunate design
choice, particularly for a product with both Windows and Macintosh
versions. With luck, both gamma and color correction will become core
features of the next major release.
<a name="INDEX-100" />
<a name="INDEX-101" />
<a name="INDEX-102" />




</p>
</div>


</div>



<hr> <!-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -->

<a href="preface.html"><img width=24 height=13 border=0 align="left"
 src="images/prev.png" alt="&lt;-"></a>

<a href="chapter02.html"><img width=24 height=13 border=0 align="right"
 src="images/next.png" alt="-&gt;"></a>

<div align="center">
  <a href="preface.html"><font size="-1" color="#000000"
   ><b>PREVIOUS</b></font></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
     href="toc.html"><font size="-1" color="#000000"
   ><b>CONTENTS</b></font></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
     href="chapter02.html"><font size="-1" color="#000000"
   ><b>NEXT</b></font></a>
</div>

<hr> <!-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -->


</body></html>