Názory k článku Programujeme JPEG: Progresivní JPEG a informace EXIF
-
Pavel TišnovskýZlatý podporovatelTo je pravda, ale dobrej právník by poukázal na to, že se jedná o informace, které je možné jednoduše změnit a že se k nim nemusí přihlížet třeba při obhajobě. Ale nevím přesně, jak u nás tyto "doličné předměty" fungují. -
P_V (neregistrovaný)Domníval jsem se, že i v progresivním spektrálním režimu se používá zigzag scan, a počet průchodů (na kolik dílů se ten scan rozdělí), stejně tak i které barvové složky se v kterém průchodu budou přenášet, je na libovůli aplikace. Zde je však ukázán scan v upraveném pořadí koeficientů (zřejmě výhodnějším z hlediska rozložení energie) a pevně daný počet průchodů. Tady jsou i příklady spektrálních a aproximačních JPEGů i s popisem "trhaného" cikcak skenu.
-
Pavel TišnovskýZlatý podporovatelAno, ty koeficienty byly vybrány tak, aby se ve stejném kroku přenášely hodnoty umístěné zhruba na kruhu. Střed je v DC složce, poloměr se zvyšuje o "jednu horizontální pozici". Mělo by to více odpovídat rozložení energie v obrázku, jak správně říkáte.
-
Pavel TišnovskýZlatý podporovatelJeště jsem ve článku neuvedl odkaz na stránku, kde se vizuálně porovnávají obě metody tvorby progresivních JPEGů:
http://wwwicg.informatik.uni-rostock.de/Projekte/MoVi/jpeg/pexamples.html -
Jakub Drnec (neregistrovaný)Jpeg 2000 je progresivni vzdy. Kdyz to velmi hrube zjednodusim, tak se obrazek prekoduje na vlnky, ty se setridi od nejvice k nejmene viditelnym a tato sekvence vlnek se zakoduje do binarni formy. Pokud to chcete bezeztratove, nechate je vsechny, pokud ztratove, uriznete si prislusny kus od zacatku.
Teoreticky by se dal napriklad na web dat obrazek v maximalni kvalite a rozhodovani o tom, jak kvalitni nahled si dotahne, presunout ke klientovi. Coz by ostatne mohlo jit i s progresivnim jpegem. -
Pavel TišnovskýZlatý podporovatelAno, JPEG2000 takto opravdu funguje. V nekterych pripadech to vsak pusobi problemy: tiskarny a plottery s malou pameti (nutno rastrovat primo v ovladaci), zarizeni s malo pameti (dig. fotaky, mobily) atd. Precejen ma sekvencni JPEG stale co rici.
U progresivniho JPEGu (klasickeho) se tusim o necem podobnem taky uvazovalo -> klient by posilal serveru, kterou cast ma dotahnout a kdy uz to dostacuje, ale nejak se ten mechanismus neujal (dlouhe timeouty technologie TCP?). Dneska se tedy progresivni JPEGy stahuji cele, pokud tedy klient prenos neprerusi, jak klient tak i server JPEG berou jako normalni balik bytu a ne jako strukturovana data. -
Pavel TišnovskýZlatý podporovatelDneska uz spis babicka :-) Jde o obrazek, ktery se uz dlouhou dobu pouziva jako urcity mustr pri porovnavani ruznych algoritmu zpracovani obrazu. Lennu ci Lenu muzete videt pri popisu ruznych obrazovych filtru, metod ztratove komprimace atd.
-
Fik (neregistrovaný)"Největší předností progresivních JPEGů je schopnost zobrazení poměrně kvalitního náhledu na obrázek již po načtení cca jedné desetiny obsahu souboru s uloženým obrázkem, nevýhodou pak poněkud menší komprimační poměr v porovnání se sekvenčními soubory JFIF/JPEG ..."
No mne se naopak zda (aspon u fotek z digitalu), ze progresivni JPG je skoro vzdy mensi, nez sekvencni. Kdyz zkusim napriklad jednu fotku:
jpegtran -copy all -optimize img_6899.cr2.jpg > optimize.jpg
jpegtran -copy all -progressive img_6899.cr2.jpg > progressive.jpg
pak velikost je:
2601313 optimize.jpg
2514374 progressive.jpg
Pritom se jedna o bezestratovou transformaci (teda aspon si to myslim), takze toto bezne delam se vsema svyma fotkama. Usetrena velikost zavisi na fotkach a na fotaku, spolu s "jhead -dt" (vymazani thumbnailu z EXIF) a s prevodem do progresivniho jpegu pro Canon 350D je to v radu 10%. -
Pavel TišnovskýZlatý podporovatelZalezi na obrazku, predevsim rozlozeni energie ve spektru a clenitosti. Jde o to, ze progresivni JPEG nejprve zpracovava DCT slozky s nizsimi energiemi a potom slozky s energiemi vyssimi. Pokud se stane, ze je obrazek vhodne rozmazany (typicky fotky, tam je to mimo jinych okolnosti dano take principem snimani), tak maji slozky s vyssimi energiemi hodnotu blizkou nule a diky 'progresivnosti' se dostanou k sobe, coz v dusledku vede k vetsi komprimaci Huffmanovym kodem.
U obrazku vzniklych napr. v raytraceru, nebo tak, kde se casto stridaji motivy (plakaty) ten pomer muze byt opacny, opet je to v radech 1-10%. -
imcon (neregistrovaný)Rád bych se zeptal odborníky na chování při náhledu na JPG obrázky uložené ve složce.
Popíši:
Do adresáře jsme nahráli řadu malých obrázků (obrázky produktů).
Přepnutím zobrazení obsahu adresáře je možné vidět náhledy obrázků (WinXP...).
U některých obrázků jsem ale zpozoroval, že zobrazený náhled neodpovídá aktuálnímu obrázku při otevření souboru, ale jedná se zřejmě o náhled odpovídající fotce před úpravou.
Pokud zadám Obnovit náhled, vše se spraví.
Ptám se: jak to, že náhled zobrazovaný v Exploreru (možná i na jiném systému, nezkoušell jsem) se liší od obrázku?
Pokud je náhled uložen v nejakém tagu JPG, je možné pomocí nějakého SW zobrazit uložený náhled?
Díky za komentáře. -
Rád bych se zeptal na metadata - zajímá mě nejvhodnější typ pro správu fotografií: tedy klíčová slova apod. Co je vlastně pro správu fotografií nejlepší používat (i ve vztahu k použitelnému software)? Našel jsem v podstatě tři hlavní systémy: EXIF - ten mi připadá nejvhodnější pro práci s daty z fotoaparátu (clona, čas apod.), ale na správu fotek mi moc vhodný nepřijde. IPTC - zdá se mi moc podrobný, prý neumí unicode. XMP - nějak jsem z různých článků pochopil, že je nejperspektivnější např. je přímo implementován ve Windows Vista, umí ho Windows Live Fotogalerie, v Picase se podle něho dá vyhledávat.
Co byste doporučili, proč a v souvislosti s jakým software? Jde hlavně o to se ve fotkách vyznat. Fotky bych chtěl mít na externím médiu a používat na různých počítačích tzn. pokud má program nějakou svou vnitřní databázi (která třeba ještě navíc data nesynchonizuje), tak je to blbé.
