Graphical Interchange Format , better known by its acronym GIF ( "English respelling pronunciation"> JIF or GHIF ), is a bitmap image format developed by the team on the Service Provider bulletin board (BBS) CompuServe led by American computer scientist Steve Wilhite on June 15, 1987. Since then, it has become widely used on the World Wide Web due to its wide support and portability.
This format supports up to 8 bits per pixel for each image, allowing one image to reference its own palette to 256 different colors selected from the 24-bit RGB color space. It also supports animation and allows separate palettes of up to 256 colors for each frame. The limitation of this palette makes GIF less suitable for reproducing color photos and other images with color gradients, but is perfect for simpler drawings such as graphics or logos with solid color areas.
GIF images are compressed using the lossless data-compression technique Lempel-Ziv-Welch (LZW) to reduce file size without degrading visual quality. This compression technique was patented in 1985. Controversy over licensing agreement between software patent holder Unisys and CompuServe in 1994 encouraged the development of Portable Network Graphics (PNG) standards. In 2004 all relevant patents expired.
Video GIF
Histori
CompuServe introduced GIF on June 15, 1987 to provide a color image format for their file download area, replacing the previous long run-length coding (RLE) encoding format, which is only black and white. GIFs are popular because they use LZW data compression, which is more efficient than the coded path length coding as used by PCX and MacPaint, and large images can be downloaded for a reasonably short time, even with very slow modems.
The original GIF version is called 87a . In 1989, CompuServe released an enhanced version, called 89a , which added support for animated delays (some images in streams already supported at 87a), transparent background colors, and application-specific metadata storage. The 89a specification also supports merging text labels as text (not embedding them in graphical data), but because there is little control over font display, this feature is not widely used. Both versions can be distinguished by viewing the first six bytes of a file ("magic number" or signature), which, when interpreted as ASCII, read "GIF87a" and "GIF89a", respectively.
CompuServe encourages GIF implementation by providing downloadable conversion utilities for multiple computers. In December 1987, for example, Apple IIGS users could see images made on Atari ST or Commodore 64. GIFs are one of the first two image formats commonly used on websites, others are black and white XBMs.
In September 1995, Netscape Navigator 2.0 added the ability to animate GIFs to the loop.
The feature of storing multiple images in one file, accompanied by control data, is widely used on the Web to produce simple animations. The optional interlacing feature, which keeps irregularly scanned image lines in such a way that even some downloaded images are recognizable, also helps the popularity of GIFs, as users can cancel downloads if that is not what is required.
In May 2015, Facebook added GIF support, although initially they did not support GIF on their sites.
Maps GIF
Linguistic Characteristics
As a noun, the word GIF is found in newer editions of many dictionaries. In 2012, the American wing of Oxford University Press acknowledges GIF as a verb also, which means "to create GIF files", as in "GIFing is the perfect medium for sharing scenes from the Summer Olympics". The press lexicograph chose their words this year, saying that the GIF has evolved into "tools with serious applications including research and journalism".
GIF pronunciation
The format creator pronounces the word "jif" with a soft "G" as in "gin". Steve Wilhite said that the intended recitation deliberately echoes American peanut butter brands, Jif, and CompuServe employees often say "Developers Choosy chose GIF", falsifying this brand of TV commercials. The word is now also widely spoken with a loud "G" as in "gift". By 2017, informal polls on the Stack Overflow programming website show some numerical preferences for pronunciation "G", especially among respondents in Eastern Europe, although both "G" are soft and uttering each letter individually found to be popular in Asia and the country -developing country.
The American Heritage Dictionary cites both, showing "jif" as the main pronunciation, while the Cambridge Dictionary of American English offers only a loud "G" pronunciation. Merriam-Webster's Collegiate Dictionary and Oed cite both pronunciations, but put "gif" in default ("\ 'gif,' jif \"). The New Oxford American Dictionary only gives "jif" in the 2nd edition but updates it to "jif, gif" in the 3rd edition.
Disagreement over the pronunciation caused a heated internet debate. On the occasion of receiving a lifetime achievement award at the 2013 Webby Awards ceremony, Wilhite rejected the loud "G" pronunciation, and his speech caused 17,000 posts on Twitter and 50 news articles. The White House and the TV program Jeopardy! is also wading through the debate over 2013.
Usage
- GIF is suitable for sharp line art (like logo) with limited number of colors. It takes advantage of the lossless compression format, which supports a uniformly colored flat field with well-defined edges.
- GIFs can be used to store low color sprite data for games.
- GIFs can be used for small animations and low resolution video clips.
File format
Conceptually, GIF files describe fixed-size graphical areas ("logical screens") filled with zero or more "images". Many GIF files have one image that fills the entire logical screen. Others divide the logical screen into separate sub-images. Images can also serve as animated frames in an animated GIF file, but again this does not need to fill the entire logical screen.
The GIF file starts with a fixed header ("GIF87a" or "GIF89a") that gives the version, followed by a fixed length Logical Screen Descriptor that gives pixel dimensions and other characteristics of the logical screen. Screen descriptor can also specify the existence and size of the Global Color Table, which follows the next if any.
After that, the files are divided into segments, each introduced by a 1-byte sentinel:
- Images (introduced by 0x2C, comma ASCII ',' )
- Extension block (introduced by 0x21, ASCII exclamation '!' )
- Trailer (one byte with value 0x3B, semicolon ASCII ';' ), which should be the last byte of the file.
An image starts with a Fixed Image Descriptor, which can determine the existence and size of the Local Color Table (which follows next if any). The following image data: one byte gives the bit width of an unenccode symbol (which must be at least 2 bits wide, even for bi-color images), followed by a corresponding list of sub-blocks containing LZW encoded data.
Extension blocks (blocks that "extend" the 87a definition through a mechanism already defined in 87a specification) consist of sentinel, an additional byte that specifies the type of extension, and a list of sub-blocks linked with extension data. Blocks of extensions that change the image (such as the Graphic Control Extension that specifies the optional animation delay time and the optional transparent background color) should immediately precede the segment with the image they refer.
The related list used by image data and an extension block consists of a series of sub-blocks, each sub-block starting with a byte giving the next number of bytes of data in sub-blocks (1 to 255). The sub-block circuit is terminated by an empty sub-block (0 bytes).
This structure allows files to be parsed even if not all parts are understood. GIF marked 87a can contain an extension block; meaning the decoder can read and display files without the features covered in the extension that is not understood.
The full details of the file format are covered by the GIF specification.
Palette
GIF based palette: the colors used in the picture (frame) in the file have the RGB value specified in the pallet table that can hold up to 256 entries, and the data for the image refers to the color based on its index (0-255) in the pallet table. The color definition in the palette can be taken from the color space of millions of shadows (2 24 shades, 8 bits for each main), but the maximum number of colors that the frame can use is 256. This Limitations seems to make sense when the GIF developed because few people can afford to buy hardware to display more colors simultaneously. Simple graphics, line drawings, cartoons, and gray scale photos typically require less than 256 colors.
Each frame can designate one index as "transparent background color": Any pixel defined by this index takes pixel color in the same position from the background, which may have been determined by the previous animation frame.
Many techniques, collectively called dithering, have been developed to estimate a wider range of colors with small color palettes by using pixels of two or more colors to approximate the color in between. These techniques sacrifice spatial resolution to estimate deeper color resolution. Although not part of the GIF specification, dithering can be used in an image which is then encoded as a GIF image. This is often not the ideal solution for GIF images, either because the loss of spatial resolution usually makes the image appear blurry on the screen, and because annoying patterns often interfere with the compressibility of image data, work against the main purpose of the GIF.
In the early days of graphic web browsers, graphics cards with 8-bit buffers (allowing only 256 colors) are common and it's common enough to create GIF images using the websafe palette. This ensures a predictable look, but greatly limits color choices. When the 24-bit color becomes the norm palette can instead be filled with the optimum color for individual images.
A small color table might be enough for a small image, and keeping the small color table allows the file to download faster. Both the 87a and 89a specifications allow the color table of 2 n colors for each n from 1 to 8. Most graphics apps will read and display GIFs images with the size of this table; but some do not support all sizes when creating images. Tables 2, 16, and 256 colors are widely supported.
Original color
Although GIF is almost never used for actual color images, it is possible to do so. GIF images can include multiple image blocks, each of which can have its own 256-color palette, and the blocks can be milled to create a complete image. Alternatively, the GIF89a specification introduces a "transparent" color idea in which each image block can include its own 255 visible color palette and one transparent color. Complete images can be created by layering the image blocks with the visible portion of each layer displayed through the transparent portion of the layer above.
To create a full-color image as a GIF, the original image should be split into smaller areas that have no more than 255 or 256 different colors. Each of these areas is then stored as a separate drawing block with its own local palette and when the image block is displayed together (either by stacking or by superimposing some transparent image blocks), a full-color image will appear. For example, splitting an image into tiles 16 by 16 pixels (a total of 256 pixels) ensures that no tiles have more than 256 color local palette borders, although larger tiles can be used and similar colors are combined resulting in the loss of some colors. information.
Because each image block requires its own local color table, GIF files that have many image blocks can be very large, limiting the usefulness of full-color GIFs. Additionally, not all GIF rendering programs handle tiled or layered images correctly. Many rendering programs interpret tiles or layers as animated frames and display them sequentially as unlimited animations with most web browsers automatically displaying frames with a delay of 0.1 seconds or more.
Sample GIF file
Microsoft Paint stores a small black-and-white image as the following GIF file. Cat does not use GIF optimally; because the large unnecessary color table (save 256 full colors instead of used 2) and the width of the symbol, this GIF file is not an efficient representation of the 15-pixel image (described enlarged above).
Although the Graphic Control Extension block declares the color index 16 (hexadecimal 10) to be transparent, the index is not used in the image. The only color indexes that appear in the image data are decimals 40 and 255, each of which is colored to black and white.
Note that the hex numbers in the following table are in the order of small-endian bytes, in accordance with the specified format specifications.
text byte # hexadecimal or (hex) Meaning value 0: 47 49 46       38 38 61 GIF89a Header                                             Logical Screen Descriptor 6: 03 00 3 - the width of the logical screen in pixels 8: 05 00 5 - high logical screen in pixels A: F7 - GCT follows for 256 colors with 3 x 8 bit/primary resolution; The lowest 3 bits representing the min 1 bit depth, the highest true bit means that GCT is present B: 00 0 - background color # 0 C: 00 - the default pixel aspect ratio                  R G B Global Color Table D: 00 00 00 0 0 0 - color # 0 black 10: 80 00 00 128 0 0 - color # 1  :: 85: 00 00 00 0 0 0 - color # 40 black  :: 30A: FF FF 255 255 255 255 - color # 255 white 30D: 21 F9 Graphic Control Extension (this comment field precedes this in most files) 30F: 04 4 - 4 byte of GCE data follow 310: 01 - there is a transparent background color (bit field; lowest bit signifies transparency) 311: 00 00 - delay for animation in one hundredth of a second: not used 313: 10 16 - color # 16 is transparent 314: 00 - end of GCE block 315: Descriptor Figure 2C 316: 00 00 00 00 (0,0) - Angle angle of NW image on logical screen 31A: 03 00 05 00 (3,5) - width and height of image in pixels 31E: 00 - no local color table 31F: 08 8 Start image - LZW minimum code size 320: 0B 11 - 11 bytes LZW encoded image data follows 321: 00 51 FC 1B 28 70 A0 C1 83 01 01 32C: 00 - end of image data 32D: 3B GIF file terminator
Image encoding
Image pixel data, scanned horizontally from the top left, is converted by LZW encoding to a code that is then mapped into bytes to be stored in a file. The pixel code usually does not match the 8-bit size of the byte, so the codes are packaged into bytes by the "little-endian" scheme: the most significant bits of the first code are stored in the most significant bit of the codes. the first byte, the higher-order bit of the code into the higher-order bits of bytes, spills into the lower order bit of the next byte as necessary. Each subsequent code is stored starting from the least significant bits that have not been used yet.
This byte stream is stored in the file as a "sub-block" circuit. Each sub-block has a maximum length of 255 bytes and begins with a byte which indicates the amount of data bytes in the sub-block. The sub-block series is terminated by a blank sub-block (one 0 bytes, indicating a sub-block with 0 bytes of data).
For example images above reversible mapping between 9-bit and byte codes are shown below.
A bit of compression is obvious: pixel colors defined initially at 15 bytes are actually represented by 12 bytes of code including the control code. The encoding process that generates the 9-bit code is shown below. The local string collects the pixel color number from the palette, with no output action as long as the local string can be found in the code table. There is a special treatment of the first two pixels that arrive before the table grows from its initial size with the addition of a string. After each output code, the local string is initialized to the latest pixel color (which can not be included in the output code).
                    9-Table Table                    string - & gt; Code of Action code                   # 0 | 000h Initialize root table 9-bit code                Â... | :                   Â... :           Â 255 | 0FFh                        clr | 100 hours                            the end | 101h                          | 100 hours Clear Local Pixel | color Palette string | BLACK # 40 28 | 028h 1st pixel always be output WHITE # 255 FF | Strings found in the table           Â 28 FF | 102h Always add the first string to the table               FF | Initialize local string WHITE # 255 FF FF | String not found in table                          | 0FFh - the output code for the previous string           Â FF FF | 103jt - add the latest string to the table               FF | - initialize the local string WHITE # 255 FF FF | Strings found in the table BLACK # 40 FF FF 28 | String not found in table                          | 103h - the output code for the previous string                    FF 28 | FF 28 | 104h - add the latest string to the table    Â 28 | - initialize the local string WHITE # 255 28 FF | Strings found in the table WHITE # 255 28 FF FF | String not found in table                          | 102h - the output code for the previous string                 28 FF FF | 105h - add the latest string to the table               FF | - initialize the local string WHITE # 255 FF FF | Strings found in the table WHITE # 255 FF FF FF | String not found in table                          | 103h - the output code for the previous string                FF FF FF | 106h - add the latest string to the table               FF | - initialize the local string WHITE # 255 FF FF | Strings found in the table WHITE # 255 FF FF FF | Strings found in the table WHITE # 255 FF FF FF FF | String not found in table                          | 106h - the output code for the previous string                FF FF FF FF | 107h - add the latest string to the table               FF | - initialize the local string WHITE # 255 FF FF | Strings found in the table WHITE # 255 FF FF FF | Strings found in the table WHITE # 255 FF FF FF FF | Strings found in the table          ·  ·  ·  à  Ã,   Ã,          No more pixels         107h - the output code for the last string                                101 101 End
For clarity the table is shown above as built from an increasingly long string. The scheme works but the table consumes an unpredictable amount of memory. The memory can be stored in practice by noting that each new string to be stored consists of a previously saved string plus one character. It is very economical to store in each address only two words: an existing address and one character.
The LZW algorithm requires a table search for each pixel. A linear search of up to 4096 addresses will make the encoding to be slow. In practice the code can be stored in numerical order; this allows each search to be performed by a SAR (Successive Approximation Register, as used in some ADCs), with only 12 magnitude comparisons. For this efficiency an additional table is needed to convert between actual code and memory address; additional table maintenance is required only when new code is stored that occurs at a rate less than pixel.
Unicorn image
Decoding begins by mapping the stored bytes back to 9-bit code. This is translated to restore pixel colors as shown below. Tables that are identical to those used in the encoder are created by adding strings by this rule:
Is the login code found in the table?  YES: add a string to the local code followed by the first byte string for the login code  NO: add a string to the local code followed by a copy of the first byte itself
     shifted 9-bit ---- & gt; Local Table Pixels code code code - & gt; string Action palette 100hrs 000h | # 0 Initialize root table 9-bit code               Â: | palette               Â: | color                 0FFh | # 255                           100 hours | clr 101h | | | | 101h | | | 101h | end 028h | # 40 BLACK Decode the first pixel 0FFh 028h | The login code is found in the table                     | # 255 WHITE - string output from the table               102h | 28 FF - add to table 103h 0FFh | The login code is not found in the table               103h FF FF - add it to the table                     | - the output string from the table                     | # 255 WHITE                     | # 255 WHITE 102h 103jam | The login code is found in the table                     | - the output string from the table                     | # 40 BLACK                     | # 255 WHITE             Â 104h | FF FF 28 - add to table 103h 102h | The login code is found in the table                     | - the output string from the table                     | # 255 WHITE                     | # 255 WHITE                 105 hours | 28 FF FF - add to table 106 hours 103 hours | The login code is not found in the table                          106hours | FF FF FF - add to table                     | - the output string from the table                     | # 255 WHITE                     | # 255 WHITE                     | # 255 WHITE 107hr 106h | The login code is not found in the table               107 hours | FF FF FF FF - add to table                     | - the output string from the table                     | # 255 WHITE                     | # 255 WHITE                     | # 255 WHITE                     | # 255 WHITE 101h | End
LZW code length
Shorter code lengths can be used for palettes smaller than 256 colors in the example. If the palette is only 64 colors (so the color index is 6 bits wide), the symbol can range from 0 to 63, and the width of the symbol can be taken to 6 bits, with the code starting from 7 bits. In fact, the width of the symbol does not need to match the size of the palette: as long as the translated value is always less than the number of colors in the palette, the symbol can be a width from 2 to 8, and any power palette size from 2 from 2 to 256. For example, the first four colors (values ​​0 to 3) of the palette are used, the symbols can be loaded into 2 bits with codes ranging from 3 bits.
Conversely, the width of the symbol can be set at 8, even if only the values ​​0 and 1 are used; this data only requires 2-color table. Although there would be no point encoding the file that way, something similar usually happens for bi-color images: the minimum symbol width is 2, even if only the 0 and 1 values ​​are used.
The code table initially contains code slightly longer than the size of the symbol to accommodate two special codes clr and end and the code for the strings added during the process. When the table is full the length of the code increases to give more space for the string, until the maximum code is 4095 = FFF (hex). When the decoder builds its tables, it tracks the increase in the length of this code and it is able to disassemble the incoming bytes appropriately.
uncompressed GIF
The GIF encoding process can be modified to create uncompressed LZW files that can still be viewed as GIF images. This technique was originally introduced as a way to avoid patent infringement. An uncompressed GIF can also be a useful intermediate format for graphics programmers because individual pixels can be accessed for reading or painting. An uncompressed GIF file can be converted to a regular GIF file by simply forwarding it through the image editor.
The modified coding method ignores the creation of the LZW table and only emits root and code code for CLEAR and STOP. This results in a simpler encoding (1-to-1 correspondence between code value and palette code) but sacrifices all compression: every pixel in the image produces an output code that shows the color index. When processing an uncompressed GIF, a standard GIF decoder will not be prevented from writing a string to its dictionary table, but the width of the code should not increase because it triggers packing different bits into bytes.
If the width of the symbol is n, the width code n 1 falls naturally into two blocks: the lower block 2 n code for single symbol encoding, and the upper block 2 n code to use by decoder for a sequence of lengths greater than one. From the upper block, the first two codes have been taken: 2 n for CLEAR and 2 n 1 for STOP. Decoders should also be prevented from using the last code in the upper block, 2 n 1 - 1, because when the decoder fills that slot, it will increase the width of the code. So in the top block there are 2 n - 3 codes available for the decoder which will not trigger an increase in code width. Because the decoder is always one step behind in maintaining the table, it does not generate table entries after receiving the first code from the encoder, but will generate one for each subsequent code. Thus the encoder can generate 2 n - 2 codes without triggering the increase in code width. Therefore the encoder must issue an extra CLEAR code with interval 2 n - 2 codes or less to make the decoder reset the encoding dictionary. The GIF standard allows extra extra CLEAR codes to be inserted in the image data at any time. Composite data streams are partitioned into sub-blocks that each carry from 1 to 255 bytes.
For the above 3x5 image example, the following 9-bit code represents "clear" (100) followed by pixel image in the order of scanning and "stop" (101).
9-bit Code: 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
After the above code is mapped to bytes, uncompressed files are different from compressed files thus:
Â: 320: 14 20 20 bytes of uncompressed image data follow 321: 00 51 FC FB F7 0F C5 BF 7F FF FE FB F7 EF DF BF 7F 01 01 335: 00 - end Â:
Compression example
A trivial example of a large solid color image shows the long-variable LZW compression used in GIF files.
The displayed code values ​​are packaged in bytes which are then packed into blocks of up to 255 bytes. The image data block starts with a byte that states the number of bytes to be followed. The last block of data for an image is marked with zero-block bytes.
Interlacing
The GIF specification allows each image in the logical screen of the GIF file to specify that it is interlaced; ie, that the order of the raster lines in the data block is not consecutive. This allows a partial view of a recognizable image before the full picture is painted.
The interlaced image is divided from top to bottom into 8 pixel high strips, and a row of images is presented in the following order:
- Pass 1: Line 0 (top row) of each strip.
- Pass 2: Line 4 of each strip.
- Pass 3: Lines 2 and 6 of each strip.
- Pass 4: Lines 1, 3, 5, and 7 of each strip.
Pixels in each row are not interconnected, but are presented sequentially from left to right. As with non-interlaced images, there is no pause between data for one line and data for the next. Indicator that the interlaced image is slightly set in the image header block.
Animated GIF
Basic animations are added to the GIF89a specification via the Graphic Control Extension (GCE), which allows various images (frames) in the file to be painted with time delays, forming video clips. An animated GIF file consists of a number of consecutively displayed frames, each of which is introduced by the GCE itself, which gives the delay time to wait after the frame is retrieved. The global information at the beginning of the file is valid by default for all frames. The data is stream-oriented, so the offset of files from the beginning of each GCE depends on the previous data length. In each frame, LZW-coded image data is arranged in sub-blocks of up to 255 bytes; the size of each sub-block is expressed by the preceding byte.
By default, however, the animation displays the frame sequence only once, stopping when the last frame is displayed. Because GIF was designed to allow users to define new blocks, Netscape in the 1990s used the Application Extensions block (intended to allow vendors to add application-specific information to GIF files) to implement Netscape Application Block (NAB). This block, placed just before all the animation frames, determines the number of times the frame sequence should be played. (A value of 0 signifies a continuous view.) Support for this repeating animation first appeared in Netscape Navigator version 2.0, and then spread to other browsers. Most browsers now recognize and support NAB, even though it's not part of the GIF89a specification.
The following example shows the animated file structure Rotating earth (large).gif displayed (as a thumbnail) at the top of the article.
text byte # hexadecimal or (hex) Meaning value 0: 47 49 46       38 38 61 GIF89a Header                                            Logical Screen Descriptor 6: 90 01 400 - wide in pixels 8: 90 01 400 - high in pixels A: F7 - GCT follows for 256 colors with 3 x 8 bit/primary resolution B: 00 0 - background color # 0 C: 00 - the default pixel aspect ratio D: Global Color Table : 30D: 21 FF Application Extension Block 30F: 0B 11 - eleven bytes of data follow 310: 4E 45 54       53 43 41        50 45 NETSCAPE - The name of the 8-character application        32 2E 30 2.0 - application "authentication code" 31B: 03 3 - three bytes of data again 31C: 01 1 - index of sub-block data (always 1) 31D: FF FF 65535 - number of undocumented repetitions 31F: 00 - Application Extensions block expired 320: 21 F9 Graphic Control Extension for frame # 1 322: 04 4 - four bytes of data follow 323: 08 - bit-fields 3x: 3: 1: 1, 000 | 010 | 0 | 0 - & gt; Revert to bg color 324: 09 00 - 0.09 seconds delay before painting the next frame 326: 00 - no transparent colors 327: 00 - end of GCE block 328: Descriptor Figure 2C 329: 00 00 00 00 (0,0) - Angle angle of NW at 0,0 32D: 90 01 90 01 (400,400) - Width and frame height: 400 x 400 331: 00 - no local color table; there is no intertwining 332: 08 8 LZW min code size 333: FF 255 - 255 bytes of LZW encoded image data follows 334: data 433: FF 255 - 255 bytes of LZW encoded image data follows               Data Â                Â: 92BA: 00 - end of LZW data for this frame 92BB: 21 F9 Graphic Control Extension for frame # 2  :: 153B7B: 21 F9 Graphic Control Extension for frame # 44 Â: 15CF35: 3B Terminator file
The animation delay for each frame is specified in GCE in one hundredth of a second. Some data economics may be where frames only need to rewrite some of the pixels of the screen, because the Picture Descriptor can define smaller rectangles for review rather than the entire image. Browsers or other displays that do not support GIF animations usually show only the first frame.
The size and color quality of an animated GIF file can vary greatly depending on the application used to create it. Strategies to minimize file size include using a common global color table for all frames (rather than complete local color tables for each frame) and minimizing the number of pixels included in the consecutive frame (so that only pixels change from one frame to the frame). further included in the last frame). Simply packing a series of independent frame images into a composite animation tends to produce large file sizes.
Internet Explorer slows the GIF if the frame rate is 20 frames per second or higher and Microsoft reports that Google Chrome and Safari are also slowing down some GIF animations.
Beginning in early 1995, Ulm University used GIF animations as a live streaming video format to show controllable model trains.
Enforcement of Unisys and LZW patents
In 1977 and 1978, Jacob Ziv and Abraham Lempel published a pair of papers on a new class of lossless data compression algorithms, now collectively referred to as LZ77 and LZ78. In 1983, Terry Welch developed a fast variant of LZ78 which was named Lempel-Ziv-Welch (LZW).
Welch filed a patent application for the LZW method in June 1983. The resulting patent, US 4558302 , granted in December 1985, assigned to Sperry Corporation who later merged with Burroughs Corporation in 1986 and formed Unisys. Further patents are obtained in the UK, France, Germany, Italy, Japan and Canada.
In June 1984, an article by Welch was published in an IEEE magazine that publicly described the LZW technique for the first time. LZW became a popular data compression technique and, when the patent was awarded, Unisys entered into license agreements with more than one hundred companies.
The popularity of the LZW led CompuServe to select it as a compression technique for their GIF version, developed in 1987. At that time, CompuServe was unaware of its patents. Unisys became aware that the GIF version used LZW compression techniques and held licensing negotiations with CompuServe in January 1993. The next agreement was announced on 24 December 1994. Unisys stated that it expects all the major commercial on-line information services companies employing LZW patents to license technology from Unisys at a reasonable rate, but that they will not require licenses, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those used on the on-line service.
After this announcement, there was widespread condemnation from CompuServe and Unisys, and many software developers threatened to stop using GIF. The PNG format (see below) was developed in 1995 as the intended substitute. However, getting support from Web browser makers and other software for PNG format proved difficult and impossible to replace GIFs, although PNG has gradually increased in popularity. Therefore, GIF variations without LZW compression were developed. For example the libungif library, based on Eric S. Raymond's giflib, enables the creation of GIFs that follow the data format but avoids compression features, thus avoiding the use of Liz Unisys patents. A 2001 Dr. Dobb's article described another alternative to LZW compression, based on square root.
In August 1999, Unisys changed the details of their licensing practices, announcing options for certain non-commercial and personal website owners to obtain a one-time license fee for a $ 5,000 or $ 7500 license fee. Such licenses are not required for website owners or users Other GIFs that have used licensed software to generate GIFs. Nevertheless, Unisys is being targeted by thousands of online attacks and rough emails from users who believe they will be charged $ 5000 or sued for using GIF on their website. Despite granting free licenses to hundreds of nonprofits, schools and governments, Unisys really can not generate good publicity and continue to be condemned by individuals and organizations such as the League for Programming Freedom who started the "Burn All GIF" campaign in 1999.
The United States Patent LZW expired on June 20, 2003. The partner patents in English, French, German and Italian ended on June 18, 2004, the Japanese patent expired on June 20, 2004, and the Canadian patent expired on July 7, 2004. Consequently, while Unisys has more patents advanced and patent applications related to improved LZW techniques, GIFs can now be used freely.
Alternative
PNG
Portable Network Graphics (PNG) is designed as a substitute for GIF to avoid Unisys patent infringement on the LZW compression technique. PNG offers better compression and more features than GIF, animation being the only significant exception. PNG is more suitable than GIF in terms where true-color and alpha transparency imaging is required.
Although support for the PNG format is slow, new web browsers generally support PNG. Older versions of Internet Explorer do not support all PNG features. Version 6 and earlier does not support alpha channel transparency without using Microsoft's custom HTML extension. PNG image gamma correction is not supported before version 8, and the display of these images in previous versions may have the wrong color.
For identical 8-bit (or lower) image data, PNG files are typically smaller than equivalent GIFs, because more efficient compression techniques are used in PNG encoding. The complete support of the GIF is very complicated especially by the complex canvas structure that makes it possible, although this allows the animated feature to be concise.
Animated format
MNG was originally developed as a PNG-based solution for animation. MNG reached version 1.0 in 2001, but some apps support it.
In 2006, an extension to the PNG format called APNG was proposed as an alternative to the MNG format by Mozilla. APNG provides the ability to animate PNG files, while maintaining backward compatibility in decoders that can not understand the animated pieces (unlike MNG). Older decoders will only make the first frame of the animation. The PNG Group formally rejected APNG as an official extension on April 20, 2007. There are several subsequent proposals for simple animated graphic formats based on PNG using several different approaches. However, Animated Portable Network Graphics is still under development by Mozilla and is supported in Firefox 3 while MNG support is stopped. APNG is currently supported by most web browsers including Chrome since version 59.0 and Opera and Firefox.
The embedded Adobe Flash and MPEG objects are used on some websites to display simple videos, but require the use of additional browser plugins. WebM and WebP are in development and supported by some web browsers. Other options for web animation include serving individual frames using AJAX, or animating SVG images using JavaScript or SMIL.
With the introduction of extensive support of HTML5 tags & lt; video & gt; in most web browsers, some websites use the looped video tag version generated by the JavaScript functionality. It provides a GIF view, but with the size and speed of the compressed video. Noteworthy examples are Gfycat and Imgur and their GIFV metaphor, which is actually a video tag that plays a compressed MP4 or WebM video.
See also
- Cinemagraph, partially animated photo often in GIF
- Comparison of graph file format
- Comparison of layout engine (graph)
- GIF art, digital art forms associated with GIF
- GNU plotutils (supporting pseudo-GIF, which uses run-length encoding rather than LZW)
- Microsoft GIF Animator, a free program for creating simple GIF animations
- Software patents
References
External links
- GIFLIB Project specification
- gif89a.txt specification GIF 89a on w3.org
- The GIF 89a specification is reformatted to HTML
- LZW and GIF explain
- Animated GIF: a 6-minute documentary produced by Off Book (web series)
- GifCities (GeoCity Animated GIF Search Engine)
Source of the article : Wikipedia
0 Comments