GIF-y
.gif) Animowany GIF przedstawiający obracającą się kulę ziemską
| |
| Rozszerzenie nazwy pliku |
gif
|
|---|---|
| Rodzaj mediów internetowych |
obraz/gif
|
| Wpisz kod | GIFf |
| Jednolity identyfikator typu (UTI) | com.compuserve.gif |
| magiczny numer |
GIF87a / GIF89a
|
| Opracowany przez | CompuServe |
| Pierwsze wydanie | 15 czerwca 1987 |
| Najnowsze wydanie | 89a 1989 |
| Typ formatu | bezstratny format obrazu bitmapowego |
| Strona internetowa | |
Graphics Interchange Format ( GIF ; / ɡ ɪ f / GHIF lub / dʒ ɪ f / JIF , patrz wymowa ) to format obrazu bitmapowego opracowany przez zespół dostawcy usług online CompuServe kierowany przez amerykańskiego informatyka Steve'a Wilhite'a i wydany w dniu 15 czerwca 1987 r. Jest szeroko stosowany w sieci World Wide Web 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 techniki bezstratnej kompresji danych Lempel-Ziv-Welch (LZW) w celu zmniejszenia rozmiaru pliku bez pogorszenia jakości wizualnej.
Historia
Firma CompuServe wprowadziła GIF 15 czerwca 1987 r., Aby zapewnić format kolorowego obrazu dla swoich obszarów pobierania plików. Zastąpiło to ich wcześniejszy kodowania długości serii , który był tylko czarno-biały. GIF stał się popularny, ponieważ wykorzystywał kompresję danych Lempel-Ziv-Welch . Ponieważ było to bardziej wydajne niż kodowanie długości serii używane przez PCX i MacPaint , dość duże obrazy można było pobrać dość szybko, nawet przy wolnych modemach .
Oryginalna wersja GIF nazywała się 87a. Ta wersja obsługiwała już wiele obrazów w strumieniu.
W 1989 CompuServe wydał ulepszoną wersję o nazwie 89a. W tej wersji dodano:
- obsługa opóźnień animacji
- przezroczyste kolory tła
- przechowywanie metadanych specyficznych dla aplikacji
- dopuszczanie etykiet tekstowych jako tekstu (nieosadzanie ich w danych graficznych). Ponieważ kontrola nad wyświetlanymi czcionkami jest niewielka, funkcja ta jest rzadko używana.
Te dwie wersje można rozróżnić, patrząc na pierwsze sześć bajtów pliku („ magiczna liczba ” lub podpis), które interpretowane jako ASCII oznaczają odpowiednio „GIF87a” lub „GIF89a”.
CompuServe zachęcił do przyjęcia formatu GIF, udostępniając narzędzia do konwersji do pobrania dla wielu komputerów. Na przykład do grudnia 1987 roku Apple IIGS mógł przeglądać obrazy utworzone na Atari ST lub Commodore 64 . GIF był jednym z dwóch pierwszych formatów obrazu powszechnie używanych w witrynach internetowych, drugim był czarno-biały XBM .
We wrześniu 1995 r. Netscape Navigator 2.0 dodał możliwość zapętlania animowanych GIF-ów .
Podczas gdy GIF został opracowany przez CompuServe , wykorzystywał algorytm bezstratnej kompresji danych Lempel – Ziv – Welch (LZW), opatentowany przez Unisys w 1985 r. Kontrowersje wokół umowy licencyjnej między Unisys i CompuServe w 1994 r. Pobudziły rozwój Portable Network Graphics (PNG) standard. W 2004 roku wygasły wszystkie patenty dotyczące zastrzeżonej kompresji używanej w GIF.
Funkcja przechowywania wielu obrazów w jednym pliku wraz z danymi kontrolnymi jest szeroko stosowana w Internecie 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ł w pewnym stopniu rozpoznawalny, również pomogła w popularności GIF-a, ponieważ użytkownik mógł przerwać pobieranie, jeśli nie było to wymagane.
W maju 2015 Facebook dodał obsługę formatu 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 rozpoznało również GIF jako czasownik , co oznacza „utworzyć plik GIF”, jak w „GIFing był idealnym medium do udostępniania scen z letnich igrzysk olimpijskich ”. Leksykografowie prasy uznali to za słowo roku , twierdząc, że GIF-y przekształciły się w „narzędzie o poważnych zastosowaniach, w tym w badaniach i dziennikarstwie”.
Wymowa
Wymowa pierwszej litery GIF jest kwestionowana od lat 90. Najczęstsze wymowy w języku angielskim to / dʒ ɪ f / ( 
słuchaj ) (z miękkim g jak w gin ) i / ɡ ɪ f / ( słuchaj ) (z twardym g jak w dar ), różniące się fonemem reprezentowanym przez litera G. _ Twórcy formatu wymówili akronim GIF jako / dʒ ɪ f / , z miękkim g , a Wilhite stwierdził, że zamierzał, aby wymowa celowo odzwierciedlała amerykańską markę masła orzechowego Jif , a pracownicy CompuServe często żartowali „wybredni programiści wybierają GIF”, parodia reklam telewizyjnych Jif. Jednak słowo to jest powszechnie wymawiane jako / ɡ ɪ f / , z twardym g , a sondaże ogólnie wykazały, że ta wymowa twardego g jest bardziej rozpowszechniona.
Dictionary.com cytuje obie wymowy, wskazując / dʒ ɪ f / jako podstawową wymowę, podczas gdy Cambridge Dictionary of American English oferuje tylko wymowę hard- g . Merriam-Webster's Collegiate Dictionary i Oxford Dictionaries cytują obie wymowy, ale najpierw umieszczają twarde g : / ɡ ɪ f , dʒ ɪ f / . New Oxford American Dictionary podał tylko / dʒ ɪ f / w swoim drugim wydaniu, ale zaktualizował go do / dʒ ɪ f , ɡ ɪ f / w trzecim wydaniu.
Spór dotyczący wymowy doprowadził do gorącej debaty internetowej. Z okazji otrzymania nagrody za całokształt twórczości podczas Webby Awards 2013 Wilhite publicznie odrzucił wymowę hard- g ; jego przemówienie zaowocowało ponad 17 000 postami na Twitterze i dziesiątkami artykułów prasowych. Biały Dom i program telewizyjny Jeopardy! również wszedł do debaty w 2013 r. W lutym 2020 r. The JM Smucker Company , właściciele marki Jif, we współpracy z bazą danych animowanych obrazów i wyszukiwarką Giphy wydali limitowaną edycję „Jif vs. GIF” ( oznaczoną jako #JIFvsGIF ) słoik masła orzechowego, który miał etykietę żartobliwie deklarującą, że wymowa soft- g odnosi się wyłącznie do masła orzechowego, a GIF ma być wymawiany wyłącznie z wymową hard- g .
Stosowanie
Pliki GIF nadają się do grafiki liniowej o ostrych krawędziach i ograniczonej liczbie kolorów, na przykład 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 sprite'ów o niskim kolorze do gier. Pliki GIF mogą być używane w małych animacjach i klipach 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 pojedynczy obraz, który wypełnia cały ekran logiczny. Inne dzielą ekran logiczny na osobne obrazy podrzędne. Obrazy mogą również funkcjonować jako klatki animacji w animowanym pliku GIF, ale znowu nie muszą one wypełniać całego ekranu logicznego.
Pliki GIF zaczynają się od nagłówka o stałej długości („GIF87a” lub „GIF89a”) podającego wersję, po którym następuje logiczny deskryptor ekranu 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 tabeli 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 straż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 lokalnej tabeli kolorów (która następuje dalej, jeśli jest obecna). Dane obrazu są następujące: jeden bajt określający szerokość bitową niezakodowanych symboli (które muszą mieć szerokość co najmniej 2 bitów, nawet w przypadku obrazów dwukolorowych), po którym następuje połączona lista podbloków zawierających dane zakodowane w LZW.
Bloki rozszerzeń (bloki, które „rozszerzają” definicję 87a poprzez mechanizm już zdefiniowany w specyfikacji 87a) składają się z wartownika, 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 sterowania grafiką, które określa opcjonalny czas opóźnienia animacji i opcjonalny przezroczysty kolor tła) muszą bezpośrednio poprzedzać segment z obrazem, do którego się odnoszą.
Połączone listy używane przez dane obrazu i bloki rozszerzeń składają się z serii podbloków, z których każdy zaczyna się od bajtu określającego liczbę kolejnych bajtów danych w podbloku (od 1 do 255). Seria podbloków jest zakończona pustym podblokiem (bajt 0).
Ta struktura umożliwia analizę pliku, nawet jeśli nie wszystkie części są zrozumiałe. GIF oznaczony 87a może zawierać bloki rozszerzające; intencją jest, aby dekoder mógł odczytywać i wyświetlać plik bez funkcji objętych rozszerzeniami, których nie rozumie.
Wszystkie szczegóły dotyczące formatu pliku są zawarte w specyfikacji GIF.
Palety
GIF jest oparty na palecie: kolory użyte 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 dla obrazu odnoszą się do kolorów za pomocą ich indeksów ( 0–255) w tabeli palet. Definicje kolorów w palecie można narysować z przestrzeni kolorów składającej się z milionów odcieni (224 odcienie , 8 bitów dla każdego podstawowego), ale maksymalna liczba kolorów, których może użyć ramka, to 256. To ograniczenie wydawało się rozsądne, gdy opracowano format 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 klatka może oznaczyć jeden indeks jako „przezroczysty kolor tła”: każdy piksel, któremu przypisano ten indeks, przyjmuje kolor piksela w tej samej pozycji względem tła, który mógł zostać określony przez poprzednią klatkę animacji.
Opracowano wiele technik, zwanych wspólnie ditheringiem , w celu przybliżenia szerszego zakresu kolorów za pomocą małej palety kolorów, wykorzystując piksele o dwóch lub więcej kolorach do przybliżenia kolorów pośrednich. Techniki te poświęcają rozdzielczość przestrzenną na rzecz zbliżonej do głębszej rozdzielczości kolorów. Chociaż nie jest to częścią specyfikacji GIF, dithering może być używany w obrazach następnie kodowanych 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 wzorce ditheringu często zakłócają ściśliwość danych obrazu, działając wbrew głównemu celowi formatu GIF.
We wczesnych latach graficznych przeglądarek internetowych [ kiedy? ] , 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 bezpiecznej palety internetowej . [ według kogo? ] Zapewniało to przewidywalne wyświetlanie, ale poważnie ograniczało wybór kolorów. Kiedy standardem stały się kolory 24-bitowe, palety można było zamiast tego wypełniać optymalnymi kolorami dla poszczególnych obrazów.
Mała tabela kolorów może wystarczyć w przypadku małych obrazów, a utrzymywanie małej tabeli kolorów umożliwia szybsze pobieranie pliku. Zarówno specyfikacje 87a, jak i 89a dopuszczają tablice kolorów 2 n kolorów dla dowolnych n od 1 do 8. Większość aplikacji graficznych odczytuje i wyświetla obrazy GIF z dowolnymi z tych rozmiarów tabel; ale niektóre nie obsługują wszystkich rozmiarów podczas tworzenia obrazów. Szeroko obsługiwane są tabele zawierające 2, 16 i 256 kolorów.
Prawdziwy kolor
Chociaż GIF prawie nigdy nie jest używany do obrazów w prawdziwych kolorach , jest to możliwe. Obraz GIF może zawierać wiele bloków obrazu, z których każdy może mieć własną paletę 256 kolorów, a bloki można układać kafelkami, 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. Kompletny obraz można utworzyć, nakładając bloki obrazu warstwami, tak aby widoczna część każdej warstwy była widoczna przez przezroczyste części warstw powyżej.
Aby renderować pełnokolorowy obraz jako GIF, oryginalny obraz musi być 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ę pełny, pełnokolorowy obraz. Na przykład podzielenie obrazu na kafelki o wymiarach 16 na 16 pikseli (łącznie 256 pikseli) zapewnia, że żaden kafelek nie będzie miał więcej niż lokalny limit palety 256 kolorów, chociaż można użyć większych kafelków i połączyć podobne kolory, co spowoduje utratę koloru Informacja.
Ponieważ każdy blok obrazu może mieć własną lokalną tablicę 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 plików GIF prawidłowo obsługują obrazy kafelkowe lub warstwowe. Wiele programów renderujących interpretuje kafelki lub warstwy jako klatki animacji i wyświetla je sekwencyjnie jako animację, przy czym większość przeglądarek internetowych automatycznie wyświetla klatki z opóźnieniem 0,1 sekundy lub większym. [ potrzebne lepsze źródło ]
Przykładowy plik GIF
|
Program Microsoft Paint zapisuje mały czarno-biały obraz jako następujący plik GIF (pokazany w powiększeniu). Paint nie optymalnie wykorzystuje GIF; ze względu na niepotrzebnie dużą tablicę kolorów (przechowuje pełne 256 kolorów zamiast używanych 2) i szerokość symboli, ten plik GIF nie jest wydajną reprezentacją 15-pikselowego obrazu. Chociaż blok Graphic Control Extension deklaruje, że indeks koloru 16 (szesnastkowo 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 Global Color Table odwzorowuje odpowiednio na czerń i biel. |
 Przykładowy obraz (powiększony), rzeczywisty rozmiar 3 piksele szerokości i 5 pikseli wysokości |
Należy zauważyć, że liczby szesnastkowe w poniższych tabelach są podane w kolejności bajtów typu little-endian , zgodnie ze specyfikacją formatu.
| Bajt nr (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 następuje po 256 kolorach 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 |
|
Globalna tabela kolorów, kolor #0: #000000, czarny | |||||||
| 10 | 80 00 00 |
|
Globalna tabela kolorów, kolor nr 1: bit przezroczysty, niewykorzystany w obrazie | |||||||
| ... | ... | ... | Globalna tabela kolorów rozciąga się do 30A | |||||||
| 30A | FF FF FF |
|
Globalna tabela kolorów, kolor #255: #ffffff, biały | |||||||
| 30D | 21 F9 | Rozszerzenie Graphic Control (pola komentarza poprzedzają to w większości plików) | ||||||||
| 30F | 04 | 4 | Ilość danych GCE, 4 bajty | |||||||
| 310 | 01 | Przezroczysty kolor tła; jest to 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 narożnika obrazu na ekranie logicznym | |||||||
| 31A | 03 00 05 00 | (3, 5) | Szerokość i wysokość obrazu w pikselach | |||||||
| 31E | 00 | 0 | Lokalny bit tabeli 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 | <image data> | 11 bajtów danych obrazu, patrz pole 320 | |||||||
| 32C | 00 | 0 | Koniec bloku danych obrazu | |||||||
| 32D | 3B | Zakończenie pliku | ||||||||
Kodowanie obrazu
Dane pikseli obrazu, zeskanowane poziomo od lewego górnego rogu, są konwertowane przez kodowanie LZW na kody, które są następnie mapowane na bajty w celu zapisania w pliku. Kody pikseli 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 pierwszego bajtu, bity wyższego rzędu kodu na bity wyższego rzędu bajtu, przechodząc w razie potrzeby na bity niższego rzędu następnego bajtu. Każdy kolejny kod jest zapisywany począwszy od najmniej znaczącego bitu, który nie jest jeszcze używany.
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 podblokiem (pojedynczy bajt 0, wskazujący podblok z 0 bajtami danych).
Dla przykładowego obrazu powyżej odwracalne mapowanie między kodami 9-bitowymi a bajtami pokazano poniżej.
| 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 lekka 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. Ciąg lokalny gromadzi numery kolorów pikseli z palety, bez żadnej akcji wyjściowej, o ile ciąg lokalny można znaleźć w tabeli kodów. W specjalny sposób traktuje się pierwsze dwa piksele, które pojawiają się, zanim tabela powiększy się z początkowego rozmiaru przez dodanie ciągów. Po każdym kodzie wyjściowym lokalny ciąg jest inicjowany do ostatniego koloru piksela (którego nie można było uwzględnić w kodzie wyjściowym).
Tabela 9-bitowy łańcuch --> kod kod Akcja #0 | 000h Inicjalizacja tablicy głównej 9-bitowej palety kodów | : kolory | : #255 | 0FFh kasuj | koniec 100h | 101h | 100h Wyczyść piksel Lokalnie | łańcuch palety kolorów | CZARNY #40 28 | 028h Pierwszy piksel zawsze wysyłany na wyjście WHITE #255 FF | Ciąg znaleziony w tabeli 28 FF | 102h Zawsze dodawaj pierwszy ciąg do tabeli FF | Zainicjuj lokalny łańcuch BIAŁY #255 FF FF | Nie znaleziono ciągu znaków w tabeli | 0FFh - kod wyjścia dla poprzedniego napisu FF FF | 103h - dodaj ostatni napis do tabeli FF | - zainicjuj lokalny napis WHITE #255 FF FF | Ciąg znaleziony w tabeli CZARNY #40 FF FF 28 | Nie znaleziono ciągu znaków w tabeli | 103h - kod wyjścia dla poprzedniego napisu FF FF 28 | 104h - dodaj ostatni ciąg znaków do tabeli 28 | - zainicjuj lokalny napis WHITE #255 28 FF | Ciąg znaleziony w tabeli WHITE #255 28 FF FF | Nie znaleziono ciągu znaków w tabeli | 102h - kod wyjścia dla poprzedniego ciągu znaków 28 FF FF | 105h - dodaj ostatni napis do tabeli FF | - zainicjuj lokalny napis WHITE #255 FF FF | Ciąg znaleziony w tabeli WHITE #255 FF FF FF | Nie znaleziono ciągu znaków w tabeli | 103h - kod wyjścia dla poprzedniego napisu FF FF FF | 106h - dodaj ostatni napis do tabeli FF | - zainicjuj lokalny napis WHITE #255 FF FF | Ciąg znaleziony w tabeli WHITE #255 FF FF FF | Ciąg znaleziony w tabeli WHITE #255 FF FF FF FF | Nie znaleziono ciągu znaków w tabeli | 106h - kod wyjścia dla poprzedniego napisu FF FF FF FF| 107h - dodaj ostatni napis do tabeli FF | - zainicjuj lokalny napis WHITE #255 FF FF | Ciąg znaleziony w tabeli WHITE #255 FF FF FF | Ciąg znaleziony w tabeli WHITE #255 FF FF FF FF | Ciąg znaleziony w tabeli Koniec z pikselami 107h - kod wyjściowy dla ostatniego ciągu 101h Koniec
Dla jasności tabela jest pokazana powyżej jako zbudowana ze strun o rosnącej długości. Ten schemat może działać, ale tabela zużywa nieprzewidywalną ilość pamięci. W praktyce można oszczędzić pamięć, 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 przechowywanie pod każdym adresem tylko dwóch słów: istniejącego adresu i jednego znaku.
Algorytm LZW wymaga przeszukania tablicy dla każdego piksela. Liniowe przeszukiwanie do 4096 adresów spowolniłoby kodowanie. W praktyce kody mogą być przechowywane w kolejności wartości numerycznych; pozwala to na wykonanie każdego wyszukiwania przez SAR (Rejestr kolejnych aproksymacji, używany w niektórych ADC ), z tylko 12 porównaniami wielkości. Aby uzyskać taką wydajność, potrzebna jest dodatkowa tabela do konwersji między kodami a rzeczywistymi adresami pamięci; dodatkowe utrzymanie tabeli jest potrzebne tylko wtedy, gdy przechowywany jest nowy kod, co dzieje się z szybkością znacznie mniejszą niż częstotliwość 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 z tą używaną w enkoderze jest budowana poprzez dodawanie łańcuchów według następującej reguły:
| Tak | dodaj ciąg dla kodu lokalnego, a następnie pierwszy bajt ciągu dla kodu przychodzącego |
| NIE | dodaj ciąg dla kodu lokalnego, a następnie kopię własnego pierwszego bajtu |
shift 9-bit ----> Local Table Pixel code code code --> string Paleta kolorów Akcja 100h 000h | #0 Zainicjuj główną tablicę 9-bitowych kodów: | paleta : | kolory 0FFh | #255 100h | clr 101h | koniec 028h | #40 CZARNY Dekodowanie pierwszego piksela 0FFh 028h | Kod przychodzący znaleziony w tabeli | #255 BIAŁY - ciąg wyjściowy z tabeli 102h | 28 FFh - dodaj do tabeli 103h 0FFh | Nie znaleziono kodu przychodzącego w tabeli 103h | FF FF - dodaj do tabeli | - ciąg wyjściowy z tabeli | #255 BIAŁY | #255 BIAŁY 102h 103h | Kod przychodzący znaleziony w tabeli | - ciąg wyjściowy z tabeli | #40 CZARNY | #255 BIAŁY 104h | FF FF 28 - dodaj do tabeli 103h 102h | Kod przychodzący znaleziony w tabeli | - ciąg wyjściowy z tabeli | #255 BIAŁY | #255 BIAŁY 105h | 28 FF FF - dodaj do tabeli 106h 103h | Nie znaleziono kodu przychodzącego w tabeli 106h | FF FF FF - dodaj do tabeli | - ciąg wyjściowy z tabeli | #255 BIAŁY | #255 BIAŁY | #255 BIAŁY 107h 106h | Nie znaleziono kodu przychodzącego w tabeli 107h | FF FF FF FF - dodaj do tabeli | - ciąg wyjściowy z tabeli | #255 BIAŁY | #255 BIAŁY | #255 BIAŁY | #255 BIAŁY 101h | Koniec
Długości kodu LZW
Krótsze długości kodu mogą być używane dla palet mniejszych niż 256 kolorów w przykładzie. Jeśli paleta zawiera tylko 64 kolory (więc indeksy kolorów mają szerokość 6 bitów), symbole mogą mieścić się w zakresie od 0 do 63, a szerokość symbolu może wynosić 6 bitów, a kody zaczynają się od 7 bitów. W rzeczywistości szerokość symbolu nie musi odpowiadać rozmiarowi palety: dopóki dekodowane wartości są zawsze mniejsze niż liczba kolorów w palecie, symbole mogą mieć dowolną szerokość od 2 do 8, a rozmiar palety dowolna potęga 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, a kody zaczynają się od 3 bitów.
I odwrotnie, szerokość symbolu można ustawić 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.
Tablica kodów początkowo zawiera kody, które są o jeden bit dłuższe niż rozmiar symbolu, aby pomieścić dwa kody specjalne clr i end oraz kody dla łańcuchów, które są dodawane podczas procesu. Kiedy 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
|
Proces kodowania GIF można zmodyfikować, aby utworzyć plik bez kompresji LZW, który nadal można oglądać jako obraz GIF. Ta technika została pierwotnie wprowadzona jako sposób na uniknięcie naruszenia patentu. Nieskompresowany GIF może być również przydatnym formatem pośrednim dla programisty graficznego, ponieważ poszczególne piksele są dostępne do czytania 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 tablicy LZW i emituje tylko kody palety głównej oraz kody CLEAR i STOP. Daje to prostsze kodowanie (odpowiedniość 1 do 1 między wartościami kodu a kodami palet), ale poświęca całą kompresję: każdy piksel na obrazie generuje kod wyjściowy wskazujący jego indeks koloru. Podczas przetwarzania nieskompresowanego pliku GIF standardowy dekoder GIF nie będzie miał przeszkód w zapisywaniu ciągów znaków do swojej tablicy słownika, ale szerokość kodu nigdy nie może się zwiększać, ponieważ powoduje to inne upakowanie bitów w bajty.
Jeżeli szerokość symbolu wynosi n , kody o szerokości n +1 dzielą się naturalnie na dwa 2n bloki : dolny blok 2n kodów do kodowania pojedynczych symboli i górny blok kodów, które będą używane przez dekoder do 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. Należy również uniemożliwić dekoderowi użycie ostatniego kodu w górnym bloku, 2 n +1 - 1 , ponieważ gdy dekoder wypełni to miejsce, zwiększy szerokość kodu. Zatem w górnym bloku dostępne są 2 n -3 kody, które nie spowodują zwiększenia szerokości kodu. Ponieważ dekoder jest zawsze o krok do tyłu w utrzymywaniu tablicy, nie generuje wpisu w tablicy po odebraniu pierwszego kodu z kodera, ale generuje jeden wpis dla każdego kolejnego kodu. W ten sposób koder może wygenerować 2 n -2 kodów bez wyzwalania zwiększenia 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 powyższego przykładowego obrazu 3 × 5 następujące 9-bitowe kody oznaczają „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 następujący sposób:
| Bajt nr (szesnastkowy) | Szesnastkowy | Tekst lub wartość | Oznaczający |
|---|---|---|---|
| 320 | 14 | 20 | Następują 20-bajtowe nieskompresowane dane 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 o jednolitym kolorze demonstruje kompresję LZW o zmiennej długości używaną w plikach GIF.
| Kod | piksele | Notatki | |||
|---|---|---|---|---|---|
| Nr N i | Wartość N i + 256 | Długość (bity) | Ten kod N i | Skumulowane N i (N i + 1) / 2 | Relacje wykorzystujące N i mają zastosowanie tylko do pikseli tego samego koloru, dopóki tablica kodowania nie zostanie zapełniona. |
| 0 | 100 godz | 9 | Wyczyść tabelę kodów | ||
| 1 | FFh | 1 | 1 | Kolor lewego górnego piksela wybrany jako najwyższy indeks z palety 256 kolorów | |
| 2 | 102 godz | 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 | Tabela kodów jest pełna |
| ⋮ | FFF godz | 3839 | Maksymalny kod może się powtarzać dla większej liczby pikseli tego samego koloru. 2559 + 1/3 do Ogólna kompresja danych 8/12 zbliża się asymptotycznie 3839 × = | ||
| 101 godz | Koniec danych obrazu | ||||
Pokazane wartości kodów są pakowane w bajty, które są następnie pakowane w bloki o długości do 255 bajtów. Blok danych obrazu zaczyna się od bajtu, który określa liczbę bajtów, które mają nastąpić. Ostatni blok danych obrazu jest oznaczony bajtem o zerowej długości bloku.
Przeplot
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 pełnego obrazu.
Obraz z przeplotem jest dzielony 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:
- Pass 1: Linia 0 (najwyższa linia) z każdego paska.
- Pass 2: Linia 4 z każdego paska.
- Pass 3: Linie 2 i 6 z każdego paska.
- Pass 4: Linie 1, 3, 5 i 7 z każdego paska.
Piksele w każdej linii nie są przeplatane, ale wyświetlane kolejno od lewej do prawej. Podobnie jak w przypadku obrazów bez przeplotu, nie ma przerwy między danymi dla jednej linii a danymi dla następnej. Wskaźnik, że obraz jest przepleciony, jest bitem ustawionym w odpowiednim bloku deskryptora obrazu.
Animowany gif
Chociaż GIF nie został zaprojektowany jako medium animacji, jego zdolność do przechowywania wielu obrazów w jednym pliku naturalnie sugerowała 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 (ramek) w pliku z opóźnieniami czasowymi, tworząc klip wideo . Każda klatka w animacji GIF jest wprowadzana przez własny GCE określający opóźnienie czasowe oczekiwania po narysowaniu klatki. Informacje globalne na początku pliku dotyczą domyślnie wszystkich ramek. Dane są zorientowane strumieniowo, więc przesunięcie pliku początku każdego GCE zależy od długości poprzedzających danych. W każdej ramce dane obrazu zakodowane LZW są rozmieszczone w podblokach o długości 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ętlanie animacji, firma Netscape w latach 90. wykorzystała blok rozszerzenia aplikacji (mający na celu umożliwienie dostawcom dodawania informacji specyficznych dla aplikacji do pliku GIF) w celu zaimplementowania bloku aplikacji Netscape (NAB). Blok ten, umieszczony bezpośrednio przed sekwencją klatek animacji, określa, ile razy sekwencja klatek ma zostać odtworzona (od 1 do 65535 razy) lub ma być powtarzana w sposób ciągły (zero oznacza pętlę w nieskończoność). Obsługa tych powtarzających się animacji pojawiła się po raz pierwszy 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ęścią specyfikacji GIF89a.
Poniższy przykład pokazuje strukturę pliku animacji Rotating Earth (large).gif pokazanego (jako miniatura) w infoboksie artykułu.
| Bajt nr (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 następuje dla 256 kolorów z rozdzielczością 3 × 8 bitów/podstawową | |
| 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 weryfikacyjne (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 następnym 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 rozszerzenia aplikacji | |
| 320 | 21 F9 | Rozszerzenie kontroli grafiki dla ramki nr 1 | |
| 322 | 04 | 4 | Liczba bajtów (4) w bieżącym podbloku |
| 323 | 04 |
000..... ...001.. ......0. .........0 |
Zarezerwowane, 5 niższych bitów to pole bitowe Metoda utylizacji 1: nie wyrzucaj Brak danych wprowadzanych przez użytkownika Kolor przezroczysty, 0 oznacza brak danych |
| 324 | 09 00 | 9 | Opóźnienie klatki: 0,09 sekundy opóźnienia przed malowaniem następnej klatki |
| 326 | FF | Przezroczysty indeks kolorów (nieużywany w tej ramce) | |
| 327 | 00 | Koniec łańcucha podbloków dla bloku Graphic Control Extension | |
| 328 | 2C | Deskryptor obrazu klatki nr 1 | |
| 329 | 00 00 00 00 | (0, 0) | Pozycja północno-zachodniego narożnika obrazu na ekranie logicznym: (0, 0) |
| 32D | 90 01 90 01 | (400, 400) | Szerokość i wysokość ramki: 400 × 400 pikseli |
| 331 | 00 | 0 | Lokalna tabela 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 | ... | <image data> | Dane obrazu, 255 bajtów |
| 433 | FF | 255 | Liczba bajtów danych obrazu LZW w następnym podbloku, 255 bajtów |
| 434 | ... | <image data> | 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 kontroli grafiki dla ramki nr 2 | |
| ⋮ | Powtórz dla następnych klatek | ||
| EDABD | 21 F9 | Rozszerzenie sterowania grafiką dla ramki nr 44 | |
| ⋮ | Informacje o obrazie i dane dla klatki nr 44 | ||
| F48F5 | 3B | Trailer: Ostatni bajt w pliku, sygnalizujący EOF |
Opóźnienie animacji dla każdej klatki jest określone w GCE w setnych częściach sekundy. Możliwa jest pewna oszczędność danych, gdy ramka wymaga przepisania tylko części pikseli wyświetlacza, ponieważ deskryptor obrazu może zdefiniować mniejszy prostokąt do ponownego zeskanowania zamiast całego obrazu. Przeglądarki lub inne wyświetlacze, które nie obsługują animowanych plików GIF, zwykle pokazują 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 pełnej lokalnej tabeli kolorów dla każdej klatki) oraz minimalizowanie liczby pikseli objętych kolejnymi klatkami (tak, aby tylko piksele zmieniające się z jednej klatki na następne są zawarte w tej ostatniej ramce). Bardziej zaawansowane techniki obejmują modyfikowanie sekwencji kolorów w celu lepszego dopasowania do istniejącego słownika LZW, co jest formą kompresji stratnej . Zwykłe spakowanie serii niezależnych klatek w animację kompozytową zwykle daje duże rozmiary plików. Dostępne są narzędzia minimalizujące rozmiar pliku, biorąc pod uwagę istniejący plik GIF.
Metadane
Metadane mogą być przechowywane w plikach GIF jako blok komentarza, zwykły blok tekstowy 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.
Extensible Metadata Platform (XMP) wprowadził nieoficjalny, ale obecnie szeroko rozpowszechniony blok rozszerzeń aplikacji „XMP Data” do dołą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 bajtów 0. 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. Uzyskany w ten sposób patent US4558302, przyznany w grudniu 1985 r., Został przeniesiony na 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 r. autorstwa Jun Kanatsu z firmy NEC ,
- patent US 4 021 782 (1974) autorstwa Johna S. Hoerninga,
- patent US 4,366,551 (1977) od Klausa E. Holtza i
- niemiecki patent z 1981 r. od Karla Eckharta Heinza.
IEEE opublikowano artykuł Welcha, w którym po raz pierwszy publicznie opisano technikę LZW. LZW stał się popularną techniką kompresji danych, a kiedy przyznano patent, Unisys zawarł umowy licencyjne z ponad setką firm.
Popularność LZW skłoniła CompuServe do wybrania go jako techniki kompresji dla ich wersji GIF, opracowanej w 1987 roku. W tamtym czasie CompuServe nie był świadomy patentu. Unisys dowiedział się, że wersja GIF wykorzystuje technikę kompresji LZW i rozpoczął negocjacje licencyjne z CompuServe w styczniu 1993 r. Kolejna umowa została ogłoszona 24 grudnia 1994 r. Unisys oświadczył, że oczekuje, że wszystkie główne komercyjne usługi informacyjne on-line firmy zatrudniające Patent LZW na licencję na technologię firmy Unisys po rozsądnej cenie, ale nie będą wymagały licencji ani opłat za niekomercyjne, non-profit aplikacje oparte na GIF, w tym do użytku w usługach on-line .
Po tym ogłoszeniu nastąpiło powszechne potępienie CompuServe i Unisys, a wielu programistów zagroziło zaprzestaniem używania 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 udało się zastąpić formatu GIF, 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, które są zgodne z formatem danych, ale unikają funkcji kompresji, unikając w ten sposób korzystania z patentu Unisys LZW. Artykuł dr Dobba z 2001 roku opisał sposób na uzyskanie kodowania zgodnego z LZW bez naruszania jego patentów.
W sierpniu 1999 r. Unisys zmienił 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 od właścicieli witryn lub innych użytkowników GIF, którzy używali licencjonowanego oprogramowania do generowania GIF-ów. Niemniej jednak firma Unisys została poddana tysiącom ataków online i obraźliwych e-maili od użytkowników, którzy wierzyli, że zostaną obciążeni kwotą 5000 USD lub zostaną pozwani 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ć żadnego dobrego rozgłosu i nadal był potępiany przez osoby i organizacje, takie jak League for Programming Freedom, która rozpoczęła kampanię „Burn All GIFs ” w 1999.
Amerykański patent LZW wygasł 20 czerwca 2003 r. Odpowiednie patenty w Wielkiej Brytanii, Francji, Niemczech i Włoszech wygasły 18 czerwca 2004 r., patenty japońskie wygasły 20 czerwca 2004 r., a patent kanadyjski wygasł 7 lipca 2004 r. W konsekwencji , podczas gdy Unisys posiada dalsze patenty i wnioski patentowe dotyczące ulepszeń techniki LZW, sama LZW (a co za tym idzie GIF) jest dostępna bezpłatnie od lipca 2004 r.
Alternatywy
PNG
Przenośna grafika sieciowa (PNG) została zaprojektowana jako zamiennik GIF, aby uniknąć naruszenia patentu firmy Unisys na technikę kompresji LZW. PNG oferuje lepszą kompresję i więcej funkcji niż GIF, animacja jest jedynym znaczącym wyjątkiem. wymagane jest obrazowanie w rzeczywistych kolorach i przezroczystość alfa .
Chociaż obsługa formatu PNG pojawiała się 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. Korekta 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ą często 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ę dzięki kodekom . Praktycznie powszechna obsługa formatu GIF w przeglądarkach internetowych i 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 („Multi-image Network Graphics”) został pierwotnie opracowany jako rozwiązanie oparte na PNG do animacji. MNG osiągnął wersję 1.0 w 2001 roku, ale obsługuje ją niewiele aplikacji.
- APNG („Animowana przenośna grafika sieciowa”) została zaproponowana przez Mozillę w 2006 roku. APNG to rozszerzenie formatu PNG jako alternatywa dla formatu MNG. APNG jest obsługiwany przez większość przeglądarek od 2019 r. APNG zapewnia możliwość animowania plików PNG, zachowując jednocześnie kompatybilność wsteczną w dekoderach, które nie rozumieją fragmentu animacji (w przeciwieństwie do MNG). Starsze dekodery po prostu renderują pierwszą klatkę animacji.
- Grupa PNG oficjalnie odrzuciła APNG jako oficjalne rozszerzenie w dniu 20 kwietnia 2007 r.
- Było kilka kolejnych propozycji prostego animowanego formatu graficznego opartego na PNG przy użyciu kilku różnych podejść. Niemniej jednak APNG jest nadal rozwijany przez Mozillę i jest obsługiwany w przeglądarce Firefox 3.0, podczas gdy obsługa MNG została usunięta. 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
- MPEG były używane na niektórych stronach internetowych do wyświetlania prostego wideo, ale wymagały użycia dodatkowej wtyczki przeglądarki.
- Inne opcje animacji internetowych obejmują wyświetlanie pojedynczych klatek przy użyciu technologii AJAX lub
- animowanie obrazów SVG („Scalable vector graphics”) za pomocą JavaScript lub SMIL („Synchronized Multimedia Integration Language”). [ potrzebne źródło ]
- 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 generowanego przez funkcje JavaScript . Daje to wygląd GIF, ale z zaletami rozmiaru i szybkości skompresowanego wideo.
- Godnymi uwagi przykładami są Gfycat i Imgur oraz ich metaformat GIFV, który jest tak naprawdę tagiem wideo odtwarzającym zapętlony skompresowany plik MP4 lub WebM .
- HEIF („High Efficiency Image File Format”) to format pliku obrazu, sfinalizowany w 2015 r., Który wykorzystuje algorytm kompresji stratnej z dyskretną transformacją kosinusową (DCT) oparty na formacie wideo HEVC i powiązany z formatem obrazu JPEG . W przeciwieństwie do JPEG, HEIF obsługuje animację.
- W porównaniu z formatem 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 równoważnego rozmiaru GIF.
- VP9 obsługuje tylko składanie alfa z podpróbkowaniem chrominancji 4:2:0 w formacie pikseli YUV A420, co może być nieodpowiednie dla plików GIF, które łączą przezroczystość z rastrową grafiką wektorową z drobnymi szczegółami kolorów.
Używa
W kwietniu 2014 r. 4chan dodał obsługę cichych filmów WebM o rozmiarze poniżej 3 MB i długości 2 min, aw październiku 2014 r. Imgur zaczął konwertować wszystkie pliki GIF przesłane na stronę na wideo i udostępniać link do odtwarzacza HTML wygląd rzeczywistego pliku z rozszerzeniem .gifv .
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 przy tej samej jakości obrazu”.
Zobacz też
- AVIF
- Cinemagraph , częściowo animowana fotografia, często w formacie GIF
- Clear GIF , technika używana do sprawdzania dostępu do treści
- Porównanie formatów plików graficznych
- Grafika GIF , forma sztuki cyfrowej związana z GIF
- GIFBuilder , wczesny program do tworzenia animowanych GIF-ów
- GNU plotutils (obsługuje pseudo-GIF, który używa kodowania długości serii zamiast LZW)
- Microsoft GIF Animator , historyczny program do tworzenia prostych animowanych GIF-ów
- Patent na oprogramowanie
Linki zewnętrzne
- Projekt GIFLIB
- spec-gif89a.txt Specyfikacja GIF 89a na w3.org
- Specyfikacja GIF 89a przeformatowana do formatu HTML
- LZW i GIF wyjaśnione
- Animowane GIF-y : sześciominutowy film dokumentalny wyprodukowany przez Off Book (serial internetowy)
- GifCities (wyszukiwarka animowanych GIF-ów GeoCities)
