Nette\Image – návratový image type

Nevím, jestli právě tohle je chtěné chování. Pokud třeba obrázek otevírám, abych ho zmenšil, pak vstupní formát nemusí být pro uložení právě ideální.

No podle me by stacilo pridat do konstruktoru druhy parametr definujici dany typ a ten si ulozit jako promennou a pak ji pri exportu pouzit. Nebo by uplne stacilo aby si alespon trida pamatovala z jakeho typu resource vzniknul a byla schopna ho pres nejake getType() vratit… Tim by se obesla nutnost pouzivat primo funkce GD pokud chce clovek dosahnout funkcionality zminene vyse..

To je sice pravda, ale pokud napr. resizuji obrazek s tim, ze ho budu chtit zobrazovat na webu, tak TIFF neni dobrym resenim a pokud to budu chtit ulozit s TIFFu do JPG nebo GIFu, tak jsme tam, kde jsme byly (na jednobarevnych plochach z puvodniho GIFu udela JPEG fleky, GIF by zas z puvodniho JPG osekal barvy). Tady to neni ani tak otazka, jestli je to True Color, nebo ne, jako spis jestli se jedna o ztratovou, nebo neztratovou kompresi.

Dalo by se rict, ze tenhle problem resi PNG, kde nedochazi ani ke ztratam kvality, ani ke ztratam barev, ale jeho vyuziti na webu je zas kvuli sporadicke podpore trochu komplikovanejsi.

Je ale fakt, ze pripady, kdy je potreba tohle resitu, budou asi docela vzacne a neni asi nutne resit to na urovni frameworku.

David Grudl napsal(a):

Podle mého je vstupní formát nepodstatná informace: jeho smysl padá okamžikem načtení obrázku do nějaké interní podoby.

Tak to souhlasim jen na pul, podle me muze byt aplikace kde je vstupni format dulezitou informaci pro dalsi zpracovani. Jde ale o uhel pohledu nad danou knihovnou, pokud pro ni vstup konci nactenim a nema tvorit jakousi abstraktni „obalku“ nad konkretnim souborem existujicim nekde jinde, tak to potom jo a souhlasim, ze je vstupni format nepodstatna informace…

I tak diky za odpoved :-)

onge napsal(a):

kravco napsal(a):

majoritné prehliadače PNG dobre podporujú vo svojej ostatnej stable verzii.

Bohuzel, stale je prilis mnoho lidi, co pouziva IE 6 a ta ma podporu vicenez sporadickou a je potreba to resit nejakym podivnym javascriptem. Ja tedy zastavam nazor, ze kdo pouziva IE, obzvlast ve verzi 6, muze prikladat zodpovednost za vsechny nepristojnosti jen a jen sobe, ale holt je takovych lidi porad dost.

Pokiaľ viem, IE 6 má problémy „len“ s priesvitnosťou, ktorá pri zmenšovaní/zväčšovaní nie je veľmi zaujímavá…

Jinak na fotky je samozrejme nejlepsi jpeg, pokud bych ale nechtel zjistovat, z jakeho formatu prevadim, png je jedina moznost, jak si nesprasit obrazky.

To je otázka, čo je pre teba dôležitejšie – to, aby bola zmenšenina v 100% kvalite (bezstratová) ale veľká ako šlak, alebo o niečo menej kvalitná a v rozumnej veľkosti. Pre mňa GIF ako formát nie je zaujímavý, fotky do PNG zmenšovať určite nebudem a keď budem potrebovať dodržať vstupný formát aj na výstupe, tak si napíšem detekciu. Myslím, že Davidove predvolené nastavenie je rozumné.

David Grudl napsal(a):

Podle mého je vstupní formát nepodstatná informace: jeho smysl padá okamžikem načtení obrázku do nějaké interní podoby.

podle mého je vstupní formát velice podstatná informace. pokud předpokládáme, že uživatel není úplný pitomec a nepoužívá nějaký naprosto nevhodný formát, tak nám může něco říci o tom jaká data obrázek obsahuje

pokud si porovnám ty nejpoužívanější, třeba fotografii (truecolor, ztrátová komprese), screenshot nebo vektorovou grafiku převedenou na bitmapu (truecolor, bezztrátová komprese) a animovaný obrázek (třeba avatar; paleta), není ŽÁDNÝ formát, který by byl vhodný pro všechny. pro to první se hodí jpeg, pro druhé png, pro třetí gif

Přeuložení GIF do JPG není vhodné proto, že GIF je určený pro obrázky s paletou, JPG pro truecolor fotografie. Vedle toho takový TIFF je vhodný pro uložení obojího.

Takže není lepší prostě něco takového?

$image->send( $image->isTrueColor() ? Image::JPEG : Image::GIF );

paleta-nepaleta, jsou i jiné důležité informace, které pravděpodobně vzal uživatel v potaz při volbě formátu (animace, průhlednost, rozložení souvislých ploch) a ty by tedy měl respektovat i výstupní formát

bohužel při VÝCHOZÍM nastavení Nette\Image dva z výše uvažovaných tří obrázků zničí, protože nezachová původní formát. při převodu do jpeg bude u png výsledek méně kvalitní a větší, protože pro souvislé plochy má png lepší kompresi než jpeg, u gifu dojde ke ztrátě animace (IM umí resizovat animovaný gif, GD zřejmě ne) a ke zhoršení kvality. gif jako defaultní formát použít nelze kvůli ztrátě barev. png zase proto, že u fotografií by výsledný soubor byl příliš velký, stejně jako u tiffu atd..

formáty prostě MAJÍ SVŮJ SMYSL, jinak by jsme používali jen jeden. žádný jednotný ‚interní‘ formát neexistuje. a jistě by bylo pro programátory i pro uživatele nejjednodušší, kdyby Nette\Image při úpravách zachovával ten formát, který je na vstupu, pokud programátor neurčí jinak – třeba podle pravidla „Less code, more quality“ :]

proto se také přimlouvám za změnu aktuálního chování. ať je prosím defaultně výstup stejný jako vstup

ano. zřejmě nějaké transformace provedeny budou, k tomu ostatně Nette\Image slouží. ale předem není známo, které konkrétní transformace bude ten který programátor provádět a jakým způsobem to ovlivní obsah obrázku, a tudíž nelze určit nějaký konkrétní defaultní formát. a když tyto údaje neznám, je podle mne nejlepší chování spolehnout se na informaci ze vstupu. pokud bude například proveden jen ořez, je změna ostatních formátů na jpeg nesmyslná

pokud nic jiného (nebo možná „ještě lépe“), mohl by alespoň Nette\Image uchovávat a zpřístupňovat informaci o typu získanou při načtení přes Image::fromFile()? jinak je totiž třeba ke zjištění původního formátu znovu a tedy zbytečně volat funkci getimagesize(), která již jednou byla volána při vytvoření objektu

>

pokud nic jiného (nebo možná „ještě lépe“), mohl by alespoň Nette\Image uchovávat a zpřístupňovat informaci o typu získanou při načtení přes Image::fromFile()? jinak je totiž třeba ke zjištění původního formátu znovu a tedy zbytečně volat funkci getimagesize(), která již jednou byla volána při vytvoření objektu

Za tohle jsem uz nahore taky zkousel lobovat.. :-)

Já bych implementoval nějakou metodu getOriginalType, která by vracela typ, který se zjišťuje v konstruktoru. A bylo by vystaráno.

Ja bych byl spis pro moznost zjistovat typ vstupniho obrazku, nez jen zachovat puvodni format – dostat treba tiff nebo bmp by mohl byt problem