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.

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.

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.

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ó.

Ez tényleg egy program-gyilkos kép ezzel a lehetetlen háttérszínnel. Én világoskékkel futottam bele hasonlóba: volt olyan árnyalatú ég, amit sehogy se tudott megtalálni, csak pöttyözgetett össze-vissza.

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 konvertált képet a mellékelt BASIC programmal próbáltam betölteni...
"Ez az üzemmód nem támogatott." hibát kapom.
Mit csinálok rosszul?

Találtam hibát. A karakterek visszatöltésénél, ha kevesebb karakter volt mentve, mint amennyi a képernyőn volt, a maradékot nem törölte, ill. a karakterek számát se frissítette. Ez lett javítva.

(István hozzászólása az EPI-IVIEW konverterrel hová tűnt?)

Ezek szerint nem hallucináltam, hogy volt itt egy ilyen