Nechtel bych kompresi, ja si fakt pred ctenim toho clanku myslel ze popise jak dumpnout bitmapu v pameti do jednoduchyho PNG (bez komprese, bez progrese, bez prokladani, bez alternativnich streamu) ciste v C, to by se imho hodilo trochu vic, protoze pak by mel clovek svobodu volby, pouziti libpng je trosku omezujici ;)
Hmm.. keep it small and simple? Ked chces dumpnut raw data, tak ich dumpni ako raw data, pripadne prihod 54bajtovu hlavicku a dumpni ich ako bmp. V oboch pripadoch existuju externe programy (za vsetky convert z ImageMagick-u), ktore ti z toho spravia kludne aj komprimovane png... ak to silou mocou nepotrebujes, je kompresia do png v tvojom programe zbytocna..
Ad pruhlednost: to jsem resil prave ruznymy stupni sedi. Po vytisknuti na folii a par experimentech s nastavenim tiskarny jsem dostal pozadovany vysledek.
Ad libpng a ostatni knihovny versus C: jiste ze je moznost tlacit png primo z C bez jakychkoli knihoven, ale to je dost jina liga kterou nevladnu a lidi pro ktere tento clanek zaujme jako HOWTO asi taky ne.
Asi jsem netrefil nazev clanku, opravdu byl mysleny jako HOWTO libpng - jak vytvorit obrazek.
Pruhlednost je u PNG resena 32bitovou barevnou hloubkou. kanaly jsou RGBA (A jako alpha transparency) po 8 bitech. pruhlednost je tedy definovana 256 urovnemi - 0 zcela pruhledna, 255 zcela nepruhledna. Nemam zkusenosti s libpng, ale GD umi s pruhlednosti pracovat pomerne slusne.
Krome zminenych knihoven muzete mrknout na GDAL (www.remotesensing.org)
Japhy
Protoze nejak ten obrazek nakreslit musis, potrebujes funkce na cary, polygony apod. OpenGL je knihovna prave pro toto a zadna lepsi se zatim neobjevila. Neni to zadny "moloch" ale velmi dobre navrzena knihovna, podporovana v hw a navic multiplatformni. Ostatni podobne knihovny (Gdk, Qt, GD, Win GDI, DirectX, apod.) jsou jenom znovu vynalezenym kolem, neuplne kulatym ;-)
Jenže já ten program chci spouštět i na počítači, který třeba vůbec nemá grafickou kartu (takže to bude báječně akcelerovat), o X ani nemluvě. Když v programu chci jako výstup jednoduchou bitmapovou grafiku, tak to nebývá nic s GUI, ale něco, co spustíš ze skriptu nebo Makefile a něco to vyplivne ... Takže závislost na X je chyba.
K tomuhle dodam jenom to, ze to je ponekud podivny nazor... jednak srovnavat OpenGL s napr. Windows GDI je IMHO dost mimo, druhak bylo GDI driv nez OGL, tretak OpenGL neni zadne "prvni vynalezene kolo", uz proto, ze to je proste dalsi knihovna vyvinuta na zaklade zkusenosti s predchozimi resenimi, takze podle toho by to bylo taky "znovu vynalezene kolo"...
Ja by som pri rieseni popisaneho problemu postupoval tym sposobom, ze by som vytvoril obrazok vo formate .pnm, co je ascii texttovy subor, ma jednoduchu hlavicku (komentar, typ obrazku (grayscale vs. rgb) a rozmery obrazku) a udaje idu bud ako jednotlive cisla 0-255 pre grayscale alebo ako trojice cisel 0-255 pre rgb. Na prevod do png by som pouzil program pnmtopng. Vyhoda mojho postupu je v tom, ze porozumenie formatu pnm trva pri pohlade na jeden subor vo formate grayscale a jeden vo formate rgb menej ako jednu minutu... Nevyhodou je va:zba na nastroj pnmtopng, ale export zvladne vzhladom na jednoduchost formatu pnm snad kazdy graficky editor, ktory vie do png ukladat.
predbehol si ma :)
linux intenzivne vyuzivam 4 mesiace. v ramci doktoratu mam okrem inaho za ulohu vyprodukovat obrazy elektronovej hustoty na povrchu krystalov. ked bola vyriesena vedecka cast, zacal som hutat, ako teda dostat data do grafickej podoby.
hladanie na inete zabralo asi 20 minut, kym som nasiel zdrojak, ktory ascii bitmapy zapisoval. po najdeni prislusneho miesta v zdrojaku trvalo naozaj velmi kratko, kym som pochopil, co sa odo mna ocakava. pre tych, co chcu vyskusat, takto by mala vyzerat struktura suboru:
mn
# moze byt komentar
ncol nrow
maxclr
cislo cislo cislo.....
kde
mn - magic number, konkretne P1 pre b&w, P2 pre greyscale alebo P3 pre rgb.
ncol - pocet stplcov
nrow - pocet riadkov
maxclr - maximalna pouzita farba (1 az 255)
potom sa uz iba zapise matica cisel <= maxclr (pripadne trojic cisel pre rgb).
ascii bitmapy vie citat gimp, imagemagic aj xfig.
pekny den prajem
gdk_pixbuf_save(pixbuf, "foo.png", "png", &err, NULL);
pokud už člověk používá Gtk+/Gdk a spol.
Jinak nic proti libpng, také ji použivám i ručně, ale pokud potřebuji hlavně ukládat obrázky, a nikoli ukládat je v nějakém konkrétním formátu (nebo šetřit místem na disku), ppm je patrně nejvhodnější -- zápis i čtení jsou triviality, bez zdržujících kompresí, dodatečných knihoven a dokonce ho občas lze i mmapnout a kreslit přímo do něj...
No nevim, ja jsem se uz davno rozhodl, ze kdyz uz pracovat s obrazky, tak se neomezovat na jediny format, a naucil jsem se pracovat s knihovnou ImageMagick ... mimochodem ne ze by byla prilis kvalitne dokumentovana a navic ji mezi verzemi uplne prekopali, ale treba uz to bylo naposledy.
Pokud vim je jedina co umi alphu.
super, akorat me mrzi ze to tu nebylo tak pred pul rokem - to sem to potreboval ja a stravil sem nekolik hodin hledanim jak to udelat.. no a protoze to sice fungovalo, ale ne moc dobre (ja potreboval png i cist), nakonec sem pouzil
system("convert file1.png file2.ppm");
:(
a zpatky
jinak ale doufam ze takovejch clanku bude vic!
no a i kdyz mozna existujou jiny knihovny atd, libpng je dost standardni a dostatecne mala aby si ji mohli stahnout i modemisti.
Dost mi taky vadej "zadosti" o "jednoduchej" zapis do png z c-programu... pride mi to dost proti filozofii unixu a teda i linuxu, proc nepouzit png kdyz tu je a vymejslet znova kolo (a este nejaky divne hranaty, bez komprese, apod)
To o ty filozofii je docela sranda ;) Proc teda mame ruzny distribuce, kdyz mezi nima neni vice mene zadnej rozdil? To me prijde jako vymejsleni jednoho a toho samyho porad dokola, kazdej si akorat prida par nestandardnich veci aby pak mohl prodavat podporu. Nemluve o tom ze samotnej Linux je pouze a jen vymejsleni uz existujicich veci dokola...
Co se tyce pouzivani system() - treba web aplikace by nemely vubec mit praco cokoli pustit, zvlast pokud budes predavat retezec co obsahuje i parametry, to je az moc jednoduchy to nabourat...