Editing GIF (section)

===Uncompressed GIF ===
{| class="wikitable floatright" width=145px
|-
|[[File:Quilt design as 46x46 uncompressed GIF.gif|center]]
{{small|A 46×46 uncompressed GIF with 7-bit symbols (128 colors, 8-bit codes).<br/>Click on the image for an explanation of the code.}}
|}
The GIF encoding process can be modified to create a file without LZW compression that is still viewable as a GIF image. This technique was introduced originally as a way to avoid patent infringement. Uncompressed GIF can also be a useful intermediate format for a graphics programmer because individual pixels are accessible for reading or painting. An uncompressed GIF file can be converted to an ordinary GIF file simply by passing it through an image editor.

The modified encoding method ignores building the LZW table and emits only the root palette codes and the codes for CLEAR and STOP. This yields a simpler encoding (a 1-to-1 correspondence between code values and palette codes) but sacrifices all of the compression: each pixel in the image generates an output code indicating its color index. When processing an uncompressed GIF, a standard GIF decoder will not be prevented from writing strings to its dictionary table, but the code width must never increase since that triggers a different packing of bits to bytes.

If the symbol width is {{mvar|n}}, the codes of width {{math|''n''+1}} fall naturally into two blocks: the lower block of {{math|2{{sup|''n''}}}} codes for coding single symbols, and the upper block of {{math|2{{sup|''n''}}}} codes that will be used by the decoder for sequences of length greater than one. Of that upper block, the first two codes are already taken: {{math|2{{sup|''n''}}}} for CLEAR and {{math|2{{sup|''n''}} + 1}} for STOP. The decoder must also be prevented from using the last code in the upper block, {{math|2<sup>''n''+1</sup> − 1}}, because when the decoder fills that slot, it will increase the code width. Thus in the upper block there are {{math|2{{sup|''n''}} − 3}} codes available to the decoder that won't trigger an increase in code width. Because the decoder is always one step behind in maintaining the table, it does not generate a table entry upon receiving the first code from the encoder, but will generate one for each succeeding code. Thus the encoder can generate {{math|2{{sup|''n''}} − 2}} codes without triggering an increase in code width. Therefore, the encoder must emit extra CLEAR codes at intervals of {{math|2{{sup|''n''}} − 2}} codes or less to make the decoder reset the coding dictionary. The GIF standard allows such extra CLEAR codes to be inserted in the image data at any time. The composite data stream is partitioned into sub-blocks that each carry from 1 to 255 bytes.

For the sample 3×5 image above, the following 9-bit codes represent "clear" (100) followed by image pixels in scan order and "stop" (101).

 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

After the above codes are mapped to bytes, the uncompressed file differs from the compressed file thus:

{| class="wikitable"
! Byte # (hex) !! Hexadecimal !! Text or value !! Meaning 
|-
| 320 || 14 || 20 || 20 bytes uncompressed image data follow
|-
| 321 || 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01 || ||
|-
| 335 || 00 || 0 || End of image data
|}