/
spec-gif89a.txt
2476 lines (1389 loc) · 81.1 KB
/
spec-gif89a.txt
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
Cover Sheet for the GIF89a Specification
DEFERRED CLEAR CODE IN LZW COMPRESSION
There has been confusion about where clear codes can be found in the
data stream. As the specification says, they may appear at anytime. There
is not a requirement to send a clear code when the string table is full.
It is the encoder's decision as to when the table should be cleared. When
the table is full, the encoder can chose to use the table as is, making no
changes to it until the encoder chooses to clear it. The encoder during
this time sends out codes that are of the maximum Code Size.
As we can see from the above, when the decoder's table is full, it must
not change the table until a clear code is received. The Code Size is that
of the maximum Code Size. Processing other than this is done normally.
Because of a large base of decoders that do not handle the decompression in
this manner, we ask developers of GIF encoding software to NOT implement
this feature until at least January 1991 and later if they see that their
particular market is not ready for it. This will give developers of GIF
decoding software time to implement this feature and to get it into the
hands of their clients before the decoders start "breaking" on the new
GIF's. It is not required that encoders change their software to take
advantage of the deferred clear code, but it is for decoders.
APPLICATION EXTENSION BLOCK - APPLICATION IDENTIFIER
There will be a Courtesy Directory file located on CompuServe in the PICS
forum. This directory will contain Application Identifiers for Application
Extension Blocks that have been used by developers of GIF applications.
This file is intended to help keep developers that wish to create
Application Extension Blocks from using the same Application Identifiers.
This is not an official directory; it is for voluntary participation only
and does not guarantee that someone will not use the same identifier.
E-Mail can be sent to Larry Wood (forum manager of PICS) indicating the
request for inclusion in this file with an identifier.
GRAPHICS INTERCHANGE FORMAT(sm)
Version 89a
(c)1987,1988,1989,1990
Copyright
CompuServe Incorporated
Columbus, Ohio
CompuServe Incorporated Graphics Interchange Format
Document Date : 31 July 1990 Programming Reference
Table of Contents
Disclaimer................................................................. 1
Foreword................................................................... 1
Licensing.................................................................. 1
About the Document......................................................... 2
General Description........................................................ 2
Version Numbers............................................................ 2
The Encoder................................................................ 3
The Decoder................................................................ 3
Compliance................................................................. 3
About Recommendations...................................................... 4
About Color Tables......................................................... 4
Blocks, Extensions and Scope............................................... 4
Block Sizes................................................................ 5
Using GIF as an embedded protocol.......................................... 5
Data Sub-blocks............................................................ 5
Block Terminator........................................................... 6
Header..................................................................... 7
Logical Screen Descriptor.................................................. 8
Global Color Table......................................................... 10
Image Descriptor........................................................... 11
Local Color Table.......................................................... 13
Table Based Image Data..................................................... 14
Graphic Control Extension.................................................. 15
Comment Extension.......................................................... 17
Plain Text Extension....................................................... 18
Application Extension...................................................... 21
Trailer.................................................................... 23
Quick Reference Table...................................................... 24
GIF Grammar................................................................ 25
Glossary................................................................... 27
Conventions................................................................ 28
Interlaced Images.......................................................... 29
Variable-Length-Code LZW Compression....................................... 30
On-line Capabilities Dialogue.............................................. 33
1
1. Disclaimer.
The information provided herein is subject to change without notice. In no
event will CompuServe Incorporated be liable for damages, including any loss of
revenue, loss of profits or other incidental or consequential damages arising
out of the use or inability to use the information; CompuServe Incorporated
makes no claim as to the suitability of the information.
2. Foreword.
This document defines the Graphics Interchange Format(sm). The specification
given here defines version 89a, which is an extension of version 87a.
The Graphics Interchange Format(sm) as specified here should be considered
complete; any deviation from it should be considered invalid, including but not
limited to, the use of reserved or undefined fields within control or data
blocks, the inclusion of extraneous data within or between blocks, the use of
methods or algorithms not specifically listed as part of the format, etc. In
general, any and all deviations, extensions or modifications not specified in
this document should be considered to be in violation of the format and should
be avoided.
3. Licensing.
The Graphics Interchange Format(c) is the copyright property of CompuServe
Incorporated. Only CompuServe Incorporated is authorized to define, redefine,
enhance, alter, modify or change in any way the definition of the format.
CompuServe Incorporated hereby grants a limited, non-exclusive, royalty-free
license for the use of the Graphics Interchange Format(sm) in computer
software; computer software utilizing GIF(sm) must acknowledge ownership of the
Graphics Interchange Format and its Service Mark by CompuServe Incorporated, in
User and Technical Documentation. Computer software utilizing GIF, which is
distributed or may be distributed without User or Technical Documentation must
display to the screen or printer a message acknowledging ownership of the
Graphics Interchange Format and the Service Mark by CompuServe Incorporated; in
this case, the acknowledgement may be displayed in an opening screen or leading
banner, or a closing screen or trailing banner. A message such as the following
may be used:
"The Graphics Interchange Format(c) is the Copyright property of
CompuServe Incorporated. GIF(sm) is a Service Mark property of
CompuServe Incorporated."
For further information, please contact :
CompuServe Incorporated
Graphics Technology Department
5000 Arlington Center Boulevard
Columbus, Ohio 43220
U. S. A.
CompuServe Incorporated maintains a mailing list with all those individuals and
organizations who wish to receive copies of this document when it is corrected
2
or revised. This service is offered free of charge; please provide us with your
mailing address.
4. About the Document.
This document describes in detail the definition of the Graphics Interchange
Format. This document is intended as a programming reference; it is
recommended that the entire document be read carefully before programming,
because of the interdependence of the various parts. There is an individual
section for each of the Format blocks. Within each section, the sub-section
labeled Required Version refers to the version number that an encoder will have
to use if the corresponding block is used in the Data Stream. Within each
section, a diagram describes the individual fields in the block; the diagrams
are drawn vertically; top bytes in the diagram appear first in the Data Stream.
Bits within a byte are drawn most significant on the left end. Multi-byte
numeric fields are ordered Least Significant Byte first. Numeric constants are
represented as Hexadecimal numbers, preceded by "0x". Bit fields within a byte
are described in order from most significant bits to least significant bits.
5. General Description.
The Graphics Interchange Format(sm) defines a protocol intended for the on-line
transmission and interchange of raster graphic data in a way that is
independent of the hardware used in their creation or display.
The Graphics Interchange Format is defined in terms of blocks and sub-blocks
which contain relevant parameters and data used in the reproduction of a
graphic. A GIF Data Stream is a sequence of protocol blocks and sub-blocks
representing a collection of graphics. In general, the graphics in a Data
Stream are assumed to be related to some degree, and to share some control
information; it is recommended that encoders attempt to group together related
graphics in order to minimize hardware changes during processing and to
minimize control information overhead. For the same reason, unrelated graphics
or graphics which require resetting hardware parameters should be encoded
separately to the extent possible.
A Data Stream may originate locally, as when read from a file, or it may
originate remotely, as when transmitted over a data communications line. The
Format is defined with the assumption that an error-free Transport Level
Protocol is used for communications; the Format makes no provisions for
error-detection and error-correction.
The GIF Data Stream must be interpreted in context, that is, the application
program must rely on information external to the Data Stream to invoke the
decoder process.
6. Version Numbers.
The version number in the Header of a Data Stream is intended to identify the
minimum set of capabilities required of a decoder in order to fully process the
Data Stream. An encoder should use the earliest possible version number that
includes all the blocks used in the Data Stream. Within each block section in
this document, there is an entry labeled Required Version which specifies the
3
earliest version number that includes the corresponding block. The encoder
should make every attempt to use the earliest version number covering all the
blocks in the Data Stream; the unnecessary use of later version numbers will
hinder processing by some decoders.
7. The Encoder.
The Encoder is the program used to create a GIF Data Stream. From raster data
and other information, the encoder produces the necessary control and data
blocks needed for reproducing the original graphics.
The encoder has the following primary responsibilities.
- Include in the Data Stream all the necessary information to
reproduce the graphics.
- Insure that a Data Stream is labeled with the earliest possible
Version Number that will cover the definition of all the blocks in
it; this is to ensure that the largest number of decoders can
process the Data Stream.
- Ensure encoding of the graphics in such a way that the decoding
process is optimized. Avoid redundant information as much as
possible.
- To the extent possible, avoid grouping graphics which might
require resetting hardware parameters during the decoding process.
- Set to zero (off) each of the bits of each and every field
designated as reserved. Note that some fields in the Logical Screen
Descriptor and the Image Descriptor were reserved under Version
87a, but are used under version 89a.
8. The Decoder.
The Decoder is the program used to process a GIF Data Stream. It processes the
Data Stream sequentially, parsing the various blocks and sub-blocks, using the
control information to set hardware and process parameters and interpreting the
data to render the graphics.
The decoder has the following primary responsibilities.
- Process each graphic in the Data Stream in sequence, without
delays other than those specified in the control information.
- Set its hardware parameters to fit, as closely as possible, the
control information contained in the Data Stream.
9. Compliance.
An encoder or a decoder is said to comply with a given version of the Graphics
Interchange Format if and only if it fully conforms with and correctly
implements the definition of the standard associated with that version. An
4
encoder or a decoder may be compliant with a given version number and not
compliant with some subsequent version.
10. About Recommendations.
Each block section in this document contains an entry labeled Recommendation;
this section lists a set of recommendations intended to guide and organize the
use of the particular blocks. Such recommendations are geared towards making
the functions of encoders and decoders more efficient, as well as making
optimal use of the communications bandwidth. It is advised that these
recommendations be followed.
11. About Color Tables.
The GIF format utilizes color tables to render raster-based graphics. A color
table can have one of two different scopes: global or local. A Global Color
Table is used by all those graphics in the Data Stream which do not have a
Local Color Table associated with them. The scope of the Global Color Table is
the entire Data Stream. A Local Color Table is always associated with the
graphic that immediately follows it; the scope of a Local Color Table is
limited to that single graphic. A Local Color Table supersedes a Global Color
Table, that is, if a Data Stream contains a Global Color Table, and an image
has a Local Color Table associated with it, the decoder must save the Global
Color Table, use the Local Color Table to render the image, and then restore
the Global Color Table. Both types of color tables are optional, making it
possible for a Data Stream to contain numerous graphics without a color table
at all. For this reason, it is recommended that the decoder save the last
Global Color Table used until another Global Color Table is encountered. In
this way, a Data Stream which does not contain either a Global Color Table or
a Local Color Table may be processed using the last Global Color Table saved.
If a Global Color Table from a previous Stream is used, that table becomes the
Global Color Table of the present Stream. This is intended to reduce the
overhead incurred by color tables. In particular, it is recommended that an
encoder use only one Global Color Table if all the images in related Data
Streams can be rendered with the same table. If no color table is available at
all, the decoder is free to use a system color table or a table of its own. In
that case, the decoder may use a color table with as many colors as its
hardware is able to support; it is recommended that such a table have black and
white as its first two entries, so that monochrome images can be rendered
adequately.
The Definition of the GIF Format allows for a Data Stream to contain only the
Header, the Logical Screen Descriptor, a Global Color Table and the GIF
Trailer. Such a Data Stream would be used to load a decoder with a Global Color
Table, in preparation for subsequent Data Streams without a color table at all.
12. Blocks, Extensions and Scope.
Blocks can be classified into three groups : Control, Graphic-Rendering and
Special Purpose. Control blocks, such as the Header, the Logical Screen
Descriptor, the Graphic Control Extension and the Trailer, contain information
used to control the process of the Data Stream or information used in setting
hardware parameters. Graphic-Rendering blocks such as the Image Descriptor and
5
the Plain Text Extension contain information and data used to render a graphic
on the display device. Special Purpose blocks such as the Comment Extension and
the Application Extension are neither used to control the process of the Data
Stream nor do they contain information or data used to render a graphic on the
display device. With the exception of the Logical Screen Descriptor and the
Global Color Table, whose scope is the entire Data Stream, all other Control
blocks have a limited scope, restricted to the Graphic-Rendering block that
follows them. Special Purpose blocks do not delimit the scope of any Control
blocks; Special Purpose blocks are transparent to the decoding process.
Graphic-Rendering blocks and extensions are used as scope delimiters for
Control blocks and extensions. The labels used to identify labeled blocks fall
into three ranges : 0x00-0x7F (0-127) are the Graphic Rendering blocks,
excluding the Trailer (0x3B); 0x80-0xF9 (128-249) are the Control blocks;
0xFA-0xFF (250-255) are the Special Purpose blocks. These ranges are defined so
that decoders can handle block scope by appropriately identifying block labels,
even when the block itself cannot be processed.
13. Block Sizes.
The Block Size field in a block, counts the number of bytes remaining in the
block, not counting the Block Size field itself, and not counting the Block
Terminator, if one is to follow. Blocks other than Data Blocks are intended to
be of fixed length; the Block Size field is provided in order to facilitate
skipping them, not to allow their size to change in the future. Data blocks
and sub-blocks are of variable length to accommodate the amount of data.
14. Using GIF as an embedded protocol.
As an embedded protocol, GIF may be part of larger application protocols,
within which GIF is used to render graphics. In such a case, the application
protocol could define a block within which the GIF Data Stream would be
contained. The application program would then invoke a GIF decoder upon
encountering a block of type GIF. This approach is recommended in favor of
using Application Extensions, which become overhead for all other applications
that do not process them. Because a GIF Data Stream must be processed in
context, the application must rely on some means of identifying the GIF Data
Stream outside of the Stream itself.
15. Data Sub-blocks.
a. Description. Data Sub-blocks are units containing data. They do not
have a label, these blocks are processed in the context of control
blocks, wherever data blocks are specified in the format. The first byte
of the Data sub-block indicates the number of data bytes to follow. A
data sub-block may contain from 0 to 255 data bytes. The size of the
block does not account for the size byte itself, therefore, the empty
sub-block is one whose size field contains 0x00.
b. Required Version. 87a.
6
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Block Size Byte
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | |
+- -+
| | Data Values Byte
+- -+
up | |
+- . . . . -+
to | |
+- -+
| |
+- -+
255 | |
+---------------+
i) Block Size - Number of bytes in the Data Sub-block; the size
must be within 0 and 255 bytes, inclusive.
ii) Data Values - Any 8-bit value. There must be exactly as many
Data Values as specified by the Block Size field.
d. Extensions and Scope. This type of block always occurs as part of a
larger unit. It does not have a scope of itself.
e. Recommendation. None.
16. Block Terminator.
a. Description. This zero-length Data Sub-block is used to terminate a
sequence of Data Sub-blocks. It contains a single byte in the position of
the Block Size field and does not contain data.
b. Required Version. 87a.
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Block Size Byte
+---------------+
i) Block Size - Number of bytes in the Data Sub-block; this field
contains the fixed value 0x00.
ii) Data Values - This block does not contain any data.
7
d. Extensions and Scope. This block terminates the immediately preceding
sequence of Data Sub-blocks. This block cannot be modified by any
extension.
e. Recommendation. None.
17. Header.
a. Description. The Header identifies the GIF Data Stream in context. The
Signature field marks the beginning of the Data Stream, and the Version
field identifies the set of capabilities required of a decoder to fully
process the Data Stream. This block is REQUIRED; exactly one Header must
be present per Data Stream.
b. Required Version. Not applicable. This block is not subject to a
version number. This block must appear at the beginning of every Data
Stream.
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Signature 3 Bytes
+- -+
1 | |
+- -+
2 | |
+---------------+
3 | | Version 3 Bytes
+- -+
4 | |
+- -+
5 | |
+---------------+
i) Signature - Identifies the GIF Data Stream. This field contains
the fixed value 'GIF'.
ii) Version - Version number used to format the data stream.
Identifies the minimum set of capabilities necessary to a decoder
to fully process the contents of the Data Stream.
Version Numbers as of 10 July 1990 : "87a" - May 1987
"89a" - July 1989
Version numbers are ordered numerically increasing on the first two
digits starting with 87 (87,88,...,99,00,...,85,86) and
alphabetically increasing on the third character (a,...,z).
iii) Extensions and Scope. The scope of this block is the entire
Data Stream. This block cannot be modified by any extension.
8
d. Recommendations.
i) Signature - This field identifies the beginning of the GIF Data
Stream; it is not intended to provide a unique signature for the
identification of the data. It is recommended that the GIF Data
Stream be identified externally by the application. (Refer to
Appendix G for on-line identification of the GIF Data Stream.)
ii) Version - ENCODER : An encoder should use the earliest possible
version number that defines all the blocks used in the Data Stream.
When two or more Data Streams are combined, the latest of the
individual version numbers should be used for the resulting Data
Stream. DECODER : A decoder should attempt to process the data
stream to the best of its ability; if it encounters a version
number which it is not capable of processing fully, it should
nevertheless, attempt to process the data stream to the best of its
ability, perhaps after warning the user that the data may be
incomplete.
18. Logical Screen Descriptor.
a. Description. The Logical Screen Descriptor contains the parameters
necessary to define the area of the display device within which the
images will be rendered. The coordinates in this block are given with
respect to the top-left corner of the virtual screen; they do not
necessarily refer to absolute coordinates on the display device. This
implies that they could refer to window coordinates in a window-based
environment or printer coordinates when a printer is used.
This block is REQUIRED; exactly one Logical Screen Descriptor must be
present per Data Stream.
b. Required Version. Not applicable. This block is not subject to a
version number. This block must appear immediately after the Header.
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Logical Screen Width Unsigned
+- -+
1 | |
+---------------+
2 | | Logical Screen Height Unsigned
+- -+
3 | |
+---------------+
4 | | | | | <Packed Fields> See below
+---------------+
5 | | Background Color Index Byte
+---------------+
6 | | Pixel Aspect Ratio Byte
+---------------+
9
<Packed Fields> = Global Color Table Flag 1 Bit
Color Resolution 3 Bits
Sort Flag 1 Bit
Size of Global Color Table 3 Bits
i) Logical Screen Width - Width, in pixels, of the Logical Screen
where the images will be rendered in the displaying device.
ii) Logical Screen Height - Height, in pixels, of the Logical
Screen where the images will be rendered in the displaying device.
iii) Global Color Table Flag - Flag indicating the presence of a
Global Color Table; if the flag is set, the Global Color Table will
immediately follow the Logical Screen Descriptor. This flag also
selects the interpretation of the Background Color Index; if the
flag is set, the value of the Background Color Index field should
be used as the table index of the background color. (This field is
the most significant bit of the byte.)
Values : 0 - No Global Color Table follows, the Background
Color Index field is meaningless.
1 - A Global Color Table will immediately follow, the
Background Color Index field is meaningful.
iv) Color Resolution - Number of bits per primary color available
to the original image, minus 1. This value represents the size of
the entire palette from which the colors in the graphic were
selected, not the number of colors actually used in the graphic.
For example, if the value in this field is 3, then the palette of
the original image had 4 bits per primary color available to create
the image. This value should be set to indicate the richness of
the original palette, even if not every color from the whole
palette is available on the source machine.
v) Sort Flag - Indicates whether the Global Color Table is sorted.
If the flag is set, the Global Color Table is sorted, in order of
decreasing importance. Typically, the order would be decreasing
frequency, with most frequent color first. This assists a decoder,
with fewer available colors, in choosing the best subset of colors;
the decoder may use an initial segment of the table to render the
graphic.
Values : 0 - Not ordered.
1 - Ordered by decreasing importance, most
important color first.
vi) Size of Global Color Table - If the Global Color Table Flag is
set to 1, the value in this field is used to calculate the number
of bytes contained in the Global Color Table. To determine that
actual size of the color table, raise 2 to [the value of the field
+ 1]. Even if there is no Global Color Table specified, set this
field according to the above formula so that decoders can choose
the best graphics mode to display the stream in. (This field is
made up of the 3 least significant bits of the byte.)
vii) Background Color Index - Index into the Global Color Table for
10
the Background Color. The Background Color is the color used for
those pixels on the screen that are not covered by an image. If the
Global Color Table Flag is set to (zero), this field should be zero
and should be ignored.
viii) Pixel Aspect Ratio - Factor used to compute an approximation
of the aspect ratio of the pixel in the original image. If the
value of the field is not 0, this approximation of the aspect ratio
is computed based on the formula:
Aspect Ratio = (Pixel Aspect Ratio + 15) / 64
The Pixel Aspect Ratio is defined to be the quotient of the pixel's
width over its height. The value range in this field allows
specification of the widest pixel of 4:1 to the tallest pixel of
1:4 in increments of 1/64th.
Values : 0 - No aspect ratio information is given.
1..255 - Value used in the computation.
d. Extensions and Scope. The scope of this block is the entire Data
Stream. This block cannot be modified by any extension.
e. Recommendations. None.
19. Global Color Table.
a. Description. This block contains a color table, which is a sequence of
bytes representing red-green-blue color triplets. The Global Color Table
is used by images without a Local Color Table and by Plain Text
Extensions. Its presence is marked by the Global Color Table Flag being
set to 1 in the Logical Screen Descriptor; if present, it immediately
follows the Logical Screen Descriptor and contains a number of bytes
equal to
3 x 2^(Size of Global Color Table+1).
This block is OPTIONAL; at most one Global Color Table may be present
per Data Stream.
b. Required Version. 87a
11
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
d. Extensions and Scope. The scope of this block is the entire Data
Stream. This block cannot be modified by any extension.
e. Recommendation. None.
20. Image Descriptor.
a. Description. Each image in the Data Stream is composed of an Image
Descriptor, an optional Local Color Table, and the image data. Each
image must fit within the boundaries of the Logical Screen, as defined
in the Logical Screen Descriptor.
The Image Descriptor contains the parameters necessary to process a table
based image. The coordinates given in this block refer to coordinates
within the Logical Screen, and are given in pixels. This block is a
Graphic-Rendering Block, optionally preceded by one or more Control
blocks such as the Graphic Control Extension, and may be optionally
followed by a Local Color Table; the Image Descriptor is always followed
by the image data.
This block is REQUIRED for an image. Exactly one Image Descriptor must
be present per image in the Data Stream. An unlimited number of images
may be present per Data Stream.
b. Required Version. 87a.
12
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Image Separator Byte
+---------------+
1 | | Image Left Position Unsigned