Názory k článku Programujeme JPEG: Kvantizace DCT koeficientů
-
jx0 (neregistrovaný)Tradicne velmi dobre. Dekuji za clanek.
Opet par poznamek:
[1] preklep: Q77 je vpravo dole
[2] U kvantizacnich tabulek jeste nezaznelo nejak natvrdo (a proto se tak domnivam), ze kvantizacni tabulka musi byt uvedena nekde v souboru. Mam i dotaz: Je mozne mit v jednom JPEGu vice techto tabulek? (Neco jako v GIFu vic framu s paletami.) -
Pavel TišnovskýZlatý podporovatelDiky za opravu.
Kvantizacni tabulky jsou ukladany do vysledneho JPEGu, aby ho bylo mozne spravne zrekonstruovat. Format ulozeni je podobny jako u vlastnich pixelu: cik-cak. Urcite je mozne ukladat vice tabulek, minimalne tri (jsou ocislovane). Typicky se jedna tabulka pouziva pro barvonosne signaly (Cr, Cb) a druha pro luminanci (Y), protoze na rozmazani jsme citlivejsi prave u luminance, proto se zde take "mene kvantuje". Da se vsak take pro kazdou barvovou slozku pouzit samostatna tabulka, tj. jedna pro Y, druha pro Cr a treti pro Cb. -
Pavel TišnovskýZlatý podporovatelPokud je mi znamo, tak prepinani tabulek pri zpracovani neni povoleno.
-
Pavel TišnovskýZlatý podporovatelTaky mam dojem, ze se ty mene dulezite casti obrazu kvantuji trosku jinou kvantovaci matici, nez tou, ktera je ulozena spolu se souborem. Pri dekomprimaci to nevadi, protoze 0 x cokoli=0.
-
Pavel TišnovskýZlatý podporovatelPorad se mi ta otazka honila hlavou, protoze jsem si pamatoval, ze nekde se skutecne dalo pouzit vice kvantizacnich tabulek.
Ve skutecnosti se u JPEGu jasne pise, ze od chvile zahajeni prenosu dat (tim mysli spusteni kodovani ci dekodovani) se uz kvantizacni tabulky nesmi menit.
Narozdil od JPEGu se u MPEGu mohou menit kvantizacni tabulky jak pro cele snimky (framy), tak i dokonce pro jednotlive bloky 8x8 hodnot. U JPEGu ani u MJPEGu to mozne neni. -
Pavel TišnovskýZlatý podporovatelOriginalni tabulky JPEGu byly ziskany ze zpracovani velkeho mnozstvi obrazoveho materialu a tyto koeficienty jim v realnych testech vysly jako nejlepe pouzitelne. Jestli je to proto, ze se v obrazcich vyskytovalo vice vertikalnich hran (priroda, budovy atd.) to nevim. Mozne take je, ze proste HVS neni uplne symetricky (to by odpovidalo umisteni a funkcim oci - cloveka vlastne nikdy neohrozovali dravci ze vzduchu, ale potreboval pomerne ostre a presne videni smerem dopredu a nepresne, ale aspon nejake, videni do stran).
Clovek jako lovec (tedy vetsinou, nekdy se role otocily) ma oci umistene na predni strane hlavy a ne na bocich, jako nektera zver, ktera je nepotrebuje pro lov, ale naopak pro ochranu pred predatory.
Musite si uvedomit, ze u JPEGu (ale i u OGG ci MP3) se pohybujeme v oblasti navrhu nejakeho systemu, kde presne nezname model lidskeho vnimani (my ho dokonce nezname ani hrube). Proto se ani nedaji provadet nejake presnejsi vypocty ale je zapotrebi provest realne testy, at uz nad obrazky nebo nad hudbou/zvuky. -
P_V (neregistrovaný)Tak to jsem zkoušel a dospěl k překvapivým závěrům. Tedy, bezeztrátově otočit fotku ve formátu jpeg, pak originál i otočený jpeg otevřít v nějakém grafickém editoru, v bitmapové podobě otočit zpět a udělat rozdíl. Téměř vždy tam byly rozdíly (šum kolem jedné až dvou úrovní z 256), a ty rozdíly se lišily program od programu. Vypovídá to o kvalitě použitých algoritmů. Kdyby se kvant. tabulka neotočila tak by ty rozdíly asi byly zásadnější a pro všechny programy shodné. Kupodivu nejméně šumu vyprodukoval Photoshop.
-
Pavel TišnovskýZlatý podporovatelTo je opravdu zajimave, protoze bezeztratova rotace je uz (podle jmena) bezeztratova :-) Ale doopravdy, pokud ten program jenom poprehazuje koeficienty ulozene v JPEGu a transponuje kvantizacni tabulku, tak by k zadne ztrate nemelo dojit (to poprehazeni neni zas tak jednoduche, protoze se meni Huffmanuv kod, ale porad jde o vec celociselnou a hlavne nikde nic nevznika ani nezanika).
Ostatne kdyby se otaceni delalo "otrocky" az na urovni bitmap, tak by trvalo o dost delsi dobu, protoze by se prosel cely cyklus JPEG->inv.Huffman->inv.kvantizace->inv.DCT->YCbCr->RGB->otoceni->RGB->YCbCr->DCT->kvantizace->Huffman->JPEG. Jestli spise neni problem v tech grafickych editorech, ktere pri dekomprimaci JPEGu muzou treba zaokrouhlovat apod. (hlavne aby to bylo rychle ne?). -
jx0 (neregistrovaný)Tak jsem to zkusil taky a ate pravdu. Zkusil jsem to shrnout tady. Opravdu ten sum je kolem te jedne az dvou (maximalne tri, ale velmi zridka) urovni z 256. Ale cim to je, to teda nevim, to je otazka pro odbornika.
-
P_V (neregistrovaný)Podle mně jsou to zaokrouhlovací chyby při dekompresi. Jestliže daný algoritmus provádí zaokrouhlené výpočty v určitém pořadí, pak při zpřeházení tohoto pořadí se chyby sejdou jinak.
Podle charakteru šumu by snad bylo možno i identifikovat použitý dekompresní algoritmus. Výsledky jsem nezkoumal tak exaktně jako Vy, ale bylo možno usoudit že většina programů co mi přišla pod ruku, produkuje rozdílový šum obdobný (bajvoko) jako dekodér v utilitě jpegcrop založené na zdrojácích IJG. Z toho vybočovaly některé prastaré dosové prohlížeče (šuměly více nebo "jinak") a již zmíněný Photoshop, jehož dekodér produkoval rozdílového šumu nejméně. -
Culibrk (neregistrovaný)Myslim, ze je to kvuli fyzilogii cloveka - vnimani obrazu je citlivejsi na svisle hrany nez vodorovne, protoze pomoci nich rekonstruuje vzdalenost predmentu. A u jpegu se s tim evidentne pocita. Na druhou stranu to take znamena, ze pri konverzi na bezztratovoy format a rotaci o 90 stupnu dostaneme (subjektivne) mene kvalitni obraz. Hmmm.
-
Jakub Friedl (neregistrovaný)To je ovšem docela zajímavé z hlediska fotografie. I fotoaparáty rozeznávající svoji orientaci mění orientaci snímků pouze EXIF tagem, ne otočením JPEG jako takového. Alespoň IMHO. Ale vzhledem k tomu, že většina foťáků produjuje dost brutálně interpolovaný obraz, je to asi jedno.
ČLÁNKY DO MAILU