jednim slovem huusty. zkouset to radsi nebudu.

Dr4k3: Ušlo vám, že jde o ztrátový algoritmus! Jakoukoliv "dekompresí" nikdy už nezískáte původní data!

Kompakcia - beztratove algoritmy
Kompresia - stratove algoritmy

No jo, ale co kdyby v článku bylo alespoň s jakou kvalitou se ten JPEG ukládal? Je to *ztrátová* komprese, takže kvalita (kolik se toho může ztratit) dost výrazně ovlivňuje výsledek. Schválně si zkuste uložit JPEG s kvalitou 1% :-)

Asi bude hodně záležet na nastavení, protože po dekompresi už jednou zkomprimovaného obrázku a následné kompresi bych měl při správném nastavení dostat stejná data, protože k zaokrouhlení členů DCT už jednou došlo. Zřejmě to bude způsobené tím, že dekompresor se snaží zkomprimovaný obrázek "vylepšit" a následně se komprimují změněná data, tomu by odpovídalo i to video, kde je hezky vidět, že k prvním viditelným chybám dochází tam, kde jsou obrysy objektů.

Dr4k3: Někteří jedinci o tom, co čtou, prostě nepřemýšlí, jenom memorují a pak papouškují, třeba zde přítomní ms a kvackina.

DR4K - neni to vubec tak jednoduche, pri ztratove kompresi do JPEG-u vznikaj v obraze  artefakty, ktere pri dalsi rekompresi zase  prochazej kompresnim algoritmem a vzniknou dalsi artefakty...atd... Proste nekomprimujes ten samy zdroj, je vzdy mirne odlisny - o tom to cele je. Taky hodne zalezi na nastaveni komprese, tech moznosti je u Jpegu jaxi docela dost ;)

Tak udelam ze sebe vola - Dr4k3 ma pravdu! :)) Pokud  budu komprimovat  dokola vysledek predchozi komprese s absolutne stejne nastavenymi parametry, bude vysledek  absolutne stejny, po kazde, do posledniho pixelu ;) Takze me napada jedine delat  to na stridacku s 2 ruznymi nastavenimi, ale nechce se mi s tim hrat....nemam na to tolik casu :D

S tim jpegem jsem neco podobneho predpokladal (samozrejme velmi zalezi na nastaveni pri ukladani do jpg), vic mne ale vzdycky zajimalo, jak by pri podobnem testu dopadla mp3 (napr. v LAME pri 160-192kbps pri nastaveni vysoke kvality) .... Neda si s tim nekdo tu praci? ;-)

dle mne to dopadne stejne jak u toho Jpegu - pri stejnem software a stejnem nastaveni by mel byt  vysledek identicky. Ted jsem zkousel ten jpeg, jen ukladat  vzdy s o 1% jinou kompresi - 40 - 41 - 40 - 41 - 40 - 41 % - a okem to po nekolika ulozenich sice nepoznam, ALE  uz to neni datove identicke,   takze po  dostatecnem poctu  opakovani by tam rozdil byl i viditelny. Pri rekompresi s tim samym nastavenim je vysledek i datove identicky - pokazde.

Mě by spíš zajímalo, co by se dělo dál - jak bude vypadat obr. po 1000x, 2000x, ... uloženích - jestli se to "ustálí" na nějaké periodické sekvenci obrázků nebo jen na jednom ... a jak tento "otisk" bude vypadat pro různé obrázky - jestli se budou lišit, nebo všechny obrázky "vyšumí" stejně :-)

Dr4k3: presne tak, presnetak... rozoznavame dva zakladne druhy stratovych kompresii, tie ktore maju tendenciu ustalit sa na nejakej forme (tie co pouzivaju DCT, FFT systemy) a tie ktore s kazdou kompresiou vytvaraju novy vysledok, znacne odlisny of povodneho (chirp systemy ako v GSM6.10, ako sa to uz vsetko vola si uz vobec nevybavim)

Xspy: samá perla :-) :-)

Dr4k3 má pravdu. Proč by se měla ztrácet další informace? Si představte že zaokrouhlujete číslo 2.5, získáte 2 a ztratili jste informaci. Když číslo 2 znovu zaokrouhlíte máte zase 2, už se neztratí další informace, tak proč by se měl jpeg zhoršovat, pokud se mezi tím neprovedou nějaké změny? Nechápu, ale aspoň mělo bejt uveden název softwaru ve kterým to bylo ukládáno...

Vzhledem k tomu ze jsem kompresi a dekompresi JPEGu delal na vejsce jako jeden skolni projekt (s pouzitim DCT), tak o tom neco vim, a ty tabulky pres ktery to leze pred a po ulozeni byly naprosto identicky (pokud by nebyly presne na bit stejny, tak projekt nebyl spravne naprogramovanej, prave tak se kontrolovala spravnost programu), pokud se parametry komprese nemeni a pracujete s dostatecnou sirkou floatu. Tady muselo do hry vstupovat neco navic, napr. antialiasing, smoothing, jina komprese nebo neco podobnyho pro zlepseni dojmu. Program kterej datove zachovava obraz (nehraje si s nim jen kvuli zobrazeni) tohle proste neudela ... V posledni dobe tech amaterskejch uletu a zarucenejch kachen mate nejak moc, ne?

Chápu se vysvětlování: Mám obrázek o velikosti 10MB. Uložím ho s kompresí 90%, na disku bude obrázek o velikosti 9MB. Tento obrázek o velikosti 9MB na disku otevřu a budu z něj mít obrázek o velikosti 10 MB v RAM - to je to rozbalení komprimovaného souboru. Takto získaný obrázek o velikosti 10MB uložím s kompresí 90%. Budu mít soubor o velikosti 9MB ... Z toho vzniká ta vtíravá otázka, jestli opakovaným ukládáním a otvíráním se bude obrázek nadále degradovat či nikoliv. Já bych hlasoval pro variantu, že k největší degradaci dojde při prvním uložení. Následující ukládání už bude mít vliv na degradaci zanedbatelnou, takže jestli to provedu 600x nebo 6000x bude jedno, i když rozdíl půjde "změřit". 

Xspy: 1) ten soubor není menší a menší... stačí vyzkoušet 2) jakékoliv uložení do ztrátového formátu je ztrátové 3) TIFF je jen taková obálka, pokud použiješ kompresi ZIP, pak máš pokud jde o velikost ekvivalent

Hugocz: Všechno špatně. "Mám obrázek o velikosti 10MB." Pleteš si už základní věci - velikost obrazu a souboru. "Uložím ho s kompresí 90%, na disku bude obrázek o velikosti 9MB." Naprostý blud. A tak se to valí dál.

RIMAN - prave ze jsem si to zkusil a je to jak popisuji.Pokud  vysledek = zdroj, po opakovanem pouziti vysledku coby dalsiho zdroje, tak ...?

Teda absolutní hodnoty jsem si demonstrativně vymyslel - tak doufám že mě za to neukamenujete. Jen jsem chtěl naznačit, že po 10 uložení se soubor nebude vždy zmenšovat o dalších 10 %.

A co když je to dané tím jak se k tomu ten software chová. Nějaký může být dostatečně inteligentní. Třeba tak, že ví, že otevřel JPEG a když ho chceš znovu uložit tak se podívá jestli byly nějaké změny. V případě že nebyly tak ho neuloží, jen změní datum poslední změny.

Co zkusit takovýhle pokus. Vzít BMP, převést ho do JPEG, ten převést do BMP a následně z něj zase udělat JPEG. A porovnat ty dva JPEGy (teď jsem to udělal v GIMPu a ty dva JPEGy jsou různé).

Tak a teď jednoduché a zjednodušené vysvětlení. Jde o to, že JPEG využívá sinovou a cosinovou transformaci (Fourierka). Prostě vezme obrázek, udělá nad tím fourierku a ukládá jen parametry té transformace (koeficienty u sinů a cosinů). Při otvírání dojde k vypočítání původního obrázku. Během té transformace došlo ke ztrátě vyšších frekvencí (ano, i u obrázku je možné mluvit o frekvencích) a díky tomu dojde ke vzniku oscilací, které se na obrázku projeví jako nové (jiné) barvičky. Při opětovné kompresi do JPEGu se to zase pokusí udělat co nejlepší koeficienty, ale ty jsou už jiné (máme JINÝ zdrojový obrázek než na začátku pokusu).

Vím že mi asi nebudete věřit, ale zkuste si to v tom GIMPu (je to otázka 2 minut)

Dr4k3> navazas sa tu do mna ako keby som neviem co napisal, robis tu zo seba odbornika a ze nech nepisu ti co tomu nerozumia a pritom sam mas v tom bordel silno zasadny.
Najvacsiu pravdu tu mal zatial Milosh, ked v v podstate vysletlil, ako to funguje + zdoraznil, ze po viacnasobnom komprimovani nikdy nedostaneme to iste. Preco? Pretoze ked nieco zkomprimovane ulozite a nasledne otvorite, mate obraz iny ako na zaciatku. Spolu napriklad s novymi artefaktami a pod, ktore sa pri dalsom komprimovani spracuju inak!! Preto je obrazok po 600x taky aky je.

Jak už si paco správně všiml, v původním článku je napsáno, že komprese byla po každém uložení o něco zvýšena (tj. došlo ke změně kompresních parametrů) - z toho plynou změny v obraze i po 600. uložení.

Milosh to vysetlil nejlepe. Finta je v tom, ze ztratova komprese se jmenuje ztratova, protoze pri kazde komprimaci dochazi ke ztrate informace. Ta ztrata nemusi byt linearni a zavisi na druhu komprese a komprimovanych datech(obsahu). Takze zjednodusene, pri kazde kompresi dojde ke ztrate informace - tudiz v kazdem kroku komprimujeme jiny obrazek !!

riman: jádro pudla je ve slově "neshoduje se". Co to znamená? Např. rozdíl v jednom bajtu? A při každé další rekompresi rozdíl v dalším jednom bajtu? To je po 600 rekompresích krásný rozdíl 600 bajtů u nekolika MB obrázku? A to neřeším, jaký vliv má jeden bajt na vzhled celého obrázku. Mýslím, že se tady pánové dohadují právě o tohle. Jestli obrázek změněný o 0.00000001% je ještě původní obrázek, nebo už ne. Podle mě k největší ztrátě dat dojde první kompresí. Dalšími opakováními se už kvalita "výrazně" nezmění.

Vzal jsem obrázek a uložil ho do JPG. Ten jsem otevřel v editoru a znovu uložil do nového JPEG s nezměněným nastavením, výsledek jsem otevřel a opět uložil - celkem mám 6 JPEG souborů. Výsledek? První tři JPEG soubory se liší, čtvrtý a všechny další jsou binárně identické se třetím. Použitý software: Zoner Photo Studio 11, fc /b.

jaj...

samozrejme, ze to jsou zaokrouhlovaci chyby... Vemte si libovolny obrazek ve fotosopu aulozte si jej jako JPG. Potom jej otevrete, zkopirujte do schranky, vytvorte novy soubor a vlozde... provedte nekolkrat (stacilo 3x). Otevrete prvni soubor a posledni soubor, dejte vrstvy na sebe, zvolte rozdil. Vrstvy slucte. Na prvni pohled uvidite cerno, ale pokud si změníte kontrast (prip CTRL+L) tak po trech takovychto ulozenich s naprosto stejnymi parametry uz rozdil najdete.

RIMAN - zkus to udelat ne 3x, ale 30x po sobe. Je asi veci Photoshopu ze jeste neco optimalizuje, nebo dochazi k nejakemu zaokrouhleni certnevi ceho pri kompresi, proto ty prvni kopie se jemne lisi - dalsi uz jsou uplne identicke. Viz http://tinyurl.com/jpegy-jpg - vzdy  je dalsi vysledek nacten a preulozen jako kopie = "zrekompresovan" - az do " f " se o par  B lisi, ale od f dal je to uplne stejne - az po z  a dal me to nebavi neb je to porad stejne. Kdyz porovnam ty JPEG-y tak od  f po z  jediny rozdil je nekde v hlavicce - cas/datum, obsah je stejny.
 
Stejny pokus  s Paintshop Pro - umi detailnejsi nastaveni JPEG exportu, a jsou vysledky stejne  od  prvniho zkomprimovaneho.

UWE neporovnavej velikost souboru ale jejich obsah, napr. pomoci Total Commanderu "Porovnat podle obsahu".

OK, porovnal jsem v a z a je tam v nekolika bajtech  (asi 5) rozdil = ano, neni to absolutne identicke, po nejakych 5 milionech znovuulozeni by to mozna bylo i videt. ;)  Nebo zaokrouhlovani zaokrouhli to co minule jeste ne a po dalsich 10 - 20 rekompresich uz to identicke bude, nevim - nechce se mi to overovat/nemam tolik casu ;)

Protože při kompresi do JPEG formátu se určuje kvantifikátor (= víceméně kvalita zobrazení), nikoli úroveň komprese. Q=90% neznamená, že se při každém uložení ztratí 10% informací, ale že se odstraní informace, které pro danou kvalitu nejsou potřeba - pokud už takové informace v obraze nejsou, není co odebírat (zjednodušeně a asi ne úplně přesně řečeno).

JPEG komprese ma dve casti: prevod do frekvencniho prostoru (DCT) a zaokrouhleni. Prevod do frekvencniho prostoru a zpatky je bezeztratovy. Zaokrouhleni uz zaokrouhlene cislo nezmeni.

V zavislosti na programu mozna skutecne kazdy jpeg bude jiny (kvuli zaokrouhlovacim chybam), ale odlisnosti budou porad mensi - rekomprimace i po desitkach tisic iteraci neskonci sumem, ale obrazkem opticky nerozeznatelnym od rekneme desate iterace.

Samozrejme pokud ten program neobsahuje chybu.

Každý JPEG kompresor by měl po několika krocích komprese (se stejnými parametry) konvergovat k jednomu stavu, ze kterého se to už nepohne (může to být klidně i více obrázků, mezi kterými to bude rotovat). Řekl bych, že na tento proces bude mít velký vliv implementace komprese v enkodéru (celá čísla vs. plovoucí čárka) a přítomnost postprocesingu v některých dekodérech.

Jenže ze zdrojáku vyplývá, že se zároveň mění (zvyšuje) nastavení JPEG komprese... čili není konstantní...

wift: ja to resil prechodem na linux :-), beztak jsem v dosu pouzival djgpp, ktery vychazel z gcc.

Tedy já na tenhle server přispívám nerad, protože zobrazuje IP adresu (místo hashe), ale naprogramoval jsem si program na opakované načítání a ukládání JPEGu a musím se podělit. Video by z toho pěkné nebylo, protože JPEG se prostě na stejnou kvalitu dále nezhoršuje! Situace by se jistě změnila při editaci obrázku, na nepoužívání JPEGu na rozdělanou práci to nic nemění, aby mě zase někdo blbě nebral za slovo, ale prostě na fotce absolutně žádný rozdíl není znát ani po 4000 iteracích na kvalitu 5 ani 95. Zkusil jsem nasprejovat do fotky ostré červené pixely, to algoritmus nemá rád. Sice už se pak daly najít drobné rozdíly, ale byly minimální.
Technická informace: Použil jsem Intel JPEG Library 1.51. Je možné, že jiné ukládače budou kvalitu zhoršovat víc.

Nějak nechápu o čem tahle diskuze je, kvalita jpegu nemá důvod se zhoršovat, už z principu na kterém je jeho komprese postavená...

spis by me zajimalo ktery expert po sobe uklada ztratovou kompresi? pokud potrebuji neco upravovat a nekolikrat ukladat, budu to delat v nejakem bezztratovem formatu jako TIFF. JPEG bude pouze posledni vysledek jednou konvertovany. zajimalo by me k cemu tenhle clanek slouzi :o)

Timto se verejne omlouvam veskerym internetovym serverum typu Novinky apod. jakozto i televizi Nova za to ze jsem si kdy dovolil je obvinit ze zkreslovani informaci. Vzit zdroj kde je ve 20 slovech napsany co se s tim obrazkem provedlo a vynechat z nej zrovna ty 4 slova ktery jediny popisujou cim se vlastne ta informace ztraci ("with slightly more compression"), to je fakt unikat :-) A jeste se k tomu vymlouvat na neznalost kodu kterej vubec neni potreba cist ani analyzovat :-D
 
Milosh: Ano, po prvnim ulozeni se ztrati (orezou) vysoke frekvence, nicmene vysledkem je ze obrazek ktery nadale tyto vysoke frekvence neobsahuje a tudiz vysledek pristi Fourierrky jsou uz jen ty nizsi frekvence. Za predpokladu ze orezavame stejny prostor koeficientu, neni co orezavat a tudiz obraz se dal uz nemeni. FT je exaktni vypocet, ne nejaka stochasticka metoda a jak vyplyva z nazvu, pouze Transformuje data (hodnoty pixelu na frekvence), krome zaokrouhleni je tudiz sama o sobe bezeztratova a jak uz tady nekdo zminil, jednou zaokrouhlene cislo se dalsim zaokrouhlenim nezmeni. Jedina ztrata je v ni mozna v pripade, ze nesplnuje vzorkovaci teorem coz by v korektne implementovane metode ovsem splnovat vzdycky mela.
 
Pro ty co to zkouseli v programcich a nezda se jim to: Pokud vas program nepracuje v barevne hloubce pracujici s floatem (0-1 spojite) ale bajtem (0-256 diskretne) pak se opravdu muze stat ze oteviranim a ukladanim se ztrati informace, je to ale zpusobeno zaokrouhlenim pri konverzi z realneho prostoru cisel do diskretniho prostoru coz vlozi do obrazu dalsi nechtene vysoke frekvence ktere musi neco oriznout. Kazdy seriozni graficky program ovsem zasadne pracuje v barevnych modelech s realnymi cisly. Uz jen proto ze se s nimi mnohem snadneji provadeji vypocty s obrazem protoze pri nasobeni 0..1 x 0..1 z toho vzdycky vypadne 0..1 bez jakychkoliv dalsich uprav. Tudiz v JPEG kompresi bez zmeny parametru a pracujici s realnymi cily se po prvnim ulozeni obraz dale uz opravdu nemeni.
 
Komu se to jeste nezda, doporucuju nejdriv dukladne nastudovat na internetu JPEG kompresi a az pak protestovat. "Nezda se mi to, je to prece ztratova komprese" a "Muj program ty data fakt ztraci, i babicka to rikala ze to nejak vybledlo" nejsou argumenty :-)

JeCh: Na otazku ohledne komprese MP3 bohuzel nedokazu jiste odpovedet, protoze tou jsem se nikdy nezabyval takze nevim co se tam vlastne z vysledku uklada a jak se to pak rekonstruuje. Proto si jen zaspekuluju: V pripade zvuku to je princip nejspis jinej, protoze pokud by se osekaly jen vyssi frekvence, tak to bude pasmova propust, a tudiz to bude mit efekt jako ekvalizer, zvuk se vyrazne zmeni, tam na frekvencich zalezi, protoze zvuk sam o sobe je vec harmoniky. Tj. FT probehne, ale vyber vzorku nebude oriznutim. Rekl bych ze se tam budou nejakym zpusobem vybirat frekvence podle nejakyho pravdepodobnostniho modelu aby se zachovalo co nejvic tech ktery se podileji na tom zvuku a tom jak ho vnima ucho, ale ne nutne ty nizky nebo vysoky ... urcite se tam neco oreze i zespoda i shora v pasmu co clovek neslysi, ale i neco mezi tim. To by vysvetlovalo ty prubezny ztraty (pokud k nim zase teda dochazi i v pripade zpracovani na urovni floatu a ne kvuli zaokrouhlovacim chybam v diskretnim meritku amplitudy).
 
Co se tyce toho ulozeni, tak to bude zrejme ten pripad kdy program nebude pracovat s float modelem, ale s byte modelem a dochazi tam k tem zaokrouhlovacim chybam co jsem zminil v minulym prispevku.
 
Tady je to docela dobre vysvetleny i pro cloveka kterej to vidi poprve, je na tom dobre videt co se tam deje a co se vlastne osekava a jak se urci ktery oblasti pro zachovani obrazu jsou nejdulezitejsi a rozdil mezi ztratovou a bezeztratovou JPEG kompresi: http://en.wikipedia.org/wiki/JPEG

Jeste k tomu musim dodat to, ze si muzete vsimnout ze tam je hromada mist kde je Round(), protoze v prikladech pracuji s hodnotami v rozsahu -127 az 127 aby to bylo lepe pochopitelne ale presto realne, aplikace pracujici ve "spojitem" rozsahu se prave techto zaokrouhlovacich chyb ktere pri dalsi kompresi obraz poskozuji vysokymi i nizkymi frekvencemi nedopusti a timpadem to ulozi stejne jak to bylo predtim (pokud to bylo predtim ulozene zase z ni).

2HejtmaMa: at uz to oduvodnis jakoukoliv akademickou metodou. zdravi rozum mi rika, a mam to overene z praxe, ztratova komprese jiz z nazvu udela dalsi ztraty. nebo-li prirustove ztraty. nebo mi chces tvrdit, ze JPEG komprimovan nejakou kompresi a pak znovu komprimovan je opet stejny jako predesly? po druhem ulozeni a rekompresi musi byt rozdilny. to je ptakovina co tu pises nebo mas podivny program co uz nekomprimuje.

v kazdm pripade nechapu porad smysl teto diskuze. kdo uklada nekolikrat po sobe do stejneho JPEGu? fotim v RAW, exportuji po doladenich do JPEG, hotovo. fotim v JPEG, poladim znovu ulozim, hotovo. po nekolikate ulozeny JPEG uz je prasarna, nemyslite?

sniper29a: Diskuse neni o kompresi existujiciho JPEGu ale o jeho otevreni a ulozeni. Otevreni a ulozeni neni komprese ... pokud bych ho chtel dal komprimovat, musim udelat to co je napsano v tom originalnim clanku a nebylo puvodne v tomhle, a to sice znizit kvalitu zvysenim komprese.
 
Az ted jsem si vsiml ze je clanek opraveny, dekuji autorovi za uznani chyby.

sniper29a: To ze ponekolikate ulozeny JPEG je prasarna plne souhlasim, ale jen v pripade kdy se v nem pri kazdym z tech ulozeni neco zedituje nebo ho ukladam nekolikrat zkusebne a zvysuju kompresi dokud se nedostanu na velikost ktera mi vyhovuje a muzu ji napr. poslat mailem. To je ta vec kterou zdroj predvadi ...

HejtmaMa: Nezapomínej na to, že při JPEG kompresi nedochází jen k ořezání vyšších frekvencí, ale také ke kvantizaci frekvenčních koeficientů. Takže při zpracování jpegu dochází vždy k převodům float -> int a tím i k zaokrouhlovacím chybám. Toto není závislé na použitém grafickém programu, kvantizace je pevnou součástí jpeg komprese. K ustálení proto dojde obvykle až po více krocích.
Další problém spočívá v tom, že JPEG používá YUV model, zatímco grafické programy obvykle počítají v RGB prostoru. I při převodech mezi těmito barevnými prostory vznikají další zaokrouhlovací chyby a to už vůbec neřeším to, jak různě je řešen převod vzorkování, kdy RGB používá 4:4:4 a YUV 4:2:2.

jirka1: Kvantizacni koeficienty se jednou zaokrouhli (pri prvnim ulozeni) a pak uz je obraz rekonstruovany se zaokrouhlenymi a ukladany s temi samymi. Pokud se nikde na ceste otevreni souboru -> ulozeni souboru nikde nezaokrouhluje (coz neni problem, staci vsude pro vsechny promenne pouzit float nebo double), tak zustanou stejne ... aspon ten nas skolni projekt s tim nemel problemy, takze predpokladam ze kdyz to zvladnou dva studenti v tymu naprogramovat tak ze otevreni a ulozeni je bezeztratove a funguje to pro vic nez jeden obrazek, tak ze to algoritmus umi ;-)

WIFT: Vsak jo, to je v poradku. Ja to psal v dobe kdy jsem si nevsiml ze to v clanku uz je opraveno, takze jsem byl porad trosku namichnutej tim informacnim nesmyslem. Za to se omlouvam ja. Nic ve zlym ;-)

HejtmaMa: Jenže tím, že program počítá vše ve floatu, si moc jistý nejsem. Pokud otevřu obrázek, dám na něj kontrast +50 a následně -50, nedostanu původní obrázek, ale obrázek, kde hodnoty, které po aplikaci prvního filtru přesáhly rozsah 0-255, byly osekány. Pokud by výpočet probíhal ve floatu, měl bych ovšem dostat obrázek identický s originálem. Jde tedy o to, jestli při otevření souboru dojde k převodu na RGB <0-255> vždy, nebo až po nějaké editaci.

jirka1: Program pocita v tom v cem ho naprogramujes :-) Odflaknuty graficky jadro programu bude pocitat s integerem, kvalitni s floatem, precizni s doublem, algoritmus to nevylucuje. Pokud to zrovna tvuj program dela spatne, tak ma graficky jadro odflaknuty :-) Mimochodem, pokud zmensis kontrast na 50% a pak zvysis o 50%, tak vysledek je 75%, protoze tech druhejch 50% je z tech zbyvajicich 50 po prvni operaci, spravne bys musel nejdriv snizit o 50% a pak zvysit o 100% :-) Teda za predpokladu ze zmena kontrastu bude nejakou linearni funkci ... coz asi nebude tak uplne pravda ...

HejtmaMa: No, ten příklad byl z Photoshopu, což je asi program, kde dělá hodně lidí. Je to starší verze, nabízí 8 bit na barvu, 16 bit na barvu, ale nikoliv float. V novější verzi je 32 bit.
Ty procenta ber jako příklad, důležité je, že vznikne ta osekaná oblast.

jirka1: Ano, je spousta programu ktery pouziva hodne lidi a nejsou vubec takovej zazrak jak se navenek tvari :-) Nehlede na to ze bitovy hloubky ktery ti nabizi nemusi vubec odpovidat modelu se kterym interne pracuje, kdyz udelas prebarveni barvy kterou nastavis v RGB, tak to nutne neznamena ze program ma v pameti model RGB ... 
 
Dobre, oseknuti oblasti je paralela k prvnimu ulozeni JPEGu. Uloz ten obrazek se snizenym kontrastem (do BMP, at tam netahame dalsi ztraty), zvys kontrast, pak ho sniz zpatky. Obrazek bude oseknutej porad stejne protoze se v ramci operace vesel do puvodniho datovyho prostoru. Ano, i takova operace jako je zmena kontrastu muze byt vratna, pokud se s ni vejdu do prostoru hodnot ve kterym to provadim ... Pri otevreni JPEGu obrazek nemenim, tudiz datovej prostor zustava (pokud nezaokrouhluju), a stejne tak i po ulozeni.
 
Promin, ale argumentace toho co vidis v nejakym konkretnim programu a jeste nejaky starsi verzi neznamena ze algoritmus je spatne a ztratovej. To znamena pouze ze danej program ho nema implementovanej dostatecne presne aby ztratovej nebyl, je to dan za rychlost zpracovani. Beru argumenty ktery budou rozebirat metodu komprese, princip kvantizace, FT (popr. DCT) a ukazou kde konkretne se ty data pri kazdym ulozeni ztrati, ale ne pohled koncovyho uzivatele na obrazek kterej vidi.

HejtmaMa: Ale já taky neříkám, že JPEG algoritmus je špatný, jen jsem říkal, že očekávám, že se ve většině programů projeví zaokrouhlovací chyby. Neustále tedy bude nastávat převod Int-float-int. Je tu prostě rozdíl mezi ideálním řešením a řešením užívaným v praxi.

Jirka1: No to teda rikas :-)
 
Cituji: "Takže při zpracování jpegu dochází vždy k převodům float -> int a tím i k zaokrouhlovacím chybám. Toto není závislé na použitém grafickém programu, kvantizace je pevnou součástí jpeg komprese."
 
zpracovani jpegu, VZDY, neni zavisle na programu ... tvuj originalni prispevek mluvi jasne a hodnoti JPEG algoritmus, nikoliv jeho pouziti v praxi :-)

HejtmaMa: Jenže když se nad tím zamyslíš, tak to není v rozporu. Opravdu při zpracování jpegu dochází vždy ke kvantizaci a tím i k zaokrouhlovací chybě. To je součástí ztrátového algoritmu, kdybys ukládal přímo výsledky DCT, tak by těch dat bylo naopak víc než ve vstupním obrázku, ale bylo by to bezeztrátové.
Ty tvrdíš, že pokud tu samou kompresi provedu po druhé na obrázek dekomprimovaný bez zaokrouhlovacích chyb, dojdu opět ke stejnému výsledku. S tím souhlasím a jen říkám, že v reálném softwaru je to jinak.
To, že dochází k degradaci obrázku i při dalším kódování je způsobeno dvojím zaokrouhlováním: Jedno je to obsažené v jpegu, druhé při převodu float - 8 bit RGB. Kdyby existovalo jen jedno zaokrouhlování, nebude se už dál obrázek degradovat. Ale takhle dochází k převodu 8 bit RGB -> DCT + kvantizace (1. zaokrouhlení) -> hotový JPEG -> IDCT -> zaokrouhlení na 8 bit RGB (2. zaokrouhlení).

Jirka1: V rozporu to je, protoze ty tvrdis ze v realnem programu je tam vzdycky zaokrouhlovani. Nas program z projektu je nerealny kdyz nezaokrouhluje? Je snad imaginarni? :-D Nic v systemu nevyzaduje aby obraz byl v pameti ulozenej na tech 8 bitu, napr. OpenGL se bezproblemu da krmit texturama typu float ktery konvertuje az interne.
 
Termin realny program pro tebe proste znamena: "Programy ktere znas a pouzivas", coz je jen mala podmnozina vsech, smir se s tim ze existujou i jiny :-)

HejtmaMa: Dobrá, když jde o slovíčka, tak ne v reálném, ale v běžně dostupném SW :-)

Otevřel jsem a uložil jpeg obrázek 1200x a je pořád stejný. Kde je chyba?

Jirka1: Dej tam misto "Dostupnem" radsi "Pouzivanem", a pak souhlasim :-) Dostupne jsou samozrejme i ty ktere float pouzivaji :-D

Ztrátový algoritmus obsahuje ztráty informace. Jůůů... to je fakt objev, hodný demonstrace :-)