This file is indexed.

/usr/share/doc/png-definitive-guide/html/chapter12.html is in png-definitive-guide 20060430-1.

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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>Multiple-image Network Graphics (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="chapter11.html"><img width=24 height=13 border=0 align="left"
 src="images/prev.png" alt="&lt;-"></a>

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

<div align="center">
  <a href="chapter11.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="chapter13.html"><font size="-1" color="#000000"
   ><b>NEXT</b></font></a>
</div>

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


<h1 class="chapter">Chapter 12. Multiple-image Network Graphics</h1>

<div class="htmltoc"><h4 class="tochead">Contents:</h4><p>
<a href="#png.ch12.div.1">12.1. Common Applications of MNG</a><br />
<a href="#png.ch12.div.2">12.2. MNG Structure</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch12.div.2.1">12.2.1. Image-Defining Chunks</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#png.ch12.div.2.2">12.2.2. Chunks for Image Display, Manipulation, and Control</a><br />
<a href="#png.ch12.div.3">12.3. The Simplest MNG</a><br />
<a href="#png.ch12.div.4">12.4. An Animated MNG</a><br />
<a href="#png.ch12.div.5">12.5. An Algorithmic MNG</a><br />
<a href="#png.ch12.div.6">12.6. A JPEG Image with Transparency</a><br />
<a href="#png.ch12.div.7">12.7. MNG Applications</a><br />
<a href="#png.ch12.div.8">12.8. The Future?</a><br />
</p></div>


<p><a name="INDEX-898" />
<a name="INDEX-899" />The Multiple-image Network Graphics format, or MNG, is not merely a
multi-image, animated extension to PNG; it can also be used to store
certain types of single images more compactly than PNG, and in mid-1998
it was extended to include JPEG-compressed streams.
Conceivably, it may one day incorporate audio or even video channels,
too, although this is a more remote possibility. Yet despite all of
this promise--or, rather, because of it--MNG was still a slowly
evolving draft proposal nearly four years after it was first suggested.</p>


<p>As noted in <a href="chapter07.html">Chapter 7, "History of the Portable Network Graphics Format"</a>, MNG's early development was delayed due to
weariness on the part of the PNG group and disagreement over whether
it should be a heavyweight multimedia format or a very basic ``glue''
format. What it has evolved into, primarily due to the willingness of
<a name="INDEX-900" />Glenn Randers-Pehrson to continue working on it, is a moderately
complex format for composing images or parts of images, either
spatially or temporally, or both. I will not attempt to describe it in
full detail here--a complete description of MNG could fill a book
all by itself and probably will, one of these days--but I will give
a solid overview of its basic features and most useful applications.
Further information on the format can be found at the MNG web site,
<a href="http://www.libpng.org/pub/mng/">http://www.libpng.org/pub/mng/</a>.
</p>


<div class="sect1"><a name="png.ch12.div.1" />
<h2 class="sect1">12.1. Common Applications of MNG</h2>


<p><a name="INDEX-901" />
<a name="INDEX-902" />Perhaps the most basic, nontrivial MNG application is the slide show: a
sequence of static images displayed in order, possibly looping indefinitely
(e.g., for a kiosk). Because MNG incorporates not only the concepts of
frames, clipping, and user input but also all of PNG's features, a MNG slide
show could include scrolling, sideways transitions, fades, and palette
animations--in other words, most of the standard effects of a dedicated
presentation package and maybe a few nonstandard ones. Such an approach
would not necessarily produce smaller presentations than the alternative methods
(although the most popular alternatives tend to be rather large), and, as
currently specified, it would be limited to a particular resolution defined
by the component raster images. But MNG offers the <em class="emphasis">potential</em> of a
more open, cross-platform approach to slide shows.</p>


<p><a name="INDEX-903" />
<a name="INDEX-904" />
<a name="INDEX-905" />MNG also supports partial-frame updates, which not only could be used for
further slide show transitions (for example, dropping bulleted items
into place, one at a time) but also are able to support animated movies.
Unlike animated GIFs, where moving a tiny, static bitmap (or ``sprite'')
around a frame requires many copies of the sprite, MNG can simply indicate
that a previously defined sprite should move somewhere else. It also
supports nested loops, so a sprite could move in a zigzag path to the right,
then up, then left, and finally back down to the starting position--all
with no more than one copy of the background image (if any) and one copy of
the moving bitmap. In this sense, MNG defines a true animation format,
whereas GIF merely supports slightly fancy slide shows.




</p>


<p>Images that change with time are likely to be some of the most common types
of MNG streams, but MNG is useful in completely static contexts as well.
For example, one could easily put together a MNG-based contact sheet of
thumbnail images without actually merging the images into a single, composite
bitmap. This would allow the same file to act both as an archive (or container)
for the thumbnails, from which they could easily be extracted later without
loss, and as a convenient display format.<a href="#FOOTNOTE-91">[91]</a>
If the number of thumbnails grew too large to fit on a single ``page,'' MNG's
slide show capabilities could be invoked to enable multipage display.</p><blockquote class="footnote">


<a name="FOOTNOTE-91" /><p>[91] A file format encapsulating both data and a display method? Egad,
it's object-oriented!</p>


</blockquote>


<p><a name="INDEX-906" />
<a name="INDEX-907" />
<a name="INDEX-908" />Other types of static MNGs might include algorithmic images or
three-dimensional ``voxel'' (volume-pixel) data such as medical scans.
Images that can be generated by simple algorithms are fairly rare if one
ignores fractals. But <em class="emphasis">16million.png</em>, which I discussed in <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>, is
such an image. Containing all 16.8 million colors possible in a 24-bit image,
it consists of nothing but smooth gradients, both horizontally and vertically.
While this allowed PNG's filtering and compression engine to squeeze a 48 MB
image into just over 100 KB, as a MNG containing a pair of loops, move
commands, and a few odds and ends it amounts to a mere 476 bytes. Of course,
compression factors in excess of 100,000 times are highly atypical. But
background gradient fills are not, and MNG effectively allows one to compress
the foreground and background parts independently, in turn allowing the
compression engine and the file format itself to work more efficiently.</p>


<p><a name="INDEX-909" />
<a name="INDEX-910" />Ironically, one of the most popular nonanimated forms of MNG is
likely to have no PNG image data inside at all. I've
emphasized in earlier chapters that PNG's lossless compression method
is not well suited to all tasks; in particular, for web-based display
of continuous-tone images like photographs, a lossy format such as
JPEG is much more appropriate, since the files can be so much smaller.
For a multi-image format such as MNG, support for a lossy
subformat--JPEG in particular--is a natural extension. Not only
does it provide for the efficient storage of photographic backgrounds
for composite frames (or even photographic sprites in the foreground),
it also allows JPEG to be enhanced with PNG-like features such as
gamma and color correction and (ta da!) transparency. Transparency
has always been a problem for JPEG precisely because of its lossy
approach to compression. What MNG provides is a means for a lossy
JPEG image to inherit a loss less alpha channel. In other words,
all of the size benefits of a JPEG image and all of the fine-tuned
anti-aliasing and fade effects of a PNG alpha channel are now possible
in one neat package.
















<a name="INDEX-911" /></p>
</div>

















</div>
<div class="sect1"><a name="png.ch12.div.2" />
<h2 class="sect1">12.2. MNG Structure</h2>


<p><a name="INDEX-912" />
<a name="INDEX-913" />So that's some of what MNG can do; now let's take a closer look at what the
format looks like and how it works. To begin with, MNG is chunk-based, just
like PNG. It has an 8-byte signature similar to PNG's, but it differs
in the first two bytes, as shown in 
<a href="#png.ch12.tbl.1">Table 12-1</a>. 
</p>


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

<p>
<table width="502" border="0">
  <tr>
    <td>
      <b class="emphasis-bold">Table 12-1.</b>
      <i>MNG Signature Bytes</i>
    </td>
  </tr>
</table>
</p>

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

<tr>
<td><b class="emphasis-bold">Decimal<br />Value</b></td>
<td><b class="emphasis-bold">ASCII Interpretation
<?x-space 2p?><?x-space 2p?></b></td>
</tr>

<tr>
<td>138</td>
<td>A byte with its most significant bit set (``8-bit character'')</td>
</tr>

<tr>
<td>77</td>
<td>M</td>
</tr>

<tr>
<td>78</td>
<td>N</td>
</tr>

<tr>
<td>71</td>
<td>G</td>
</tr>

<tr>
<td>13</td>
<td>Carriage-return (CR) character, a.k.a. CTRL-M or ^M</td>
</tr>

<tr>
<td>10</td>
<td>Line-feed (LF) character, a.k.a. CTRL-J or ^J</td>
</tr>

<tr>
<td>26</td>
<td>CTRL-Z or ^Z</td>
</tr>

<tr>
<td>10</td>
<td>Line-feed (LF) character, a.k.a. CTRL-J or ^J</td>
</tr>

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


<p>So while a PNG-supporting application could be trivially modified to identify
and parse a MNG stream,<a href="#FOOTNOTE-92">[92]</a>
there is no danger that an older PNG application might mistake a MNG stream for a
PNG image. Since the file extensions differ as well (<em class="emphasis">.mng</em> instead
of <em class="emphasis">.png</em>), ordinary users are unlikely to confuse images with animations. The only cases in which they might do so are when an allowed component
type (e.g., a PNG or a JNG) is renamed with a <em class="emphasis">.mng</em> extension; such
files are considered legal MNGs.</p><blockquote class="footnote">


<a name="FOOTNOTE-92" /><p>[92] Actually making sense of the MNG stream would require considerably
more work, of course.</p>


</blockquote>


<p><a name="INDEX-914" />
<a name="INDEX-915" />With the exception of such renamed image formats, all MNG streams begin with
the MNG signature and MHDR chunk, and they all end with the MEND chunk.
The latter, like PNG's IEND, is an empty chunk that simply indicates the
end of the stream. MHDR, however, contains seven fields, all unsigned
32-bit integers: frame width, frame height, ticks per second, number of
layers, number of frames, total play time, and the complexity (or simplicity)
profile.</p>


<p><a name="INDEX-916" />Frame width and height are just what they sound like: they give the overall
size of the displayable region in pixels. A MNG stream that contains no
visible images--say, a collection of palettes--should have its frame
dimensions set to zero.</p>


<p><a name="INDEX-917" />The ticks-per-second value is essentially a scale factor for
time-related fields in other chunks, including the frame rate. In the
absence of any other timing information, animations are recommended to
be displayed at a rate of one frame per tick. For single-frame MNGs,
the ticks-per-second value is recommended to be 0, providing decoders
with an easy way to detect non-animations. Conversely, if the value
is 0 for a multiframe MNG, decoders are required to display only the
first frame unless the user specifically intervenes in some way.</p>


<p>``Number of layers'' refers to the total number of displayable images in the
MNG stream, including the background. This may be many more than the number
of frames, since a single frame often consists of multiple images composited
(or layered) on top of one another. Some of the layers may be empty if they
lie completely outside the clipping boundaries. The layer count is purely
advisory; if it is 0, the count is considered unspecified. At the other
end of the spectrum, a value of 2<sup class="superscript">31</sup>-1 (2,147,483,647) is


considered infinite.</p>


<p><a name="INDEX-918" />
<a name="INDEX-919" />The frame-count and play-time values are also basically what they sound
like: on an ideal computer (i.e., one with infinite processing speed), they
respectively indicate the number of frames that correspond to distinct instants
of time<a href="#FOOTNOTE-93">[93]</a>
and the overall duration of the complete animation. As with the layer count,
these values are advisory; 0 and 2<sup class="superscript">31</sup>-1 correspond to
``unspecified'' and ``infinite,'' respectively.</p><blockquote class="footnote">

<a name="FOOTNOTE-93" /><p>[93] MNG's concept of frames and subframes allows one to speak of two or more
distinct frames with precisely zero delay between them, but these are
considered just one frame for the purpose of counting the total number of
frames in the stream.</p>


</blockquote>


<p><a name="INDEX-920" />Finally, MHDR's complexity profile provides some indication of the level of
complexity in the stream, in order to allow simple decoders to give up
immediately if the MNG file contains features they are unable to render.
The profile field is also advisory; a value of zero is allowed and indicates
that the complexity level is unspecified. But a nonzero value indicates
that the encoder has provided information about the presence or absence of
JPEG (JNG) chunks, transparency, or complex MNG features. The latter
category includes most of the animation features mentioned earlier,


including looping and object manipulation (i.e., sprites). All
possible combinations of the three categories are encoded in the lower
4 bits of the field as odd values only--all even values other
than zero are invalid, which means the lowest bit is always set if the
profile contains any useful information. The remaining bits of the
2 lower bytes are reserved for public expansion, and all but the
most significant bit of the 2 upper bytes are available for private
or experimental use. The topmost bit must be zero.








































</p>


<p>Note that any unset (0) bit guarantees that the corresponding feature
is not present or the MNG stream is invalid. A set bit, on the
other hand, does not automatically guarantee that the feature <em class="emphasis">is</em>
included, but encoders should be as accurate as possible to avoid
causing simple decoders to reject MNGs unnecessarily.</p>


<p>The stuff that goes between the MHDR and MEND chunks can be divided into a
few basic categories:</p>


<ul>
   <li>Image-defining chunks</li>
   <li>Image-displaying chunks</li>
   <li>Control chunks</li>
   <li>Ancillary (optional) chunks</li>
</ul>

<p>Note the distinction between <em class="emphasis">defining</em> an image
and <em class="emphasis">displaying</em>
it. This will make sense in the context of a composite frame made up of
many subimages. Alternatively, consider a sprite-based animation composed
of several sprite ``poses'' that should be read into memory (i.e., defined)
as part of the animation's initialization procedure. The sprite frames may
not actually be used until much later, perhaps only in response to user
input.</p>


<a name="png.ch12.div.2.1" /><div class="sect2">
<h3 class="sect2">12.2.1. Image-Defining Chunks</h3>


<p><a name="INDEX-921" />The most direct way to define an image in MNG is simply to incorporate one.
There are two possibilities for this in the current draft specification: a
PNG image without the PNG signature, or the corresponding PNG-like JPEG
<a name="INDEX-922" />format, JNG (JPEG Network Graphics).<a href="#FOOTNOTE-94">[94]</a>
Just as with standalone PNGs, an embedded PNG must contain at least IHDR,
IDAT, and IEND chunks. It may also include PLTE, tRNS, bKGD, gAMA, cHRM, sRGB,
tEXt, iTXt, and any of the other PNG chunks we've described. The PLTE chunk
is allowed to be empty in an embedded PNG, which indicates that the global MNG
PLTE data is to be used instead.</p><blockquote class="footnote">


<a name="FOOTNOTE-94" /><p>[94] OK, that's a stretch, acronym-wise. But it's pronounceable, rhymes
with PNG and MNG, and has a file extension, <em class="emphasis">.jng</em>, that differs
by only one letter from <em class="emphasis">.jpg</em>, <em class="emphasis">.png</em>, and <em class="emphasis">.mng</em>.</p>


</blockquote>


<p><a name="INDEX-923" />
<a name="INDEX-924" />
<a name="INDEX-925" />
<a name="INDEX-926" />An embedded JNG stream is exactly analogous to the PNG stream: it begins
with a JHDR chunk, includes one or more JDAT chunks containing the actual JPEG
image data, and ends with an IEND chunk. Standalone JNGs are also allowed;
they must include an 8-byte JNG signature before JHDR, with the format
that's shown in 
<a href="#png.ch12.tbl.2">Table 12-2</a>. 
</p>


<a name="png.ch12.tbl.2" />
<div class="table" align="center">

<p>
<table width="502" border="0">
  <tr>
    <td>
      <b class="emphasis-bold">Table 12-2.</b>
      <i>JNG Signature Bytes</i>
    </td>
  </tr>
</table>
</p>

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

<tr>
<td><b class="emphasis-bold">Decimal<br />Value</b></td>
<td><b class="emphasis-bold">ASCII Interpretation
<?x-space 2p?><?x-space 2p?></b></td>
</tr>

<tr>
<td>139</td>
<td>A byte with its most significant bit set (``8-bit character'')</td>
</tr>

<tr>
<td>74</td>
<td>J</td>
</tr>

<tr>
<td>78</td>
<td>N</td>
</tr>

<tr>
<td>71</td>
<td>G</td>
</tr>

<tr>
<td>13</td>
<td>Carriage-return (CR) character, a.k.a. CTRL-M or ^M</td>
</tr>

<tr>
<td>10</td>
<td>Line-feed (LF) character, a.k.a. CTRL-J or ^J</td>
</tr>

<tr>
<td>26</td>
<td>CTRL-Z or ^Z</td>
</tr>

<tr>
<td>10</td>
<td>Line-feed (LF) character, a.k.a. CTRL-J or ^J</td>
</tr>

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


<p>JDATs simply contain JFIF-compatible JPEG data, which can be either baseline,
extended sequential, or progressive--i.e., the same format used in
practically every web site and commonly (but imprecisely) referred to as
JPEG files. The requirements on the allowed JPEG types eliminate the
<a name="INDEX-926.01-new" />
less-common arithmetic and lossless JPEG variants, though the 12-bit grayscale
and 36-bit color flavors are still allowed.<a href="#FOOTNOTE-95">[95]</a>
To decode the JPEG image,
simply concatenate all of the JDAT data together and treat the whole as a
normal JFIF-format file stream--typically, this involves feeding the data
to the Independent JPEG Group's free <em class="emphasis">libjpeg</em> library.
<a name="INDEX-927" />


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


<a name="FOOTNOTE-95" /><p>[95] MNG optionally allows 12-bit-per-sample JPEG image data to follow the far
more common 8-bit flavor, giving decoders the freedom to choose
whichever is most appropriate. If both are included, it is signalled in JHDR
by a bit-depth value of 20 instead of 8 or 12, and the 8-bit and 12-bit JDATs
are separated by a special JSEP chunk. The 8-bit data must come first.
Note that current versions of libjpeg can only be compiled to handle either
8-bit or 12-bit JPEG data, not both simultaneously.</p>


</blockquote>


<p><a name="INDEX-928" />
<a name="INDEX-929" />In order to accommodate an alpha channel, a JNG stream may also include one
or more grayscale IDAT chunks. The JHDR chunk defines whether the image has
an alpha channel or not, and if so, what its bit depth is. Unlike PNG, which
restricts alpha channels to either 8 bits or 16 bits, a JNG alpha channel may
be any legal PNG grayscale depth: 1, 2, 4, 8, or 16 bits.
<a name="INDEX-930" />The IDATs composing the alpha channel may come before or after or be interleaved
with the JDATs to allow progressive display of an alpha-JPEG image, but no
other chunk types are allowed within the block of IDATs and JDATs.</p>


<p>Although incorporating complete JNGs or PNGs is conceptually the simplest
approach to defining images in a MNG stream, it is generally not the most
efficient way. MNG provides two basic alternatives that can be much better
<a name="INDEX-931" />in many cases; the first of these is <em class="emphasis">delta images</em>.<a href="#FOOTNOTE-96">[96]</a>
A delta image is simply a difference image; combining it with its parent
re-creates the original image, in much the same way that combining an
``up''-filtered row of pixels with the previous row results in the original,
unfiltered row. (Recall the discussion of compression filters in <a href="chapter09.html">Chapter 9, "Compression and Filtering"</a>.)
The difference of two arbitrary images is likely to be at least as large as
either parent image, but certain types of images may respond quite well
to differencing. For example, consider a pair of prototype images for a
web page, both containing the same background graphics and much of the
same text, but differing in small, scattered regions. Since 90% of
the image area is identical, the difference of the two will be 90% zeros,
and therefore will compress much better than either of the original images
will.


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


<a name="FOOTNOTE-96" /><p>[96] Named for the Greek letter <em class="emphasis">delta</em>
<!-- (<img src="images/U0394.png" alt="[uppercase delta]" /> or
      <img src="images/U03B4.png" alt="[lowercase delta]" />), -->
(&#916; or &#948;),
which is often used in science and engineering to denote differences.</p>


</blockquote>


<p>Currently, MNG allows delta images to be encoded only in PNG format, and it
delimits them with the DHDR and IEND chunks. In addition to the delta
options for pixels given in DHDR--whether the delta applies to the main
image pixels or to the alpha channel, and whether applying the delta involves


pixel addition or merely replacement of an entire block--MNG
defines several chunks for modifying the parent image at a higher level.
Among these are the PROM chunk, for promoting the bit depth or color type
of an image, including adding an alpha channel to it; the DROP and DBYK chunks,
<a name="INDEX-932" />
<a name="INDEX-933" />
<a name="INDEX-934" />for dropping certain chunks, either by name alone or by both name and keyword; 
and the PPLT chunk, for modifying the parent's palette (either PLTE or tRNS, or
both). The latter could be used to animate the palette of an image, for
example; cycling the colors is a popular option in some fractal programs.
PPLT could also be used to fade out an image by adding an opaque tRNS chunk
and then progressively changing the values of all entries until the image
is fully transparent.






</p>


<p><a name="INDEX-935" />The second and more powerful alternative to defining an image by including
its complete pixel data is <em class="emphasis">object manipulation</em>. In this mode, MNG
basically treats images as little pieces of paper that can be copied and
pasted at will. For example, a polka-dot image could be created from a single
bitmap of a circle with a transparent background, which could be copied and
pasted multiple times to create the complete, composite image. Alternatively,
tileable images of a few basic pipe fittings and elbow joints could be pasted
together in various orientations to create an image of a maze. The three
chunks used for creating or destroying images in the object sense are CLON
(``clone''), PAST (``paste''), and DISC (``discard'').</p>


<p><a name="INDEX-936" />The CLON chunk is the only one necessary for the first example; it not only
copies an image object in the abstract sense, but also gives it a position
in the current frame--either as an absolute location or as an offset from
the object that was copied. In order to change the orientation of objects,


<a name="INDEX-937" />as in the maze example, the PAST chunk is required; as currently
<!-- defined, it only supports 180<img src="images/U00B0.png" alt="-degree" />
     rotations and mirror operations around -->
defined, it only supports 180&#176; rotations and mirror operations around
the <em class="emphasis">x</em> and <em class="emphasis">y</em> axes.
<!--
(Ninety-degree rotations were ruled out since they
 -->
(90&#176; rotations were ruled out since they
are rarely supported in hardware, and abstract images are intended to map
to hardware and platform-specific APIs as closely as possible.) PAST also
includes options to tile an object, and not only to replace the underlying
pixel data but also to composite either over or under it, assuming either
the object or underlying image includes transparency information.
Once component objects are no longer needed--for example, in the maze image
when the maze is completely drawn--the decoder can be instructed to discard
them via the DISC chunk.
<a name="INDEX-938" />






















<a name="INDEX-939" /></p>
</div>








<a name="png.ch12.div.2.2" /><div class="sect2">
<h3 class="sect2">12.2.2. Chunks for Image Display, Manipulation, and Control</h3>


<p><a name="INDEX-940" />MNG includes nine chunks for manipulating and displaying image objects and
for providing a kind of programmability of the decoder's operations. The most
<a name="INDEX-941" />complex of these is the framing chunk, FRAM. It is used not only to delimit
the chunks that form a single frame, but also to provide rendering information
(including frame boundaries, where clipping occurs) and timing and
synchronization information for subsequent frames. Included in FRAM's timing and
synchronization information is a flag that allows the user to advance frames, which would be
necessary in a slide show or business presentation that accompanies a live
speaker.</p>


<p><a name="INDEX-942" />The CLIP chunk provides an alternate and more precise method for specifying
clipping boundaries. It can affect single objects or groups of objects, not
just complete frames, and it can be given both as absolute pixel coordinates
and in terms of a relative offset from a previous CLIP chunk. Images that
are affected by a CLIP chunk will not be visible outside the clipping boundary,
which allows for windowing effects.
</p>


<p><a name="INDEX-943" />
<a name="INDEX-944" />The LOOP and ENDL chunks are possibly the most powerful of all MNG chunks.
They provide one of the most fundamental programming functions, the ability
to repeat one or more image-affecting actions many times. I mentioned earlier
that <em class="emphasis">16million.mng</em>, the MNG image with all possible 24-bit colors in it,
makes use of a pair of loops; those loops are the principal reason the complete
image can be stored in less than 500 bytes. Without the ability to repeat the
same copy-and-paste commands by looping several thousand times, the MNG version
would be at least three times the size of the original PNG (close to 1,000
times its actual size)--unless the PNG version were simply
renamed with a <em class="emphasis">.mng</em> extension.
</p>


<p>In addition to a simple iteration count, which can go as high as two
billion, the LOOP chunk can provide either the decoder or the user
discretionary control over terminating the loop early. It also allows
for control via signals (not necessarily Unix-style signals) from an
external program; for example, this capability might be invoked by a
program that monitors 
<?x-need 10?>an infrared port, thus enabling the user to
control the MNG decoder via a standard television remote control.</p>


<p><a name="INDEX-945" />Often used in conjunction with loops and clipping is the MOVE chunk,
one of MNG's big advantages over animated GIFs. As one might expect, MOVE
allows one or more already defined image objects to be moved, either to an
absolute position or relative to the previous position of each object.
Together with LOOP and ENDL, MOVE provides the basis for animating sprites.
Thus, one might imagine a small Christmas MNG, where perhaps half a dozen
poses of a single reindeer are cloned, positioned appropriately
(with transparency for overlaps, of course!), and looped at slightly different
rates in order to create the illusion of eight tiny reindeer galloping
independently across the winter sky.<a href="#FOOTNOTE-97">[97]</a>


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


<a name="FOOTNOTE-97" /><p>[97] Add a few more poses of a waving fat guy in a sleigh, and
you'll swear you hear sleigh bells ringing and chestnuts roasting on
an open fire.</p>


</blockquote>


<p>Up until now, we've glossed over the issue of how or whether any given image
is actually seen; the implication has been that any image that gets defined
is visible, unless it lies outside the image frame or local clipping region.
But an object-based format should have a way of effectively turning on and
<a name="INDEX-946" />off objects, and that is precisely where the SHOW chunk comes in. It
contains a list of images that are affected and a 1-byte flag indicating
the ``show mode.''  The show-mode flag has two purposes: it can direct the
decoder to modify the potential visibility of each object, and it can direct
the decoder to display each object that is potentially visible. Note that
I say <em class="emphasis">potential</em> visibility; any object outside the clipping region
or frame or completely covered by another object will clearly not be visible
regardless of whether it is ``on.''  Among the show modes SHOW
supports is one that cycles through the images in the specified range, making
one potentially visible and the rest not visible. This is the means by which
a single sprite frame in a multipose animation--such as the reindeer
example--is displayed and advanced.


</p>


<p>In order to provide a suitably snowy background for our reindeer example,
<a name="INDEX-947" />
<a name="INDEX-948" />
<a name="INDEX-949" />MNG provides the background chunk, BACK. As with PNG's bKGD chunk, BACK can
specify a single color to be used as the background in the absence of any
better candidates. But it also can point at an image object to be used as
the background, either tiled or not. And either the background color or the
background image (or both) may be flagged as mandatory, so that even if the
decoder has its own default background, for example, in a web browser, it
must use the contents of the BACK chunk. When both the background color
and the background image are required, the image takes precedence; the color
is used around the edges if the image is smaller than the frame and not tiled,
or if it is tiled but clipped to a smaller region, and it is the ``true''
background with which the image is blended if it has transparency.


</p>


<p><a name="INDEX-950" />
<a name="INDEX-951" />Finally, MNG provides a pair of housekeeping chunks, SAVE and SEEK.
Together, they implement a one-entry stack similar to PostScript's <b class="emphasis-bold">gsave</b> and
<b class="emphasis-bold">grestore</b> commands; they can be used to store the state of the MNG stream at
a single point. Typically, this point would represent the end of a prologue
section containing such basic information as gamma and chromaticity, the
default background, any non-changeable images (the poses of our
reindeer, for example), and so forth. Once the SAVE chunk appears--and only
one is allowed--the prologue information is effectively frozen. Some of its
chunks, such as gAMA, may be overridden by later chunks, but they will be
restored as soon as a SEEK chunk is encountered. Any images in the prologue
are fixed for the duration of the MNG stream, although one can always make a
clone of any such image and move that instead.</p>


<p>The SEEK chunk is allowed to appear multiple times, and it is where the real
power lies. As soon as a decoder encounters SEEK, it is allowed to throw out
everything that appeared after the SAVE chunk, flush memory buffers, and so
forth. If a MNG were structured as a long-form story, for example, the SEEK
chunks might be used to delimit chapters or scenes--any props
used for only
one scene could be thrown away, thus reducing the memory burden on the
decoder.</p>


<p>That summarizes the essential structure and capabilities of MNG. I've
skipped over a few chunks, mostly ancillary ones, but the basic ideas have
been covered. So let us now take a look at a few examples.
<a name="INDEX-952" />
<a name="INDEX-953" />
<a name="INDEX-954" />
</p>
</div>









</div>
<div class="sect1"><a name="png.ch12.div.3" />
<h2 class="sect1">12.3. The Simplest MNG</h2>


<p>Arguably the absolute simplest MNG is just the simplest PNG (recall
<a href="chapter08.html">Chapter 8, "PNG Basics"</a>), renamed with a <em class="emphasis">.mng</em> extension. Another
truly simple one would be the empty MNG, composed only of MHDR, FRAM, and MEND
chunks, which could be used as a spacer on web pages--it would generate a
transparent frame with the dimensions specified in MHDR. But if we consider
only nontrivial MNGs, the most basic one probably looks like 
<a href="#png.ch12.fig.1">Figure 12-1</a>.</p>


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

      <img width=502 height=148 border=0
       src="figs/png.1201.png" alt="Figure 12-1" /><br>
      <br>
      <b>Figure 12-1:</b>  <i>Layout of the simplest MNG.</i>

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

<p>This is a very basic, two-image slide show, consisting of a pair of grayscale
or truecolor PNG images (note the absence of PLTE chunks, so they cannot be
colormapped images) and nothing else. In fact, the MNG stream is a little
too basic; it contains no color space information, so the images will not
display the same way on different platforms. It includes no explicit
timing information, so the decoder will display the images at a rate
of one frame per tick. At the minimum value of MHDR's ticks-per-second field,
that translates to a duration of just one second for the first image and one
or more seconds for the second image (in practice, probably indefinitely).
There is no way to use this abbreviated method to define a duration longer
than one second. To avoid those problems, sRGB and FRAM chunks could be
added after MHDR; the latter would specify an interframe delay--say, five
seconds' worth. Thus the simplest reasonable MNG looks like 
<a href="#png.ch12.fig.2">Figure 12-2</a>. 
</p>


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

      <img width=502 height=186 border=0
       src="figs/png.1202.png" alt="Figure 12-2" /><br>
      <br>
      <b>Figure 12-2:</b>  <i>Layout of the second simplest MNG.</i>

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

<p>Of course, sRGB should only be used if the images are actually in the
standard RGB color space 
(see <a href="chapter10.html">Chapter 10, "Gamma Correction and Precision Color"</a>); 
if not, explicit gamma and chromaticity chunks can be used. Note
that sRGB is only 13 bytes long, so its overhead is negligible.
<?x-space -3p?></p>




</div>
<div class="sect1"><a name="png.ch12.div.4" />
<h2 class="sect1">12.4. An Animated MNG</h2>


<?x-space -2p?><p><a name="INDEX-955" />
<a name="INDEX-956" />As a more complex example, let us take a closer look at how we might create
the animated reindeer example I described earlier. I will assume that a
single cycle of a reindeer's gallop can be represented by six poses
(sprite frames), and I'll further assume that all but the first pose can
be efficiently coded as delta-PNGs. The complete MNG of a single
reindeer galloping across the screen might be structured as shown in
<a href="#png.ch12.fig.3">Figure 12-3</a>. 
</p>


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

      <img width=502 height=474 border=0
       src="figs/png.1203.png" alt="Figure 12-3" /><br>
      <br>
      <b>Figure 12-3:</b>  <i>Layout of an animated MNG.</i>

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

<p>As always, we begin with MHDR, which defines the overall size of the
image area. I've also included a gamma chunk so that the (nighttime)
animation won't look too dark or too bright on other computer
systems. The animation timing is set by the FRAM chunk, and then we
begin loading sprite data for
<a name="INDEX-957" />the six poses. The DEFI chunk (``define image'') is one I haven't
discussed so far; it is included here to set the potential visibility
of the first pose explicitly--in this case, we want the first pose
to be visible. After the IHDR, PLTE, IDAT, and IEND chunks defining
the first pose is a clone chunk, indicating that the second object
(the second pose in the six-pose sequence) is to be created
<a name="INDEX-958" />by copying the first object. The CLON chunk also indicates that the second
object is <em class="emphasis">not</em> potentially visible yet. It is followed by the delta-PNG
chunks that define the second image; we can imagine either that the IDAT
represents a complete replacement for the pixels in the first image, with
the delta part referring to the inheritance of the first image's palette
chunk, or perhaps the second image is truly a pixel-level delta from the
first image. Either way, the third through sixth images are defined similarly.


<?x-space -2p?></p>


<p><a name="INDEX-959" />The heart of the animation is the loop at the end. In this case, I've
included a MOVE chunk, which moves the animation objects to the left by
a few pixels every iteration, and a SHOW chunk to advance the poses
in sequence. If there are 600 iterations in the loop, the animation
will progress through 100 six-pose cycles.</p>


<p>The complete eight-reindeer version would be very similar, but instead of
defining full clones of the sprite frames, each remaining reindeer would
be represented by partial clones of the six original poses. In effect,
a partial clone is an empty object: it has its own object ID, visibility,
and location, but it points at another object for its image data--in this
case, at one of the six existing poses. So the seven remaining
reindeer would be represented by 42 CLON chunks, of which seven would have
the potential-visibility flag turned on. The loop would now include a total
of eight SHOW chunks, each advancing one of the reindeer sprite's poses; a
single MOVE chunk would still suffice to move all eight forward. Of
course, this is still not quite the original design; this version has all
eight reindeer galloping synchronously. To have them gallop at different
rates would require separate FRAM chunks for each one.<a href="#FOOTNOTE-98">[98]</a>


<a name="INDEX-960" />
<a name="INDEX-961" />
</p><blockquote class="footnote">


<a name="FOOTNOTE-98" /><p>[98] Note that Rudolph could be encoded as a set of six tiny delta-PNGs relative
to the six original poses. Of course, to get that realistic
Rudolph glow would require a semitransparent reddish region around his
olfactory appendage, which necessarily involves either an alpha channel or
a full tRNS chunk. But now we're talking True Art, and no sacrifice is too
great.</p>


</blockquote>


















</div>
<div class="sect1"><a name="png.ch12.div.5" />
<h2 class="sect1">12.5. An Algorithmic MNG</h2>


<p><a name="INDEX-962" />
<a name="INDEX-963" />Another good delta-PNG example, but one that creates only a single image
algorithmically, is <em class="emphasis">16million.mng</em>, which I mentioned once or twice
already.  
<a href="#png.ch12.fig.4">Figure 12-4</a> shows its complete contents.
</p>


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

      <img width=502 height=352 border=0
       src="figs/png.1204.png" alt="Figure 12-4" /><br>
      <br>
      <b>Figure 12-4:</b>  <i>Layout of an algorithmic MNG.</i>

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

<p>The initial FRAM chunk defines the structure of the stream as a
composite frame, and it is followed by a DEFI chunk that indicates the
image is potentially visible. The IHDR...IEND sequence defines the
first row of the image (512 pixels wide), with red changing every
pixel and blue incrementing by one at the halfway point. Then the
outer loop begins--we'll return to that in a moment--followed
immediately by the inner loop of 255 iterations. The inner loop
simply increments the green value of every pixel in the row and moves
the modified line down one. The DHDR, IDAT, and IEND chunks represent
this green increment; the delta pixels are simply a sequence of 512
``0 1 0'' triples. As one might guess, they compress extremely well;
the 1,536 data bytes are packed into a total of 20 zlib-compressed
bytes, including six zlib header and trailer bytes.


</p>


<p>The outer loop has the task of resetting the green values to 0 again
(easily accomplished by incrementing them by one more, so they roll over
from 255 to 0) and of incrementing the blue values by two--recall that
the first block of rows had blue = 0 on the left side and blue = 1 on the
right. Thus the delta-PNG data at the bottom of the outer loop consists
of 512 ``0 1 2'' triples, which compress to 23 bytes. Because the blue
increments by two, this loop only needs to interate 128 times. It
actually produces one extra row at the very end, but because this appears
outside the frame boundary (as defined by the MHDR chunk), it is not visible.</p>


















</div>
<div class="sect1"><a name="png.ch12.div.6" />
<h2 class="sect1">12.6. A JPEG Image with Transparency</h2>


<p><a name="INDEX-964" />
<a name="INDEX-965" />
<a name="INDEX-966" />
<a name="INDEX-967" />Finally, let's look at an example of a JPEG image with an interleaved
alpha channel. The particular example shown in
<a href="#png.ch12.fig.5">Figure 12-5</a> is still wrapped inside
a MNG stream, but it could as easily exist standalone if the MHDR and MEND
chunks were removed and the signature changed to the JNG signature.
</p>


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

      <img width=502 height=124 border=0
       src="figs/png.1205.png" alt="Figure 12-5" /><br>
      <br>
      <b>Figure 12-5:</b>  <i>Layout of an alpha-JNG MNG.</i>

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

<p>The JHDR chunk introduces the embedded JNG, defines its dimensions, and
declares it to have an alpha channel. It is followed by an sRGB PNG chunk
that indicates the image is in the International Color Consortium's standard
RGB color space; decoders without access to a color management system should
instead use the predetermined gamma and chromaticity values that approximate
the sRGB color space (see <a href="chapter10.html#png.ch10.tbl.3">Table 10-3</a>).
</p>


<p>The color-space chunk is followed by the IDAT chunks that define the image's
alpha channel and the JDAT chunks that define its main (foreground) image.
We've included a two-way interleave here in order to allow some possibility
of progressive display, but in general one would want to interleave the IDATs
and JDATs after perhaps every 16 or 32 rows--16 is a special number for
JPEG decoders, and 16 or 32 rows is usually a reasonable amount to display
at a time unless the image is quite skinny. On the other hand, keep in
mind that each interleave (interleaf) adds an extra 24 bytes of IDAT/JDAT
wrapper code; this overhead should be balanced against the desired smoothness
of the progressive output.</p>


<p>Note that we've included an IDAT first. This may be a good idea since the
decoder often will be able to start displaying the image before all of the
JDAT arrives, and we've assumed that the alpha channel is simple enough that
the PNG data compressed extremely well (i.e., the IDAT is smaller than
the JDAT of the same region). If the reverse is true, the JDAT should come
first so that the image can be displayed as each line of alpha channel
arrives and is decoded.</p>


<p><a name="INDEX-968" />
<a name="INDEX-969" />Also note that, although I've referred to ``progressive'' display here, 
I am not necessarily referring either to progressive JPEG or to
interlaced PNG. In fact, MNG prohibits interlaced PNG alpha channels in
JNG streams, and progressive JPEG may not mix well even with noninterlaced
alpha channels, depending on how the application is written. The reason is
that the final value of any given pixel will not be known until the JPEG is
almost completely transmitted, and ``approximate rendering'' of partially
transparent pixels (that is, rendering before the final values are known)
requires that the unmodified background image remain available until the
end, so that the approximated pixels can be recomputed during the final pass.
Of course, a sophisticated decoder could display such an image progressively
anyway, but it would incur a substantially greater memory and computational
overhead than would be necessary when displaying a nonprogressive JPEG
interleaved with an alpha channel. Instead, most decoders are likely to
wait for sections of the image (e.g., the first 32 rows) to be competely
transmitted before displaying anything. If progressive JPEG data <em class="emphasis">is</em>
interleaved with the alpha channel, then such decoders will end up waiting
for practically the entire image to be transmitted before even starting to
render, which defeats the purpose of both interleaved JNG and progressive JPEG.




<a name="INDEX-970" />
<a name="INDEX-971" />
<a name="INDEX-972" />
<a name="INDEX-973" />
</p>


















</div>
<div class="sect1"><a name="png.ch12.div.7" />
<h2 class="sect1">12.7. MNG Applications</h2>


<p><a name="INDEX-974" />As of April 1999, there were a total of six applications available that
supported MNG in some form or another, with at least one or two more under
development. The six available applications are listed; four of them
were new in 1998.</p>


<dl>
<dt><b><em class="emphasis">Viewpng</em></b></dt><dd><p><a name="INDEX-975" />
<a name="INDEX-976" />The original MNG application, Viewpng was Glenn
Randers-Pehrson's test bed for PNG- and MNG-related features and modifications.
It has not been actively developed since May 1997, and it runs only under IRIX
on Silicon Graphics (SGI) workstations.</p></dd>

</dl>


<blockquote><pre class="code"><a href="ftp://swrinde.nde.swri.edu/pub/mng/applications/sgi/">ftp://swrinde.nde.swri.edu/pub/mng/applications/sgi/</a></pre></blockquote><dl>
<dt><b><em class="emphasis">ImageMagick</em></b></dt><dd><p><a name="INDEX-977" />This is a viewing and conversion toolkit for the X Window
System; it runs under both Unix and VMS and has supported a minimal subset of
MNG (MHDR, concatenated PNG images, MEND) since November 1997. In particular,
it is capable of converting GIF animations to MNG and then back to GIF.</p></dd>

</dl>


<blockquote><pre class="code"><a href="http://www.wizards.dupont.com/cristy/ImageMagick.html">http://www.wizards.dupont.com/cristy/ImageMagick.html</a></pre></blockquote><dl>
<dt><b><em class="emphasis">MNGeye</em></b></dt><dd><p><a name="INDEX-978" />Probably the most complete MNG decoder yet written, MNGeye was
written by Gerard Juyn starting in May 1998 and runs under 32-bit Windows.
Its author has indicated a willingness to base a MNG reference library on the
code in MNGeye.</p></dd>

</dl>


<blockquote><pre class="code"><a href="http://www.3-t.com/3-T/products/mngi/Homepage.html">http://www.3-t.com/3-T/products/mngi/Homepage.html</a></pre></blockquote><dl>
<dt><b><em class="emphasis">pngcheck</em></b></dt><dd><p><a name="INDEX-979" />A simple command-line program that can be compiled for almost any operating
system, pngcheck simply prints the PNG chunk information in human-readable form
and checks that it conforms to the specification. Partial MNG support was
added by Greg Roelofs beginning in June 1998. Currently, the program does
minimal checking of MNG streams, but it is still useful for listing MNG chunks
and interpreting their contents.</p></dd>

</dl>


<blockquote><pre class="code"><a href="http://www.libpng.org/pub/png/apps/pngcheck.html">http://www.libpng.org/pub/png/apps/pngcheck.html</a></pre></blockquote><dl>
<dt><b><em class="emphasis">PaintShopPro</em></b></dt><dd><p><a name="INDEX-980" />PSP 5.0 uses MNG as the native format in its Animation Shop component,
but it is not clear whether any MNG support is actually visible to the
user.  Paint Shop Pro runs under both 16-bit and 32-bit Windows.</p></dd>

</dl>


<blockquote><pre class="code"><a href="http://www.jasc.com/psp.html">http://www.jasc.com/psp.html</a></pre></blockquote><dl>
<dt><b><em class="emphasis">XVidCap</em></b></dt><dd><p><a name="INDEX-981" />This is a free X-based video-capture application for Unix; it captures
a rectangular area of the screen at intervals and saves the images in
various formats. Originally XVidCap supported the writing of
individual PNG images, but as of its 1.0 release, it also supports
writing MNG streams.</p></dd>

</dl>


<blockquote><pre class="code"><a href="http://home.pages.de/~rasca/xvidcap/">http://home.pages.de/~rasca/xvidcap/</a></pre></blockquote><p>While support for MNG is undeniably still quite sparse, it is
nevertheless encouraging that a handful of applications already
provide support for what has been, in effect, a moving target. Once
MNG settles down (plans were to freeze the spec by May 1999) and is
approved as a specification, and once some form of free MNG
programming library is available to ease the burden on application
developers, broader support can be expected.</p>


<p>New programs will be listed on the MNG applications page,
<a href="http://www.libpng.org/pub/mng/mngapps.html">http://www.libpng.org/pub/mng/mngapps.html</a>.</p>


















</div>
<div class="sect1"><a name="png.ch12.div.8" />
<h2 class="sect1">12.8. The Future?</h2>


<p>MNG's development has not been the same success story that PNG's was,
primarily due to a lesser interest in and need for a new animation
format. Especially with the advent of the World Wide Web, people from
many different walks of life have direct experience with ordinary
images, and, in particular, they are increasingly aware of various
limitations in formats such as GIF and JPEG.  All of this worked (and
continues to work) in PNG's favor. But when it comes to multi-image
formats and animation, not only do these same people have much less
experience, what need they do have for animation is largely met by the
animated GIF format that Netscape made so popular. Animated GIFs may
not be the answer to all of the world's web problems, but they're good
enough 99% of the time. All of this, of course, works against MNG.
</p>


<p>In addition, MNG is decidedly complex; objects may be modified by
other objects, loops may be nested arbitrarily deeply, and so
on. While it is debatable whether MNG is <em class="emphasis">too</em>
complex--certainly there are some who feel it is--even its
principal author freely admits that fully implementing the current
draft specification is a considerable amount of work.</p>


<p>On the positive side, animated GIFs often can be rewritten as MNG
animations in a tiny fraction of the file size, and there are no
patent-fee barriers to implementing MNG in applications. Moreover, the
Multiple-image Network Graphics format <em class="emphasis">is</em> making progress, both
as a mature specification and as a supported format in real
applications, and versions released since March 1999 now include
implementor-friendly subsets known as MNG-LC and MNG-VLC (for Low
Complexity and Very Low Complexity, respectively). Its future looks
good.

<a name="INDEX-982" /></p>

</div>

<PRE>














</PRE>


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

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

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

<div align="center">
  <a href="chapter11.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="chapter13.html"><font size="-1" color="#000000"
   ><b>NEXT</b></font></a>
</div>

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



</body></html>