GIF -GIF

GIF
Obracająca się ziemia (duża).gif
Animowany GIF przedstawiający obracającą się kulę ziemską
Rozszerzenie nazwy pliku
.gif
Rodzaj mediów internetowych
image/gif
Kod typu GIFf
Jednolity identyfikator typu (UTI) com.compusserve.gif
magiczny numer GIF87a/GIF89a
Opracowany przez CompuServe
Pierwsze wydanie 15 czerwca 1987 ; 35 lat temu ( 1987-06-15 )
Najnowsze wydanie
89a
1989 ; 33 lata temu ( 1989 )
Rodzaj formatu bezstratny format obrazu bitmapowego
Stronie internetowej www .w3 .org /Grafika /GIF /spec-gif89a .txt

Graphics Interchange Format ( GIF ; / ɪ f / JIF lub / ɡ ɪ f / GHIF , patrz wymowa ) to format obrazu bitmapowego , który został opracowany przez zespół dostawcy usług internetowych CompuServe kierowany przez amerykańskiego informatyka Steve'a Wilhite'a i wydany 15 czerwca 1987 r. Od tego czasu jest szeroko stosowany w sieci WWW ze względu na szerokie wsparcie i przenośność między aplikacjami i systemami operacyjnymi.

Format obsługuje do 8 bitów na piksel dla każdego obrazu, dzięki czemu pojedynczy obraz może odwoływać się do własnej palety do 256 różnych kolorów wybranych z 24 - bitowej przestrzeni kolorów RGB . Obsługuje również animacje i pozwala na oddzielną paletę do 256 kolorów dla każdej klatki. Te ograniczenia palety sprawiają, że GIF jest mniej odpowiedni do reprodukcji kolorowych fotografii i innych obrazów z gradientami kolorów , ale dobrze nadaje się do prostszych obrazów, takich jak grafika lub logo z jednolitymi obszarami koloru.

Obrazy GIF są kompresowane przy użyciu bezstratnej techniki kompresji danych Lempel-Ziv-Welch (LZW) w celu zmniejszenia rozmiaru pliku bez pogorszenia jakości wizualnej. Ta technika kompresji została opatentowana w 1985 roku. Kontrowersje wokół umowy licencyjnej między posiadaczem patentu na oprogramowanie , Unisys i CompuServe w 1994 roku, pobudziły rozwój standardu Portable Network Graphics (PNG). Do 2004 r. wszystkie odnośne patenty wygasły.

Historia

CompuServe wprowadził GIF 15 czerwca 1987 r., aby zapewnić kolorowy format obrazu dla obszarów pobierania plików. Zastąpiło to ich wcześniejszy format kodowania długości przebiegu , który był tylko czarno-biały. GIF stał się popularny, ponieważ używał kompresji danych Lempel–Ziv–Welch . Ponieważ było to bardziej wydajne niż kodowanie run-length używane przez PCX i MacPaint , dość duże obrazy można było pobierać dość szybko nawet przy wolnych modemach .

Oryginalna wersja GIF nosiła nazwę 87a . Ta wersja obsługuje już wiele obrazów w strumieniu.

W 1989 roku CompuServe wypuścił ulepszoną wersję o nazwie 89a . Ta wersja dodała:

  • obsługa opóźnień animacji ,
  • przezroczyste kolory tła,
  • przechowywanie metadanych specyficznych dla aplikacji i
  • włączanie etykiet tekstowych jako tekstu (nie osadzanie ich w danych graficznych),
    ale ponieważ kontrola nad czcionkami wyświetlanymi jest niewielka, funkcja ta nie jest powszechnie stosowana.

Te dwie wersje można odróżnić, patrząc na pierwsze sześć bajtów pliku („ magiczna liczba ” lub podpis), które po zinterpretowaniu jako ASCII czytają odpowiednio „GIF87a” i „GIF89a”.

CompuServe zachęcił do przyjęcia GIF-ów, udostępniając narzędzia do konwersji do pobrania dla wielu komputerów. Na przykład do grudnia 1987 roku użytkownik Apple IIGS mógł oglądać zdjęcia stworzone na Atari ST lub Commodore 64 . GIF był jednym z dwóch pierwszych formatów graficznych powszechnie używanych w witrynach sieci Web, drugim jest czarno-biały XBM .

We wrześniu 1995 Netscape Navigator 2.0 dodał możliwość zapętlania animowanych GIF-ów .

Funkcja przechowywania wielu obrazów w jednym pliku wraz z danymi kontrolnymi jest szeroko wykorzystywana w sieci Web do tworzenia prostych animacji .

Opcjonalna funkcja przeplotu , która przechowuje linie skanowania obrazu w kolejności w taki sposób, że nawet częściowo pobrany obraz był nieco rozpoznawalny, również pomogła popularności GIF, ponieważ użytkownik mógł przerwać pobieranie, jeśli nie było to wymagane.

W maju 2015 Facebook dodał wsparcie dla GIF. W styczniu 2018 Instagram dodał również naklejki GIF do trybu fabularnego.

Terminologia

Jako rzeczownik słowo GIF występuje w nowszych wydaniach wielu słowników. W 2012 roku amerykańskie skrzydło Oxford University Press uznało GIF również za czasownik , co oznacza „utworzyć plik GIF”, ponieważ w tekście „GIFing był idealnym medium do udostępniania scen z Letnich Igrzysk Olimpijskich ”. Leksykografowie prasy głosowali na to słowo roku , mówiąc, że GIF ewoluowały w „narzędzie o poważnych zastosowaniach, w tym badaniach i dziennikarstwie”.

Wymowa

Humorystyczny obrazek zapowiadający uruchomienie konta Tumblr dla Białego Domu sugeruje wymawianie GIF -ów z twardym g .

Wymowa pierwszej litery GIF jest kwestionowana od lat 90. XX wieku. Najczęstsze wymowy w języku angielskim to / ɪ f / ( słuchać ) ( z miękkim g jak w gin ) i / ɡ ɪ f / ( słuchać ) ( z twardym g jak w gift ), różniące się fonemem reprezentowanym przez litera G . Twórcy formatu wymówili akronim GIF jako / ɪ f / , z miękkim g , przy czym Wilhite stwierdził, że jego celem jest celowe naśladowanie wymowy amerykańskiej marki masła orzechowego Jif , a pracownicy CompuServe często żartowali „wybredni programiści wybierają GIF”, parodia telewizyjnych reklam Jifa. Jednak słowo to jest powszechnie wymawiane jako / ɪ f / , z twardym g , a sondaże generalnie wykazały, że ta wymowa twardego g jest bardziej powszechna.

Dictionary.com przytacza obie wymowy, wskazując / ɪ f / jako podstawową wymowę, podczas gdy Cambridge Dictionary of American English oferuje tylko twardą wymowę . Merriam-Webster's Collegiate Dictionary i Oxford Dictionaries przytaczają obie wymowy, ale twarde g należy umieścić na początku: / ɡ ɪ f , ɪ f / . New Oxford American Dictionary podał tylko / ɪ f / w drugim wydaniu, ale zaktualizował go do/ɪ f , ɡ ɪ f / w trzecim wydaniu.

Spór o wymowę wywołał gorącą debatę internetową. Z okazji otrzymania nagrody za całokształt twórczości podczas ceremonii wręczenia nagród Webby w 2013 roku , Wilhite publicznie odrzucił twardą wymowę ; jego przemówienie zaowocowało ponad 17 000 postów na Twitterze i dziesiątkami artykułów prasowych. Biały Dom i program telewizyjny Jeopardy! również wzięła udział w debacie w 2013 r. W lutym 2020 r. The JM Smucker Company , właściciele marki Jif, nawiązali współpracę z bazą danych animowanych obrazów i wyszukiwarką Giphy , aby wydać limitowaną edycję „Jif vs. GIF” ( hasztatowane jako #JIFvsGIF ) słoik z masłem orzechowym, który miał etykietę humorystycznie deklarującą, że wymowa soft- g odnosi się wyłącznie do masła orzechowego, a GIF ma być wymawiane wyłącznie z wymową hard- g .

Stosowanie

GIF-y nadają się do grafik o ostrych krawędziach i ograniczonej liczbie kolorów, takich jak logo. Wykorzystuje to bezstratną kompresję formatu, która faworyzuje płaskie obszary o jednolitym kolorze z dobrze zdefiniowanymi krawędziami. Mogą być również używane do przechowywania danych o słabych kolorach dla gier. GIF-y mogą być używane do małych animacji i klipów wideo o niskiej rozdzielczości lub jako reakcje w wiadomościach online, używane do przekazywania emocji i uczuć zamiast używania słów. Są popularne na platformach społecznościowych, takich jak Tumblr, Facebook i Twitter.

Format pliku

Koncepcyjnie, plik GIF opisuje obszar graficzny o stałym rozmiarze („ekran logiczny”) wypełniony zerem lub większą liczbą „obrazów”. Wiele plików GIF ma jeden obraz, który wypełnia cały ekran logiczny. Inne dzielą ekran logiczny na oddzielne podobrazy. Obrazy mogą również funkcjonować jako klatki animacji w animowanym pliku GIF, ale znowu nie muszą one wypełniać całego logicznego ekranu.

Pliki GIF zaczynają się od nagłówka o stałej długości („GIF87a” lub „GIF89a”), podającego wersję, po którym następuje deskryptor ekranu logicznego o stałej długości, podający wymiary w pikselach i inne cechy ekranu logicznego. Deskryptor ekranu może również określać obecność i rozmiar globalnej tablicy kolorów (GCT), która jest następna, jeśli jest obecna.

Następnie plik jest dzielony na segmenty, z których każdy jest wprowadzany przez 1-bajtowy wskaźnik:

  • Obraz (wprowadzony przez 0x2C, przecinek ASCII ',')
  • Blok rozszerzenia (wprowadzony przez 0x21, wykrzyknik ASCII '!')
  • Trailer (pojedynczy bajt o wartości 0x3B, średnik ASCII ';'), który powinien być ostatnim bajtem pliku.

Obraz zaczyna się od deskryptora obrazu o stałej długości, który może określać obecność i rozmiar Tabeli Kolorów Lokalnych (która jest następna, jeśli jest obecna). Dane obrazu są następujące: jeden bajt podający szerokość bitową niezakodowanych symboli (które muszą mieć co najmniej 2 bity szerokości, nawet w przypadku obrazów dwukolorowych), po którym następuje połączona lista podbloków zawierających dane zakodowane metodą LZW.

Bloki rozszerzeń (bloki, które „rozszerzają” definicję 87a poprzez mechanizm już zdefiniowany w specyfikacji 87a) składają się z wartości sentinel, dodatkowego bajtu określającego typ rozszerzenia oraz połączonej listy podbloków z danymi rozszerzenia. Bloki rozszerzeń, które modyfikują obraz (takie jak rozszerzenie kontroli grafiki, które określa opcjonalny czas opóźnienia animacji i opcjonalny przezroczysty kolor tła) muszą bezpośrednio poprzedzać segment obrazem, do którego się odnoszą.

Połączone listy używane przez dane obrazu i bloki rozszerzeń składają się z serii podbloków, przy czym każdy podblok rozpoczyna się bajtem podającym liczbę kolejnych bajtów danych w podbloku (1 do 255). Seria podbloków jest zakończona pustym podblokem (0 bajt).

Ta struktura umożliwia przeanalizowanie pliku, nawet jeśli nie wszystkie części są zrozumiałe. GIF oznaczony 87a może zawierać bloki rozszerzeń; intencją jest, aby dekoder mógł odczytać i wyświetlić plik bez funkcji objętych rozszerzeniami, których nie rozumie.

Wszystkie szczegóły dotyczące formatu pliku znajdują się w specyfikacji GIF.

Palety

Przykład obrazu GIF zapisanego z paletą bezpieczną w Internecie i poddanego ditheringowi przy użyciu metody Floyda-Steinberga . Ze względu na zmniejszoną liczbę kolorów obrazu występują problemy z wyświetlaniem.

GIF jest oparty na palecie: kolory używane w obrazie (ramce) w pliku mają swoje wartości RGB zdefiniowane w tabeli palet , która może pomieścić do 256 wpisów, a dane obrazu odnoszą się do kolorów według ich indeksów ( 0–255) w tabeli palet. Definicje kolorów w palecie można wyciągnąć z przestrzeni kolorów składającej się z milionów odcieni (2 24 odcienie, 8 bitów na każdy kolor podstawowy), ale maksymalna liczba kolorów, z których może korzystać rama, to 256. To ograniczenie wydawało się rozsądne, gdy opracowano GIF ponieważ niewiele osób mogło sobie pozwolić na sprzęt do jednoczesnego wyświetlania większej liczby kolorów. Proste grafiki, rysunki liniowe, kreskówki i fotografie w skali szarości zwykle wymagają mniej niż 256 kolorów.

Każda ramka może wyznaczyć jeden indeks jako „przezroczysty kolor tła”: każdy piksel, któremu przypisano ten indeks, przyjmuje kolor piksela w tej samej pozycji z tła, który mógł zostać określony przez poprzednią klatkę animacji.

Wiele technik, zbiorczo nazywanych ditheringiem , zostało opracowanych w celu przybliżenia szerszego zakresu kolorów za pomocą małej palety kolorów przy użyciu pikseli o dwóch lub większej liczbie kolorów w celu przybliżenia kolorów pośrednich. Techniki te poświęcają rozdzielczość przestrzenną, aby przybliżyć głębszą rozdzielczość kolorów. Chociaż nie jest to część specyfikacji GIF, dithering może być używany w obrazach następnie zakodowanych jako obrazy GIF. Często nie jest to idealne rozwiązanie dla obrazów GIF, zarówno dlatego, że utrata rozdzielczości przestrzennej zwykle powoduje, że obraz na ekranie wygląda na rozmyty, jak i dlatego, że wzory ditheringu często zakłócają kompresję danych obrazu, co jest sprzeczne z głównym celem GIF.

We wczesnych dniach graficznych przeglądarek internetowych, karty graficzne z 8-bitowymi buforami (pozwalającymi tylko na 256 kolorów) były powszechne i dość powszechne było tworzenie obrazów GIF przy użyciu palety bezpiecznych w sieci . Zapewniało to przewidywalne wyświetlanie, ale mocno ograniczało wybór kolorów. Kiedy kolor 24-bitowy stał się normą, palety można było zapełnić optymalnymi kolorami dla poszczególnych obrazów.

W przypadku małych obrazów może wystarczyć mała tabela kolorów, a utrzymanie małej tabeli kolorów umożliwia szybsze pobieranie pliku. Obie specyfikacje 87a i 89a dopuszczają tabele kolorów z 2 n kolorów dla dowolnych n od 1 do 8. Większość aplikacji graficznych odczytuje i wyświetla obrazy GIF o dowolnym z tych rozmiarów tabel; ale niektóre nie obsługują wszystkich rozmiarów podczas tworzenia obrazów. Szeroko obsługiwane są tabele 2, 16 i 256 kolorów.

Prawdziwy kolor

Chociaż GIF prawie nigdy nie jest używany do obrazów w prawdziwym kolorze , jest to możliwe. Obraz GIF może zawierać wiele bloków obrazu, z których każdy może mieć własną 256-kolorową paletę, a bloki można układać sąsiadująco, aby utworzyć pełny obraz. Alternatywnie, specyfikacja GIF89a wprowadziła ideę „przezroczystego” koloru, w którym każdy blok obrazu może zawierać własną paletę 255 widocznych kolorów plus jeden przezroczysty kolor. Pełny obraz można utworzyć, nakładając na siebie bloki obrazu z widoczną częścią każdej warstwy prześwitującą przez przezroczyste części warstw powyżej.

Animowany GIF ilustrujący technikę wyświetlania ponad typowy limit 256 kolorów

Aby renderować obraz w pełnym kolorze jako GIF, oryginalny obraz musi zostać podzielony na mniejsze regiony zawierające nie więcej niż 255 lub 256 różnych kolorów. Każdy z tych regionów jest następnie przechowywany jako oddzielny blok obrazu z własną lokalną paletą, a gdy bloki obrazu są wyświetlane razem (przez kafelkowanie lub nakładanie warstw częściowo przezroczystych bloków obrazu), pojawia się kompletny, pełnokolorowy obraz. Na przykład rozbicie obrazu na kafelki 16 na 16 pikseli (łącznie 256 pikseli) zapewnia, że ​​żaden kafelek nie ma więcej niż lokalny limit palety 256 kolorów, chociaż mogą być używane większe kafelki i podobne kolory są łączone, co powoduje pewną utratę kolorów Informacja.

Ponieważ każdy blok obrazu może mieć własną lokalną tabelę kolorów, plik GIF zawierający wiele bloków obrazu może być bardzo duży, co ogranicza użyteczność pełnokolorowych plików GIF. Ponadto nie wszystkie programy do renderowania GIF-ów poprawnie obsługują obrazy kafelkowe lub warstwowe. Wiele programów renderujących interpretuje kafelki lub warstwy jako klatki animacji i wyświetla je w sekwencji jako animację, a większość przeglądarek internetowych automatycznie wyświetla klatki z opóźnieniem 0,1 sekundy lub więcej.

Przykładowy plik GIF

Program Microsoft Paint zapisuje mały czarno-biały obraz jako następujący plik GIF (ilustracja w powiększeniu).

Przykładowy obraz (powiększony), rzeczywisty rozmiar 3 piksele szerokości na 5 pikseli
Bajty D h do 30C h w przykładzie definiują paletę 256 kolorów.

Paint nie optymalnie wykorzystuje GIF; ze względu na niepotrzebnie dużą tabelę kolorów (przechowywanie pełnych 256 kolorów zamiast używanych 2) i szerokość symbolu, ten plik GIF nie jest wydajną reprezentacją 15-pikselowego obrazu.

Chociaż blok Graphic Control Extension deklaruje, że indeks koloru 16 (szesnastkowy 10) jest przezroczysty, ten indeks nie jest używany w obrazie. Jedyne indeksy kolorów pojawiające się w danych obrazu to dziesiętne 40 i 255, które Globalna Tablica Kolorów mapuje odpowiednio na czerń i biel.

Zwróć uwagę, że liczby szesnastkowe w poniższych tabelach są ułożone w kolejności bajtów little-endian , zgodnie z zaleceniami specyfikacji formatu.

Tabela przykładowych wartości obrazu GIF
Bajt # (szesnastkowy) Szesnastkowy Tekst lub wartość Oznaczający
0 47 49 46 38 39 61 GIF89a nagłówek
6 03 00 3 Logiczna szerokość ekranu
8 05 00 5 Logiczna wysokość ekranu
A F7 GCT podąża za 256 kolorami z rozdzielczością 3  ×  8 bitów/podstawową, najniższe 3 bity reprezentują głębię bitową minus 1, najwyższy prawdziwy bit oznacza, że ​​GCT jest obecny
B 00 0 Kolor tła: indeks #0; #000000 czarny
C 00 0 Domyślny współczynnik proporcji pikseli, 0:0
D 00 00 00
R (czerwony) G (zielony) B (niebieski)
0 0 0
Globalna tabela kolorów, kolor #0: #000000, czarny
10 80 00 00
R (czerwony) G (zielony) B (niebieski)
128 0 0
Globalna tabela kolorów, kolor nr 1: przezroczysty bit, nieużywany w obrazie
... ... ... Globalna tablica kolorów rozciąga się do 30A
30A FF FF FF
R (czerwony) G (zielony) B (niebieski)
255 255 255
Globalna tabela kolorów, kolor #255: #ffffff, biały
30D 21 F9 Graphic Control Extension (pola komentarza poprzedzają to w większości plików)
30F 04 4 Ilość danych GCE, 4 bajty
310 01 Przezroczysty kolor tła; to jest pole bitowe, najniższy bit oznacza przezroczystość
311 00 00 Opóźnienie animacji w setnych częściach sekundy; nieużywany
313 10 16 Numer koloru przezroczystego piksela w GCT
314 00 Koniec bloku GCE
315 2C Deskryptor obrazu
316 00 00 00 00 (0, 0) Pozycja północno-zachodniego rogu obrazu na ekranie logicznym
31A 03 00 05 00 (3, 5) Szerokość i wysokość obrazu w pikselach
31E 00 0 Lokalny bit tablicy kolorów, 0 oznacza brak
31F 08 8 Początek obrazu, minimalny rozmiar kodu LZW
320 0B 11 Ilość zakodowanego obrazu LZW, 11 bajtów
321 00 51 FC 1B 28 70 A0 C1 83 01 01 <dane obrazu> 11 bajtów danych obrazu, patrz pole 320
32C 00 0 Koniec bloku danych obrazu
32D 3B Zakończenie pliku

Kodowanie obrazu

Dane pikselowe obrazu, skanowane poziomo od górnego lewego rogu, są konwertowane przez kodowanie LZW na kody, które są następnie mapowane na bajty w celu przechowywania w pliku. Kody pikselowe zwykle nie pasują do 8-bitowego rozmiaru bajtów, więc kody są pakowane w bajty według schematu „little-Endian”: najmniej znaczący bit pierwszego kodu jest przechowywany w najmniej znaczącym bicie kodu pierwszy bajt, bity wyższego rzędu kodu na bity wyższego rzędu bajtu, w razie potrzeby rozchodzące się na bity niższego rzędu następnego bajtu. Każdy kolejny kod jest przechowywany począwszy od najmniej znaczącego bitu, który nie został jeszcze użyty.

Ten strumień bajtów jest przechowywany w pliku jako seria „podbloków”. Każdy podblok ma maksymalną długość 255 bajtów i jest poprzedzony bajtem wskazującym liczbę bajtów danych w podbloku. Seria podbloków jest zakończona pustym podblokem (pojedynczy bajt 0, wskazujący podblok z 0 bajtami danych).

Na przykładowym obrazie powyżej odwracalne mapowanie między 9-bitowymi kodami a bajtami pokazano poniżej.

Mapowanie odwracalne
9-bitowy kod Bajt
Szesnastkowy Dwójkowy Dwójkowy Szesnastkowy
100 1 00000000 00000000 00
028 00 0101000 0101000 1 51
0FF 011 111111 111111 00 FC
103 1000 00011 00011 011 1B
102 10000 0010 0010 1000 28
103 100000 011 011 10000 70
106 1000001 10 10 100000 A0
107 10000011 1 1 1000001 C1
10000011 83
101 1 00000001 00000001 01
0000000 1 01

Widoczna jest niewielka kompresja: kolory pikseli zdefiniowane początkowo przez 15 bajtów są dokładnie reprezentowane przez 12 bajtów kodu, w tym kody kontrolne. Poniżej przedstawiono proces kodowania, w wyniku którego powstają kody 9-bitowe. Lokalny ciąg gromadzi liczby kolorów pikseli z palety, bez akcji wyjściowej, o ile lokalny ciąg można znaleźć w tabeli kodów. Pierwsze dwa piksele, które pojawiają się przed powiększeniem tabeli ze swojego początkowego rozmiaru, są traktowane w specjalny sposób przez dodanie ciągów znaków. Po każdym kodzie wyjściowym lokalny ciąg jest inicjowany do najnowszego koloru piksela (który nie mógł zostać uwzględniony w kodzie wyjściowym).

                          Table           9-bit
                     string --> code      code    Action
                          #0 | 000h               Initialize root table of 9-bit codes
                    palette  |  :
                     colors  |  :
                        #255 | 0FFh
                         clr | 100h
                         end | 101h
                             |            100h     Clear
Pixel          Local         |
color Palette  string        |
BLACK  #40     28            |            028h     1st pixel always to output
WHITE  #255    FF            |                     String found in table
                  28 FF      | 102h                Always add 1st string to table
               FF            |                     Initialize local string
WHITE  #255    FF FF         |                     String not found in table
                             |            0FFh     - output code for previous string
                  FF FF      | 103h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
BLACK  #40     FF FF 28      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF 28   | 104h                - add latest string to table
               28            |                     - initialize local string
WHITE  #255    28 FF         |                     String found in table
WHITE  #255    28 FF FF      |                     String not found in table
                             |            102h     - output code for previous string
                  28 FF FF   | 105h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF FF   | 106h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String not found in table
                             |            106h     - output code for previous string
                  FF FF FF FF| 107h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String found in table
                                                   No more pixels
                                          107h     - output code for last string
                                          101h     End

Dla jasności tabela została pokazana powyżej jako zbudowana ze sznurków o coraz większej długości. Ten schemat może działać, ale tabela zużywa nieprzewidywalną ilość pamięci. Pamięć można zaoszczędzić w praktyce, zauważając, że każdy nowy ciąg do zapisania składa się z wcześniej zapisanego ciągu powiększonego o jeden znak. Ekonomiczne jest zapisanie pod każdym adresem tylko dwóch słów: istniejącego adresu i jednego znaku.

Algorytm LZW wymaga przeszukania tabeli dla każdego piksela. Liniowe przeszukiwanie do 4096 adresów spowolniłoby kodowanie. W praktyce kody mogą być przechowywane w kolejności wartości liczbowej; pozwala to na wykonanie każdego wyszukiwania przez SAR (Rejestr Aproksymacji Sukcesu, stosowany w niektórych przetwornikach ADC ), z porównaniami tylko 12 wielkości. Dla tej wydajności potrzebna jest dodatkowa tablica do konwersji między kodami a rzeczywistymi adresami pamięci; dodatkowe utrzymanie tabeli jest potrzebne tylko wtedy, gdy jest przechowywany nowy kod, co dzieje się z dużo mniejszą szybkością niż liczba pikseli.

Dekodowanie obrazu

Dekodowanie rozpoczyna się od odwzorowania zapisanych bajtów z powrotem na kody 9-bitowe. Są one dekodowane w celu odzyskania kolorów pikseli, jak pokazano poniżej. Tablica identyczna jak ta użyta w enkoderze jest budowana przez dodanie ciągów według tej zasady:

Czy w tabeli znajduje się kod przychodzący?
TAk dodaj ciąg dla kodu lokalnego, a następnie pierwszy bajt ciągu dla kodu przychodzącego
Nie dodaj ciąg dla lokalnego kodu, po którym następuje kopia własnego pierwszego bajtu
      shift
9-bit ----> Local      Table                 Pixel
code        code   code --> string   Palette color  Action
100h               000h  | #0                       Initialize root table of 9-bit codes
                    :    | palette
                    :    | colors
                   0FFh  | #255
                   100h  | clr
                   101h  | end
028h                     |             #40   BLACK  Decode 1st pixel
0FFh        028h         |                           Incoming code found in table
                         |             #255  WHITE   - output string from table
                   102h  | 28 FF                     - add to table
103h        0FFh         |                           Incoming code not found in table
                   103h  | FF FF                     - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
102h        103h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #40   BLACK
                         |             #255  WHITE
                   104h  | FF FF 28                  - add to table
103h        102h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                   105h  | 28 FF FF                  - add to table
106h        103h         |                           Incoming code not found in table
                   106h  | FF FF FF                  - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
107h        106h         |                           Incoming code not found in table
                   107h  | FF FF FF FF               - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
101h                     |                           End

Długości kodów LZW

Krótsze długości kodu mogą być użyte dla palet mniejszych niż 256 kolorów w przykładzie. Jeśli paleta zawiera tylko 64 kolory (a więc indeksy kolorów mają szerokość 6 bitów), symbole mogą mieć zakres od 0 do 63, a szerokość symboli może wynosić 6 bitów, przy czym kody zaczynają się od 7 bitów. W rzeczywistości szerokość symbolu nie musi odpowiadać rozmiarowi palety: tak długo, jak dekodowane wartości są zawsze mniejsze niż liczba kolorów w palecie, symbole mogą mieć dowolną szerokość od 2 do 8, a rozmiar palety może mieć dowolną potęgę 2. od 2 do 256. Na przykład, jeśli używane są tylko pierwsze cztery kolory (wartości od 0 do 3) z palety, symbole mogą mieć szerokość 2 bitów z kodami zaczynającymi się od 3 bitów.

I odwrotnie, szerokość symbolu może być ustawiona na 8, nawet jeśli używane są tylko wartości 0 i 1; te dane wymagałyby jedynie dwukolorowej tabeli. Chociaż nie byłoby sensu kodować pliku w ten sposób, coś podobnego zwykle dzieje się w przypadku obrazów dwukolorowych: minimalna szerokość symbolu wynosi 2, nawet jeśli używane są tylko wartości 0 i 1.

Tabela kodów początkowo zawiera kody, które są o jeden bit dłuższe niż rozmiar symbolu, aby pomieścić dwa specjalne kody clr i end oraz kody ciągów, które są dodawane podczas procesu. Gdy tabela jest pełna, długość kodu zwiększa się, aby dać miejsce na więcej ciągów, aż do maksymalnego kodu 4095 = FFF(hex). Gdy dekoder buduje swoją tablicę, śledzi wzrost długości kodu i jest w stanie odpowiednio rozpakować przychodzące bajty.

Nieskompresowany GIF

Nieskompresowany plik GIF 46×46 z 7-bitowymi symbolami (128 kolorów, 8-bitowe kody). Kliknij na obrazek, aby uzyskać wyjaśnienie kodu.

Proces kodowania GIF można zmodyfikować, aby utworzyć plik bez kompresji LZW, który nadal będzie widoczny jako obraz GIF. Ta technika została pierwotnie wprowadzona jako sposób na uniknięcie naruszenia patentu. Nieskompresowany GIF może być również użytecznym formatem pośrednim dla programisty graficznego, ponieważ poszczególne piksele są dostępne do odczytu lub malowania. Nieskompresowany plik GIF można przekonwertować na zwykły plik GIF, po prostu przepuszczając go przez edytor obrazów.

Zmodyfikowana metoda kodowania ignoruje budowanie tabeli LZW i emituje tylko kody palety głównej oraz kody CLEAR i STOP. Daje to prostsze kodowanie (odpowiada 1 do 1 między wartościami kodu i kodami palet), ale poświęca całą kompresję: każdy piksel obrazu generuje kod wyjściowy wskazujący jego indeks koloru. Podczas przetwarzania nieskompresowanego GIF-a, standardowy dekoder GIF nie będzie uniemożliwiał zapisywania ciągów do swojej tabeli słownikowej, ale szerokość kodu nigdy nie może się zwiększać, ponieważ powoduje to inne pakowanie bitów do bajtów.

Jeśli szerokość symbolu wynosi n , kody o szerokości n +1 w sposób naturalny dzielą się na dwa bloki: dolny blok 2 n kodów do kodowania pojedynczych symboli i górny blok 2 n kodów, które będą używane przez dekoder dla sekwencji długość większa niż jeden. Z tego górnego bloku, pierwsze dwa kody są już zajęte: 2 n dla CLEAR i 2 n + 1 dla STOP. Dekoder musi być również zabezpieczony przed użyciem ostatniego kodu w górnym bloku, 2 n +1 − 1 , ponieważ gdy dekoder zapełni tę szczelinę, zwiększy szerokość kodu. Tak więc w górnym bloku dostępne są dla dekodera 2 n - 3 kody, które nie powodują zwiększenia szerokości kodu. Ponieważ dekoder jest zawsze o krok za utrzymywaniem tabeli, nie generuje wpisu w tabeli po otrzymaniu pierwszego kodu z kodera, ale generuje jeden dla każdego kolejnego kodu. W ten sposób enkoder może generować 2 n − 2 kody bez wyzwalania wzrostu szerokości kodu. Dlatego koder musi emitować dodatkowe kody CLEAR w odstępach 2 n - 2 kodów lub mniej, aby dekoder zresetował słownik kodowania. Standard GIF umożliwia wstawianie takich dodatkowych kodów CLEAR do danych obrazu w dowolnym momencie. Złożony strumień danych jest podzielony na podbloki, z których każdy zawiera od 1 do 255 bajtów.

Dla przykładowego obrazu 3×5 powyżej, następujące 9-bitowe kody reprezentują „czysty” (100), po którym następują piksele obrazu w kolejności skanowania i „stop” (101).

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

Po zmapowaniu powyższych kodów na bajty plik nieskompresowany różni się od pliku skompresowanego w ten sposób:

Bajt # (szesnastkowy) Szesnastkowy Tekst lub wartość Oznaczający
320 14 20 Następuje 20 bajtów nieskompresowanych danych obrazu
321 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335 00 0 Koniec danych obrazu

Przykład kompresji

Trywialny przykład dużego obrazu w jednolitym kolorze pokazuje kompresję LZW o zmiennej długości używaną w plikach GIF.

Przykładowa kompresja pliku GIF
Kod Piksele Uwagi
Nie.
N i
Wartość
Ni + 256
Długość
(bity)
Ten kod
N i
Skumulowane
N i (N i + 1)/2
Relacje przy użyciu N i dotyczą tylko pikseli tego samego koloru, dopóki tabela kodowania nie będzie pełna.
0 100h 9 Wyczyść tabelę kodów
1 FFh 1 1 Kolor górnego lewego piksela wybrany jako najwyższy indeks z 256-kolorowej palety
2 102h 2 3
3
255
103h
1FFh
3
255
6
32640
Ostatni 9-bitowy kod
256
767
200h
3FFh
10 256
767
32896
294528
Ostatni 10-bitowy kod
768
1791
400h
7FFh
11 768
1791
295296
1604736
Ostatni 11-bitowy kod
1792
3839
800h
FFFh
12 1792
3839
1606528
7370880
Pełna tabela kodów
FFFh 3839 Maksymalny kod może się powtarzać w przypadku większej liczby pikseli tego samego koloru.
Całkowita kompresja danych asymptotycznie zbliża się do 3839 ×8/12= 2559+1/3
101h Koniec danych obrazu

Wyświetlane wartości kodu są pakowane w bajty, które są następnie pakowane w bloki do 255 bajtów. Blok danych obrazu zaczyna się od bajtu, który deklaruje liczbę bajtów, które mają nastąpić. Ostatni blok danych dla obrazu jest oznaczony bajtem o zerowej długości bloku.

Przeplatanie

Specyfikacja GIF pozwala każdemu obrazowi na ekranie logicznym pliku GIF określić, że jest z przeplotem; tj. kolejność linii rastrowych w jego bloku danych nie jest sekwencyjna. Pozwala to na częściowe wyświetlenie obrazu, który można rozpoznać przed namalowaniem całego obrazu.

Obraz z przeplotem jest podzielony od góry do dołu na paski o wysokości 8 pikseli, a rzędy obrazu są prezentowane w następującej kolejności:

  • Przebieg 1: Linia 0 (najwyższa linia) z każdego paska.
  • Pass 2: Linia 4 z każdego paska.
  • Przejście 3: Linie 2 i 6 z każdego paska.
  • Przejście 4: Linie 1, 3, 5 i 7 z każdego paska.

Piksele w każdej linii nie są przeplatane, ale prezentowane kolejno od lewej do prawej. Podobnie jak w przypadku obrazów bez przeplotu, nie ma przerwy między danymi z jednej linii a danymi z następnej. Wskaźnikiem, że obraz jest z przeplotem, jest bit ustawiony w odpowiednim bloku deskryptora obrazu.

Animowany gif

GIF może służyć do wyświetlania animacji, tak jak na tym obrazie kołyski Newtona .
Animacja GIF złożona z dwóch zdjęć, z których jedno przechodzi w drugie

Chociaż GIF nie został zaprojektowany jako nośnik animacji, jego zdolność do przechowywania wielu obrazów w jednym pliku naturalnie sugeruje użycie formatu do przechowywania klatek sekwencji animacji. Aby ułatwić wyświetlanie animacji, w specyfikacji GIF89a dodano rozszerzenie Graphic Control Extension (GCE), które umożliwia malowanie obrazów (klatek) w pliku z opóźnieniem czasowym, tworząc klip wideo . Każda klatka w animacji GIF jest wprowadzana przez własne GCE, określające opóźnienie czasu oczekiwania po narysowaniu klatki. Globalne informacje na początku pliku dotyczą domyślnie wszystkich ramek. Dane są zorientowane na strumień, więc przesunięcie pliku początku każdego GCE zależy od długości poprzedzających danych. Wewnątrz każdej ramki dane obrazu kodowane LZW są ułożone w podblokach do 255 bajtów; rozmiar każdego podbloku jest deklarowany przez poprzedzający go bajt.

Domyślnie animacja wyświetla sekwencję klatek tylko raz, zatrzymując się po wyświetleniu ostatniej klatki. Aby umożliwić zapętlenie animacji, Netscape w latach 90. używał bloku Application Extension (który miał umożliwić dostawcom dodawanie informacji specyficznych dla aplikacji do pliku GIF) do implementacji Bloku aplikacji Netscape (NAB). Ten blok, umieszczony bezpośrednio przed sekwencją klatek animacji, określa, ile razy sekwencja powinna zostać odtworzona (1 do 65535 razy) lub że powinna się powtarzać w sposób ciągły (zero oznacza pętlę na zawsze). Obsługa tych powtarzających się animacji pojawiła się najpierw w Netscape Navigator w wersji 2.0, a następnie rozprzestrzeniła się na inne przeglądarki. Większość przeglądarek rozpoznaje i obsługuje NAB, chociaż nie jest to ściśle część specyfikacji GIF89a.

Poniższy przykład pokazuje strukturę pliku animacji Obracająca się ziemia (duża).gif pokazanego (jako miniatura) w infoboksie artykułu.

Struktura GIF
Bajt # (szesnastkowy) Szesnastkowy Tekst lub wartość Oznaczający
0 47 49 46 38 39 61 GIF89a Logiczny deskryptor ekranu
6 90 01 400 Szerokość w pikselach
8 90 01 400 Wysokość w pikselach
A F7 GCT podąża za 256 kolorami z rozdzielczością 3  ×  8 bitów/podstawowy
B 00 0 Kolor tła: #000000, czarny
C 00 0 Domyślny współczynnik proporcji pikseli, 0:0
D 00 Globalna tabela kolorów
30D 21 FF Rozszerzenie aplikacji
30F 0B 11 Rozmiar bloku, w tym nazwa aplikacji i bajty weryfikacji (zawsze 11)
310 4E 45 54 53 43 41 50 45 32 2E 30 NETSCAPE2.0 8-bajtowa nazwa aplikacji plus 3 bajty weryfikacyjne
31B 03 3 Liczba bajtów w kolejnym podbloku
31C 01 1 Indeks bieżącego podbloku danych (zawsze 1 dla bloku NETSCAPE)
31D FF FF 65535 Nieoznaczona liczba powtórzeń
31F 00 Koniec łańcucha podbloków dla bloku Application Extension
320 21 F9 Rozszerzenie graficznego sterowania dla ramy nr 1
322 04 4 Liczba bajtów (4) w bieżącym podbloku
323 04
000.....
...001..
......0.
.......0
(podzielony na sekcje dla łatwiejszego czytania)
Zarezerwowane, 5 niższych bitów to pole bitowe
Sposób utylizacji 1: nie wyrzucaj
Brak danych wprowadzonych przez użytkownika
Kolor przezroczysty, 0 oznacza brak danych
324 09 00 9 Opóźnienie ramki: 0,09 sekundy opóźnienia przed malowaniem następnej klatki
326 FF Indeks koloru transparentnego (nieużywany w tej ramce)
327 00 Koniec łańcucha podbloków dla bloku rozszerzenia sterowania graficznego
328 2C Obraz Deskryptor ramki nr 1
329 00 00 00 00 (0, 0) Pozycja północno-zachodniego rogu obrazu na ekranie logicznym: (0, 0)
32D 90 01 90 01 (400, 400) Szerokość i wysokość ramki: 400  ×  400 pikseli
331 00 0 Lokalna tablica kolorów: 0 oznacza brak i brak przeplotu
332 08 8 Minimalny rozmiar kodu LZW dla danych obrazu klatki nr 1
333 FF 255 Liczba bajtów danych obrazu LZW w następującym podbloku: 255 bajtów
334 ... <dane obrazu> Dane obrazu, 255 bajtów
433 FF 255 Liczba bajtów danych obrazu LZW w kolejnym podbloku, 255 bajtów
434 ... <dane obrazu> Dane obrazu, 255 bajtów
Powtórz dla następnych bloków
92C0 00 Koniec łańcucha podbloków dla tej ramki
92C1 21 F9 Rozszerzenie graficznego sterowania dla ramy nr 2
Powtórz dla następnych klatek
EDABD 21 F9 Rozszerzenie graficznego sterowania do ramy #44
Informacje o obrazie i dane dla klatki #44
F48F5 3B Zwiastun: Ostatni bajt w pliku, sygnalizujący EOF

Opóźnienie animacji dla każdej klatki jest określone w GCE w setnych częściach sekundy. Pewna oszczędność danych jest możliwa, gdy ramka wymaga tylko przepisania części pikseli wyświetlacza, ponieważ Deskryptor obrazu może zdefiniować mniejszy prostokąt do ponownego skanowania zamiast całego obrazu. Przeglądarki lub inne wyświetlacze, które nie obsługują animowanych plików GIF, zazwyczaj wyświetlają tylko pierwszą klatkę.

Rozmiar i jakość kolorów animowanych plików GIF może się znacznie różnić w zależności od aplikacji użytej do ich utworzenia. Strategie minimalizowania rozmiaru pliku obejmują używanie wspólnej globalnej tabeli kolorów dla wszystkich klatek (zamiast kompletnej lokalnej tabeli kolorów dla każdej klatki) oraz minimalizację liczby pikseli pokrywanych w kolejnych klatkach (tak, aby tylko piksele zmieniały się z jednej klatki na następne są zawarte w drugiej ramce). Bardziej zaawansowane techniki obejmują modyfikowanie sekwencji kolorów w celu lepszego dopasowania do istniejącego słownika LZW, co jest formą kompresji stratnej . Proste pakowanie serii niezależnych obrazów klatek do złożonej animacji daje zwykle duże rozmiary plików. Dostępne są narzędzia do minimalizowania rozmiaru pliku w istniejącym pliku GIF.

Metadane

Metadane mogą być przechowywane w plikach GIF jako blok komentarza, blok zwykłego tekstu lub blok rozszerzenia aplikacji specyficznej dla aplikacji. Kilka edytorów graficznych używa nieoficjalnych bloków rozszerzeń aplikacji, aby uwzględnić dane użyte do wygenerowania obrazu, aby można go było odzyskać do dalszej edycji.

Wszystkie te metody technicznie wymagają podziału metadanych na podbloki, aby aplikacje mogły poruszać się po bloku metadanych bez znajomości jego wewnętrznej struktury.

Standard metadanych Extensible Metadata Platform (XMP) wprowadził nieoficjalny, ale obecnie szeroko rozpowszechniony blok rozszerzeń aplikacji „XMP Data” do włączania danych XMP do plików GIF. Ponieważ dane XMP są kodowane przy użyciu UTF-8 bez znaków NUL, w danych nie ma 0 bajtów. Zamiast dzielić dane na formalne podbloki, blok rozszerzenia kończy się „magicznym zwiastunem”, który kieruje każdą aplikację traktującą dane jako podbloki do końcowego bajtu 0, który kończy łańcuch podbloków.

Egzekwowanie patentów Unisys i LZW

W 1977 i 1978 roku Jacob Ziv i Abraham Lempel opublikowali parę artykułów na temat nowej klasy algorytmów bezstratnej kompresji danych, obecnie określanych zbiorczo jako LZ77 i LZ78 . W 1983 roku Terry Welch opracował szybki wariant LZ78, który nazwano Lempel–Ziv–Welch (LZW).

Welch złożył wniosek patentowy na metodę LZW w czerwcu 1983 r. Otrzymany patent, US4558302, przyznany w grudniu 1985 r., został przydzielony firmie Sperry Corporation , która następnie połączyła się z Burroughs Corporation w 1986 r. i utworzyła Unisys . Kolejne patenty uzyskano w Wielkiej Brytanii, Francji, Niemczech, Włoszech, Japonii i Kanadzie.

Oprócz powyższych patentów, patent Welcha z 1983 r. zawiera również cytaty z kilku innych patentów, które miały na niego wpływ, w tym:

  • dwa japońskie patenty z 1980 roku z NEC Jun Kanatsu,
  • Patent USA 4 021 782 (1974) od Johna S. Hoerninga,
  • Patent USA 4,366,551 (1977) od Klausa E. Holtza, oraz
  • niemiecki patent z 1981 roku od Karla Eckharta Heinza.

W czerwcu 1984 roku w magazynie IEEE opublikowano artykuł Welcha , który po raz pierwszy publicznie opisał technikę LZW. LZW stał się popularną techniką kompresji danych, a po przyznaniu patentu Unisys zawarł umowy licencyjne z ponad setką firm.

Popularność LZW skłoniła CompuServe do wybrania go jako techniki kompresji dla swojej wersji GIF, opracowanej w 1987 roku. W tym czasie CompuServe nie wiedział o patencie. Unisys dowiedział się, że wersja GIF wykorzystuje technikę kompresji LZW i rozpoczął negocjacje licencyjne z CompuServe w styczniu 1993 roku. Kolejną umowę ogłoszono 24 grudnia 1994 roku. Patent LZW na licencjonowanie technologii firmy Unisys za rozsądną stawkę, ale nie wymagałoby to licencjonowania ani uiszczania opłat za niekomercyjne, non-profit aplikacje oparte na GIF, w tym te do użytku w usługach on-line .

Po tym ogłoszeniu pojawiło się powszechne potępienie CompuServe i Unisys, a wielu programistów groziło, że przestanie używać GIF-ów. Format PNG (patrz poniżej) został opracowany w 1995 roku jako zamierzony zamiennik. Jednak uzyskanie wsparcia od twórców przeglądarek internetowych i innego oprogramowania dla formatu PNG okazało się trudne i nie było możliwe zastąpienie GIF-a, chociaż popularność formatu PNG stopniowo rosła. Dlatego opracowano odmiany GIF bez kompresji LZW. Na przykład biblioteka libungif, oparta na giflib Erica S. Raymonda , umożliwia tworzenie plików GIF zgodnych z formatem danych, ale bez funkcji kompresji, co pozwala uniknąć korzystania z patentu Unisys LZW. Artykuł dr. Dobba z 2001 r. opisuje inną alternatywę dla kompresji LZW, opartą na pierwiastkach kwadratowych.

W sierpniu 1999 r. firma Unisys zmieniła szczegóły swojej praktyki licencyjnej, ogłaszając możliwość uzyskania licencji przez właścicieli niektórych niekomercyjnych i prywatnych witryn internetowych po uiszczeniu jednorazowej opłaty licencyjnej w wysokości 5000 USD lub 7500 USD. Takie licencje nie były wymagane dla właścicieli witryn lub innych użytkowników GIF-ów, którzy używali licencjonowanego oprogramowania do generowania GIF-ów. Niemniej jednak Unisys był przedmiotem tysięcy ataków online i obraźliwych wiadomości e-mail od użytkowników, którzy wierzyli, że zostanie obciążony opłatą w wysokości 5000 USD lub pozwany za używanie GIF-ów na swoich stronach internetowych. Pomimo udzielania bezpłatnych licencji setkom organizacji non-profit, szkołom i rządom, Unisys nie był w stanie wygenerować dobrego rozgłosu i nadal był potępiany przez osoby i organizacje, takie jak League for Programming Freedom , która rozpoczęła kampanię „Spal wszystkie GIF-y” w 1999.

Amerykański patent LZW wygasł 20 czerwca 2003 r. Odpowiedniki patentów w Wielkiej Brytanii, Francji, Niemczech i Włoszech wygasły 18 czerwca 2004 r., japońskie wygasły 20 czerwca 2004 r., a kanadyjski patent wygasł 7 lipca 2004 r. W konsekwencji , podczas gdy Unisys posiada kolejne patenty i zgłoszenia patentowe dotyczące ulepszeń techniki LZW, sam LZW (a w konsekwencji GIF) może być swobodnie używany od lipca 2004 roku.

Alternatywy

PNG

Portable Network Graphics (PNG) został zaprojektowany jako zamiennik GIF-a, aby uniknąć naruszenia patentu Unisys na technikę kompresji LZW. PNG oferuje lepszą kompresję i więcej funkcji niż GIF, a animacja jest jedynym znaczącym wyjątkiem. Format PNG jest bardziej odpowiedni niż GIF w przypadkach, w których wymagane jest odwzorowanie prawdziwych kolorów i przezroczystość alfa .

Chociaż obsługa formatu PNG przychodziła powoli, nowe przeglądarki internetowe obsługują format PNG. Starsze wersje Internet Explorera nie obsługują wszystkich funkcji PNG. Wersje 6 i wcześniejsze nie obsługują przezroczystości kanału alfa bez użycia rozszerzeń HTML specyficznych dla firmy Microsoft. Korekcja gamma obrazów PNG nie była obsługiwana przed wersją 8, a wyświetlanie tych obrazów we wcześniejszych wersjach może mieć niewłaściwy odcień.

W przypadku identycznych 8-bitowych (lub niższych) danych obrazu pliki PNG są zwykle mniejsze niż odpowiadające im pliki GIF ze względu na bardziej wydajne techniki kompresji stosowane w kodowaniu PNG. Pełna obsługa GIF jest skomplikowana głównie ze względu na złożoną strukturę płótna, na którą pozwala, chociaż to właśnie umożliwia kompaktowe funkcje animacji.

Formaty animacji

Filmy rozwiązują wiele problemów związanych z GIF-ami, które są powszechnie używane w sieci. Obejmują one drastycznie mniejsze rozmiary plików , możliwość przekroczenia ograniczenia 8-bitowego koloru oraz lepszą obsługę ramek i kompresję za pomocą kodeków . Praktycznie powszechna obsługa formatu GIF w przeglądarkach internetowych oraz brak oficjalnej obsługi wideo w standardzie HTML spowodowały, że GIF zyskał na znaczeniu w celu wyświetlania w sieci krótkich plików wideo.

  • MNG ("Multiple-image Network Graphics") został pierwotnie opracowany jako rozwiązanie oparte na PNG dla animacji. MNG osiągnął wersję 1.0 w 2001 roku, ale niewiele aplikacji ją obsługuje.
  • APNG („Animated Portable Network Graphics”) został zaproponowany przez Mozillę w 2006 roku. APNG jest rozszerzeniem formatu PNG jako alternatywą dla formatu MNG. APNG jest obsługiwany przez większość przeglądarek od 2019 r. APNG zapewnia możliwość animowania plików PNG przy zachowaniu kompatybilności wstecznej w dekoderach, które nie potrafią zrozumieć fragmentu animacji (w przeciwieństwie do MNG). Starsze dekodery po prostu wyrenderują pierwszą klatkę animacji.
Grupa PNG oficjalnie odrzuciła APNG jako oficjalne rozszerzenie w dniu 20 kwietnia 2007 r.
Pojawiło się kilka kolejnych propozycji prostego formatu animowanej grafiki opartego na PNG przy użyciu kilku różnych podejść. Niemniej jednak APNG jest nadal rozwijany przez Mozillę i jest obsługiwany w Firefoksie 3.0 , podczas gdy obsługa MNG została porzucona. APNG jest obecnie obsługiwany przez wszystkie główne przeglądarki internetowe, w tym Chrome (od wersji 59.0), Opera, Firefox i Edge.
  • Osadzone obiekty Adobe Flash i
  • Pliki MPEG były używane na niektórych stronach internetowych do wyświetlania prostego wideo, ale wymagały użycia dodatkowej wtyczki przeglądarki.
  • WebM i
  • WebP są w fazie rozwoju i są obsługiwane przez niektóre przeglądarki internetowe.
  • Inne opcje animacji internetowych obejmują wyświetlanie pojedynczych klatek za pomocą AJAX lub
  • animowanie obrazów SVG („Scalable Vector Graphics”) za pomocą JavaScript lub SMIL („Synchronized Multimedia Integration Language”).
  • Wraz z wprowadzeniem powszechnej obsługi tagu wideo HTML5 ( <video>) w większości przeglądarek internetowych niektóre witryny używają zapętlonej wersji tagu wideo generowanej przez funkcje JavaScript . Daje to wygląd GIF-a, ale z zaletami rozmiaru i szybkości skompresowanego wideo.
Godnymi uwagi przykładami są Gfycat i Imgur oraz ich metaformat GIFV , który w rzeczywistości jest tagiem wideo odtwarzającym zapętlone skompresowane wideo MP4 lub WebM .
W porównaniu do formatu GIF, w którym brakuje kompresji DCT, HEIF umożliwia znacznie wydajniejszą kompresję. HEIF przechowuje więcej informacji i tworzy animowane obrazy o wyższej jakości w niewielkim ułamku rozmiaru równoważnego GIF-a.
  • Kodek AV1 może być również używany jako wideo lub sekwencyjny obraz.

Zastosowania

W kwietniu 2014 r. 4chan dodał obsługę cichych filmów WebM o rozmiarze poniżej 3 MB i długości 2 min, a w październiku 2014 r. Imgur zaczął konwertować dowolne pliki GIF przesłane do witryny na wideo i udostępniając link do odtwarzacza HTML. wygląd rzeczywistego pliku z .gifvrozszerzeniem.

W styczniu 2016 r. Telegram zaczął ponownie kodować wszystkie pliki GIF do filmów MPEG-4 , które „wymagają do 95% mniej miejsca na dysku dla tej samej jakości obrazu”.

Zobacz też

Bibliografia

Zewnętrzne linki