gif87.htm

刚刚看到本站有Visual C++数字图象处理（人民邮电出版社）的电子书

    graphics interchange format (gif) page 10<br>
    appendix b - interactive sequences<br>
    gif sequence exchanges for an interactive environment<br>
    the following sequences are defined for use in mediating control<br>
    between a gif sender and gif receiver over an interactive communications<br>
    line. these sequences do not apply to applications that involve<br>
    downloading of static gif files and are not considered part of a gif<br>
    file.<br>
    gif capabilities enquiry<br>
    the gce sequence is issued from a host and requests an interactive<br>
    gif decoder to return a response message that defines the graphics<br>
    parameters for the decoder. this involves returning information about<br>
    available screen sizes, number of bits/color supported and the amount of<br>
    color detail supported. the escape sequence for the gce is defined as:<br>
    esc [ &gt; 0 g (g is lower case, spaces inserted for clarity)<br>
    (0x1b 0x5b 0x3e 0x30 0x67)<br>
    gif capabilities response<br>
    the gif capabilities response message is returned by an interactive<br>
    gif decoder and defines the decoder's display capabilities for all<br>
    graphics modes that are supported by the software. note that this can<br>
    also include graphics printers as well as a monitor screen. the general<br>
    format of this message is:<br>
    #version;protocol{;dev, width, height, color-bits, color-res}... &lt;cr&gt;<br>
    '#' - gcr identifier character (number sign)<br>
    version - gif format version number; initially '87a'<br>
    protocol='0' - no end-to-end protocol supported by decoder<br>
    transfer as direct 8-bit data stream.<br>
    protocol='1' - can use an error correction protocol to transfer gif data<br>
    interactively from the host directly to the display.<br>
    dev = '0' - screen parameter set follows<br>
    dev = '1' - printer parameter set follows<br>
    width - maximum supported display width in pixels<br>
    height - maximum supported display height in pixels<br>
    color-bits - number of bits per pixel supported. the number of<br>
    supported colors is therefore 2**color-bits.<br>
    color-res - number of bits per color component supported in the<br>
    hardware color palette. if color-res is '0' then no<br>
    hardware palette table is available.<br>
    note that all values in the gcr are returned as ascii decimal<br>
    numbers and the message is terminated by a carriage return character.<br>
    graphics interchange format (gif) page 11<br>
    appendix b - interactive sequences<br>
    the following gcr message describes three standard ega<br>
    configurations with no printer; the gif data stream can be processed<br>
    within an error correcting protocol:<br>
    #87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2&lt;cr&gt;<br>
    enter gif graphics mode<br>
    two sequences are currently defined to invoke an interactive gif<br>
    decoder into action. the only difference between them is that different<br>
    output media are selected. these sequences are:<br>
    esc [ &gt; 1 g display gif image on screen<br>
    (0x1b 0x5b 0x3e 0x31 0x67)<br>
    esc [ &gt; 2 g display image directly to an attached graphics printer.<br>
    the image may optionally be displayed on the screen as<br>
    well.<br>
    (0x1b 0x5b 0x3e 0x32 0x67)<br>
    note that the 'g' character terminating each sequence is in lower<br>
    case.<br>
    interactive environment<br>
    the assumed environment for the transmission of gif image data from<br>
    an interactive application is a full 8-bit data stream from host to<br>
    micro. all 256 character codes must be transferrable. the establishing<br>
    of an 8-bit data path for communications will normally be taken care of<br>
    by the host application programs. it is however up to the receiving<br>
    communications programs supporting gif to be able to receive and pass on<br>
    all 256 8-bit codes to the gif decoder software.<br>
    graphics interchange format (gif) page 12<br>
    appendix c - image packaging &amp; compression<br>
    the raster data stream that represents the actual output image can<br>
    be represented as:<br>
    7 6 5 4 3 2 1 0<br>
    +---------------+<br>
    | code size | <br>
    +---------------+ ---+<br>
    |blok byte count| |<br>
    +---------------+ |<br>
    : : +-- repeated as many times as necessary<br>
    | data bytes | |<br>
    : : |<br>
    +---------------+ ---+<br>
    . . . . . .<br>
    +---------------+<br>
    |0 0 0 0 0 0 0 0| zero byte count (terminates data stream)<br>
    +---------------+<br>
    the conversion of the image from a series of pixel values to a<br>
    transmitted or stored character stream involves several steps. in brief<br>
    these steps are:<br>
    1. establish the code size - define the number of bits needed to<br>
    represent the actual data.<br>
    2. compress the data - compress the series of image pixels to a series<br>
    of compression codes.<br>
    3. build a series of bytes - take the set of compression codes and<br>
    convert to a string of 8-bit bytes.<br>
    4. package the bytes - package sets of bytes into blocks preceeded by<br>
    character counts and output.<br>
    establish code size<br>
    the first byte of the gif raster data stream is a value indicating<br>
    the minimum number of bits required to represent the set of actual pixel<br>
    values. normally this will be the same as the number of color bits.<br>
    because of some algorithmic constraints however, black &amp; white images<br>
    which have one color bit must be indicated as having a code size of 2.<br>
    this code size value also implies that the compression codes must start<br>
    out one bit longer.<br>
    compression<br>
    the lzw algorithm converts a series of data values into a series of<br>
    codes which may be raw values or a code designating a series of values.<br>
    using text characters as an analogy, the output code consists of a<br>
    character or a code representing a string of characters.<br>
    graphics interchange format (gif) page 13<br>
    appendix c - image packaging &amp; compression<br>
    the lzw algorithm used in gif matches algorithmically with the<br>
    standard lzw algorithm with the following differences:<br>
    1. a special clear code is defined which resets all<br>
    compression/decompression parameters and tables to a start-up state.<br>
    the value of this code is 2**&lt;code size&gt;. for example if the code<br>
    size indicated was 4 (image was 4 bits/pixel) the clear code value<br>
    would be 16 (10000 binary). the clear code can appear at any point<br>
    in the image data stream and therefore requires the lzw algorithm to<br>
    process succeeding codes as if a new data stream was starting.<br>
    encoders should output a clear code as the first code of each image<br>
    data stream.<br>
    2. an end of information code is defined that explicitly indicates the<br>
    end of the image data stream. lzw processing terminates when this<br>
    code is encountered. it must be the last code output by the encoder<br>
    for an image. the value of this code is &lt;clear code&gt;+1.<br>
    3. the first available compression code value is &lt;clear code&gt;+2.<br>
    4. the output codes are of variable length, starting at &lt;code size&gt;+1<br>
    bits per code, up to 12 bits per code. this defines a maximum code<br>
    value of 4095 (hex fff). whenever the lzw code value would exceed<br>
    the current code length, the code length is increased by one. the<br>
    packing/unpacking of these codes must then be altered to reflect the<br>
    new code length.<br>
    build 8-bit bytes<br>
    because the lzw compression used for gif creates a series of<br>
    variable length codes, of between 3 and 12 bits each, these codes must<br>
    be reformed into a series of 8-bit bytes that will be the characters<br>
    actually stored or transmitted. this provides additional compression of<br>
    the image. the codes are formed into a stream of bits as if they were<br>
    packed right to left and then picked off 8 bits at a time to be output.<br>
    assuming a character array of 8 bits per character and using 5 bit codes<br>
    to be packed, an example layout would be similar to:<br>
    byte n byte 5 byte 4 byte 3 byte 2 byte 1<br>
    +-.....-----+--------+--------+--------+--------+--------+<br>
    | and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa|<br>
    +-.....-----+--------+--------+--------+--------+--------+<br>
    note that the physical packing arrangement will change as the<br>
    number of bits per compression code change but the concept remains the<br>
    same.<br>
    package the bytes<br>
    once the bytes have been created, they are grouped into blocks for<br>
    output by preceeding each block of 0 to 255 bytes with a character count<br>
    byte. a block with a zero byte count terminates the raster data stream<br>
    for a given image. these blocks are what are actually output for the<br>
    graphics interchange format (gif) page 14<br>
    appendix c - image packaging &amp; compression<br>
    gif image. this block format has the side effect of allowing a decoding<br>
    program the ability to read past the actual image data if necessary by<br>
    reading block counts and then skipping over the data.<br>
    graphics interchange format (gif) page 15<br>
    appendix d - multiple image processing<br>
    since a gif data stream can contain multiple images, it is<br>
    necessary to describe processing and display of such a file. because<br>
    the image descriptor allows for placement of the image within the<br>
    logical screen, it is possible to define a sequence of images that may<br>
    each be a partial screen, but in total fill the entire screen. the<br>
    guidelines for handling the multiple image situation are:<br>
    1. there is no pause between images. each is processed immediately as<br>
    seen by the decoder.<br>
    2. each image explicitly overwrites any image already on the screen<br>
    inside of its window. the only screen clears are at the beginning<br>
    and end of the gif image process. see discussion on the gif<br>
    terminator.<br>
    &#26;</td>
  </tr>
</table>
</center></div>

<p align="center"><a href="../index.htm">返回</a></p>
</body>
</html>