Welcome, Guest. Please login or register.


Author Topic: EP128pal képkonvertáló (Read 2338 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4377
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 57.0 Firefox 57.0
    • View Profile
Re: EP128pal képkonvertáló
« Reply #75 on: 2018.February.08. 13:20:58 »
1) Nem nagyon használok emu -t.
2) Akkor ez NEM különálló program, mint a lentebbi (tehát jól mondtam, hogy az az egyetlen "ilyen"). :-)

Egy csomagban tölthető le az emulátorral innen, de egyébként a konvertáláshoz nincs szükség az emulátorra, és természetesen a képek megjelenítéséhez sem.

Érdekes, azt vettem észre, (lehet, hogy én vagyok a balta a beállításokkal, bár mindent kipróbáltam látszólag) hogy ha egy egyszínű (!) háttér előtt vannak betűk és egy ábra / kép, akkor az egyszínű (!) (pl. fekete) hátteret valamiért nem képes visszaadni a konvertáláskor. Holott ott semmit nem kellene variálnia, csak feketén hagyni ami amúgy is fekete. :-) (Tele lesz ilyen "zizivel", tehát "odaszemetel" a program, ahol nem is kellene semmit változtasson.)

Valószínűleg nem teljesen fekete az eredeti háttér, és a program dither használatával próbálja közelíteni a színt.

Két módszert próbáltam ki: először számszerűen a legtöbbször előforduló színeket használta a program, de az sokszor nem volt jó, mert ha egy kis részlet más színű, akkor az kimarad. Ezután próbáltam, hogy az árnyalatban legtávolabbi színeket használja, és az egymáshoz közeli árnyalatok egyikét eldobja. Ezzel gyakran jobb eredményt lehet elérni, de a legjobb valahol a kettő között volt, ezért van a csúszka.

Ez ugyan nem feltétlenül jó megoldás, de az epimgconv a szín eltérés négyzetének az összegét próbálja minimalizálni. Azaz például ha egy pixel színe R0,G0,B0 volt eredetileg és R1,G1,B1 lenne konvertálva, akkor a "hiba" ennél a pixelnél (R1-R0)^2+(G1-G0)^2+(B1-B0)^2. A cél az, hogy a teljes képen ennek az összege, azaz a "zaj" a legkisebb legyen. A program valójában nem RGB színtérben dolgozik, de a működés elve szempontjából ez nem lényeges. A keresésre használt algoritmus nem tökéletes, gyakorlatilag véletlenszerű színekkel tölti fel a palettát, majd ciklusban addig próbálja a színeket egyenként optimalizálni, amíg tovább már nem javítható egyik sem. A konvertálás minőségének (-quality) az emelése növeli a kezdeti véletlenszerű állapotok számát. A sebességet különböző trükkökkel próbáltam javítani, az értelmetlen vagy ismétlődő szín keresés elkerülésével, így azonban nem túl olvasható a kód. :)

A fent leírt elv jó lenne dither nélkül, azonban nem veszi figyelembe, hogy dither használatakor előnyösebb lehet egymástól távolabbi színeket választani. Erre a problémára ez a program jó megoldást talált, ez a zajt "gaussian blur" effektus után minimalizálja, ami egyszerre valósítja meg a dithert és az ahhoz optimális palettát. Az epimgconv-ban azonban csak hagyományosabb dithert tudtam megvalósítani, és néhány trükköt a paletta javítására. Ezek közül az egyik azt használja ki, hogy a Floyd-Steinberg és hasonló dither algoritmusok az aktuális sorról tovább viszik a "hibát" a következőre, paletta és attribútum keresésnél pedig már az így módosított színeket célozza a program. Így jól kihasználható a soronként változó paletta és attribútumok, hátránya azonban a konvertált képeken látható jellegzetes csíkozás. Egy másik trükk részben az scolorq megoldására hasonlít, bár kezdetlegesebb. A szín hiba összeg számításakor nem csak a teljes felbontású képet veszi figyelembe, hanem kisebb felbontásokat és "kevert" színeket is. Azaz a paletta és attribútum keresésnél például egy 8x1-es attribútum cellát 4x1-re és 2x1-re is konvertálja (a szomszédos pixelek egyszerű átlagának a számításával), és ezeknél a papír és tinta szín közötti átmenetek is lehetségesek (4x1-nél 50%, 2x1-nél 25% és 75% is). A teljes hiba pedig az összes tesztelt felbontásnál számított érték súlyozott összege. Ez elvileg az egymástól távolabbi és jobban ditherelhető színek felé tolja el az eredményt, bár a gyakorlatban nem igazán jól működik.

Online szipucsu

  • EP addict
  • *
  • Posts: 6782
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: EP128pal képkonvertáló
« Reply #76 on: 2018.February.08. 23:08:52 »
az egyszínű (!) (pl. fekete) hátteret valamiért nem képes visszaadni a konvertáláskor. Holott ott semmit nem kellene variálnia, csak feketén hagyni ami amúgy is fekete.
Az nem soronként változó paletta volt? Ott minden sorban meghatározza a színeket, és ha mondjuk feketéhez kicsit hasonló színből van még, és nincs elég szín a feketének, belövi a feketére is azt, ami hasonlít hozzá.

Offline Tomato77

  • User
  • *
  • Posts: 96
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 64.0.3282.140 Chrome 64.0.3282.140
    • View Profile
Re: EP128pal képkonvertáló
« Reply #77 on: 2018.February.08. 23:30:16 »
Valószínűleg tényleg az lehet, hogy nem teljesen fekete az a háttér, hanem valahol két EP szín között van, erre nem gondoltam.

Köszi a magyarázatot, István! Érthető és eléggé részletes is. :)

A pixelek színeltérését az EP128pal háromféle módon számolja, ezeket ki lehet kiválasztani. Az általad leírt képletekhez hasonlóan ezek vannak:
- egyszerű: Abs(R1-R0)+Abs(G1-G0)+Abs(B1-B0)
- súlyozott: Abs(R1-R0)*3+Abs(G1-G0)*4+Abs(B1-B0)*2
- exponenciális: (R1-R0)^2+(G1-G0)^2+(B1-B0)^2 <- ez ugyanaz, amit te is használsz

Érzetre valahogy a súlyozott lett a legjobb. Abból indultam ki, hogy a zöld a legfényesebb szín, aztán a piros, a kék pedig a legsötétebb. Ezért ha pl. a zöld eltér, azt jobban észrevenni, ezért azt súlyozza és számításkor nagyobb hibának veszi. Ha a kék tér el ugyanannyi árnyalatot, azt kevésbé lehet érezni.

Az EP128pal előbb az összes palettát megcsinálja minden sorra (vagy blokkra) egyszerre, csak utána készíti el a képet. A tiéd jobb megoldás, mert a következő sorhoz már a dithering után korrigált pixelekhez válogatja ki a színeket. Mondjuk ez csak soronkénti palettához lehet hatékony, ha nagyobb méretű blokkok vannak (pl. szabvány EXOS videolapok) egy palettához, akkor már nem. Az én programom az elején nem támogatta a soronkénti palettát, azért lett ilyen a feldolgozás sorrendje, aztán később eszembe se jutott.

Azt néztem, hogy attribútum módban mindkét attribútumnál végigpörgeted a 16 színt, aztán a legkisebb hibát adó színeket választod ki. Kipróbáltam, de nem értettem, mihez képest számítja a hibát. :) Ha pixelenként néztem a 8 pixeles cellában, akkor olyan színeket választott ki, ami a legközelebb esik az eredeti színhez, ezért a dithering hatása nagyon lecsökkent, szinte mintha ki lett volna kapcsolva. Ha pedig a 8 pixelt együtt számoltam, akkor változatosabb színeket talált, de sokszor két teljesen oda nem illő szín különbsége adta a legkisebb hibát, így meglehetősen fura képeket konvertált. Végül hagytam a csudába és az lett a módszer, hogy a 8 pixelből két nagyon eltérő színt választott ki, a dithering rutin pedig majd megoldja. Ha az egyik szín sokszor szerepel, akkor azt mindenképp kiválasztja, a második színnél pedig annyit figyelt, hogy lehetőleg 1 pixelnél több helyen is előforduljon. Úgyhogy lenne még hová fejlődni, lehetne csiszolni rajta, de max. annyit érnék el vele, hogy talán megközelítené az epimgconv minőségét, de az már létezik és jó is, akkor meg minek. :)
Kotasoft     Kotasoft

Offline Tomato77

  • User
  • *
  • Posts: 96
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 64.0.3282.140 Chrome 64.0.3282.140
    • View Profile
Re: EP128pal képkonvertáló
« Reply #78 on: 2018.February.08. 23:36:41 »
Ha nagyon nem jönne össze az a fekete háttérszín, ott van az a checkbox, amit bekarikáztam. Azzal rá lehet venni a programot, hogy méltóztasson igazi feketét használni.
Kotasoft     Kotasoft

Offline IstvanV

  • EP addict
  • *
  • Posts: 4377
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 57.0 Firefox 57.0
    • View Profile
Re: EP128pal képkonvertáló
« Reply #79 on: 2018.February.08. 23:49:56 »
A pixelek színeltérését az EP128pal háromféle módon számolja, ezeket ki lehet kiválasztani. Az általad leírt képletekhez hasonlóan ezek vannak:
- egyszerű: Abs(R1-R0)+Abs(G1-G0)+Abs(B1-B0)
- súlyozott: Abs(R1-R0)*3+Abs(G1-G0)*4+Abs(B1-B0)*2
- exponenciális: (R1-R0)^2+(G1-G0)^2+(B1-B0)^2 <- ez ugyanaz, amit te is használsz

Érzetre valahogy a súlyozott lett a legjobb. Abból indultam ki, hogy a zöld a legfényesebb szín, aztán a piros, a kék pedig a legsötétebb. Ezért ha pl. a zöld eltér, azt jobban észrevenni, ezért azt súlyozza és számításkor nagyobb hibának veszi. Ha a kék tér el ugyanannyi árnyalatot, azt kevésbé lehet érezni.

Az epimgconv valójában YUV színtérben számolja a hibát, ami már "súlyozott", bár azért is használtam, mert eredetileg Plus/4-re konvertált a program. Ezért is állítható egy paraméterrel a szín (U, V) összetevők relatív súlya a világossághoz (Y = 0.299*R + 0.587*G + 0.114*B) képest.

Quote
Azt néztem, hogy attribútum módban mindkét attribútumnál végigpörgeted a 16 színt, aztán a legkisebb hibát adó színeket választod ki. Kipróbáltam, de nem értettem, mihez képest számítja a hibát. :) Ha pixelenként néztem a 8 pixeles cellában, akkor olyan színeket választott ki, ami a legközelebb esik az eredeti színhez, ezért a dithering hatása nagyon lecsökkent, szinte mintha ki lett volna kapcsolva.

Itt lehet jelentősége az előző hozzászólásom végén leírt megoldásnak, ami a dither lehetőségét is próbálja figyelembe venni a színek keresésénél, ez az attr16.cpp-ben például a 160. sornál található.

Offline Ep128

  • EP addict
  • *
  • Posts: 1508
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
    • Honlapom
Re: EP128pal képkonvertáló
« Reply #80 on: 2018.February.08. 23:54:23 »
Köszönöm, hogy így rámozdultatok és ráadásul nektek volt igazatok! Tényleg nem 100% -ban fekete a fekete, csak az álmos fejemnek tűnt annak. De ideteszem az "eredményt" és az eredeti képet is:

Offline Tomato77

  • User
  • *
  • Posts: 96
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 64.0.3282.140 Chrome 64.0.3282.140
    • View Profile
Re: EP128pal képkonvertáló
« Reply #81 on: 2018.February.09. 00:25:48 »
Ez tényleg egy program-gyilkos kép ezzel a lehetetlen háttérszínnel. :D Én világoskékkel futottam bele hasonlóba: volt olyan árnyalatú ég, amit sehogy se tudott megtalálni, csak pöttyözgetett össze-vissza.
Kotasoft     Kotasoft

Offline IstvanV

  • EP addict
  • *
  • Posts: 4377
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 57.0 Firefox 57.0
    • View Profile
Re: EP128pal képkonvertáló
« Reply #82 on: 2018.February.09. 16:25:22 »
Minden 8 sorhoz saját karakterkészlet az már szinte bitmap. :) Azzal az összes 8*8-as terület lefedhetô, ha mondjuk 46 karakter széles a kép. Akkor inkább mindegyik ilyen területet egy-egy konvertálandó mini képnek kellene tekinteni, és kiválogatni hozzá azt a 2 vagy 4 színt, ami leginkább jellemzi. Mint attribútum módban. :)

Karakteres mód használatának elsősorban video konvertálásnál lenne értelme. Itt a legfontosabb, hogy kis méretű legyen a konvertált adat, még azon az áron is, ha a kép rossz minőségű lesz és nem színes. Egy "Spectrum méretű" kép 64 8 magasságú karakterrel például csak 1280 byte tömörítetlenül, LPIXEL módban viszont 6144 byte lenne.

- a videomódok miatt megváltozott az .EPI kép formátuma (a videomódot a blokkokba menti, a vízszintes méretet nem tárolja, stb.)

Talán hasznos lehetne IVIEW formátumban is menteni, itt elvileg bármi változhat tetszőleges számú soronként, bár az EP-s képnéző programokat eddig csak az epimgconv által is támogatott módokkal teszteltük. Az emulátor csomagja tartalmaz egy iview2png programot is, amivel az ilyen képek PNG formátumra konvertálhatók.

Online endi

  • EP addict
  • *
  • Posts: 6245
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 63.0.3239.132 Chrome 63.0.3239.132
    • View Profile
    • Honlapom
Re: EP128pal képkonvertáló
« Reply #83 on: 2018.February.09. 16:40:28 »
gondolkodtam azon hogy a gracha módot lehetne használni videóhoz. a jpg és más hasolnó tömörítések kis kockákból építkeznek, amelyekben néhány paraméteres "átmenet" van (nagyon erősen leegyszerűsítve), szóval létre kell hozni ilyen gracha karaktereket és videóhoz jó lehet...

ez itt egy nagyon alacsony minőségre állított jpg részlete:

A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D