Autor Zpráva
Darker
Profil
Přizpůsobit obrázek rozumným rozměrům je snadné. Jak mám ale, bez nějakého „pokus - omyl“, obrázek zmešit tak aby se přesně vešel pod požadovanou datovou velikost, pokud tuto přesahuje?
Davex
Profil
Co máš proti metodě pokus - omyl a proč se musí obrázek přesně vejít pod požadovanou velikost?
weroro
Profil
Darker:
Jak mám ale, bez nějakého ‚pokus - omyl‘, obrázek zmešit tak aby se přesně vešel pod požadovanou datovou velikost, pokud tuto přesahuje?
Pokiaľ by sa jednalo o BMP obrázok, tak by sa to dalo prepočítať, ale to tento prípad nebude.
peta
Profil
Nevim o tom, ze by to slo jinak nez pokus - omyl. Vyrobis pokusny obrazek a podle jeho velikosti ho muzes doladit bud jemne nebo hrube pomoci moznosti. Stejne se to uklada do pameti a pak das v php freemem a neni problem. Pamet to snese, pokud to neni nejaky obri obrazek.
Co znamena zmensit obrazek?
* rozmery? 1024x768 na 320x200? (++)
* kvalita? 0.85 na 0.7? (+++)
* metoda ukladani desetinne carky? (+)
* zpusob prokladani barevnych vrstev? (+++)
* pocet barev, barevna hloubka, nejcasteji u Gifu? (++)
* metoda ukladani? (+ jpeg / +++ tiff bw)
A co ja vim, co jde jeste nastavit pro obrazky.
Darker
Profil
peta:
Doufal jsem, že někdo ví, jak tu velikost spočítat. Generování obrázku třeba na tři pokusy se mi zdá jako ztráta času a záležitost procesorově docela náročná.

metoda ukladani desetinne carky?
Tuhle úpravu velikosti obrázku nechápu, poradíš víc?
Davex
Profil
Darker:
Doufal jsem, že někdo ví, jak tu velikost spočítat.
Velikost obrázku v nekomprimovaném formátu jde spočítat jednoduše.

šířka krát výška krát počet bajtů na jeden pixel + hlavička

Výsledná velikost obrázku v komprimovaném formátu dopředu spočítat nejde, protože každý obrázek a komprimační metoda potřebuje jiné množství informace k zrekonstruování původního obrázku.
peta
Profil
Darker:
Nainstaluj si gimp, otevri obrazek a zvol tak Soubor, Ulozit jako, napis aaa.jpg a dej ok. Rozbali ti na vyber spoustu moznosti pro jpeg format. Umi zaskrtnutim spocitat i velikost souboru. Defaultne je to vyskrtnute.

Velikost bmp souboru lze spocitat viz Davex.
Velikost jpg muzes spocitat prepocitanim obrazku do jpeg, cili ulozenim. Nelze to osidit. Ze znalosti zvolenych parametru pro ulozeni to lze odhadnout, pokud neco vis o jpeg kompresi. Jenze odhad nema smysl, protoze prepocitani do jpeg je rychla zalezitost. Na 286 pc 40MHz se 4MB ram se mi jpeg obrazky zobrazovali blik, blik, asi s 0.3s zpozdenim. Co se tyce zateze, kdyz to zvladla 286, tak dnesni procesory 4000MHz s tim asi nebudou mit problem.
Cela operace vypada asi takto:
- rozloz na barvy RGB, pripadne prepocitej na (YUV)
- rozostri UV slozky (prokladani barev, 4 sousedni body na 1 nebo nerozostri, viz nastaveni)
- vezmi matici bodu, ctverecek treba 8x8 (pro kazdou slozku barvy YUV)
- rozmnoz ji do pameti do 8x8 poli, cili 64x namnoz
- pronasob s jinym polem 8x8 matic dct // nasobeni dvou cisel je brnkacka pro procesor
- spoj opet do 8x8
- pronasob matici qauntizace (8x8)
- rozloz na velka a mala cisla a uloz (na 286 se jeste nerozkladalo)
- pokracuj s dalsi matici
- velka a mala cisla uloz specialni metodou
Zpetny proces je podobny.
Plovouci carka jen zvysuje drobne presnost nasobeni, kvalitu vysledku. DCT matice ma totiz desetinna cisla generovana funkci cosinus.
Principialne vetsina operaci je pouhe nasobeni. Vysledkem DCT*Q je treba 1 velke cislo a asi 10 malych kladnych a zapornych, zbytek ze 64 byva nula. tady by se dala odhadnout velikost podle poctu nul nebo cisel nule blizkych. Operace ukladani je sice trosku narocnejsi, ale probiha tez celkem bleskove.
Potom by se dal vysledek odhadnout take s poctu ruznych barev nebo stridani barev. Jpeg nesnasi prudkou zmenu bila vs. cerna / barvevna slozka. Pri stejnych parametrech se kvalita obrazku prudce zhorsuje. Png proti tomu trpi opacnym problemem :) Aspon jsem ted delal zmenseniny barevneho textu, zmensenina 1:2/1:2 mela 38k, 1:1/1:1 original mel 21k. Pri zmenseni se mi texty rozmazaly, trosku a to png nedal. Jpg jsem nezkousel, chtel jsem text co nejvice citelny.

Na wiki to neni moc rozepsane, ale na rootu zas az moc :)
http://en.wikipedia.org/wiki/JPEG
http://www.root.cz/clanky/programujeme-jpeg-huffmanovo-kodovani-kvantovanych-dct-slozek/

Jpeg vs. PNG na textu
http://upload.wikimedia.org/wikipedia/commons/a/a4/Comparison_of_JPEG_and_PNG.png
Joker
Profil
Darker:
Doufal jsem, že někdo ví, jak tu velikost spočítat.
A o jaký formát obrázku jde?

U nekomprimovaného formátu to jde spočítat hlavička plus bitů na pixel krát počet pixelů, jak píše Davex.
U komprimovaného formátu je komprese právě ten výpočet.
Velikost komprimovaných dat závisí na vstupních datech (třeba náhodný šum se bezeztrátovou kompresí nezmenší vůbec, zatímco u vhodných dat může úspora místa být klidně přes 99%), takže logicky nelze vypočítat velikost komprimovaných dat bez analýzy toho vstupu.
Sice by nejspíš šlo výslednou velikost odhadnout na základě nějaké analýzy vstupních dat, ale pochybuji, že by to bylo ve výsledku rychlejší, než obrázek skutečně převést.

Navíc třeba u JPEGu lze zmenšit datový objem obrázku jednak zmenšením rozměrů obrázku, jednak snížením kvality (čili větší ztrátovostí komprese).

Ale metodu pokus-omyl by šlo vylepšit pomocnou tabulkou sestavenou na základě předchozích převodů obrázků.
Fungovalo by to asi tak, že by se vybral nejpodobnější dřívější obrázek a nový obrázek se konvertoval na stejné nastavení, jaké bylo úspěšné u toho dřívějšího.
Tam jsou pak různé varianty provedení, od několika natvrdo daných „profilů konverze“, až po učení se na základě výsledků zpracování předchozích obrázků.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: