Nach dem letzten Reno-Treffen war ich noch so in Action, dass ich gleich noch bis 4:00 Uhr weitergemacht habe. Und nun hatte ich 4 Tage Urlaub, in denen ich endlich mal viel Zeit für den Atari gefunden habe. Ich habe deshalb am GraphicsTileMaster weiter gearbeitet und mit verschiedenen Optimierungen und Parametern sowie Bewertungsfunktionen Erfahrungen gesammelt. Mit der Evolutionsstrategie habe ich dann plötzlich bessere Ergebnisse bekommen, als ich erwartet hatte.
Ich arbeite eigentlich am Problem "Viele Farben", aber beim Schreiben der Tests werden nur Aspekte getestet und deshalb sind nur 4 Farben im Einsatz. Überraschenderweise gab das ganz gute Bilder schon bei 4 Farben:


OK, den Text könnte man noch besser machen, aber schon echt nett für nur 4 Farben!
(1 Rot, 1 Grün, 1 Blau und 1 sehr helles Gelb)
Also kein Interlace oder so!

Also gleich mal das olle Bild (mit dem ich CIN ausprobiert hatte, was ordentlich flackert auf PAL) herausgesucht und umgewandelt in 5 Farben nach dem aktuellen Verfahren:


Aber nun ist der Urlaub auch erstmal vorbei.
Ich werde aber weiter fleißig weitermachen, wenn die Kinder schlafen ...

Nun,

auf dem PC habe ich auch schonmal *aus Spaß* ein paar Tests bezüglich Farbreduktion vorgenommen. Also einige 16,7 Mio. JPG oder PNG Bilder in 256 Farben GIF`s umgewandelt. Je nach verwendeter Technik sah das Ergebnis mittelmäßig, mager, miserabel oder gut aus. Ich bin kein Fan von Dithering, daher sind mir so ziemlich alle Dither-Varianten (z.B. Floyd-Steinberg, etc.) zuwider. XnView und Irfan-View bieten auf dem PC ja noch viele andere Farbreduktions-Verfahren an, überrascht war und bin ich aber, dass ein so simples und altes Programm wie SlowView so gut abschneidet (vor Jahren war Slowview noch Freeware, inzwischen ist es unter diesem Namen nicht mehr erhältlich, da es von Ashampoo aufgekauft wurde und unter neuem Namen kommerziell vertrieben wird).

Neben drei Dithertypen (None, Ordered, Serpentine-Floyd-Steinberg) für 8Bit und 16 Bit, bietet Slowview im Bereich 8Bit noch drei Typen zur Palettenerstellung an, als da wären Median Cut, Popularity Sort und Neural Net Quantization. Meine Favoriteneinstellung bei der Farbreduktion im 8Bit Bereich lautet dort dann Dithertyp=None und Palettenerstellung = Neural-Net Quantization, das bringt die besten Ergebnisse. Bei vielen GIF Bildern war nachher der Unterschied zu PNG und JPG Bildern kaum noch zu sehen. Ich vermute mal, dass das (für den A8 gemachte) PC-Programm "Quantizator" ähnliche Techniken benutzt...

Vielleicht hast du ja Lust dir den Quantizator mal näher anzusehen oder forschst mal nach welche Möglichkeiten es zur Farbreduktion bei Bildern gibt und was sich davon evtl. auf den A8 übertragen oder nutzen lässt. Und bitte nicht allein auf Dithering beschränken, es gibt noch andere und teilweise bessere Methoden... zum kurzen Einstieg: http://de.wikipedia.org/wiki/Farbreduktion

Gruß, Andreas Koch.

Ein modifiziertes Median-Cut habe ich auf dem ST immer gern verwendet. Bei 16 verfügbaren Farben kann man auch schon einiges machen und bei 256 Farben ist eigentlich alles ganz gut. Bei 4 Farben oder 9 bei G2F und Quantizator sieht das schon anders aus. Außerdem gehen noch mehr Farben auf dem Atari, aber das war bisher alles auch nur in Handarbeit wirklich gut (G2F). Quantizator ist im source verfügbar (von ilmenit). Das habe ich mir schon angesehen. Mich inteessiert nicht was schon da ist und "optimal" geht. Ich bin Forscher und mache gern neue Dinge, gern auch unmögliche Die Ideen bleiben alle geheim, bis es wirklich funktioniert.
Übrigends ist auch bei GraphicsTileMaster das Dithering inzwischen wählbar, da es als Plugin umgesetzt ist.
Dank C# und .Net 4 geht auch die Nutzung von mehreren Prozessoren, was auf dem i7 2600K sehr gut funktioniert. Ich schieße hier also mit potenter Hardware auf wenige Farben und kann folglich neue Wege gehen. Irgendwann geht das dann bestimmt in der Cloud und alle können es benutzen, auch vom Handy. Eine Brute-Force-Methode geht deshalb aber immer noch nicht, denn das Problem ist sehr komplex: Allein das G2F-Farbmodell:

- 5 Farben in Tiles, alle 8 Zeilen mit neuer Farbe
oder: 4 Farben in Gr15 bei 4 Farben jede Zeile.

- Die Hintergrundfarbe kann dabei durch eine Playerfarbe ersezt werden, weil darunterliegende Player/Missiles dann durch das "Loch" durchscheinen.

- Die Player sind einfarbig und 8 Pixel breit, die Pixelbreite kann aber horizontal auf Gr15 Breite, doppelte oder 4fache Breite gesetzt werden.

- Die Player können horizontal in jeder Zeile an eine neue Position geschoben werden
- Die Player können jede Zeile eine neue Farbe erhalten

Damit liegen sehr viele Variablen vor.
Es sind also nur 8-10 Farben pro Zeile verfügbar und das unter großen Einschränkungen. Eine Bild hat bei 160 Pixeln pro Zeile aber eher 20-30 Atari-Farben nach Quell-Optimierung jede Zeile. Einfach die häufigsten Farben zu nehmen geht leider schnell schief und führt zu sehr streifigen Ergebnissen.

Für die automatische Bestimmung eines guten Ergebnisses ist eine brauchbare Bewertungsfunktion entscheidend: Was für das Auge gut aussieht muss eine gute Bewertung erhalten. Das allein ist schon eine interessante Aufgabe: Streifen vermeiden, Verläufe erhalten, Farbe des YUV-Modells erhalten, ...

Außerdem gilt es eine gute Bedienung dafür hinzubekommen. Im Moment habe ich dazu die DevExpress Library verwendet, welche bei Veröffentlichung mindestens 900 Dollar verschlingt. Die Alternative habe ich gestern mal ausprobiert und mit ordinären Drop-Down-Menüs hat man natürlich die gleichen Ergebnisse
Da bringt vielleicht das nächste Visual Studio etwas. Das ist in der Express-Edition sogar kostenlos und reicht vollkommen aus.

Etwas Erfahrung konnte ich schon sammeln seit ich auf dem Atari 800 XL einen Drucker zum Scanner umgebaut habe. Seit 1986 auf dem ST und dann ab 1989 auf dem PC mit 256-Farb-VGA-Karte. Seit TrueColor ist es natürlich einfach geworden
Und seit 2010 mache ich gern wieder XL Ich hatte plötzlich viel Zeit...
Und darum geht es auch nur: Spaß haben! Und Atari macht immer|wieder Spaß.

Aber falls jemand mit 4 Farben schöne bunte Bilder mit einem Programm hinbekommt, dann interessiert mich das brennend! Wobei natürlich die Farbeimer gemeint sind (siehe Atari-Handbuch).

Und das kommt bei dem teuersten Programm heraus, das ich benutzen darf:


Es steht auch oft in den Verfahren drin: ... doesn't work well for 4/8 colours. Bei 256 Farben geht dann jedes Verfahren - 256 ham wir aba nich!
2 Bit sind genug! (8 Bit hat VBXE, was wirklich genug ist)

Najaaaaaaa,

256 Farben hat der Atari XL/XE schon, je nach Sichtweise: 16 Farben x 16 Helligkeiten => 256 Farben; einfach Gr. 9+11 oder Gr. 9+10+11; aber die Auflösung ist da doch etwas niedrig. Ohne Interleave/Interlace und sonstige Tricks sind es gerade mal 80x96 Pixel, mit Interlace je nach Verfahren 80x192 Pixel oder 160x119 Pixel - alles recht bescheiden.

Schade, dass der HIP/RIP/TIP Trick nur bei Gr. 10 funktioniert, wäre er bei Gr. 9 oder 11 möglich, so wäre 160x200 Pixel in 256 Farben möglich und die C64 Leute wären endlich mal neidisch auf den A8. So bleiben viele Farben mit gleichzeitig guter A8 Auflösung, also mind. 160x192 bzw. 160x200 leider weiterhin ein Traum (es gab von Warner-Atari mal Pläne und Curt Vendel besitzt diese auch, Antic+GTIA als ein Chip, zwei Antic`s + zwei GTIA`s, ein Antic + drei GTIA`s in den A8 einzubauen, daraus wurde natürlich nix).

Ich habe mir angewöhnt Bilder auf dem PC zumeist erstmal auf 256 Farben und max. 320x200 Pixel oder 320x192 Pixel zu reduzieren, bevor ich sie für den A8 nutze/konvertiere (Ausnahme: CPEGview, der colour JPEG-Converter für den A8 von R.Espino). Zwar ist es immer noch nicht leicht 4 bis 16 Farben aus 256 auszuwählen, aber schon bedeutend leichter als sie aus 16,7 Mio. oder 65k Farben auszuwählen...

Viel Spaß beim weiteren rumprobieren...
-Andreas Koch.

Hi Ingo,
die oberen 2 Bilder sind echt nett. Musste sich erst mal in WUDSN IDE stecken um zu schauen, dass auch wirklich nur 4 Farben verwendet werden

Dat Problemsche ist nur, das bei 160x200 in 256 Farben schon 32KB Speicher benötigt werden. Und der 6502 würde durch das 4fache DMA nochmal kräftig gebremst. Bleiben von 1,77Mhz bei 40 Byte DMA pro Zeile nur ca. 1 MHz effektiv übrig, so kann man sich vorstellen, das bei 160 Bytes pro Zeile der 6502 kaum noch Luft bekommt. Der Prozessor hat keinen Cache und muss dauend auf den gleichen Bus zugreifen. Ich denke, dass erklärt schon warum das nicht im 8 Bit Atari drin ist.
Mit abgeschaltetem Antic kann der 6502 fast doppelt so schnell rechnen wie bei Grafik (oder Textmode Gr.0).
Es hilft auch Grobklotzgrafik einzuschalten mit nur 10 Bytes pro Zeile.
Für eine 7-Segment-Anzeige reicht das noch

Mehr Farben gibt es auf 16 Bit Rechnern - Aber man geht doch bewusst soweit zurück wie es geht: Dann landet man bei Atari XL und C64. Da geht fast alles schon: Sound, Grafik und diverse Hardware. Alternativ geht noch das VCS 2600, wenn man ganz über drauf ist. Das ist aber sehr ähnlich, da es den gleichen Prozessor hat, aber nicht einmal Speicher für eine SMS und einen "unglaublich blöden Grafikchip" damit das quasi ohne Ram überhaupt geht. Hut ab!
Auf dem ST macht auch vieles Spaß, gerade weil es relativ einfach ist. Aber das kann auch jeder! Cool ist es zu sagen: 8 Bit sind genug!
Klar ist, dass ich einem Pentium 90 heute gar nichts mehr abgewinnen kann. Entweder richtig schnell oder richtig "klein". Ich würde aber auch auf eine Casio Uhr Pong oder Sheriffs Job portieren! ich bräuchte nur so eine Uhr in die Finger bekommen und ein PDF mit Infos zum Prozessor und Grafik. Wen intersssiert dabei ob das sinnvoll ist? Was braucht man schon wirklich? Man will doch meist ohne Grund etwas haben, aber man will es haben! Und nicht etwa, weil man es braucht.
Warum modded jemand seinen Rechner oder customized seine Harley? Man will etwas eigenes haben! Und manchmal gefällt es ja sogar anderen. Finde ich immer klasse, wenn es nicht Mainstream ist.
Beruflich muss ich immer ganz modern sein, aber als Hobby muss ich es nicht!
Deshalb: 8 Bit sind genug! Fehlt nur noch die schwarze Nerd-Brille, die gerade total in ist.