Heute so konvertiert (aus: Heute so gepixelt)

Hier der erste Test meiner grad selbstgeschriebenen ASM-Routine 32K-Gimp-Raw-Data -> mc-Bitmap (seit heute endlich soweit korrekt lauffähig) :

Laufzeit für die Umwandlung zur Zeit noch ca. 45 Sekunden (mit Check auf vorrangig zu vergebenden Farben für Hintergrund / mc 1 & 2 / Vordergrund).

Hier noch mögliche Zwischenschritte:

Vorschau (mit vorrangiger Farbe pro Charblock):

Anzahl Farben pro Char-Block (ohne Fehler):

Fehleranzeige (> 4 Farben/Charblock):

Ursprungs-JPEG wurde in Gimp in indizierte Farben mit eigener (hier z. T. reduzierter) Farbpalette umgewandelt. Funzt soweit also schon ganz gut .

Wenn man das Ausgangsbild auf 163 x 207 macht, kann das Programm das Bild auch pixelweise 'verschieben/rotieren' und sagen, wo am wenigsten (oder gar keine) Fehler (>4 Farben/Block) auftreten:

An der Pixel(Block)-genauen Angabe bin ich noch bei. Geht aber erstmal auch so.

P.S.: Ja, solche Converter gibt's natürlich schon (GoDot etc.), aber ich wollte was eigenes, wo ich die 'Macht' drüber habe und für meine geplanten Zwecke ab-/umwandeln kann .

Gruß

Hier noch im Vergleich:

homer3.jpg (hier nur als 1x1 Pixel statt als auf 2x1 gestretched in Gimp)

Zitat von Rayne

Mal ein bisschen ausprobiert wie konvertierte Grafiken auf dem DTV so aussehen können.

DTV Grafik ist nicht C64 Grafik.

Vermutlich hat er deshalb den Begriff "DTV" verwendet und nicht "C64".

Sieht sehr sweeeeet aus, Rayne.

Klar DTV ist nur der sterile synthetische Bruder vom C64 mit hässlicher Stimme aber verbesserten Video-Optionen. Warum soll man die nicht auch mal nutzen.

Und da DTV releases ja eher selten sind, hoffe ich, dass da dann auf irgend ner Party mal was Schönes bei raus kommt, nette Slideshow, evtl mit Mucke, würd ja schon reichen.

PS: Wenn's JMP besser gefällt, kann das ja jemand von C64 graphics in DTV verschieben

Der Kram von Hexworx sieht spannend aus, soll das Tool releast werden? Gibt zwar einen Haufen solchen Zeugs, aber native C64 noch nicht allzu viel bzw manchmal freut man sich ja auch bei Tools über Konkurrenz i.S.v. Auswahl.

Zitat von TheRyk

soll das Tool releast werden?

Könnte passieren. Braucht aber noch etwas Arbeit. Zur Zeit muss manches noch händisch eingetragen werden (bevorzugte Farben für Hintergrund/Multicolor etc.). Da muss auf jeden Fall noch ein Menü her. Und die Hintergrundfarbe muss bei der 4-Farb-Erkennung noch extra erkannt werden. Und noch ein paar Kleinigkeiten.

Im Moment sind ca. 45K in Benutzung (davon < 2K Code). Da ist sogar noch Platz für eine zweite Bitmap...

Ich hab mir bei dem Ding aber auch fast den A... gebrochen. Hatte mir das zu Anfang auch einfacher vorgestellt. Hätte nicht gedacht, dass dafür soviele Tabellen/Variablen/Schritte nötig sind. Wenn es soweit ist, geh ich da mal weiter in die Tiefe.

Multicolor-Bitmap ist jedenfalls schon ein ziemlich es Format... .

Zitat von Hexworx

Multicolor-Bitmap ist jedenfalls schon ein ziemlich es Format...

Das schreit jetzt natuerlich nach Multicolor (mixed) charset Grafik
Aber tatsaechlich ist MC bitmap sehr viel weiter von 'ich beschraenke mich mal eben auf 16 Farben' weg als viele denken....

Zitat von enthusi

Aber tatsaechlich ist MC bitmap sehr viel weiter von 'ich beschraenke mich mal eben auf 16 Farben' weg als viele denken....

So isses. Hab' die Tage auch grad' irgendwo noch einen Kommentar zu JPEG -> Bitmap gelesen, so ungefähr: Man braucht man ja NUR die Farben blabla und NUR pro Block drauf achten und NUR usw.. . Sinngemäß zu "Pics, or it didn't happen" -> "Code it, or shut up..."

Wobei Assembler für diese Aufgabe wirklich eine Krücke ist. In BASIC wäre das vielleicht (technisch) sogar leichter von der Hand gegangen. Die Gegenprobe mag ich aber nicht mehr machen...

Zitat von enthusi

Das schreit jetzt natuerlich nach Multicolor (mixed) charset Grafik

MC-Charset wäre aus meiner Routine prinzipiell noch als 'Abfallprodukt' denkbar. Ich schau mal . Dran gedacht hatte ich auch schon.

Wow!

Zitat von Hexworx

Hatte mir das zu Anfang auch einfacher vorgestellt. Hätte nicht gedacht, dass dafür soviele Tabellen/Variablen/Schritte nötig sind. [...] Multicolor-Bitmap ist jedenfalls schon ein ziemlich es Format... .

Hehe...

Arndt

Ich fände es ganz spannend, mal zu sehen, was die einzelnen Leute mit ihren Lieblings-Konvertern so aus einem Bild herausholen. Vielleicht könnte man ja aus Spaß mal Bilder posten, die dann von anderen (und einem selbst) konvertiert werden. Ich mache mal den Anfang und dann können wir ja gucken, ob das eine Serie wird oder ein gescheiterter Versuch.

Das Bild hat 640 x 400 Pixel. Da ist genug Datail-Tiefe drin, dass sich das jeder auf seine eigene Art und Weise auf die nötigen 320 (160) x 200 Pixel runterrechnen kann (keine Ausschnitte wählen, sonst sind die Ergebnisse nicht vergleichbar). Ich würde vorschlagen, dass man die Ursprungsbilder in dieser Auflösung (ohne weitere Rahmen o.ä.) postet (ob PNG oder JPG, sollte egal sein). Als Endprodukt schlage ich "Multicolor Bitmap" (Koala) vor, einmal als GIF/PNG zum Angucken hier im Forum und auf Wunsch als startfähiges C64-PRG (damit man sich das auf echter Hardware ansehen kann). Was meint ihr? hätte da jemand Spaß dran?

Unbehandelt, P1,in zwei Minuten:
yuv sowie brightness-sensitive

Gibt sicher besseres als Project1 - gerade "Color Sensitive" macht bei quietschbunt nicht das, was es soll.
Aber die Gradients von P1 gefallen mir: Pro.Grey & Vintage

Eighties Art

Hier mal ein Start.
Entspricht meinem normalen Workflow.

Photoshop
-> auf 160x200 bikubisch
-> auf pepto palette mit diffusion 30-60%
-> auf 320x200 mit nearest neighbor
-> save als bmp
-> in project one öffnen und zu koala konvertieren
-> (entfällt hier) von Hand weiter in Pixcen

Gibt sicher nicht die bestmöglichen Ergebnisse (bin daher sehr interessiert an alternativen Konvertierungsmethoden mit guten Ergebnissen).

Anbei ein Screenshot vom Koala Ergebnis zum schnellen Check (ist MC 160x200)

Zitat von awsm

Hier mal ein Start.
Entspricht meinem normalen Workflow.

Sieht für mich fast am besten aus.

Also, P1 bringt mit yuv bei diesem Bild wohl das beste Ergebnis, sonst bleibt bei den Original-Farben ja recht wenig übrig.

Der 2. Workflow (von awsm) scheint mir aber etwas besser zu funktionieren. Das Rastern wird hier Photoshop überlassen und P1 wandelt im Prinzip nur noch in Koala und muss halt gucken, was zu tun ist, wenn mal zu viele Farben in einem Block vorkommen (das kann PS ja nicht verhindern).

Könnt ihr jeweils sagen, welche Farbe BG ist? Oder wird stillschweigend von schwarz ausgegangen?

Eiei, da ist die Aspect-Ratio in der Vorlage ja hinueber
Aber hier ein nufli-Versuch.
Alles etwas arg gelb Ist aber auch ne Ewigkeit her, dass ich den benutzt habe...

Zitat von enthusi

Aber hier ein nufli-Versuch.

Auch schön – aber mich interessiert vorwiegend Multi-Color (standard). Dass man mit den ganzen getricksten Bildformaten deutlich detailliertere Ergebnisse bekommt, ist klar. Ich finde spannend, wie die Ergebnisse bei 160 x 200 Pixeln (ohne Interlace-Geflimmer und Sprites) sind.

Gracon spuckt bei der Vorlage folgendes aus (Pattern-Raster, BG = hellrot, Coco-Palette (daher bunter in der Voransicht)):

Bei der Erhaltung von feinen Details scheint mir P1 etwas überzeugender, beim Farbmatching (mehr rosa, weniger gelb) gefällt mir das Gracon-Ergebnis etwas besser. Was meint ihr?

Wer Lust hat, kann gerne mal ein anderes Bild hochladen. (Vorgaben wie oben von mir vorgeschlagen, außer es gibt "bessere").