Heute so konvertiert (aus: Heute so gepixelt)

Ja nee, strikt Koala-Format ist ja auch nicht hier, sondern der andere Thread drüben.

und auf NTSC stimmt die ratio dann sowieso nicht mehr

Als Anleitung für mich und andere (bezieht sich auf GIMP 2.8):



GIMP-Einstellungen:

1) Datei - Neu - Bildgröße : 160x200 / erweiterte Einstellungen - Auflösung : 1x1

2) Bearbeiten - Einstellungen - Anzeige - Bildschirmauflösung ('Manuell eingeben') -> 1.875 hor. x 1.000 vert. (vorher Verkettung unten lösen)

3) Ansicht - Punkt für Punkt -> ABHAKEN (!)



Ggf. Raster einschalten:

1) Bild - Raster konfigurieren - Abstand -> Breite/Höhe sollte auf 1x1 stehen

2) Ansicht - Raster anzeigen



indizierte Farbpalette anlegen:

1) Fenster - andockbare Dialoge - Paletten -> 'Eine neue Palette anlegen' (die 16 Farben in der bekannten Reihenfolge)

Bild konvertieren:

1) zu konvertierendes Bild auf 160x200 skalieren (Bild - Bild skalieren : 160x200)

2) Bild in die leere Bild-Datei reinkopieren (copy/paste)

3) Bild - Modus - Indiziert... - 'Farbtabelle' - 'Eigene Palette verwenden' - Tabelle auswählen - 'nicht verwendete Farben aus der Palette entfernen' ABHAKEN (!) - ggf. 'Rasterung' auswählen/ausprobieren

Das reine HiRes also 320x200 und 2 Farben je 8x8 finde ich grossartig.
Ab und zu habe ich mich darin auch versucht, aber wie es so schoen heisst: coder-Grafik
Veto hat damit aber z.B. wahre Wunder verbracht. Der/die ein oder andere auch (hier passt DIE auch endlich mal).
Man kann hier ja mal reinschnuppern fuer ein einige Beispiele:
c64pixels.com

Zitat von enthusi

Das reine HiRes also 320x200 und 2 Farben je 8x8 finde ich grossartig.
Ab und zu habe ich mich darin auch versucht, aber wie es so schoen heisst: coder-Grafik
Veto hat damit aber z.B. wahre Wunder verbracht. Der/die ein oder andere auch (hier passt DIE auch endlich mal).
Man kann hier ja mal reinschnuppern fuer ein einige Beispiele:
c64pixels.com

Das aber eben ausgearbeitete Grafiken. Dort hat man die volle Kontrolle jedes Pixels (innerhalb der Hardware Restriktionen) und kann mit cleveren Kompositionen des Grafikers auch viel mehr machen, was schöner aussieht, als bei einem konvertierten Bild.

Die Künstler von solchen Bildern haben auch ständig die technischen Restriktionen im Kopf und bringen trotz (oder genau deswegen) tolle Bilder zustande. Das ist sehr bewundernswert, finde ich.
Ein heutiger Künstler nimmt ein Cintiq und Photoshop & co und muss sich zumindest auf der technischen Seite nicht um vergleichbare Restriktionen wie bei den damaligen Homecomputern kümmern.

Zitat von enthusi

Hm, sehr schoen, aber warum in so einer verzogenen Aspect-Ratio?

Zum einen hatte ich oben vergessen, die Pixel-Aspect-Ratio in die CRT-Darstellung herein zurechnen (hier jetzt korrigiert), zum anderen sind die Meisten nicht so empfindlich, wie du. Man ist beim C64 (wegen der doppelt breiten Pixel bei Multicolor-Darstellung und wegen des 16:10-Formats) durchaus gewohnt, dass (gerade bei Spielen) die Darstellung etwas "zusammengedrückt" wird. Von daher mache ich das auch ab und zu, wenn es mir wichtiger ist, das Motiv nicht (oder möglichst wenig) zu beschneiden, als die Aspect Ratio einzuhalten.

Dankeschoen und was z.B. Dein Beispiel angeht: Ja, schrecklich

Hab nochmal mit P1 rumgespielt: der Konverter überrascht mich immer wieder. Allein das Brightness Sensitive Ergebnis ist verblüffend nah am Original...

So, und jetzt ist auch Schluss für mich mit Konvertieren

Zitat von Retrofan

zum anderen sind die Meisten nicht so empfindlich, wie du.

Wenn ein Fernsehsender von sich aus meint, alte 4:3 Filme auf 16:9 zerren zu müssen regt mich das allerdings immer sehr auf & ich muss dann früh ins Bett

Das linke gefaellt mir mit Abstand am besten

Ich hatte bei meinem Konverter mal den Ansatz, das Bild in 163 x 207 zu machen und die Pixel dann 'rumzuschieben' (3 hor./7 vert. = 32 Variationen) um rauszufinden, wo am wenigsten nachzubearbeiten ist (und das dann noch irgendwie einzubauen).

Check auf zuviel Farben pro Char-Block:

Angeblich also teilweise nur wenige Fehler in einigen wenigen Blocks insgesamt bei z. B. bei x+1 und y+4 = #04 Fehler. Das Ergebnis sagt aber leider noch was anderes (war noch ein 160x320 Bild - deswegen die Ränder):

Irgendwie noch etwas buggy...

Zitat von Hexworx

Ich hatte bei meinem Konverter mal den Ansatz, das Bild in 163 x 207 zu machen und die Pixel dann 'rumzuschieben' (3 hor./7 vert. = 32 Variationen) um rauszufinden, wo am wenigsten nachzubearbeiten ist (und das dann noch irgendwie einzubauen).

Müßtest du das dann nicht auch gleich 16x machen, um (erstmal?) die optimale (hier: die wenigsten Fehler verursachende) Hintergrundfarbe zu finden..?

Deine Bilder/Links sind bei mir übrigens grad "broken"

Zitat von Squidward

Deine Bilder/Links sind bei mir übrigens grad "broken"

Jetzt?

Zitat von Squidward

Müßtest du das dann nicht auch gleich 16x machen, um (erstmal?) die optimale (hier: die wenigsten Fehler verursachende) Hintergrundfarbe zu finden..?

Die hab ich vorgegeben. Der "Check" prüft allgemein auf die Anzahl der enthaltenen Farben pro Block. Die weiteren Farben werden aufgrund einer Tabelle jeweils vorrangig 01/10/11 zugeordnet. Theoretisch alles richtig - praktisch...

Erst konvertiert, dann korrigiert (= massiv nachgemalt)

... ein 320x200 *.ppm von Truecolour auf 4 Farben. Und zwar optimiert über alle möglichen Kombinationen der 4 Farben aus den 16 Farben des VC-20 (da Zeichenfarbe und Rahmen nur aus den ersten 8 gewählt werden können, sind das 2548 Möglichkeiten). Mit dem Ergebnis hier:

Einstweilen wird am Konverter noch ein wenig gebastelt.

Natürlich braucht das auch eine gescheite Anzeigeroutine für den VC. Die läuft allerdings nur im Vollausbau mit +35K RAM (ja, genau, das heißt: +24K in BLK1..3, +8K in BLK5 *und* +3K in RAM1..3!)

Zum Ausprobieren einfach das Archiv unten entpacken, die Datei "BOOT" laden und mit RUN ausführen und beim "FILE?"-Prompt eins der drei Bilder "PCPAINT1", "CECILE" oder eben "SPLATOON" eingeben.

Mit den Cursor-Tasten kann der Ausschnitt verschoben werden, die Taste "S" speichert den aktuellen Ausschnitt im MG-Format (für MINIPAINT) und mit der Leertaste wird das Programm beendet.

Zitat von Mike

Einstweilen wird am Konverter noch ein wenig gebastelt.

Durch einen genauen Zählappell ergab sich die genaue Anzahl der Kombinationen sogar auf 'nur' 1302.

Für die Freunde der Kommandozeile hab' ich mal die aktuelle Version in den Anhang gesteckt. Bei der Ausführung von 'ppm2cga.cmd' wird die Datei 'input.ppm' (mit genau 320x200 Punkten in 24 bpp) quantisiert und die Dateien 'result.ppm' (Vorschau für PC) und 'result.seq' (für die Anzeigeroutine aus dem vorigen Posting) erzeugt. Falls man im Batch die Dateinamen ändert, bekommen weder das Eingabebild noch die Vorschau die ".ppm"-Extension - die wird intern angehängt!

Das mitgelieferte Executable läuft auf einem 64-Bit-Windows. Für diejenigen, die sich den Konverter selber bauen wollen und/oder mal sehen wollen wie das innendrin aussieht - Source ist dabei. Der sollte auf so ziemlich allem kompilieren, was einen C-Compiler hat.

Es wird nur eines von mehreren möglichen Mappings von logischen auf physikalische Farben erzeugt - unter anderen kann man z.B. immer die Hintergrundfarbe mit der Hilfsfarbe oder die Rahmenfarbe mit der Zeichenfarbe tauschen - davon realisiert der Konverter aber nur die erste Kombination die den minimalen Fehler liefert. Für den Fall, daß man das bei einem der gespeicherten Ausschnitte (mit der "S"-Taste im Viewer, siehe ebenfalls oben) trotzdem durchtauschen möchte, kann man das Remap-Utility hernehmen, zu finden hier.

Gestern ein paar HiRes-Bilder, die alle noch aus der damaligen Zeit stammen und bei mir auf Diskette zu finden waren, mit meinem "SuperHiRes" konvertiert und gescreenshottet.

Hintergrund: Das Programm stammt aus der Zeit, als es längst leistungsfähigere Rechner mit vielen Farben gab, wodurch ich (und mein Bruder) meinten, wir müssten da mit dem C64 mit Hilfe von zeitraubenden Tricks irgendwie versuchen mitzuhalten (ab Ende der 80er). Auf diese Weise sind zwar jede Menge interessanter Programmroutinen und Tools entstanden, nur das Spiel, für das dies angedacht war, wurde dadurch nicht fertig, zumal dann aber auch andere Umstände hinzukamen.

Was SHR war und wieso es für die Konvertierung so lange braucht (hauptsächlich für die umfangreichen Algorithmen, Flimmern zweier Interlacestufen zu minimieren; das war das neue daran), kann ich gern später erklären. Beim 640x400-Pagefox-Großbild von Marlene Dietrich waren es in BASIC sogar über 5 Stunden, in Assembler ca. 2 Min.

links das Original in "Handiscan V1.2" in der Übersicht, rechts als SHR 192x200+128x200

Ein so großes Bild konnte nicht in der ganzen Breite dargestellt, sondern musste gescrollt werden. 192x200 war das Maximum (80 Sprites über HR-Bitmap). Es war aber sowieso nur für kleinere illustrative Bilder (Krieger, Waffen, Tiere, Burgen, etc.) für das Strategiespiel "Lemuria" gedacht. Zur Zeit des Entwicklungsabbruchs beherrschte das Programm nur "Monochrom" mit 5 Stufen für die resampelten 2x2-Bit-Kacheln der Vorlage (2x2 = 4 Pixel mit den 5 Pixelmengen 0 bis 4). Das Feature, die Farben im Rahmen der Möglichkeiten zu editieren, hatte ich angefangen; im Menü von SHR steht "edit color mask", geht aber noch nicht. Auch die Lade- und Speicherfunktion für SHR-Bilder reagiert nicht. Hab vergessen, was ich da gemacht hatte. Das Konvertieren geht also nur über das von mir erweiterte Handyscan (siehe Bild, letzter Menüeintrag, rechts unten). Da ich selbst wusste (heute weiß ich nix mehr), wie und wo die generierten Daten abgelegt und wie sie als Bild angezeigt werden, reichte das für mich schon aus, da ich die Daten genauso gut mit dem Monitor der Action Replay speichern konnte.

Charaktere für LEMURIA, die über den Handyscanner den Weg aus alten Schwermetall-Heften in den C64 gefunden hatten. Bei kommerziellem Vertrieb nicht unbedenklich. Mein Bruder hätte auch malen können, denn das kann der super.

Beispiel für einen präparierten Hintergrund

"Hawk" heißt dieses Bild, aber ich glaube, es ist eine Eule.

Antialiasing bei filigranen Details. Die höhere Informationsdichte wirkt

wie eine höhere Punktauflösung; daher der Name des Programms.

Hier noch mal deutlich bei dieser Zeichnung zu sehen.

Zitat von atomcode

"Monochrom" mit 5 Stufen für die resampelten 2x2-Bit-Kacheln der Vorlage (2x2 = 4 Pixel mit den 5 Pixelmengen 0 bis 4)

Besonders das letzte Bild (der Scanntronik-Schlumpf) zeigt, wie genial das ist! Du resamplest also ein 2x2-Pixel-Feld über fünf Graustufen und schreibst das Ergebnis als neues Bild weg, richtig? Das ist genau das Antialiasing, das ich mir schon immer für GoDot vorgestellt hatte! Würdest du deine Routinen evtl. teilen für GoDot?

Zum Vergleich: Dies ist, was GoDot draus macht (verkleinert auf 320x200).

Bei der Darstellung verwendest du Sprite-Overlays, damit die Hires-Auflösung erhalten bleibt?

Arndt

Edit: Bild eingefügt

(Der Hawk ist wirklich ein Hawk, keine Eule, das war unser erstes, mit GoDot von IFF nach Multicolor konvertiertes Bild damals, es ist in der 64'er der Aufmacher gewesen, als GoDot dort vorgestellt wurde...)