Posted By: JohnP (JohnP) on 'CZgraphics'
Title:     Shrnuti GIF & PNG & JPEG, part II
Date:      Tue Mar 25 15:57:58 1997

Posledne jsem odbyl popis JPEGu a srovnani komprese. Tak se to ted pokusim 
napravit.

JPEG
 - podporuje jen odstiny sedi a TrueColor.
 - povoleno 8 a 12 bitu na barevnou slozku a bod, ale pouziva se jen 8.
 - TrueColor predstavuje predevsim barevne modely YCbCr, CMYK a RGB.
 - CMYK se pouziva jen v DTP, neznam jiny SW nez pro DTP, ktery by si dokazal
   s CMYK JPEG poradit.
 - YCbCR je prakticky jediny pouzivany bar. model. Podoba se televiznim normam
   YUV a YIQ. Snad az na Kodak Photo CD pouzivaji ostatni formaty a zobrazovaci
   adaptery RGB, proto je vzdy nutne provadet konverzi mezi RGB a YCbCr.
   Y predstavuje intenzitu, je shodna s tim, co vyleze po konverzi obrazku
   do odstinu sedi. Cb a Cr jsou doplnujici informace odstin a sytost.

Pozn. ke konverzi do sedi a zpetne kolorizaci:
- pri konverzi do sedi se ztraci Cb a Cr (nebo U a V resp. I a Q)
- pri kolorizaci je potreba Cb a Cr nekde nasmelit, nejlepe si vycucat z prstu.
Konec poznamky.

   Proc se to dela takto?
   Lidske oko je totiz mnohem citlivejsi na intenzitu nez na barvu,
   proto lze slozky Cb a Cr zkomprimovat s vetsimi ztratami, aniz by
   to clovek poznal. Tj. Vysledny soubor je pri stejne subjektivni kvalite
   obrazku mensi v modelu YCbCr nez RGB.
  
 - pouzity kompresni algoritmus DCT (Discrete Cosine Transform) je vhodny na 
   obrazky s plynulymi barevnymi prechody - napr. fotografie. V zadnem
   pripade se nehodi na ostre hrany a prechody mezi barvami (vykresy,
   scannovany text, firemni loga apod.). Tyto prechody jsou totiz pri 
   dekompresi rozmazany. Prudke prechody taktez generuji mnohem vice 
   komprimovanych dat, coz vede k vetsim souborum.
 - lze volit mnozstvi ztrat (tj. zmen obrazku), ktere jsme ochotni
   akceptovat. Ani nastaveni 100% kvality nemuze garantovat nulove ztraty.
   Existuji ruzne dekompresni enginy, ktere pouzivaji ruzne aproximace DCT,
   z nichz kazda muze vest ke zcela jinym vysledkum.   
 - Pri pozadavku na 100% qalitu neni nicim zvlastnim narust velikosti 
   souboru oproti nekomprimovanym datum.
 - bezny (tj. snesitelny) kompresni pomer je nekde mezi 10:1 a 20:1, coz    
   zalezi na obrazku i na kompresnim enginu. 



Srovnani:
 - JPEG ma pomerne velkou rezii. Driv, nez zacnou vlastni data obrazku,
   je potreba ulozit de/kompresni, o velikosti radove nekolika set bajtu.
   -> je krajne nevyhodne ukladat male obrazky jako JPG.
 - PNG ma, jak jsem uz psal, vprumeru o cca 10% lepsi kompresni pomer nez GIF.
   V prumeru. Tzn., ze lze celkem snadno najit antipriklady.
 - ze ztratovosti JPEGu plyne, ze JPEG vede ke zhorseni kvality obrazku.


-- JohnP