Formát JPEG

4.12.2020 14:50 | Přečteno: 2204× | Komprese | | poslední úprava: 6.12.2020 15:26

JPEG (Joint Photographic Experts Group) je název výboru, který stojí za standardem pro kompresi obrazu ISO/IEC 10918-1 nebo též doporučením CCITT/ITU-T T.81. Tento standard z roku 1992 se běžně označuje zkratkou JPEG. Stejně tak se touto zkratkou označuje formát souboru, který takovýto kompresní formát zaobaluje. JPEG je formát primárně určený ke ztrátové kompresi obrazu. Standard však definuje také režim pro bezeztrátovou kompresi. Pro ztrátovou kompresi podporuje JPEG sekvenční a progresivní přenos obrazových dat. Mimoto JPEG definuje hierarchický režim, kdy je obrázek uložen v několika různých rozlišeních. Ten může komprimován obrázek ztrátově i bezeztrátově. Standard definuje také formát JIF, do kterého je možné data komprimovaná metodou JPEG uložit. Ten se však sám o sobě nepoužívá. Namísto toho se používají s JIF kompatibilní souborové formáty JFIF a Exif, případně JFIF s vloženými segmenty Exif. Tyto soubory mají příponu jpeg nebo jpg.

Standard JPEG definuje čtyři kompresní postupy (procesy). Základní postup (baseline process), který musejí být schopny provést všechny aplikace pracující s formátem JPEG, umožňuje komprimovat 8bitová vstupní data (na každou složku). Pracuje s Huffmanovým kódování a ke kompresi umožňuje použít až 2 tabulky Huffmanových kódů pro koeficienty AC a 2 tabulky pro koeficienty DC. Data jsou komprimována pouze sekvenčně. Tímto způsobem je možno zkomprimovat až 4 složky (např. Y, C_b a C_r). Rozšířený postup (extended process) rozšiřuje možnosti základního také na 12bitová data. Umožňuje využít progresivní zpracování a až 4 tabulky pro koeficienty AC a 4 pro DC. Další je bezeztrátový postup, který se v praxi nepoužívá. A posledním je hierarchický postup, který se taktéž nepoužívá. Následující text se věnuje pouze základnímu postupu (baseline).

Zjednodušené schéma kodéru JPEG. Stejné schéma se aplikuje na každý obrazový kanál.

Vstupní obraz je zpracováván v barevném modelu YCbCr. Jednotlivé složky lze horizontálně i vertikálně podvzorkovat. Barvonosné (chromatické) složky C_b a C_r se typicky podvzorkovávají v jednou nebo obou směrech na polovinu (4:2:2 a 4:2:0). Tyto tři složky barevného modelu jsou dále zpracovávány odděleně.

Každá složka je rozsekána na bloky 8×8 vzorků. To je hlavní důvod vzniku tzv. blokového efektu (blokových artefaktů) u obrázků s vysokým stupněm komprese (obrázek výše). K blokovému efektu přispívá menší mírou také podvzorkování barvonosných složek. Blok 8×8 vzorků je základní datovou jednotkou formátu JPEG. Pokud některá složka obrazu nemá rozměry přesně v násobcích bloků, bude při kompresi na velikost bloku rozšířena. Doporučený způsob rozšíření je duplikace nejbližšího řádku/sloupce. Na každém takovém bloku 8×8 je následně spočtena jeho diskrétní kosinová transformace (DCT).

Výsledkem je matice 64 koeficientů. Transformovaný blok má v levém horním rohu koeficient udávající posun vůči 0 neboli průměr bloku, tedy tzv. stejnosměrnou složku signálu. Odtud se nazývá koeficient DC (analogie ke stejnosměrnému proudu, anglicky Direct Current). Tento koeficient se dále kóduje odlišně proti zbytku transformace. Zbylých 63 koeficientů se označuje jako koeficienty AC (analogicky ke střídavému proudu, Alternating Current). Udávají váhy, se kterými je v bloku přítomna odpovídající dvourozměrná kosinusoida. Právě popsaný postup je plně invertibilní, nedochází ke ztrátě dat. Nejvíce energie (nejvyšší amplitudy koeficientů) bývá soustředěno kolem nízkých frekvencí (okolí koeficientu DC). Vyšší frekvence se vyskytují především na hranách objektů.

Následujícím krokem je kvantování koeficientů. K tomu musí kodér i dekodér obdržet tzv. kvantizační tabulku. To je tabulka s hodnotami, kterými má být při kompresi podělen korespondující koeficient DCT. Následně je každý koeficient zaokrouhlen na nejbližší celé číslo. Nejvyšší hodnoty jsou v kvantizačních tabulkách koncentrovány u vysokých frekvencí, kde je možné dopustit se větší ztráty dat.

16 11 10 16 124 140 151 161 12 12 14 19 126 158 160 155 14 13 16 24 140 157 169 156 14 17 22 29 151 187 180 162 18 22 37 56 168 109 103 177 24 35 55 64 181 104 113 192 49 64 78 87 103 121 120 101 72 92 95 98 112 100 103 199

Příklad kvantizační tabulky pro 8bitovou jasovou složku Y.

Při dekompresi jsou těmito hodnotami koeficienty naopak násobeny. Protože byly hodnoty koeficientů zaokrouhleny na celá čísla, je rekonstruovaný koeficient kvantovaný do několika hladin. Kvantizační tabulka udává, jak velké ztráty dat se kompresor dopustí. Vyšší hodnoty znamenají hrubší kvantování, tedy větší ztrátu informace a tedy méně kvalitní dekomprimovaný obraz. Hodnoty v tabulce jsou tudíž vytvářeny s ohledem na cílovou kvalitu a lidský psychovizuální model. Pro jasovou složku Y a chromatické složky C_b a C_r se používá odlišná tabulka. Důvodem k tomu je větší citlivost lidského oka na jas Y.

Význam koeficientů DCT v bloku 8×8 pixelů. V (a) je naznačena orientace funkce cosinus. Červeně jsou vybarveny vertikální hrany (světle jsou čistě vertikální), modře horizontální (světle čistě horizontální) a zeleně mřížka vytvořená kombinací vertikální a horizontální funkcí. V (b) je zobrazeno rozdělení frekvencí. Modře jsou vyznačeny nízké frekvence, červeně vysoké. Bázové funkce jsou zobrazeny v (c).

Kvantovací tabulky jsou parametrem metody JPEG, které udávají míru a kvalitu komprese. Uživatel samozřejmě pro nastavení míry komprese nemusí specifikovat 64 koeficientů každé kvantizační tabulky. Namísto toho je použitým programem spočtena každá z kvantizačních tabulek na základě jediného parametru q, který udává kvalitu obrazu neboli míru komprese. Jestliže je zvolena vhodná kvantovací tabulka, bude většina koeficientů DCT po kvantizaci nulová. Zbylé budou koncentrovány v levém horním rohu (nízké frekvence).

Matice kvantovaných koeficientů je dále linearizována tzv. zig-zag průchodem. Tento průchod prochází nejdříve koeficienty s nižšími frekvencemi. Ty mají typicky vyšší amplitudu a tudíž je u nich větší šance, že zůstanou i po kvantizaci nenulové. Naopak koeficienty ke konci průchodu budou s vyšší pravděpodobností nulové a není třeba je kódovat. Namísto toho se za poslední nenulový koeficient umístí symbol EOB (End Of Block). Řada linearizovaných koeficientů je dále podrobena variantě RLE kódování nul. Mimo řetězec RLE stojí pouze koeficient DC, který je kódován diferenciálně (rozdílově) proti koeficientu DC z předchozího bloku. Tento rozdílný krok je proveden, protože průměrné hodnoty (koeficienty DC) sousedních bloků jsou velmi blízké.

Posledním krokem jejich komprese je Huffmanovo nebo aritmetické kódování. Obě kódování probíhají za pomoci dodaných tabulek. Aritmetické je cca o 5 až 10 % účinnější.

Protože aritmetické kódování (QM kodér) se u JPEGu prakticky nepoužívá, věnuje se následující text pouze Huffmanovu kódování. Koeficienty DC se kódují za pomoci odlišných tabulek Huffmanových kódů než koeficienty AC. Sled koeficientů AC (zlinearizovaných průchodem zig-zag) obsahuje jen několik málo nenulových čísel. Mezery mezi nimi vyplňují sledy nul. Jak už bylo zmíněno výše, za posledním nenulovým koeficientem následuje dlouhý sled koncových nul, který je nahrazen symbolem EOB. Efektivní kódování těchto sledů nul je motivací k využití metody RLE.

Rozdílová hodnota koeficientu DC se kóduje podle tabulky níže. Ve skutečnosti není třeba takovou tabulku mít umístěnou v paměti. Kategorii lze pro danou hodnotu koeficientu jednoduše spočítat. Číslo kategorie se zakóduje kódem z použité tabulky Huffmanových kódů. Tento kód je následován stejným počtem bitů, jako je hodnota kategorie. Tyto další bity udávají pořadí hodnoty uvnitř sloupce rozsah zmíněné tabulky. Např. rozdílová hodnota koeficientu −2 bude zakódována Huffmanovým kódem kategorie 2, za kterým následuje binárně 01, tedy 2. hodnota ve sloupci rozsah. První bit udává vlastně znaménko. Za kategorii 0 se již žádné další bity nepřipojují. Aby se předešlo konfliktu se synchronizačními značkami 0xff, netvoří žádný z použitých Huffmanových kódů pouze bity 1. Pokud by se bajt 0xff vyskytnul v zápise hodnoty za kódem kategorie, musí být následován vloženou hodnotou 0x00. Sestavení tabulky Huffmanových kódů je záležitostí kodéru. Často se však používají předpočítané tabulky, což má výhodu v menší výpočetní náročnosti komprese.

kategorie	rozsah hodnot
0	0
1	−1, 1
2	−3, −2, 2, 3
3	−7 … −4, 4 … 7
4	−15 … −8, 8 … 15
5	−31 … −16, 16 … 31
6	−63 … −32, 32 … 63
7	−127 … −64, 64 … 127
8	−255 … −128, 128 … 255
9	−511 … −256, 256 … 511
10	−1023 … −512, 512 … 1023
11	−2047 … −1024, 1024 … 2047

Kategorie a rozsahy koeficientů DC.

Před kódováním každého nenulového koeficientu AC hledá kodér sled Z předcházejících nul. Pokud je nalezen sled délky více než 15 nul, je sled 15 nul zakódován symbolem ZRL. Dalším krokem je výpočet kategorie S pro amplitudu kódovaného nenulového koeficientu. Princip je stejný jako u kategorií koeficientů DC. Kategorie 0 není využita, protože koeficienty jsou již nenulové (nulové se kódují pomocí RLE). Kategorie S a délka sledu Z se nyní použíjí jako indexy do tabulky Huffmanových kódů. Za kódem opět následují bity, které udávají pořadí ve sloupci rozsah (tedy upřesňují hodnotu koeficientu). Kód pro Z = 0 a S = 0 má význam EOB. Kód pro Z = 15 a S = 0 je ZRL, což lze chápat jako sled 15 nul, který je následován koeficientem s amplitudou 0, tedy celkem 16 nul.

Standard JPEG (T.81) definuje základní kontejner JIF pro data komprimovaná metodou JPEG. JIF využívá uspořádání bajtů big endian. Soubory jsou rozděleny do segmentů, což je blok max. 65 535 B. Každý segment začíná značkou čili markerem, který identifikuje jeho obsah. Marker je dvoubajtová hodnota, ve které první bajt má vždy hodnotu 0xff. Druhý bajt je vždy v rozsahu 0x01 až 0xfe. Hodnota 0x00 je vyhrazena pro použití skutečné hodnoty 0xff (255) uvnitř segmentu. Další hodnoty 0xff před začátkem markeru jsou ignorovány. Důležité markery jsou APP0 (hlavička JFIF), APP1 (Exif), SOF0 (začátek obrázku v základním režimu), SOS (začátek komprimovaných dat), RSTm (restartovací značky), DHT (definice Huffmanových tabulek) a DQT (definice kvantizačních tabulek). Datový tok zkomprimovaný metodou JPEG je možné vkládat do různých kontejnerů (např. MJPEG, PDF, TIFF). Nejčastěji se vkládá do samostatného souborového formátu JFIF, který rozšiřuje JIF především o hlavičku a náhledy. Tyto soubory pak mají příponu jpeg nebo jpg. Další možností je použít formát Exif, který je taktéž rozšířením formátu JIF. Exif je značně složitější než JFIF – vkládá do formátu JIF formát TIFF, do kterého ukládá nejrůznější informace o snímku (např. výrobce, model fotoaparátu), náhled obrázku atd. Exif a JFIF nejsou kompatibilní, často se však používá hack, ve kterém se jako kontejner použije JFIF a za hlavičku se vloží ještě segment s daty Exif.

Pro ty, které tento blogový zápisek zaujal, přikládám odkaz na svůj vlastní dekodér a enkodér formátu JPEG. I s komentáří má cca 4 000 řádek kódu. Za reportování jakýchkoli chyb budu vděčný.        

Komentáře

[jiwopene]

Moc děkuji za tento zápisek. Myslím si, že AbcLinuxu takovéto články pomohou.

[z_sk]

K obsahu. Mohol by si nieco technicky spomenut o head tohto formatu, ked uz spominas to kodovanie. Ja som raz si robil vlastny program na najdenie a obnovenie vsetkych .jpg/.jpeg suborov z odielu sdaX a nebolo to az take tazke.

Preco si vyvijal vlastny en/decoder?

- written in C99

Bolo by fajn dopisat, ze so GNU GCC rozsireniami. ;)

V Makefile by bolo fajn dat premene:

BIN_ENCODER=jpg_encoder
BIN_DECODER=jpg_decoder

A doplnit make install/uninstall do /usr/local/bin.

Nechces zo svojho programu urobit kniznicu + bin program?

[DaBler]

Ten make install by měl fungovat. Jinak je to takové pěkné cvičení k pochopení detailů, jak JPEG přesně funguje. Dekodér vypisuje informace, co přesně našel v bitstreamu. Původně jsem ho začal vyvíjet, abych s ním mohl experimentovat. Zatím mám na mysli vymezení oblasti zájmu (ROI), kde se bude komprimovat ve vysoké kvalitě, přičemž zbytek obrazu (pozadí) zůstane v nízké kvalitě. Dělat z toho teď knihovnu nevidím jako úplně smysluplné, protože je k dispozici libjpeg(-turbo), který je rychlejší a nabízí mnohem větší funkcionalitu.

[z_sk]

Aha. Install tam mas, ale nie uz uninstall.

[ehmmm]

Kdysi o tom mel pan Tisnovsky luxusni serial na rootu:

https://www.root.cz/clanky/programujeme-jpeg-diskretni-kosinova-transformace-dct/

[Bherzet]

Skvělý článek, díky.

[Petr Fiedler]

Díky za skvělý článek.

[David Ježek]

JPEG, to ještě někdo používá?

[_]

Tak 99.9% lidí s ptistupem k počítači, telefonu nebo fotoaparatu?

[Jendа]

Bohužel ano, HEIC furt není leckde podporováno. Browsery, ale ani spousta desktopových prohlížečů (Eog, Ristretto) to neumí. Co používáte na prohlížení HEIC na Linuxu? (samozřejmě si to umím konvertovat imagemagickem a prohlížet pak, ale je to na nic)

[vencour]

Co to, kde eog nemá podporu pro jpeg? V gentoo je to

* media-gfx/eog
     Available versions:  (1) 3.36.3
       {+exif gtk-doc +introspection +jpeg lcms +svg tiff xmp}
     Homepage:            https://wiki.gnome.org/Apps/EyeOfGnome
     Description:         The Eye of GNOME image viewer

[Jendа]

JPG samozřejmě zobrazuje, mluvil jsem o HEIC.

[vencour]

Pardon, nějak jsem nedával pozor. Co koukam, tak gimp má podporu pro "heif". A ještě má podporu imagemagick (aspoň to říká "equery h heif"). Nápovědou mi byl tenhle přehled.

[Jendа]

samozřejmě si to umím konvertovat imagemagickem a prohlížet pak

...

Ale prohlížet si fotky tímto způsobem je dost nepohodlné. To už bych si snad napsal FUSE filesystém, který to bude konvertovat za běhu…

[Bherzet]

Nebo si napsat skript, který zaregistruješ v Thunaru na otevírání *.heif a on na pozadí udělá konverzi někam do tmpfs a pak to otevře normálním prohlížečem? Když pro tu konverzi použiješ nějakou nekomprimovanou bitmapu, nemusela by tam být ani moc velká prodleva oproti nativní podpoře přímo prohlížečem samotným.

[Jendа]

Mně jde asi hlavně o prohlížení šipkama next/prev.

[vencour]

Balíček imagemagicku má i "/usr/bin/display", to nejde nějak volat, asociovat a nekonvertovat?

[Jendа]

Ten má dost příšerné UX (a ještě mi zobrazuje blbě barvy, což nevím čím je).

[vencour]

Co se podívat na verze apod. ... tedy něčim to být musí.

$ ls -l /usr/bin/display
lrwxrwxrwx 1 root root 6  2. led 17.32 /usr/bin/display -> magick
$ ldd /usr/bin/magick
	linux-vdso.so.1 (0x00007ffdef3c7000)
	libMagickCore-7.Q16.so.8 => /usr/lib64/libMagickCore-7.Q16.so.8 (0x00007effb0938000)
	libMagickWand-7.Q16.so.8 => /usr/lib64/libMagickWand-7.Q16.so.8 (0x00007effb07fd000)
	libc.so.6 => /lib64/libc.so.6 (0x00007effb063f000)
	libxml2.so.2 => //usr/lib64/libxml2.so.2 (0x00007effb04da000)
	libfontconfig.so.1 => //usr/lib64/libfontconfig.so.1 (0x00007effb0493000)
	libfreetype.so.6 => //usr/lib64/libfreetype.so.6 (0x00007effb03d0000)
	libXext.so.6 => //usr/lib64/libXext.so.6 (0x00007effb03b9000)
	libX11.so.6 => //usr/lib64/libX11.so.6 (0x00007effb0277000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007effb0264000)
	libz.so.1 => /lib64/libz.so.1 (0x00007effb024a000)
	libltdl.so.7 => //usr/lib64/libltdl.so.7 (0x00007effb023e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007effb00fa000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007effb00d8000)
	libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgomp.so.1 (0x00007effb00a3000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_s.so.1 (0x00007effb0089000)
	/lib64/ld-linux-x86-64.so.2 (0x00007effb0c6c000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007effb0084000)
	libicuuc.so.67 => /usr/lib64/libicuuc.so.67 (0x00007effafea3000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007effafe74000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007effafe6b000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007effafe32000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007effafe07000)
	libicudata.so.67 => /usr/lib64/libicudata.so.67 (0x00007effae2ee000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libstdc++.so.6 (0x00007effae077000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007effae070000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007effae068000)
	libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007effae04e000)
$

[Gréta]

a ty velikánský neekologický foťáky co dělaj fotky z prací sody kafe a pomerančový šťávy by se taky měli zrušit dneska má stejně každej normální člověk mobil auž ani jako neví kudy se do takovýho starobylýho foťáku kouká a kudy z něj lítaj takový ty světelný blesky :O ;D

[Podlesh]

ty mas tak maximalne velikanskou neekologickou pipinu

[Gréta]

a už jeto tady hele :D :D ;D ;D

[xxxs]

to nie je zle. este nieco vyvesti.

[Agent]

Vůbec temu nerozumim, ale je to zajímavý :) Kde se vzaly hodnoty těch tabulek?

[DaBler]

Co se týče té kvantizační tabulky, tak ve standardu k tomu uvádějí: These are based on psychovisual thresholding and are derived empirically using luminance and chrominance and 2:1 horizontal subsampling.

[Gréta]

8bitová vstupní data (na každou složku)

díky :D :D :D :D

Mimoto JPEG definuje hierarchický režim, kdy je obrázek uložen v několika různých rozlišeních.

to trošku připomíná jakoby mipmapu hele :O :O

[Tomáš]

Díky za krátký přehled. Mám dotaz.

Stále jsem se nedostal k podrobnému studiu steganografie. Všude se píše, že skrytá data se dají propašovat např. i do obrázku JPG. Ale není mi jasné, kam konkrétně a jestli to změní obrázek. Nebyl by k tomu taky nějaký zápisek?

[DaBler]

Typicky se data skrývají do kvantovaných DCT koeficientů. Na tom jsou založeny třeba metody JSTEG, F3, F4, F5. Reference: Westfeld, A.: F5—a steganographic algorithm. In International workshop on information hiding, Springer, 2001, s. 289–302.

Pak je možné je uložit na nápadnější místa mimo obrazová data. Například na konec souboru (za marker EOI), do nevyužitých kvantovacích tabulek, do APPn markerů, apod.

[Josef Kufner]

Ano, obrázek se změní. Pointa je, že jen tak málo, aby si toho nikdo nevšiml.

[Radovan]

Samozřejmě že se obrázek změní, protože do těch změn je zakódovaná utajená informace. Podstatné je, že pro její zpětné získání potřebuješ mít i původní obrázek, bez kterého nesmí být rozdíly v pozměněném obrázku patrné. Což může být u JPG trochu problém, kvůli ztrátové kompresi. Bezztrátové formáty jsou vhodnější.

Zápisek si můžeš přečíst třeba tady: https://www.root.cz/clanky/jak-ukryt-tajna-data-do-obrazku-aneb-steganografie-v-praxi/

[Aleš Kapica]

Tss, utajované informace. Bohatě by stačilo, kdyby u těch svých obrázků zachovávali informace neutajované.

[PetebLazar]

Podstatné je, že pro její zpětné získání potřebuješ mít i původní obrázek.

A je to opravdu nutné, já bych naopak řekl že původní obrázek je zapotřebí účinně zničit? Pokud vezmu případ formátu obrázku s bezeztrátovou kompresí a pro jednoduchost řekneme, že nejnižší bit barevné informace subpixelů bude představovat bit zakódované informace (samozřejmě předem zašifrovaný jinou metodou), pak pouhá extrakce těchto nejméně důležitých bitů z obrázku mi dá stream šifrované zprávy (z něhož po dešifrování získáme otevřený obsah). Na obrázku se užitečná informace projeví pouze jako nepatrný šum. Další otázkou je samozřejmě charakter takového šumu, výsledek prvodního zašifrování může být až příliš náhodný (snímače mají typicky jiný charakter šumu, ale i s tím se lze vypořádat).

[Radovan]

A opravdu je nutné používat něco silnějšího než Caesarova šifra?

Ale jistě, to co popisuješ ty je dávno známé, fungovalo to jako zpráva vytetovaná do kůže na hlavě otroka a zarostlá vlasy. Nebo jako psaní neviditelným inkoustem mezi řádky skutečného dopisu. To co popisuji já odpovídá Vernamově šifře. Ve všech třech případech jde o steganografii, a rozhodnutí co je lepší ponechám klidně na tobě.

[JiK]

jake sifry, kdo nema co schovavat, tak nesifruje. Kdo sifruje, je nepritel spolecnosti, terorista a pedofil. A mozna i popirac boje proti klimatu. Strana a Vlada to s nama zasadne mysli dobre.

[Radovan]

Připojuješ se sem přes HTTPS? Jsi zločinec a zasluhuješ exemplární trest.

[M]

Co si volis, to mas.

[Miriam (ta pravá)]

díky za pěkný článek, připomíná mi to staré dobré časy, než na ábíčku udělali adminem mámomrda a buzíka kolibáče

[_]

kdyz nekdo prca samice, neni buzik, i kdyz si vybira v jinem zivocisnem radu nebo v hrackarstvi

[Miriam (ten levý)]

jenže jeho máma je chlap. nechala se přeoperovat, protože se jí narodil buzík!!