Software, Einstellungen und Paletten für Konvertierungen

Es gibt 265 Antworten in diesem Thema, welches 21.357 mal aufgerufen wurde. Der letzte Beitrag (13. April 2022 um 15:20) ist von Tobias.

  • Aber da gibt es doch eindeutige Farbtendenzen, oder nicht?

    Nein, nach dem Graustufenbalken kommen zwei rötliche, zwei grünliche, zwei bläuliche und ein Magenta-Balken. Wichtig ist, was Deekay gesagt hat:

    Dann weicht das Bild dieser PEPTO Mischfarbenpalette aber ganz schön ab, oder? Da sieht man ja so gut wie überhaupt keine Gelb oder Rot Abstufungen, weil alle Rot Töne und selbst ein paar Braun Töne dort wie Lila Abstufungen aussehen. In der DEEKAY Palette sieht es farblich insgesamt ausgeglichener aus, aber sie ist schlechter zu verwenden bei Umwandlungen als die PEPTO, sprich man hat damit dann öfter mal eine Flacker-Farbe mit im MUIFLI.

    Color-Ramps! Das ist der entscheidende Hinweis. Wenn in einer Gegend des Bildes Abstufungen zwischen mehreren Farben gefunden werden, sucht Mufflon eine festgelegte Farbfolge (von sicherlich mehreren) aus, die bei Übergängen einerseits gezielt für geringe Flackertätigkeit sorgen und andererseits ein harmonischeres Ganzes erzeugen. Dadurch häufen sich in so einer Gegend bestimmte Farben, also z.B. violett oder purpur. Diese Farbfolgen sind in den 79-Farbbildern, die bei Mufflon dabei sind, ja ausgewiesen (Quadrat - großer Kreis - kleiner Kreis).

    Okay. Was das mit diesem Quadrat, grosser Kreis, kleiner Kreis in dem Bild auf sich hat, war mir nicht klar. Dann sucht er also keine einzelnen Farben immer heraus, sondern färbt nebeneinander liegende Farbabstufungen, immer mit von Anfang an festgelegten Dreier-Farbfolgen ein.

    Warum macht man das so? Bringt das Vorteile in den Ergebnissen, verglichen damit, immer zu jeder Farbe einzeln eine Austauschfarbe herauszusuchen?

    Das hatte ich ja bei meiner Dither-Version von dem Bild schon dazugeschrieben (anscheinend nicht klar genug): Hier liegt kein Grau vor, sondern ein niederschwelliges Blau, das in unseren Augen scheinbar wie ein Grau aussieht, aber dennoch einen ganz bestimmten Glanz rüberträgt, der dem Künstler 100prozentig wichtig war!

    Dass es keine reinen Grau-Töne sind, im Hintergrund dieses Bildes, hatte ich ja mehrfach geschrieben. Das was ich mit diesem Satz gemeint hatte, war eher dahingehend gedacht, dass in den 16 normalen Farben des C64 schon alleine 3 verschiedene Grau-Töne enthalten sind und ich mir deshalb vorstellen könnte, dass sich das bei Mischungen mit anderen Farben auswirken könnte und ich deshalb denke, dass die Mischfarbepalette ja gar nicht ausgeglichen sein kann. Wenn es aber dennoch so ist, dass es immer gleich viele Abstufungen zu jeder Farbe gibt, wundert mich das. Aber wird dann wohl so sein, du wirst das schließlich wissen.

    Wie jetzt? Ja, die hattest du bei den ersten drei Bildern aus, weil du ja behauptet hattest, dass es bei dir mehr geflackert hätte, als Deflicker aktiviert war, als wenn es aus gewesen war und zwar hier:

    Niein. Du musst schon genau lesen. )

    Das Flicker-Map-Fenster in Mufflon kennst Du?!

    Deshalb extra mein Eintrag Bitte melde dich an, um diesen Link zu sehen., weil das unklar ausgedrückt war von mir. Aber da du wohl zeitgleich geschrieben hattest, war das noch nicht zu sehen, als du schriebst, wie du weiter unten schon erwähnt hattest. :)

    Diese seltsamen Flächen (braun abgebrochen im Buch) sehe ich dann vielleicht auf meinem 1802 auch nicht, dafür das Flackern.

    Gut möglich.

    Komisch. Mein 10 Jahre alter Celeron braucht, wenn ich die Funktionen Different inks, different Papers und different Sprites aktiviert habe, vielleicht 10 Minuten, bis das Bild fertig ist, daher merkwürdig dass das bei dir soviel länger dauert. Auf aktuellen Rechnern dürfte das keine 5 Minuten brauchen.

    Danke für den Hinweis. Dann muss ich nochmal schauen. Viellleicht ist mein PC ja auch aus welchen Gründen immer nicht gut dafür geeignet.

    Es hängt natürlich teils auch sehr vom Vorlagenbild ab, also es kann in Ausnahmefällen auch schonmal länger dauern. Die längste Wartezeit, wenn alle drei Different... Funktionen an waren, hatte ich mal mit circa 25 Minuten. Darüber war es noch nie, aber mein PC ist auch schon älter. Die Nacht über anlassen lohnt sich hier wohl nicht, ich schaue zwischendrin manchmal fern oder esse was, dann ist das Bild immer fertig. *lol*

    Und ich habe auch noch bemerkt, da weiss ich aber nicht ob es an meinem PC liegt, dass ich nicht viel andere Sachen machen darf am Rechner, während MUFFLON ein Bild berechnet, sonst hängt sich MUFFLON auf und nichts tut sich mehr, also auch keine Fehlermeldung oder sowas, es geht einfach nichts mehr weiter und schaue ich dann in die Tasks, dann steht dort "keine Rückmeldung" bei MUFFLON. Deshalb mache ich es jetzt immer so, dass ich nichts anderes mache am Rechner, während das Tool ein Bild berechnet.


    Ob es bei den (nicht völlig unbrauchbar stark flackernden) Mischfarben jetzt bevorzugte Farbwinkel geben wird, würde ICH nur so bewerten, nachdem ich mit einer möglichst richtigen Basispalette die Mischfarben selbst ausgerechnet hätte. Vorher würde ich nur spekuieren.

    Ich spekuliere bei der ganzen Thematik in vielen Punkten, weil fast alles auf Rumprobiererei basiert. In der Theorie habe ich mich nie viel befasst mit dem Thema. Vielleicht sollte ich das mehr machen, aber das ist so trocken und macht mir keinen Spaß, da ist mir der Rumprobier-Weg lieber, auch wenn der nicht immer zu richtigen Schlussfolgerungen führt, wie man ja an der Color-Ramp Sache sieht. Manchmal deuten Ergebnisse, die man herausbekam, in bestimmte Richtungen und letztendlich stimmt das was man dann in einigen Punkten annimmt, scheinbar dann doch nicht. :)

    Das liegt in der Natur der Sache. Dennoch mag ich das NUFLI Format lieber, es ist "ehrlicher", für mich mehr C64 like. Einfach ein wesentlich bunteres Hires. :)

    Und wie gesagt sind die Ergebnisse vohersagbar. Dass ein Ergebnis am C64 und dann auch noch je nach Displaytyp anders ausieht, ist für mich schon mittelmäßig unbefriedigend. Ich will da nicht jedesmal 10, 20 Versionen erstellen, um mir dann das am wenigsten schlechte raussuchen müssen.

    Ja, dass MUIFLI Interlace ist, hat seine Nachteile. Ich bin inzwischen aber schon ein Fan dieses Bildformats geworden, weil es in der Detail-Darstellung einfach genial ist. Mühselig ist es auf jedenfall, von einigen Bild mehrere Versionen erstellen zu müssen, teils bis zu 10 Stück, bis endlich mal eine gut aussieht, weil man nie genau sagen kann, wie es dann auf einem alten Röhrenmonitor rüberkommt. Aber gut, muss man dann halt in Kauf nehmen, irgendwann kommt dann trotzdem ein gutes Ergebnis herarus und man weiss teils gar nicht warum.

    Sieht alles top aus, solange die beiden Bildlayer absolut stillstehen, wie im Screenshot.

    Du schreibst hier immer von stillstehenden ZWEI Bildlayern. Das ist einfach EIN Bild, das aus den BEIDEN Eizelbildern zusammengerechnet wurde. Das sind keine zwei Layer drin. Da wird nie was flackern.

    War das nicht eindeutig, wie es gemeint war? Mit dem Satz meinte ich, dass Screenshots, sagen wir mal png-Files, die so erstellt wurden, dass beide Bildlayer des MUIFLI's in einem Zeichenprogramm fest übereinanderkopiert werden, dann natürlich kein bisschen mehr flackern und man sich hier oft täuschen kann, wenn von einem MUIFLI, im Thread ein solches png gepostet wird.

    Das sieht dann oftmals absolut top aus und natürlich auch klar besser, als es dann am echten C64 oder im C64 Emulator aussehen wird, wo die beiden Bildlayer ja immer ganz schnell abwechseln und etwas flackern. Im png stehen die Layer natürlich dahingehend still, dass die sich nicht mehr abwechseln. Daher verstehe ich jetzt die Aussage von dir nicht, es ist EIN Bild, denn es sind zwei Layer die sich ganz schnell abwechseln und dadurch dann für den Betracher den Eindruck erwecken, es wäre ein Bild. In Wahrheit sind es aber zwei wechselnde Bildlayer, das weisst du doch selbst. Sieht man ja auch gut, wenn man in einem C64 Emulator den Speed auf 1% herunterdreht und sich dann ein MUIFLI ansieht. So hole ich übrigens auch immer Screenshots der beiden Bildlayer heraus, die ich dann im Zeichenprogramm wieder zusammensetze, um hier dann Screenshots der Bilder posten zu können.

    Man könnte sowas bestenfalls halbwegs mit einem animierten GIF "simulieren". Da bleibt immer noch 60 vs 50 Hz.

    Das Thema hatte man ja schonmal, weiter vorne im "Crazy News Pics" Thread. Nicht einfach, den Bildwechsel-Speed im gif so gut hinzubekommen, dass es jeweils dann immer wie im echten MUIFLI aussieht. Aber auf die Art kämen Screenshots natürlich etwas näher an das heran, wie das MUIFLI dann auf dem C64 aussieht, zumindest wenn der Speed im gif einigermaßen passt.


    Das Ditherraster könnte das "Muster", den Algorithmus, mit dem Mufflon das Flackern zu reduzieren versucht, an diesen Stellen stören.
    Wenn Mufflon eine Mischfarbfläche hat, dann macht es nicht in einem Bild vollflächig die eine Grundfarben und im anderen Bild (Du nennst dies Layer) die andere. In beiden Einzelbildern benutzt es ein Schachbrettmuster mit beiden Grundfarben. Im zweiten Bild einfach um einen Pixel versetzt. Das mag gut bei Flächen funktionieren, wenn aber Details (Dither) diesen Ansatz "stören", dann ist das Flackern in diesen Bereichen vielleicht noch schlimmer, als wenn diese flächige FLackervermeidung ganz wegggelassen wäre. Das meinte ich mit Moiree.

    Ja, sehe ich genauso, wie ja schon erwähnt. Den Erfahrungen nach, verstärkt das Rastern das Flackern. Leider, muss man sagen.

    ConGo hatte seinerzeit auch durch ein paar meiner Vorschläge zum damals noch nicht vorhandenen Dithering und meiner Palette profitiert. Sowas macht mir Spaß. Leider kann ich solche Sachen nie selbst programmiertechnisch umsetzen.

    Geht mir genauso. Ideen sind immer viele da, programmiermäßg umsetzen kann ich sie auch nicht selbst (nie wirklich damit beschäftigt und auch nie wirklich dafür interessiert, ehrlich gesagt). Aber ich hab da auch keine Scheu, Leute anzusprechen/anzuschreiben, die das dann können, egal um was für ein Programm es sich auch handelt. Auf die Art kam dann doch schon das ein oder andere in Programme (Emu's/Tools/Demos usw) mit hinein, weil tatsächlich ein Mehrwert erkannt und es berücksichtigt wurde, was einen dann natürlich freut. Deshalb war es auch gut, dass du Deekay schon mehrfach auf die V2.0 ansprachst und auch eine Beta hast usw, das zeigt ihm zumindest schonmal, dass User da sind, die Interesse daran hätten.

    Sieht natürlich super aus, wenn man sich anschaut, was man da dann alles an Einstellungsmöglichkeiten mehr hat oder hätte. Jetzt wenn ich das sehe, hoffe ich natürlich noch mehr auf eine stabile Windows GUI für die V2.0.

    Vielleicht hift es ja, wenn DeeKay jetzt noch einer mehr "nervt". ;)
    Wie gesagt, wir haben ja einige Unstimmigkeiten entdeckt. Falls diese behebbar sind, könnte man die Chance geich nutzen für ein Mufflon 2.1 oder so. :)

    Von mir weiss er ja nun definitiv schon, dass ebenfalls Interesse vorhanden ist an der V2.0 samt GUI, denn das hatte ich natürlich auch zum Ausdruck gebracht. Mal sehen, ob sich was tut und er bei der entsprechenden Person, die das umsetzen könnte, etwas erreichen kann in absehbarer Zeit? Hoffen wir es mal.

    Viele Bearbeitungen in der jeweiligen Bildvorlage, von denen man bei der Erstellung eines MUIFLI's vorher eigentlich gar nicht genau weiss, ob sie sich dann auch wirklich genau so wie gewünscht im Endbild auswirken, würden entfallen, wenn man beispielsweise Sachen wie Kontrast, Gamma usw, direkt im MUFFLON Menue ändern kann und sich dann immer direkt das Pre-Convert ansehen könnte, nach einer Umstellung. Ist das möglich, dann ginge natürlich alles viel schneller und ohne zig Versuche jedesmal erstellen zu müssen.

    Daher wäre die V2.0 von MUFFLON, die ja fast alles davon kann, natürlich schon super.


    Was sagst du eigentlich zur Version v3 des "The brightest light..." Bildes im Eintrag Bitte melde dich an, um diesen Link zu sehen.? Die ist farblich gut, oder? Aber flackert halt etwas und zwar schon so, dass es stören kann, weil ich "different inks" anschalten musste, um ein paar Grün-Töne im Hintergrund wegzubekommen, die einfach nicht reinpassten. Die Alternative wäre gewesen, diese ganzen Grüntöne manuell per Hand umzufärben in der bereits mit der PEPTO Palette belegten Bildvorlage. Aber man hätte dann auch dort malen müssen, wo es in der Vorlage gar kein Grün gibt und das wäre ein ziemlicher Aufwand geworden, da immer genau die richtigen Pixel dann zu erwischen. Beim rechten Auge der Frau musste ich aber auch zwei dunklere Pixel entfernen in der Vorlage, die im Ergebnisbild immer schwarz blieben und dann störend wirkten. Aber die waren leichter zu finden in der Vorlage, weil sie auch da dunkel waren. Es gibt keinerlei Störstreifen oder sonst irgendetwas in dieser v3, würde die etwas weniger flackern, wäre die mein Favorit.

  • Bei dem gräulichen Hintergrund sind wir uns denke ich einige, dass wir uns hier nicht einig werden. ;)
    Ich fasse zusammen:

    Arndt

    erkennt einen leichten Blaustich, ordnet ihm dem Author zu und findet ihn deswegen wichtig. Daher möchte er diesen Eindruck zumindest irgendwie und möglichst flächig wiedergeben.

    AW1

    erkennt einen leichten Magentastich und kann diesen auch mit dem Eindruck am echten AMIGA in Verbindung setzen.

    Ich

    erkenne einen leichten Blaustich. Angesichts der relativ hellen und gesättigten Blauanteile im "Strahl" nehme ich den Hintergrund nahezu als grau wahr. Die Farbfähigkeiten des C64 berücksichtigend, würde ich den Hintergund vor dem Konvertieren in reine Graustufen umwandeln. Ziel wäre es, ein Dither mit z.B. jedem 25. Pixel in blau zu vermeidem, was den Farbeindruck eh nicht reproduzieren kann und mehr wie Rauschen aussieht als dass es (mir) hilft.

    Daher verstehe ich jetzt die Aussage von dir nicht, es ist EIN Bild, denn es sind zwei Layer die sich ganz schnell abwechseln und dadurch dann für den Betracher den Eindruck erwecken, es wäre ein Bild. In Wahrheit sind es aber zwei wechselnde Bildlayer, das weisst du doch selbst.

    War das nicht eindeutig, wie es gemeint war?

    Mir ist schon klar, was Du meinst, aber die Ausdrucksweise ist für andere Leser vielleicht irreführend.

    Es ist EIN Bild am PC, was Du hier postest. Dieses wurde aus den Bildinformationen ZWEIER Bildern (AW1:"Layer") gemittelt.

    Am C64 (oder zur Not im Emulator) wird das "Interlace"-Bild aus zwei sich abwechselnden Bildern erzeugt. Dadurch kommt es zu mehr oder weniger starkem Flackern.

    Dieses sieht man am errechneten PNG Bild nicht. Das PNG Bild "sind keine zwei Layer, die sich ganz schnell abwechseln", sondern es wurde daraus berechnet/erstellt.

    dass ich nicht viel andere Sachen machen darf am Rechner, während MUFFLON ein Bild berechnet, sonst hängt sich MUFFLON auf und nichts tut sich mehr

    Das kann ich so bestätigen.
    Nach meinem Verständnis läuft da im Hintergrund ein komplettes Pyhton und was weiß ich alles mit, wenn man das Mufflon.EXE startet.

    Der Virenscanner schlägt bei jedem Schließen jedenfalls Alarm bei mir.

    Das Thema hatte man ja schonmal, weiter vorne im "Crazy News Pics" Thread. Nicht einfach, den Bildwechsel-Speed im gif so gut hinzubekommen, dass es jeweils dann immer wie im echten MUIFLI aussieht. Aber auf die Art kämen Screenshots natürlich etwas näher an das heran, wie das MUIFLI dann auf dem C64 aussieht, zumindest wenn der Speed im gif einigermaßen passt.

    Sieht man ja auch gut, wenn man in einem C64 Emulator den Speed auf 1% herunterdreht und sich dann ein MUIFLI ansieht. So hole ich übrigens auch immer Screenshots der beiden Bildlayer heraus, die ich dann im Zeichenprogramm wieder zusammensetze, um hier dann Screenshots der Bilder posten zu können.

    Ich würde mir in Mufflon eh auch ein Fenster wünschen, dass mir bei MUIFLI die beiden Einzelbilder des Ergebnisses anzeigt. Somit würde man vielleicht ein besseres Verständnis bekommen, wie (Muster..) und warum das Bild mit den Grundfarben zusammengemixt wird. Sahnehäubchen wäre noch das Speichern als animiertes GIF.

    Die Info zu Deinen Screenshots ist interessant. Bei Gelegenheit werde ich Dir vielleicht mal ein zwei Files schicken mit der Bitte um die beiden Einzelbilder. ;)

    Was sagst du eigentlich zur Version v3 des "The brightest light..." Bildes im Eintrag Bitte melde dich an, um diesen Link zu sehen.? Die ist farblich gut, oder?

    Am C64 leider noch nicht. Werde ich aber nachholen.
    Beim Screenshot würde mir persönlich immer noch meine DX Version besser gefallen vaD wegen des grauen Hintergrunds. Leider ist da ja in real dieser f'*#+ing Streifenbug drin und an 50Hz flackert das wieder zu stark, wie Du schreibst.

    Bei deser v3 hast Du das Bild in Y-Richtung gestaucht, oder? Weil jetzt der Ellenbogen ganz drauf passt.

    Bei meinem Bild hatte ich nicht den rechten Rand beschnitten, um den Lichtstrahl komplett drauf zu haben. Den linken Teil, das er ja relativ grau ist, kann man halbwegs im FLI-Bug retten. Schwarz mit hellgrau flackert dann halt entsprechend.;) Stauchen/Strecken würde ich nur ungern. Wenn dann komplett skalieren.

    mfg Tobias

  • Warum macht man das so? Bringt das Vorteile in den Ergebnissen, verglichen damit, immer zu jeder Farbe einzeln eine Austauschfarbe herauszusuchen?

    Ich versuche das jetzt mal laienhaft auszudrücken und GoDot möge mich korrigieren, wenn ich falsch liege.

    1. Zu erst einnmal müssen ja für jeden Pixel möglichste passende C64 Farben gefunden werden.

    2. Weiterhin müssen teileweise gefundene Farben durch andere ersetzt werden wegen Color Clashes.

    Bei beiden sind die Möglichkeiten der 16 C64-Farben sehr beschränkt.
    Die C64 Farbe muss in Farbton und Helligkeit dem Originalpixel halbwegs nahekommen.

    A) Stimmt jetzt zwar die Farbe halbwegs, aber der Helligkeit der C64-Farbe kann absolut nicht das Original wiedergeben, dann nimmt man im Zweifelsfalls lieber eine andere Farbe mit passender Helligkeit. Diese Stört weniger, als die "richtige", aber viel zu helle/dunkle Farbe.

    B) Findet man gar keinen passenden Farbton, dann nimmt man zumindest eine andere Farbe mit möglichst passender Helligkeit.

    So richtig?

    mfg Tobias

  • würde mir in Mufflon eh auch ein Fenster wünschen, dass mir bei MUIFLI die beiden Einzelbilder des Ergebnisses anzeigt. Somit würde man vielleicht ein besseres Verständnis bekommen, wie (Muster..) und warum das Bild mit den Grundfarben zusammengemixt wird. Sahnehäubchen wäre noch das Speichern als animiertes GIF.

    Das würde ich mir auch wünschen! :dafuer:

    eine andere Farbe mit möglichst passender Helligkeit.

    Und da spielen die eingebauten Graus eine große Rolle. Mit denen wird versucht, flackerfreie Übergänge zu schaffen. Geht das nicht (oder passt das nicht), dann nimmt man die Farbe, die helligkeitsmäßig am nächsten dran ist (siehe die Mufflon-Colorramp-Bilder). Sieht man an Bildern wie diesen ganz gut:

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Wenn man in der Realität Menschen mit grünen/quittegelben Gesichtern begegneten, würde man sich wahrscheinlich Sorgen machen. In so einem Bild fällt es einem dagegen nicht einmal auf.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Grau und Helligkeiten, das waren meine Stichworte.:D

    Dazu wäre es interessant, mit welchen Helligkeiten Mufflon nun für die Grundfarben und deren Mischfarben rechnet.

    Mit den tatsächlichen Helligkeiten der verwendeten RGB-Paletten oder den 1/32-Stufen der Pepto-Theorie?

    Ich hab mal wieder mit den Helligkeiten gespielt.

    Dazu hab ich mir einige "reduzierte Paletten" ausgesucht, und deren Farben mit den entsprechenden (meinen aktuellsten) Helligkeitswerten ersetzt.

    Das Graustufen-Ursprungsbild lasse ich dann mit diesen Helligkeitswerte neu berechnen. Danach tausche ich die Palette wieder gegen die bunte Palette aus.

    Das Ergebnis ist quasi: "Farbe X entspricht Helligkeit Y"

    Die Bilder hab ich dann in Mufflon in NUFLI umgewandelt. An den Rändern gibt's bei diesem Beispiel ein paar Color Clashes.

    Jedenfalls wenn man sich die Bilder jetzt am C64 und Monitor anschaut, und die Sättigung ganz runter dreht, sollten die Bilder bis auf unterschiedliche Dithermuster einen sehr ähnlichen Helligkeitseindruck vermitteln.

    Hierzu hab ich nochmal alle 6 Varianten in ein Bild gepackt.

    Ich werde auch mal ein "technisches" Bild machen mit Graustufenflächen. Bis auf Black Bleed Effekte sollten mit allen reduzierten Paletten die Flächen gleich hell sein beim Rausregeln der Farbe.

    mfg Tobias

    Edit:
    Beim "*peptoview.png" sieht man auch, dass rot hier eher wie braun aussieht. Daher können in einer Pepto-Mischpalette auch keine rötlichen Mischfarben enthalten sein. ;)

  • Hier das Bild mit den 6 verschiedenen Flächen.
    Ohne Farbe am C64-Monitor sollten sie idealerweise nicht sichtbar sein. Die unterschiedlichen Dithermuster werden dies aber teilweise verhindern. ;)

    An Ollie's Hut ist wohl der unterschiedliche Black Bleed gut zu sehen.

    Die Gesichter sind jeweils 4-geteilt. Bei mir am C64 und Sony-CRT sehe ich davon ohne Farbe fast gar nichts mehr. :)

  • Ich werde auch mal ein "technisches" Bild machen mit Graustufenflächen. Bis auf Black Bleed Effekte sollten mit allen reduzierten Paletten die Flächen gleich hell sein beim Rausregeln der Farbe.

    Anbei die Bilder. Funktioniert durch das grobe Pixel-Raster nur bedingt gut.


    Daher habe ich nochmal die 9 C64 Farbstufen nur mit den 3 echten Graustufen gedithert.

    Bis auf die Stufe 1, bei der es wieder ein doofes Muster gibt, sehen die Mischgraus den Farbhelligkeiten bei runtergedrehter Sättigung schon sehr ähnlich.

    Also die Stufen 3, 5 und 7.

    Dazu bin ich gut 2 Meter vom Sony-TV weg und meine Lesebrille hat nochmal zusätzlich das Dither geglättet.:D

    Für mich folgt daraus, dass ich so mit den Helligkeitswerten arbeiten werde. Sie unterscheiden sich geringfüging von den 1/32er Pepto-Schritten. Die Werte wurden aus vielen Messungen und insbes. der Widerstandsmatrix im VIC-II (5 und 9 Stufen) errechnet.

    mfg Tobias

  • Daher habe ich nochmal die 9 C64 Farbstufen nur mit den 3 echten Graustufen gedithert.

    Womit wir bei GoDot angelangt wären... :wink:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Multicolor, 5 Graus (Vorlagebild Bitte melde dich an, um diesen Link zu sehen., die 5 bzw. 9 Graustufen siehst du auch dort)

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Womit wir bei GoDot angelangt wären... :wink:

    Wenn Du GoDot für Windows machst, verwende ich das sofort. ;)

    Mit welche Grauwerten arbeitet denn GoDot bei der Zuordnung?

    Schwarz 0?

    Dunkelgrau?

    Grau?

    Hellgrau?

    Weiß 255?

  • Womit wir bei GoDot angelangt wären... :wink:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Multicolor, 5 Graus (Vorlagebild Bitte melde dich an, um diesen Link zu sehen., die 5 bzw. 9 Graustufen siehst du auch dort)

    Arndt

    GoDot macht das wirklich gut.
    Als NUFLI sähe das so aus wie im Anhang.

    (ich hätte das Urpsrungsbild in grau nicht im Kontrastumfang ändern sollen, hier fehlen ein meinen Bildern nun die ganz dunklen Elemente)

  • Mir hat das Bild so gut gefallen, dass ich mir das Original gesucht und umgewandelt habe. :)

    Einmal den ähnlichen Ausschnitt wie aus dem GoDot-Beispiel.

    Dann nochmal das ganze Bild. Um das Seitenverhältnis nicht zu ändern, habe ich hier links und rechts etwas hinzubeschi..en.

    Hier erstmal das ganze Bild.

  • Leider scheint die VIC-II, zumindest meiner, Hires-Muster (wohl besonders bei dunklen Farben) nicht sonderlich zu mögen.

    Hier entsteht ein Muster, das vom Abstand her etwas aussieht wie ein LumaFix Problem.

    Bitte melde dich an, um diesen Link zu sehen.

    Ich habe keinen eingebaut, aber mein Startbildschirm hat hier kein erkennbares Problem.

    Es scheint, als ob sich das VIC-Signal irgendwie aufschwingt. Teilweise erscheinen Pixel sogar heller, als sie sind. Umgekehrtes Black Bleed quasi.

    Das hat man oben in der Farbfelderbildern auch etwas gesehen.

    Dieses Steifenmuster hab ich auch schonmal extrem bei Asslace Bildern gesehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Könnte Ihr bitte mal an Eurem C64 schauen, ob Ihr mit dem File und dem Asslace aus dem Link ähnliche Streifenmuster bekommt?

    Danke.

    mfg Tobias

  • Mit welche Grauwerten arbeitet denn GoDot bei der Zuordnung?

    Siehe Bitte melde dich an, um diesen Link zu sehen..

    Als NUFLI sähe das so aus wie im Anhang.

    In Hires kann ich das mit GoDot auch rendern, allerdings nicht im NuFLI-Format speichern. Darum hier eine GIF-Version davon von GoDot, die müsste in NuFLI super aussehen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Es ist EIN Bild am PC, was Du hier postest. Dieses wurde aus den Bildinformationen ZWEIER Bildern (AW1:"Layer") gemittelt.

    Am C64 (oder zur Not im Emulator) wird das "Interlace"-Bild aus zwei sich abwechselnden Bildern erzeugt. Dadurch kommt es zu mehr oder weniger starkem Flackern.

    Dieses sieht man am errechneten PNG Bild nicht. Das PNG Bild "sind keine zwei Layer, die sich ganz schnell abwechseln", sondern es wurde daraus berechnet/erstellt.

    Aber das ist ja wohl vollkommen klar, auch für jeden Leser, dass es, wenn ich ja selbst die beiden Bildlayer in einem Zeichenprogramm überblendet habe, dann nur noch ein Bild ist, als png-Screenshot. Gleichzeitig gilt aber auch das Argument, dass hier dann ja keine Bildlayer mehr flackern können, sie also stillstehen, weil sie nun quasi eins sind.

    Der Grund warum ich das ansprach, war schlicht und einfach der, dass man sich nicht täuschen lassen soll, wenn hier im Thread teils farblich super aussehende MUIFLI Bilder als png-Screenshots gepostet werden (auch einige deiner geditherten Bilder), da dies extrem täuschen kann, wenn genau diese Bilder dann als MUIFLI's am echten C64 wieder total anders wirken, weil man die Flackerei, wenn sie zu stark ist, dann als extremen Störfaktor empfinden kann.

    Die beiden sich abwechselnden Bildlayer bringen hier dann eben teils nicht wirklich vorhersehbare Endresultate mit sich (speziell oft in helleren Bereichen des Bildes). In den Screenshot wechseln sich die Layer dann nicht mehr ab, sie wurden ja in eine Schicht überblendet, also stehen sie hier dann still, während sie im MUIFLI flackern. Weiss nicht, was daran unverständlich sein soll?

    Ich denke, man sollte die Leser hier nicht unterschätzen, die wissen schon, wie das gemeint war.

    Ich würde mir in Mufflon eh auch ein Fenster wünschen, dass mir bei MUIFLI die beiden Einzelbilder des Ergebnisses anzeigt. Somit würde man vielleicht ein besseres Verständnis bekommen, wie (Muster..) und warum das Bild mit den Grundfarben zusammengemixt wird. Sahnehäubchen wäre noch das Speichern als animiertes GIF.

    Ja, das wäre prima, wenn das ginge. Da haben wir einen Punkt, wo wir uns alle drei einig sind. Und gut wäre auch, wenn man in MUFFLON, per Doppelklick auf das kleine Endbild-Fenster (unten rechts), dieses dann auf Gesamt-Screengröße vergrößern könnte. Hattest du ja auch schonmal erwähnt, etwas in der Art. Das wäre vor allem hilfreich, wenn man einzelne Pixel in der Bildvorlage nachbearbeiten muss, denn die kann man in diesem winzigen Endbild-Fenster nicht richtig erkennen/zuordnen und teils werden Probleme im MUIFLI dort im kleinen Fenster ja auch gar nicht angezeigt, das ist dann das Allerschlimmste.

    Man merkt es dann aber im Emulator, wenn man sich das MUIFLI ansieht. Das hatte ich zum Beispiel, mit zwei dunklen Punkten, im rechten Auge der Frau, bei der v3 MUIFLI Version. In solchen Fällen habe ich dann bislang immer das kleine PC-Tool "Zoomer" verwendet, was so etwas wie eine Lupe ist, die man verschieden stark einstellen kann. Dann schob ich die Lupe über das MUIFLI im Emu-Bild, um genau sehen zu können, welche Pixel farblich nicht passen im Bild und ich kann dann genau diese in der Bildvorlage händisch umfärben. Dann kann ich danach sicher sein, dass das nächste MUIFLI, welches ich aus dieser bearbeiteten Bildvorlage erstelle, dieses Problem dann nicht mehr haben wird.

    Wäre viel einfacher, könnte man all das bereits im Endbild-Fenster in MUFFLON sehen.

    Die Info zu Deinen Screenshots ist interessant. Bei Gelegenheit werde ich Dir vielleicht mal ein zwei Files schicken mit der Bitte um die beiden Einzelbilder. ;)

    Ja, kein Problem. :) Aber du hast ja sicher auch einen C64 Emu am Start, damit halt einfach den Speed runterdrehen. Im Denise und im VICE geht das direkt über das Custom-Speed Feld. Am besten ist natürlich 1%, da hat man circa 2 Sekunden Zeit bei jedem Bildlayer, um einen Screenshot machen zu können. Überblenden geht dann in einem Zeichenprogramm oder auch Online.

    Beim Screenshot würde mir persönlich immer noch meine DX Version besser gefallen vaD wegen des grauen Hintergrunds.

    Nur dass im originalen Bild der Hintergrund halt kein reines Grau ist, :) womit wir wieder beim alten Thema wären. Aber egal, jeder kann ja auch seine Wunschfarbe nehmen, wenn er will. Das nahm ich ja auch, in meinem allerersten Bild, in dem das Lila/Blau im Hintergrund domininiert. Nimmt man nur dieses Bild für sich, ohne die Vorlage zu kennen, sieht es toll und ist immernoch bei mir weit vorne mit dabei, nur für sich gesehen.


    Bei deser v3 hast Du das Bild in Y-Richtung gestaucht, oder? Weil jetzt der Ellenbogen ganz drauf passt.

    Nein, nicht gestaucht, das Seitenverhältnis stimmt. Ich hatte nur rechts (und auch in der Höhe natürlich) etwas vom Bild abgeschnitten, also einen 295x200 grossen Bereich herausgeschnitten wenn man so will, weil rechts ja auch nichts mehr im Originalbild ist, was das Bild noch gross beeinflussen würde. Man sieht ja, dass es dir kaum auffiel, dass da ein kleiner Teil rechts fehlt und du es für gestaucht hieltest.

    Die Frau und das Licht, welches vom Buch hochgeht, sowie die Schmetterlinge usw, passten auch so noch problemlos mit darauf. Ich schneide die MUIFLI's vorher immer lieber auf die Breite von 295 Pixel zurecht und färbe den 25 Pixel breiten Streifen der dann noch zu 320 Pixeln fehlt, dann in der Farbe, in der auch der Rand sein wird. Das bevorzuge ich, weil man sonst, wenn man die Breite auf 320 belässt, einen 25 Pixel breiten Streifen im Bild mit drin hat, der nur zweifarbig oder einfarbig ist und dann einfach nicht schön wirkt.

    Schwarz mit hellgrau flackert dann halt entsprechend.;) Stauchen/Strecken würde ich nur ungern. Wenn dann komplett skalieren.

    Wie gesagt, ist da nichts gestaucht/gestreckt. Im Gegenteil, das Bild passt vom Grössenverhältnis her perfekt, weil ich die Bildvorlagen immer auf 320x200 zurechtmache, einschließlich eben, eines 25 Pixel breiten und zumeist schwarz eingefärbten Streifens, ohne den das Bild dann 295 Pixel breit ist.

    Natürlich könnte man Amiga Bildvorlagen, die ja immer 256 Pixels hoch sind, zu Anfang auch verkleinern auf 200 Pixel Höhe und wenn man das Seitenverhältnis dabei beibehält, schrumpft dann natürlich auch gleich die Breite auf unter 295 Pixels. Aber bei Bildern von Retro-Systemen, die eh schon keine hohe Auflösung haben, zerstört man damit natürlich auch wieder einige Pixels, wenn man das Bild noch winziger macht und die Endresultate sehen dann nicht mehr gut aus, vor allem wenn ohne Zusatzfilter die Größe des Bildes verändert wurde. Und schaltet man dafür aber einen Zusatzfilter zu, werden es natürlich wieder viel mehr Farben insgesamt, was sich dann auch nachteilig auf die Umwandlung auswirkt.

    Deshalb blieb ich bislang immer dabei, einfach einen Bereich von 295x200 aus den Originalbildern herauszuschneiden, der das Geschehen des Bildes bestmöglich einfängt. Ist aber nicht bei allen Amiga Bildern wirklich einfach, wie man sich ja denken kann. Würde sich, in einem 320x256 Pixel grossen Amiga-Bild, vieles an den Bild-Rändern abspielen, hätte man hier ein Problem. :) Dann müsste man sich etwas anderes überlegen.

    Warum macht man das so? Bringt das Vorteile in den Ergebnissen, verglichen damit, immer zu jeder Farbe einzeln eine Austauschfarbe herauszusuchen?

    A) Stimmt jetzt zwar die Farbe halbwegs, aber der Helligkeit der C64-Farbe kann absolut nicht das Original wiedergeben, dann nimmt man im Zweifelsfalls lieber eine andere Farbe mit passender Helligkeit. Diese Stört weniger, als die "richtige", aber viel zu helle/dunkle Farbe.

    B) Findet man gar keinen passenden Farbton, dann nimmt man zumindest eine andere Farbe mit möglichst passender Helligkeit.

    So richtig?

    Also hat man quasi schon so etwas wie eine Farben-Schablone zurechtgelegt, die in bestimmten Fällen dann zum Einsatz kommt und noch andere Faktoren mit berücksichtigt, als nur alleine das rein farblich passendste Austausch-Element.

    Wenn man in der Realität Menschen mit grünen/quittegelben Gesichtern begegneten, würde man sich wahrscheinlich Sorgen machen. In so einem Bild fällt es einem dagegen nicht einmal auf.

    Wenn ich zulange auf das Flackern mancher MUIFLI's schaue, wird mein Gesicht nach einigen Minuten aber auch grün und quitte-gelb. Vielleicht wurde das in MUFFLON gleich mit berücksichtigt, dieser Fakt. :D Man hat hier also weit vorausgedacht und könnte davon sprechen, dass man der Zukunft schon voraus war. 8o


    Interessante Bilder (NUFLI's) in den ganzen Einträgen von Bitte melde dich an, um diesen Link zu sehen. bis Bitte melde dich an, um diesen Link zu sehen.. Und ich habe auch noch was und zwar ein Bild, auf dass sich die Mischfarben-Palette sehr gut darauflegen lässt, ohne es gross zu verändern. Also wieder ein MUIFLI, mich fasziniert dieses Format einfach. :)

    Dieses 64 Farben Amiga-Bild hier, namens "Shattered Harmony".

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.


    Sieht im png-Screenshot, wenn man es sich unter der PEPTO Palette im Emulator ansieht, überragend aus, dieses MUIFLI und kaum schlechter als die Vorlage, siehe hier:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ich habe einmal verschiedene MUIFLI Versionen daraus erstellt. Hat man keinen Zusatzfilter in MUFFLON aktiviert, hat man ein paar wenige, leider etwas unpassende Blau-Töne mit im Bild, dafür flackert der mittige, helle Bereich des Bildes recht wenig. Das sind die Bilder v1 (ohne Rasterung/Dithering) und v2 (mit Rasterung) im Anhang.

    Hat man "different inks" aktiviert, behebt das nahezu alle störenden Farben, der Flacker-Faktor wird aber halt angehoben v3 (wieder ohne Rasterung/Dithering) und v4 (mit Rasterung und Zusatzfilter). Alles Files im Anhang direkt ausführbar und gepackt. Das Gute ist, in diesem Bild verstärkt das Rastern das Flackern kaum bis gar nicht, also dies hängt immer von der Vorlage ab, scheinbar. Ideal wäre hier natürlich, beides auf einmal haben zu können - "keinerlei Störfarben" und dennoch "kein Einsatz eines Zusatzfilters nötig, der das Flackern wieder etwas erhöht".

    Die beste Lösung wäre hier wohl, nur beim hellen, mittigen Bereich des Bildes (diesem weiter entfernten Hintergrund) den Kontrast oder die Helligkeit in der Bildvorlage etwas zu reduzieren, damit nur für diesen Bereich, dann etwas dunklere Farben genommen werden, wenn man die PEPTO Palette über die Bildvorlage legt. Denn die momentane Farbe, die für den Bereich verwendet wird, flackert halt etwas mehr und man könnte so auf eine andere ausweichen.

    Dann könnte man eventuell, muss ich aber noch testen ob es wirklich klappt, den "different inks" Filter einsetzen, ohne dass das Flackern in der Mitte des Bildes stärker zunimmt und man hätte beides im Ergebnisbild - keine Farbstörungen mehr und dennoch kein zu starkes Flackern in der Bildmitte. Man wäre dann, wenn es so klappt wie ich denke, etwa bei dem Flacker-Niveau, was das Bild ohne den Einsatz des "different inks" Zusatzfilters hat. Das wäre dann noch gut ansehbar am echten Commodore Monitor, finde ich.

  • Ich denke, man sollte die Leser hier nicht unterschätzen, die wissen schon, wie das gemeint war.

    Wir formulieren einfach zu unterschiedlich. Aber das ist ja nicht schlimm. ;)

    Aber du hast ja sicher auch einen C64 Emu am Start

    Nein, tatsächlich nie gehabt. oder benutzt.

    Alles Files im Anhang direkt ausführbar und gepackt.

    Könntest Du mir bitte "beibringen", wie man das macht? Ich benenne mangels Kenntnis bisher das NUF/MUI in PRG um und muss die ungepackten Files dann mit SYS12288 "starten".

    Zum Rest später mehr.

    mfg Tobias

  • Breite von 295 Pixel

    einen 25 Pixel breiten Streifen

    Du schneidest offenbar den FLI-Bug-Streifen weg. Die korrekten Werte dafür sind: 24 Pixel Breite (3 Kacheln) und 296 Pixel Bildbreite.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Breite von 295 Pixel

    einen 25 Pixel breiten Streifen

    Du schneidest offenbar den FLI-Bug-Streifen weg. Die korrekten Werte dafür sind: 24 Pixel Breite (3 Kacheln) und 296 Pixel Bildbreite.

    Arndt

    Ja, exakt. Somit gehen 200 wertvolle Pixel verloren. ;)

    einen 25 Pixel breiten Streifen im Bild mit drin hat, der nur zweifarbig oder einfarbig ist und dann einfach nicht schön wirkt.

    3x8 wie Arndt sagt. 296 bleiben übrig.

    Die Farbe im FLI Bug ist immer hellgrau. Man kann noch die Hintergrundfarbe wählen. Somit grundsätzlich zweifarbig.

    Durch das mögliche Interlace im MUIFLI kannst Du die beiden Farben mischen. Also max. drei Farben. Immer mit hellgrau und die Mischfarbe wird stark flackern, je nachdem, wie weit die gewählte Hintergrundfarben-Helligkeit vom hellgrau weg liegt.

    Im NUFLI kann man den FLI-Bug mit Sprites "übermalen", daher ist dieser für uns Konvertierer nicht sichtbar. Da das MUIFLI aus zwei Bildern zusammengesetzt wird, ist da nicht mehr genug "Power" für Sprites im FLI-Bug verfügbar.

    Die Rechte Char-Reihe (8x200 px) im NUFLI hat übrigens kein Sprite drunter. ("AFLI only")

    mfg Tobias

  • Mit welche Grauwerten arbeitet denn GoDot bei der Zuordnung?

    Siehe Bitte melde dich an, um diesen Link zu sehen..

    Laut den Werten ordnest Du mit den "HW-Grau" den Farben einen ziemlich linearen Helligkeitsverlauf zu. Wenn man die RGB-Werte der GoDot-Palette analyisert, kommen andere Helligkeitswerte heraus. Diese sind für die Farbpaare auf gleichen Helligekeitsstufen nochmal unterschiedlich.
    Bis auf bei den Graustufen gibt es in GoDot also drei verschiedenen Helligkeitswerte für ein und dieselbe Helligkeitsstufe. Diese 9 diskreten Helligkeitsstufen sind ja defacto am echten C64 mess- und sichtbar.

    Das verstehe ich nicht.:oob:

    mfg Tobias