ja najviac pouzivam TIFF a PSD. to autorovo zboznovanie PNG formatu vobec neni na mieste, neviem ci PNG podporuje 16bitovu farebnu hlbku na kanal, ale urcite nepodporuje CMYK model, CIE L*A*B model, viackanalovy model, stylovanie vrstiev, slices, filtrovacie vrstvy, cesty, smart objects atd.
Staci, kdyz se potka DTPak se zbytkem sveta (== s uzivateli webu) :-) Jinak se to s tim CMYKem nesmi prehanet, pri pouziti barevnych profilu je prevod RGB<->CMYK vcelku bezproblemovy (a to i nasledny tisk).
Jinak taky pouzivam vyhradne png (screenshoty, grafy) pripadne jako mezivysledky (animace a pod). Alternativa moc ani neexistuje, resp. bmp neni podporovano vsim a take neni komprimovano (pouzivam vyhradne ne-MS reseni;)
PNG urcite nezboznuji, je to proste dalsi IMHO velmi dobra technologie. S TIFF a PSD je jeden velky problem - jsou podporovany velmi malym mnozstvim nastroju a zcela jiste se nehodi napriklad pro webovou grafiku, coz je podle meho odhadu tak 49% vyuziti vsech obrazku. Dalsich 49% jsou fotky z fotoaparatu a zbytek jsou ty nase graficke hracicky.
Myslim, ze jsem v clanku docela jasne napsal, k cemu je PNG vytvoreno a urceno (asi jste to cele necetl, o sestnacti bitech na kanal se tam zminuji na vice mistech). Je to proste prenos rastrovych obrazku tak, aby byly zobrazitelne a "ukladatelne" v jakemkoli nastroji, ktery o sobe rika, ze PNG podporuje. Je tomu tak v pripade TIFFu? Mimochodem, i ty dalsi veci, ktere po PNG pozadujete v nem MOHOU byt zapsany. Napriklad Macromedia Fireworks pouziva PNG jako svuj nativni format a vsechny nastaveni (cesty atd.) uklada do nej.
TIFF není obrázkový formát, ale kontejner na data. V TIFF mohou být uložena JFIF data, lze použít různé komprese (včetně gzip).
Každá fotka z fotoaparátu má v sobě TIFF - standard EXIF je totiž založen na formátu TIFF, který je vložený uvnitř APP1 bloku JPEG souboru.
Pro aplikace je jednoduché uložit si do TIFF svá vlastní data, pro jiné aplikace je pak zase jednoduché přeskočit data, kterým nerozumí, a pouze je převzít a zkopírovat do výsledku.
Což mi připomíná IFF z Amigy a jeho bloky dat uvozované čtyřpísmenným kódem. Co jsem měl obrázků jako ILBM (interleaved bitmap), zvuků jako 8SVX (8bitový sampl) a mnoho dalšího.
Přinejmenším naprostá většina dnešních digitálních fotoaparátů (a snad i mobilů) používá EXIF a DCIM adresářovou strukturu na kartě. Staré digitální fotoaparáty však často EXIF nezapisují. Nevím, jak jsou na tom jednoduché modely za 500Kč z teleshoppingu - nikdy jsem je neměl v ruce.
Ano, v tom se TIFF podoba PNGcku, ovsem s tim rozdilem, ze PNG je interne mnohem jednodussi (=nepodporuje vsechny formaty rastru ani zpusoby komprimace, z barvovych prostoru jen RGB) a pritom je jiz ve jmenu bloku jasne napsano, zda je prislusny rozsirujici blok pro aplikace povinny ci voliteleny. I z tohoto duvodu asi nema cenu TIFF a PNG moc srovnavat, protoze u TIFFu se musi rict, kterym programem se pouziva - dnes pravdepodobne neexistuje zadny konverzni ani prohlizeci program, ktery by korektne zvladl nacist vsechny variace TIFFu.
S temi fotkami bych to rekl trosku jinak: fotka muze obsahovat metainformace o obrazku, ktery je ulozen podle standardu EXIF a jeho format odpovida tagum pouzitym uvnitr TIFFu.
No, ja ti navrhujem precitat si vsetky clanky od tohoto autora (http://www.root.cz/autori/pavel-tisnovsky/) - a nie len nadpisy. Rozsiri to tvoje vedomosti, a nebudes ostatnym na smiech. A raz mozno budes schopny napisat podobne kvalitny clanok ...
(Neber to osobne, len ako konstruktivnu! kritiku)
No ono nasazeni gifu a png je nekde jinde nez nasazeni, PSD, pdf, Tiffu
PNG GIF-jsou beztratove a jsou zde kvuli webu. ale najdou upatneni i jinde.
Chtel bych videt jak html emailovou pozvanku s grafikou vytvoris s tiffem a psd :-)
Samozrejme Pokud jde vystup to tiskarny tak je dulezity jine veci nez velikost.
BTW:rekne me nekdo proc zapad jpg2000 pls ten se mi zdal ze dokazal nahradit i tiff...
PS.:Dekuji za velice prinosne clanky
Jpeg 2000 zapadl patrne diky kombinaci duvodu: jako spravny iso format byl navrzeny od stolu (viz debakl s jpeg/jfif), referencni implementace byly hotove pozde, nerozumeji si navzajem a jsou/byly neprakticky licencovane (nebyt ijg jpegliby, je na tom i jpeg dneska daleko hur), zpracovani formatu je desive vypocetne narocne (zatimco jpeg se vam dneska nacte okamzite). A asi nejdulezitejsi duvod: jeho vyhody jsou nevelke, v bezeztratovem modu komprimuje hure nez png, ve ztratovem jen o trochu lepe nez jpeg a proste to nikomu nestoji za tu namahu. Jsou dneska daleko zajimavejsi formaty (svg) a i ty maji problem se prosadit.
Jak to vypada, se SVG budou jeste problemy, viz dneska zverejnenou zpravicku o ukonceni podpory ze strany Adobe na jejich prohlizec. Je to skoda, protoze SVG je - alespon pro me - dukaz toho, ze formaty zalozene na XML maji smysl a take propojeni SVG+JavaScript dava velke moznosti.
na druhou stranu opera svg jiz tak nejak podporuje, do mozilly se pry taky neco chysta... tak ted jeste ie a bude to v pohode... kazdopadne nejlepsi implementaci, kterou jsem zatim potkal byl batik a s tim uz jdou delat kouzla.
na druhou stranu je s podivem jak malo programu tento format byt pro export podporuje (a to je to trivilita treba oproti eps)
mozilla neco podporuje uz ted:
co jsem zkousel ruzne vystupy z illustratoru tak zakldni tvary fungujou bez prblemu
problem je s grdientama a s pruhlednosti dvou elementu.
Opera mam dojem podporuje neco svg-t coz by melo byt neco jednodusiho pro spis pro mobilni zarizeni.
SVG Tiny je opravdu podmnozina SVG. Nazory na tuto podmnozinu se lisi - nekdo to vidi jako tristeni formatu, nekdo jako dobrou vec, ktera pomuze k vetsimu rozsireni SVG. Protoze SVG je sam o sobe dost slozity a maloktera aplikace ho dokonale zvlada (kupodivu i Inkscape ma problemy). Podle me pro vetsinu pouziti SVG Tiny bude dostacovat.
Asi nejvetsi problem bude v te vasi vete "...tak ted jeste ie a bude to v pohode...". Jak je videt i na prikladu PNG (s alfa kanalem), tak dokud to nebude podporovat IE, tak se PNG/SVG vic nerozsiri. Nebo nastane druha moznost, ze IE bude mit pouzivanost pod 50% a snad se dockame.
Kde je? IMHO tam, kam patří: na smetišti. Nejde o to, že by se pro danou aplikaci neuchytil – znáte snad alternativní formát pro „VR na webu“, který jej nahradil? Ba i nástroje nějaké jsou (zobrazovací pluginy do prohlížečů). Ne, problém totiž je v tom, že žádná taková aplikace neexistuje, nikdo podobné věci IMHO nechce; VRML je pozůstatek hypu kolem virtuální reality. (A fakt, že si s tím hraje pár akademiků, na věci nic nemění.)
Na prikladu VRML jsme hlavne videli, jak mizernou akceleraci ma vetsina v relevantni dobe pouzivanych systemu (graficka karta+ovladace). Jo kdyby s nim nekdo prisel v dobe, kdy kazdy webovsky prohlizec bezi nad OpenGL ... jenze tam nejsme jeste ani ted.
kdyby to ta sracka od microsoftu (IE7) podporovala, hned to pouziju na webu vyresilo by to velice elegantne orezany obrazky na libovolnym barevnym pozadi(coz v gifu kvuli jednomu bitu pruhlednosti nevypada prilis dobre) IE7 zatim jenom misto pruhledneho pozadi ukaze bilou plochu, coz na strance ktera neni bila vypada katastrofalne, samozrejme nikdo jinej nez kokoti z microsoftu s tim problem nema ( Mozilla, Opera funguje )
Toto jsem přesně řešil včera a počet nepublikovatelných výrazů na adresu Redmondu začal přetékat 32bit integer. Mrkněte sem, je to funkční na starších IE (sedmičku jsem zatím řešit nemusel): http://koivi.com/ie-png-transparency/
Díky za odkaz...
Tahle nehorázná ignorace od MS mě může vždycky rozpálit do běla. :(
Většinou se snažím průhlednosti vyhnout nebo to řeším tak, aby to nebylo do očí bijící. MS je neuvěřitelnej ignorant.
Myslím, že pokud je PNG indexed 256 barev, tak průhlednost MSIE zobrazí, ale jak to pak vypadá... fuj...
Přitom mimo MSIE interně to Wokenice umí.
Mrknete se jeste na http://entropymine.com/jason/testbed/pngtrans/
Vypada to, ze Gecko & spol. pruhlednost zvladaji, Opera (<10) ma trosku problemy a o MSIE radeji nemluvim (jako zakaznik bych si takovy nedodelek nekoupil, zhazuje to kvalitu celeho SW balicku).
teda nedavejte sem please linky na takovyhle veci - nedalo mi to a nasel jsem comp s woknousama a sel jsem se podivat na tenhle link. Malem jsem se z toho poblil. To je naprosto nechutne, jak nejaka divna firma odnekud z Redmontu ktera je nejlepsi na celem svete co se tyce operacnich systemu a software obecne (sami to tvrdi, tak to asi bude pravda), jak to dokazou ZPRASIT. Opera 6.11 for Linux (Bill by k tomu poznamenal neco o dinosaurech) to zobrazi naprosto korektne.
Kdyz uz jsme u toho Billa, zajimava je ta jeho reklama s dinosaurama. On se vlastne vysmiva vlastnim klientum, kteri pred par letama koupili to nejlepsi z nejlepsiho, ze jsou dinosauri, ze pouzivaji takovej desnej s.h.i.t. Nezbyva nez s nim souhlasit :-)
V MSIE se to musi resit pres ten jejich proprietarni filtr. Je to strasnej humus, ale treba pri praci s JSP se da vytvorit vlastni tag pro obrazek, ktery uz muze pro ten zastaraly prohlizec vytvorit humusoidni HTML kod s filtrem misto normalniho img src.
A nebo (pokud mas tu moznost, ja treba v jednom projektu ne) se na to taky muzes uplne vykaslat a delat vsechno podle standardu - uzivatele uz celkem radi prechazi z MSIE jinam, vetsinou jim staci ukazat taby a stahovani obsahu na pozadi :-)
Teda PR genialita MS je takrka dokonala - viz ta veta na Vami zminovane strance o featurkach MSIE 7:
"Podporuje průhlednost formátu obrázků PNG. Díky tomu weby vypadají lépe a lze je snáze vytvářet."
Takze IE7 je vlastne ten prohlizec, ktery nam umozni snaze vytvaret lepe vypadajici weby. O, jaky je MS dobrodinec, ze nam z Redmontu seslal tuto featurku :-) Rekneme to jinak: weby by lepe vypadaly a snaze se vytvarely v pripade, kdyby PNG byl plne podporovan uz od IE4 (jak se ostatne MS chlubil).
Pokud se jedna o obdelnikovej element da se pozit pro Ms IE filter opacity...
vim ze to tvuj pripad asi nebude ale kdyby byl tak by ti to mohlo pomoci :-)
No jestli MS ignoruje PNG, tak proste ignorujte MS IE, nevidim v tom zadny problem.
Uzivatel MSIE uvidi stranku v trosku osklivejsi podobe, ale myslim ze to prezije. (kdyz dokaze prezit vsechny ty dalsi problemy...)
To ze IE nezobrazuje spravne png ale neni proto, ze by se Microsoftu nechtelo investovat do vyvoje, ale proto, ze by byli radi, kdyby nic jako PNG nevznikalo... Podobne by Apple byli radi, kdyby nevznikalo nic jako je ogg/vorbis (jo, mluvim o iPodu), dalsich prikladu by mohlo byt mraky...
Je to neco, z ceho je cloveku na zvraceni... proc se velke firmy nedokazou smirit s tim, ze se nekde objevi neco, co prispiva stejnou merou vsem lidem a podobne aktivity se zamerne snazi znicit? Vzdycky premyslim, jak se asi na sebe samotneho diva clovek, ktery vecer prijde domu a rekne si: "dneska jsem udelal manazerske rozhodnti, ktere by mohlo znicit vec, ktera nikomu neskodila a vsem lidem na svete prospivala bez rozdilu stejnou merou."
Poskozovani svobodnych formatu a prosazovani proprietarnich je klasickym prikladem zamerneho budovani monopolniho trzniho prostredi, neco co je dle zakone trestne, bohuzel umysl je tezko prokazatelny. :P
Protože světu vládne kapitalismus, který vše měří penězi. Bohužel zatím nikdo nevymyslel nic lepšího. Firmy nedělají produkty proto, aby postrčili svět dál nebo aby někomu něco usnadnily, ulehčily, zpříjemnily. Toto vše je jen vedlejší efekt. Firmy dělají produkty proto, aby na nich vydělaly. A někomu něco zpříjemnit, usnadnit, ulehčit - to je jen prostředek, jak vydělat, ne cíl.
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
Sorry ze trocha predbieham do dalsej casti, ale filtre ma dost zaujali. Nakoniec som ich vygooglil, ale zatial neviem jak ich kombinuje (a testuje) pngcrush.
Tiez sa mi zda trocha zvlastne, ze sa pouzivaju len riadkove filtre, ale to bude asi tym, ze sa komprimuje po riadkoch. Mne by tam asi najlepsie sedel Laplacov operator (na analyzu obrazku), ten "ukaze" kompaktne oblasti, tj. oblasti s nizsimi frekvenciami, na ktore by snad dobre siel pouzit Sub/Avg. To by vyhovovalo snad vacsine "beznych" obrazkov (takych, co nie su bielym sumom).
Druha moznost co ma napadla: kompresia je hlavne kvoli pouzitiu na webe, mozno by bol dobry napad ziskat reprezentativnu vzorku cca milion nahodnych png-ciek (aby tam boli jak fotky, tak nejake schematicke nakresy a kombinacie). Z toho by sa vytvorilo zopar statistickymi metodami niekolko (napr. 5-20) "najbeznejsich profilov", ktore by boli charakterizovane napr. tvarom histogramu, druhmi frekvencii, atd. Clovek by si pri ukladani mohol vybrat kompresny profil "fotka", "skor fotka", ..., "schematicka grafika", pretoze toto myslim clovek vidi lepsie ako nejaky algoritmus (pripadne by to ten kompresny algoritmus brute-forcol vyskusanim vsetkych najbeznejsich profilov, ze ktory z nich vyjde najlepsie co do velkosti). Mozno uz taky program existuje, neviem.
Ano, v PNGcku jsou pouze radkove filtry, nektere vsak "sahaji" i o jeden radek vyse (niz nemuzou, ten neni pri dekomprimaci jeste rozbaleny). Filtr s nejvetsi informaci o svem okoli vypada tak, ze precte barvu pixelu vlevo, nahore a vlevo nahore. To uz se docela dost blizi (v mezich moznosti) k Laplaceove operatoru.
V tom clanku jsem se vyjadril obecne - pngcrush, alespon pokud vim, nezkousi uplne vsechny moznosti, protoze na kazdy obrazek vyzkousi maximalne 124 moznosti. Pokud by mel vyzkouset vsechny moznosti, jeste by se to cislo vynasobilo poctem radku. Ted me napadlo, ze bych to vlastne mohl na nejakem mensim PNGcku vyzkouset, staci si pohrat s pnglib.
Neco podobneho s temi profily maji komprimacni metody definovane CCITT (pro faxy a treba i pro TIFF). Je to urceno pouze pro cernobile obrazky (B&W) a metody pracuji tak, ze konsorcium CCITT ziskalo vzorky mnoha formularu, dopisu, perovek apod. - proste vseho, co se posila faxem - a z techto vzorku vlastne vytvorilo pevne dane kody pro Huffmannovo kodovani. Teda dost jsem to zjednodusil, protoze se aplikuji i dalsi metody, ale ten zaklad v profilech tam je - ziskani vzorku bitu z realneho sveta. A kupodivu to funguje, B&W obrazky jsou vetsinou zkomprimovany pomoci CCITT lepe, nez pomoci LZW ci deflate.
CCITT komprese faxu je fakt skvela vec. Nic nezkompresuje obycejnou nascannovanou stranku s textem v 200DPI lip nez g3fax. Ale beda, kdyz je ta stranka moc cerna.
Jeden dotaz - co je to "PEROVKA"?
google nasel mimo jine
Maps, Weather, and Airports for Perovka, Russia
a
Deníček. Domácí stránka uživatele perovka. Žena, 32 let, Praha
ale nic z toho asi nebude ta vase perovka :-)
Nevim, jestli je to jeste dnes oficialni termin, ale perovkami se oznacuji treba ruzna cernobila schematka a nakresy ve skriptech. Treba tomu rikejme "carova grafika" - hledejte line art, line-art, lineart, cartoon apod.
Jeste pridam kus manualu k jednomu grafickemu programu:
---------
Tato funkce převádí obrázek na pérovku.
Pérovky jsou monochromní obrázky "kreslené" jen "barvami" černou a bílou. Bližší vysvětlené naleznete v kapitole "Základy, Rastrové a vektorové grafiky".
Pérovky pocházejí například z různých kreslicích programů. Převod do pérovka může mít smyl pro vytvoření masek.
Při převodu z barevných nebo šedotónových obrázků se ztrácí informace o barvách a stupních šedi, na zařízeních s nízkým rozlišením proto ušetříte paměť a obraz se vypočítává rychleji. Převod však má smysl jen tehdy, když víte, že se obrázek nebude muset později převést pro jiné výstupní zařízení.
Převod barevných nebo šedotónových obrázků na pérovku uděláte vybráním obrázku a kliknutím na ikonu. Po bezpečnostním dotazu, kdy můžete zadat budoucí rozlišení obrázku a zvolit druh převodu, se konverze provede.
---------
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
Hned som o nieco mudrejsi :-)
K CCITT metodam: jednak dost pomaha ta statistika, ale druhak IMHO to, ze je to B&W obrazok. Ak sa spravne pamatam, tak ludske oko vnima hlavne jas a preto ma vacsina "zmysluplnych" obrazkov silnu korelaciu medzi R,G,B zlozkami. V RGB priestore bude asi kompresia kazdej zlozky horsia nez v YCbCr. Teda by snad bolo lepsie previest obrazok z RGB do YCbCr a analyzovat ho tam (resp. robit statistiku v tomto farebnom priestore). Pokial som googlil spravne, tak PNG nepodporuje YCbCr a po prevode RGB->YCbCr treba nejaky FX format aby sme nestratili presnost alebo povolit stratovu kompresiu.
Prevod z RGB do YCbCr se dela napriklad v JPEGu, ale CCITT bylo puvodne vytvoreno pro opravdove B&W obrazky, tj. mezi tim B a W uz nic neni :-) Zadne stupne sedi, pouze cerna a bila, 1 bit na pixel. I na techto obrazcich je CCITT vetsinou lepsi nez jine komprimacni metody, ale to je logicke, protoze jak deflate (PNG), tak i LZW (GIF) jsou vlastne strasne hloupe a "nevi", ze komprimuji obrazova - tj. prostorove usporadana - data. Trosku se da pomoci temi radkovymi filtry v PNG, ale stale to neni ono, ta dalsi "znalost", kterou ma CCITT tam proste chybi.
zkuste si do PNG ulozit bitmapu s barevnym prechodem.
kdyz je vodorovnej/svislej tak je PNG tak maly,
ze na bajty srovnatelne JPG vypada tak:
komprese pod 4% = zbyly asi 4 pruhy, okraje zmrveny tou kompresi,
kdezto PNG stale 100% bezestratove.
jasne, cely dni nedelam nic jinyho, nez plynuly barevny prechody :-)
ale zadnej jinej format to tak pekne nezvladne
( trochu gif, kdyz je to horizontalne )
Musim zatleskat, jak první díl, tak ten aktuální, je čtení, který mi na "technoidních webech" chybí - ideálně skloubená čtivost, která neubírá na odbornosti článku, informační overload bez zabíhání do zbytečných detailů, jen houšť ! ;)