Názory k článku
Programujeme JPEG: Progresivní JPEG a informace EXIF
Keny (neregistrovaný)
8. 2. 2007 13:00
Nový
Fakt díky
celé vlákno
Tomu říkám opravdu výživný článek a seriál, podobně jako ten o fraktálech. Jinak k EXIF a možnosti kompromitování. Každý rub má i svůj líc. Dovedu si představit i situace kdy vás takováto možnost lokalizace fotografie v čase a místě dokáže vytáhnout z bryndy.
8. 2. 2007 14:13
Nový
Re: Fakt díky
celé vlákno
To 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í.
jenicek (neregistrovaný)
25. 7. 2008 12:28
Nový
Re: Fakt díky
celé vlákno
Pokud bude mít ten obrázek resp. soubor kvalifikované časové razítko dle zákona, tak to průkazný je:-)
P_V (neregistrovaný)
8. 2. 2007 15:29
Nový
Zigzag
celé vlákno
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.
8. 2. 2007 17:40
Nový
Re: Zigzag
celé vlákno
Ano, 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.
8. 2. 2007 17:35
Nový
Porovnání dvou metod tvorby progresivních JPEGů
celé vlákno
Ješ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
http://wwwicg.informatik.uni-rostock.de/Projekte/MoVi/jpeg/pexamples.html
Jakub Drnec (neregistrovaný)
8. 2. 2007 20:01
Nový
Pro zajimavost - JPEG 2000
celé vlákno
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.
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.
9. 2. 2007 10:48
Nový
Re: Pro zajimavost - JPEG 2000
celé vlákno
Ano, 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.
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.
Jirka (neregistrovaný)
10. 2. 2007 12:15
Nový
Re: Pro zajimavost - JPEG 2000
celé vlákno
Obrazek v JPEG2000 je taky mozno nejprve rozdelit na mensi casti, aby je mohla zpracovat prave mensi zarizeni.
uživatel si přál zůstat v anonymitě
9. 2. 2007 10:44
Nový
Lena - JPG divka
celé vlákno
Kdo je ta divka Lena z obrazku?
uživatel si přál zůstat v anonymitě
9. 2. 2007 10:47
Nový
Re: Lena - JPG divka
celé vlákno
odpoved jsem uz nasel: http://en.wikipedia.org/wiki/Lena_Soderberg
9. 2. 2007 14:35
Nový
Re: Lena - JPG divka
celé vlákno
Dneska 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.
ladaan (neregistrovaný)
20. 3. 2007 11:37
Nový
Re: Lena - JPG divka
celé vlákno
Nas ucitel nam rikal, ze je to nabijecka z Playboye :)
Fik (neregistrovaný)
9. 2. 2007 11:15
Nový
progresivni ma mensi kompresni pomer?
celé vlákno
"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%.
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%.
9. 2. 2007 11:30
Nový
Re: progresivni ma mensi kompresni pomer?
celé vlákno
Zalezi 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%.
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%.
uživatel si přál zůstat v anonymitě
6. 4. 2007 9:29
Nový
EXIF
celé vlákno
Kterým prográmkem nejlépe a nejsnadněji odstraním informace z exifu jako jsou například informace o úpravě, použitém programu atp.??? Většinou se prográmky zaměřují jen na autora a popis obrázku. :(
imcon (neregistrovaný)
10. 2. 2009 13:12
Nový
Zobrazení náhledu JPG (liší se od obrázku)
celé vlákno
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.
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.
17. 3. 2009 8:41
Nový
EXIF, IPTC, XMP
celé vlákno
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é.
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é.

