PNG-k konvertálása Amigás ILBM és ACBM formátumba

A minap kiadtam a PNG->ILBM konverteremből egy újabb release-t, ami - nomen est omen - PNG formátumú képeket tud átalakítani az amigás ILBM formátumba, illetve mostantól már ACBM-be is. (Ez utóbbi egyébként ugyanazt az IFF konténerformátumot használja, mint az ILBM, a különbség az, hogy amíg az ILBM-ben a síkok soronként össze vannak fésülve, addig az ACBM-ben pontosan ugyanúgy egymás után helyezkednek el, ahogy az Amiga memóriájában is.)
A másik fő újdonság az a HAM képek támogatása, amiről pár hónapja már írtam. Most akkor erről is írok pár szavat.

(Nem látszanak a képek? Klikk ide.)

A cucc támogatja a 12 és a 24-bites ILBM/ACBM képeket is, 1-8 bitplane-ig, valamint az EHB-t (a múltkor már írtam róla: 6-bites 2x32 színű kép, ahol a legfelső bit lefelezi a fényerőt) és ahogy az elején írtam, a HAM-ot is, de csak a 6 és 8-bites verziókat, az 5 és 7-biteseket nem. (A múltkor szintén volt róluk szó, valószínűleg bonyolultabb lett volna tiltani a hardware-ben őket, mint a generikus lekezelés mentén hagyni őket létezni, viszont csak a kék színösszetevőt tudják változtatni, így nem túl sok mindenre használhatóak...)

Miután letöltöttük a nekünk tetsző platformra (a Mac-jeimet most nem igazán tudom használni, így a két PPC-s platformra még mindig csak a régi 1.0.1-es verzió érhető el, OSX-re meg egyelőre semmi (ellentétben a YTFE-vel, ezt le tudnám forgatni Snow Leopardon is)), csak simán elindítva kiköpi a konzolra a manualját, amin most nem mennék végig, csak pár példát mutatnék. (A kapott ILBM képeket visszakonvertálom PNG-be, hogy meg lehessen nézni őket.)

Itt van egy 1280x800-as kép, viszonylag színes, jól elütő részekkel, stb.:

Ha pl. ebből egy 32 színű, 480 pixel széles képet szeretnénk csinálni, azt a következő módon tehetjük meg:

png2ilbm ferrari-1280.png -w=480 -bp=5 -d ferrari-480w-5b.iff

A -w kapcsolóra gondolom mindenki rájött, hogy a szélességet jelenti; van "magassági" párja is, de ha csak az egyiket adja meg az ember, akkor méretarányosan számolja a másikat. A -bp a bitplane-ek számát adja meg, a -d pedig a ditherezést kapcsolja be. Van olyan kép, ami ditherezés nélkül igen csak gyehenna lesz, viszont van, ami meg épp azzal lesz túl zajos...
Itt az eredmény:

Ha egy 400 pixel magas EHB-s képet akarunk, az így néz ki:

png2ilbm ferrari-1280.png -h=400 -bp=ehb -d ferrari-400h-ehb.iff

Az eredmény:

Nézzünk pl. egy 960 pixel széles HAM6-os képet:

png2ilbm ferrari-1280.png -w=960 -bp=6 -ham ferrari-960w-ham6.iff

És az eredmény:

Gyönyörű csíkkavalkád lett. Kapcsoljuk be, hogy ne 24-biten dolgozzon:

png2ilbm ferrari-1280.png -w=960 -bp=6 -ham -f4b ferrari-960w-ham6-ocs.iff

Amit kaptunk:

Sokkal jobb lett. A hozzáadott -f4b kapcsoló felel azért, hogy a kvantizálást 12-bites módba kényszerítse. Az ILBM/ACBM képformátum a kezdetektől fogva 24-bites volt, de az Amigák az AGA megjelenéséig csak 12-bitet tudtak és a szoftverek csak a felső 4-bitjét használták a palettának. Egy 12-bites palettával dolgozó kép, amiben a paletta elemeinek az alsó 4 bitje 0, az egy AGA-s gépen sötétebb képet eredményezett, hiszen egy OCS gépen a 0xf az a maximum fényerő volt, viszont AGA-n a 0xf0 az 4-bitre visszavezetve közelebb áll a 0xe-hez, mint a 0xf-hez. Ezt úgy lehet kiküszöbölni, hogy 12-biten dolgozva a csatornák alsó és a felső 4-bitjeinek ugyanazt kell beírni, azaz tkp. 17-tel (0x11) kell szorozni az értéket. (Ami a gyakorlatban kiváltható így: x = (x << 4) | x;) Ha viszont az irány fordított, hogy egy 24-biten dolgozó szoftvert szeretnénk arra rávenni, hogy 12-biten dolgozzon, akkor át kell számítani a 8-bites csatornaértékeket erre a "szimmetrikus", "4-bites 8-bitesre", amit úgy lehet elérni, hogy először kiszámoljuk, hogy mennyi lenne 4-biten (osztjuk 17-tel és "kerekítünk"), aztán azt visszaszámoljuk 8-bitre (azaz felszorozzuk 17-tel, ld. előbb), így pl. egy 0xf3-as értékből először 0xe lesz, majd 0xee. A 17-tel való osztást és kerekítést így lehet felírni x = (x / 17) + (uint8_t)(x % 17 > 8);, viszont mivel Amigán az osztás baromira sokat zabál (többszáz CPU ciklus) és itt mindjárt kettő is van belőle, ezért azt ott célszerű csak shiftekkel, összeadással, kivonással és komparálásokkal felírni:

tmp = (((x << 4) - x) >> 8) + (uint8_t)(((x >> 4) == (x & 15)) && (x != 0));
x = tmp + (x - (uint8_t)(((tmp << 4) + tmp) > 8));

HAM8-cal

png2ilbm ferrari-1280.png -w=960 -bp=8 -ham ferrari-960w-ham8.iff

egyébként így nézne ki:

Van lehetőség arra is, hogy a paletta egyes színeit, vagy akár egész szakaszait lefoglaljuk előre, ha pl. a program - amiben a képet használni fogjuk - azokat a színregisztereket használja és nem akarjuk, hogy a kép azokat használja. Erre a -pr kapcsoló való, aminek vesszővel elválasztva lehet megadni a regisztereket, vagy tartományokat. Tehát, ha pl. 7-bites képernyőn dolgozunk, de a 0. szín, a 17., 18., 19. szín, 64-től 79-ig az összes szín, valamint a 127. szín foglalt, akkor azt így lehet megadni:

png2ilbm ferrari-1280.png -w=640 -bp=7 -d -pr=0,17-19,64-79,127 ferrari-pr7.iff

Az eredmény egy 107 színű kép:

Van lehetőség a regiszterek felülírására is - ha pl. már egy létező palettával dolgozunk és ahhoz akarjuk a képet igazítani - az -sr kapcsolóval, ahol szintén vesszővel elválasztva adjuk meg a regisztereket (tartományt itt értelemszerűen nem) és utána kettősponttal elválasztva a regisztertől lehet megadni a 12 vagy 24-bites értéket hexában, pl.: -sr=6:112233,8:456. Ez félig a preserve fordítottja, mert ugyan itt sem enged azokba a regiszterekbe szabadon választott színeket rakni, viszont itt a kép használhatja őket, feltéve, ha lesz olyan pixel, amit ezekre a színekre lehet cserélni.
Ennek van egyébként egy párja is, a -srl, ami arra való, hogy ugyanezt egy listából szedje ki. Pl. itt a C64 136 színű palettája.

png2ilbm ferrari-1280.png -w=640 -bp=8 -d -srl=c64-136.pal ferrari-sr8.iff

Vagy, ha azt szeretnénk, hogy az első 16 regiszter a C64 16 színét használja, a sprite-ok színei pedig le legyenek védve, akkor

png2ilbm ferrari-1280.png -w=640 -bp=5 -d -srl=c64-16.pal -pr=17-19,21-23,25-27,29-31 ferrari-sr5.iff

kapunk egy 20 színű képet, ahol 16 szín előre volt definiálva, 4 pedig szabadon választott volt. (Igen, ocsmány, de nem ez volt a lényeg.)

Hogy a cucc egyébként mire képes, azt nagyjából szemléltetik azok az amigás videók, amiknek a kockáit ezzel konvertálták, pl. itt egy 256 színű konvertált klip, itt egy HAM8-as (262144 színű) klip és valaki a Bad Apple-t is átkonvertálta 16 színű amigás animba. Mindhárom videót Amiga játssza le (mondjuk az első kettőt emulált Amiga), persze nem stock A500-asra kell gondolni.

Most így hirtelen ennyi. Ugyan fentebb már belinkeltem, de hátha átsiklott valaki felette; letölthető innen. Ha van kérdés/request/akármi, akkor komment/PM/email, ha tudok válaszolok/implementálok/whatever.