kann GoDot nicht
Es gibt etwas, das GoDot NICHT kann??? ![]()
Es gibt 735 Antworten in diesem Thema, welches 81.085 mal aufgerufen wurde. Der letzte Beitrag (
kann GoDot nicht
Es gibt etwas, das GoDot NICHT kann??? ![]()
Trotzdem schadet ein Standard nicht.
Sage ich auch immer! Welchen schlägst du vor? Colodore? CoCo?
Arndt
Na, klar, sowas lässt mir keine Ruhe!
Bitte melde dich an, um diesen Anhang zu sehen.
Dies hier flimmert nicht mehr und die Grieselei ist auch weg.
Ja, das ist besser. Farbenmäßig gut und schön satt und es flimmert auch weniger. Bleibt einzig und alleine das Problem mit den weniger Details die ein IFLI hat, im Vergleich zum MUIFLI. Das sieht man einfach an verschiedenen Stellen im Bild.
Aber ich stelle mir gerade vor, wie es wäre, wenn Go-Dot MUIFLI könnte und man dann diese Farben dort in ein MUIFLI einbaut. Dann müsste das Ergebnis ja top sein.
Falls es so rübergekommen sein sollte: Es liegt mir fern, Deine Konvertierungen schlecht zu machen. Sie sind toll.
Rein künstlerisch finde auch ich sie stimmig. Aus technischer Sicht darf man aber sagen, dass es Farbänderungen zum Original gibt.
Passt schon, so hatte ich das auch nicht aufgefasst. Es ist ja auch so, dass die Paletten in einigen der Ergebnisbildern dann etwas anders aussehen, als beim Vorlagenbild, weil das eben auch nicht meine höchste Priorität beim Umwandeln ist, die Farben immer ganz genau wie bei der Vorlage hinzubekommen. Vor allem dann nicht, wenn diese Vorlage von einem viel stärkeren System mit mehr Farben kommt. Ich will dann lieber, dass es, mit den etwas anderen C64 Farben wieder stimmig ist und als Bild für sich wieder gut aussieht. Das ist meine Priorität beim Umwandeln, denn man kennt ja nicht immer die Vorlagen, die kennt man nur, weil ich sie immer mit poste. ![]()
Man kann manche Farben in den Vorlagenbilder, selbst mit zwei sich überlagernden Bildlayern als MUIFLI, nicht gut hinbekommen am C64. Bevor es dann so ist, dass ich zwar die Farben recht gut treffe, andere Stellen im Bild dann aber wieder flimmern oder komisch aussehen, verzichte ich dann lieber auf genau diese Farben und ersetze sie durch eine ähnlich, die aber auch passt, wenn man die Bildvorlage nicht kennt. Beides geht nämlich oftmals nicht also muss man sich entscheiden.
Einzig fragwürdig finde ich, dass man hier am PC C64 Screenshots mit unterschiedlichen RGB-Paletten miteinander vergleicht.
Ja, das ist klar und unbestritten, also bei den Ergebnis-Screenshots hier im Thread.
Deshalb hatte ich im vorigen Eintrage auch extra mal Bilder davon gemacht, wie die Konvertierungen unter verschiedenen Paletten in den Emulatoren dann so aussehen. Das könnte man noch mit viel mehr Paletten machen, alleine im Denise Emulator hat man ja eine Auswahl aus über 10 verschiedenen Farb-Paletten. Es kann sich aber auch jeder selbst die ganzen Bilder dann auf seinem System unter seiner Wunschpalette ansehen. Die sollte natürlich nicht weit vom echten System abweichen, sonst sieht ein Bild dort natürlich wieder ganz anders aus als im Emulator, was ja nicht sein sollte. Deshalb schaue ich mir meine konvertierten Bilder dann auch extra jedesmal immer vor dem Posten nochmal am echten Rechner samt Commodore-Monitor an.
Vielleicht hatte ich diesen Satz von dir hier
-----------
Ihr wisst aber schon, dass das Bildschirmkopien am/für den PC sind, die alle mit unterschiedlichen C64-Paletten abgespeichert wurden?""
-----------
auch anders verstanden als er gemeint war, denn ich habe ihn auf die Vorlagenbilder der anderen Retro-Systeme bezogen, die man beispielsweise auf der "Tomseditor.com" Seite findet. Denn diese ganzen Bilder der verschiedensten Retro-Systeme sind dort ja zwangsläufig auch schon in einer bestimmten Farbpalette abgespeichert worden damals. Es geht ja auch nicht anders, wie soll man sonst am PC an einen Screenshot eines anderen Systems kommen, der muss ja herübergeholt werden oder das System emuliert werden und dann sind ja immer irgendwelche Farbpaletten am Werk. Da kommt man ja nicht drum herum. Darum wunderte ich mich etwas über deine Aussage, die dann aber wohl anders gemeint war, wenn es sich auf die hier im Thread geposteten Ergebnis-Screenshots bezog.
Aber um nochmal auf die Bildvorlagen zu kommen. Wie schonmal erwähnt, ist es glücklicherweise so, daß die ganzen png-Screenshots auf der "Tomseditor.com" Seite schon recht passend von den Farben her sind. Wenn ich jetzt mal einen meiner echten Amigas nehme samt Amiga-Monitor dazu und das dann vergleiche, wie es dort aussieht im Vergleich zu den Amiga-Bilder Screenshots auf "Tomseditor.com", dann ist das schon gut getroffen und mein Amiga-Monitor ist auf normale Mittelwerte eingestellt, was jetzt Helligkeit, Sättigung, usw angeht. Daher denke ich, man kann diese Screenshots hier schon ganz gut als Vorlagen zum konvertieren hernehmen.
Deine Palette verwendet ja zum Glück auch keine Gamma-"Korrektur" wie bei Pepto und ist deshalb eben im wesentlichen einfach einiges heller.
Wie die entstand damals, hatte ich hier im Thread weiter vorne ja mal erwähnt. Das war mit einem an meine TV-Karte angesteckten, echten C64 usw. Dass sie ein bisschen zu hell ist, liegt daran, dass mein Monitor immer nur auf 16% Helligkeit läuft, um die Augen zu schonen. Bei mir passt sie deshalb genau. *lol*
Ja, nur, wie soll man es sonst machen? Wenn ich von einem Amiga Bild nun im WinUAE einen Screenshot machen würde, dann wäre es auch wieder "verfälscht", weil das dann eben eine WinUAE Farbpalette wäre. Somit hat man gar keine andere Möglichkeit, Bilder anderer Systeme aus einer Vorlage heraus zu konvertieren, die bereits in irgendeiner vorgegebenen Palette existiert.
Selbst wenn User sich solche Bilder zuhause auf ihrem echten Amiga ansehen, werden sie farbmäßig unterschiedlich sein, weil jeder einen anderen Monitor und dazu dann auch noch jeweils andere Monitor-Farbeinstellungen betreibt. Vergleiche ich allerdings die ganzen Amiga-Bilder Screenshots der "tomseditor.com" Seite mit dem, wie es bei mir am echten Amiga mit meinem Amiga Monitor aussieht, dann kommt das schon ganz gut hin.
Einfach mal auf EINE einheitliche "Anschau"-RGB-Palette für C64-Screenshots einigen.
Du meinst bei den Screenshots der bereits konvertierten Bilder hier im Thread, nehme ich an? Ja, da macht es Sinn. Ich hatte nur, wie schon im vorigen Absatz erwähnt, deinen Satz ganz anders verstanden gehabt (auf die Bildvorlagen bezogen) und das merkt man ja auch an der Antwort von mir hier, mit den Amiga Bildern. Da merkt man, was ich oben schon andeutete, dass wir in diesem Punkt etwas aneinander vorbeigeredet haben.
Denn was ich hier schrieb und du in dem Punkt von mir zitiert hast, bezog sich einzig und alleine auf die Vorlagenbilder, weil ich davon ausging, dass du die meinst, mit deiner Aussage "Ihr wisst aber schon, dass das Bildschirmkopien am/für den PC sind...", deshalb ja meine Antwort, wie man es denn sonst machen solle, weil ja jedes Vorlagenbild immer schon in einer bestimmten Palette lief, als dessen Screenshot gemacht wurde. Da haben wir einfach nur aneinander vorbeigeredet.
Die Signale des C64 lassen sich messen. Somit lasse ich es nicht zu, immer wieder die Ausrede zu bringen, jeder Monitor zeigt das eh anders, jeder Anweder stellt das anders ein. Das kann ja jeder machen, aber es gibt nunmal ein Art "die echten" C64 Farben. Und warum sollte man diese nicht als Referenz verwenden, um am PC ect. möglichst nah zu zeigen, wie das am C64 mit Monitor aussehen wird? Auch PC-Monitore streuen, der User kann mit der Fabrtemperatur die Farben total ändern, die Lichtbedigungen sind anders ect. Trotzdem schadet ein Standard nicht. Aktuell vergleicht man Auf MonitorX Falsch1 mit Falsch2. Mit nem Standard würde man mindestens mal Falsch3 mit Flasch3 vergleichen. Und nein: Pepto muss nicht dieser Standard sein.
Bin ich etwas anderer Meinung, zumindest falls du das jetzt nicht rein auf die Thematik "Screenshot der Ergebnisbilder hier im Thread" beziehen solltest.
Dass sich die Signale messen lassen ist unbestritten, genauso aber auch, das User schon immer bei sich ganz andere Werte eingestellt und bevorzugt haben. Das sind andere Thematiken. Auch sind wir uns einig, dass die Screenshots hier im Thread am besten in einer einheitlichen Palette sein sollten.
Wo ich aber anderer Meinung bin, das ist, das irgendwie mischen zu wollen mit der Thematik wie die "Konvertierung" selbst funktioniert. Denn das passt dann nicht zum Thema "Konvertierungen von Bildern anderer Retro-Systeme zu C64-Bildern", wie ich finde, sondern ist eine generelle Aussage zur Messbarkeit der C64 Farben oder eben auch, wie man Screenshots hier am besten machen soll.
Hier im Thread geht es um Vorlagenbilder ganz anderer Systeme, etwa Amiga Bilder, die nie in irgendeiner C64-Farbpalette vorher existiert haben. Nun steht man bei einer Konvertierung solch eines Bildes vor der Aufgabe, es in ein Bild eines Systems mit viel weniger Farben umwandeln zu müssen. Was soll einem da irgendeine Referenzpalette bei der Konvertierung nutzen, wenn der C64 eben manche Amiga-Farben nicht richtig hinbekommt, selbst dann nicht, wenn sich zwei Bildlayer überlagern (MUIFLI, IFLI) und man dadurch noch ein paar Vorteile hat? Manche Farben lassen sich, da kann man machen was man will, nicht gut 1-zu-1 in ein C64 Bild übertragen. Das merke ich immer wieder bei den Umwandlungen.
Hier ist dann viel mehr das Augenmaß des Konvertierers gefragt und die Art der Wahl des besten Gesamteindruck-Kompromisses im Ergebnisbild, meiner Meinung nach, und weniger das sture Festhalten an bestimmte Referenz-Paletten am C64.
Ich nenne mal ein Beispiel. Weiter vorne schriebst du das hier:
Ich reduziere die Farben schon im Photoshop mit einer "richtigen" Palette. Diese ersetze ich dann durch eine, die Mufflon lkennt. Somit verhunst Mufflon 1.0 die Farben nicht mehr, sondern muss sich nur noch im die Clashes kümmern.
Das habe ich jetzt mal explizit mit dem "The brightest light comes from the darkest place" Amiga Bild ausprobiert. Und zwar gleich auf zwei Arten.
- ich nahm dieses 32 Farben Amiga-Bild und reduzierte es in "Paint Shop Pro" auf 16 Farben, indem ich es mit dieser Farbanzahl neu berechnen ließ. dann legte ich mit dem Tool "BMP2PETLOGO" die PEPTO Palette noch über das Bild
- alternativ, weil es mir durch die Reduzierung auf 16 Farben nicht mehr wirklich gefiel, legte ich auch direkt die PEPTO Palette mal noch über das 32 Farben Amiga-Bild. Dieses Ergebnis sah dann zunächst auch gut und sehr farbähnlich dem Original aus
Dann probierte ich beide Bilder in MUFFLON aus und wollte sie in MUIFLI's umwandeln und hier kam dann die böse Überraschung. Durch die beiden sich überlagernden Bildlayer des MUIFLI Formats, brachte es dann so gut wie rein gar nichts mehr, vorher das Bild schon in PEPTO umgewandelt zu haben. Im NUFLI Format, wo es ja nur ein Bildlayer gibt, schon eher, aber bei MUIFLI so gut wie gar nichts. Das Ergebnisbild sah einfach immer nur mäßig aus, egal was ich auch versuchte in MUFFLON mit dieser Bildvorlage. Die beiden Layer erzeugen aus den PEPTO Farben des Vorlagenbildes hier dann wieder einige andere Farbmuster (selbst wenn ich die Einstellung PEPTO in MUFFLON nahm) und ich bekam es auf diese Art nichtmal annähernd so gut hin, wie bei demjenigen "The brightest light comes from the darkest place" Bild, welches ich weiter vorne gepostet habe. Zwar waren die Hintergrundfarben schon näher am Originalbild dran, aber der Rest sah einfach nur schlecht aus im konvertieren C64 Bild, vor allem die Frau im Vordergrund.
Daher mein Vorschlag. Du kannst ja aus diesem "The brightest light comes from the darkest place" Amiga Vorlagenbild auch mal eine C64-Konvertierung erstellen und die dann hier posten. Interessant wird sein, ob die dann beiden Ansprüchen gerecht wird, nämlich:
- eine gute Farbtreue zum Amiga Vorlagenbild zu halten
und gleichzeitig
- keine größeren anderen Schwachstellen mit im Bild zu haben, in denen es aussieht, als würden entweder Farben fehlen, Farb-Verschmierungen vorhanden sein, die Helligkeit nicht passen oder als würde es Flimmern in einigen Stellen
Denn meiner Meinung nach ist das kaum möglich. Es geht bei einigen Vorlagenbildern immer nur eines von beiden und dies ist solch ein Vorlagenbild.
Probier das mal aus und poste dein Ergebnis dann als ausführbares prg-File, damit man einmal einen Ergebnis-Vergleich hat. Sonst schreibt man sich in der Theorie tot, aber was zählt sind ja die Bildresultate. Also poste einfach mal eines von diesem Bild.
Lila ist sowieso immer diejenige Farbe in MUFFLON zu der das Programm immer mal wieder hin tendiert, habe ich bemerkt.
Das ist auch mein Eindruck. Ob es an Palette, Farbraum oder Algorithmus liegt, kann ich nicht beurteilen.
Das ist wohl scheinbar ein "Problem" der "True Color" Funktion in MUFFLON. Wenn man direkt über DEEKAY oder PEPTO geht, passiert das nicht in dieser ausgeprägten Form mit diesem LILA. Aber dann hat man halt keine weiteren Einstellungsmöglichkeiten mehr in MUFFLON und wenn dann direkt bei DEEKAY oder PEPTO was nicht passt im Ergebnisbild, dann muss man immer in der Bildvorlage bestimmte Stellen verändern und das kostet oftmals viel Zeit.
Hätte man in MUFFLON die beiden Einstellungs-Slider auch direkt bei DEEKAY und PEPTO, dann wäre das super.
Hatte ich angeleiert, leider bisher nur mit mäßigem Zwischenerfolg. Die "Erfinder" bzw. Nutzer sind wohl eher auf anderen Platformen unterwegs und sehen daher keine persönliche Notwendigkeit für eine Windows Version.
Schade. Und das Tool ohne GUI zu benutzen wird halt nervig sein, weil man ja auch die Previews der Bilder dann nirgends sieht. Dann kann man ein Bild 50mal umwandeln, um endlich mal ein annähernd gutes Ergebnis zu erzielen, ohne die Previews. ![]()
Alles anzeigenFotos von Bildschirmen sind problematisch bzgl. Weißabgleich und Kontrast. Und hier kommt nochmal zusätzlich das Interlacing hinzu.
Trotzdem hänge ich mal was an. Vielleicht versteht man ja dann besser, was ich mit der Gesichtsfarbe bei GoDot meine.
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
Das MUIFLI kommt aber recht gut rüber, finde ich. Auch von den Gesichtsfarben her. So war es auch auf meinem Commodore Monitor im Vorab-Test.
Es weicht farbmäßig auch nicht viel ab, vom Screenshot des Threads und es ist am TV fast noch etwas heller als meine AW1 Palette, von der ja dieser Screenshot stammt. Da sieht man, dass meine Farbpalette, die durch den am PC angesteckten C64er entstand, nicht schlecht ist.
Beim IFLI wirkt es bei den Gesichtsfarben so, als wären zuviele verlorengegangen, was aber wohl eher ein Problem vom IFLI Format sein wird, als eines von Go-Dot, vermute ich jetzt mal.
Was man hier natürlich nicht vergessen darf und es wurde ja schon angesprochen mit dem Interlacing. Dieses Foto hier, kann von den beiden Bildlayern des MUIFLI und des IFLI, ja nur eines zeigen, denn die sind ja nie zugleich sichtbar, wenn man fotografiert, sondern ja zeitlich versetzt. Das ändert dann natürlich auch die Farben wieder etwas, deshalb sieht man beim MUIFLI im Hintergrund auch diese helleren Punkte jetzt stärker am TV. Man müsste eigentlich zwei Fotos machen, von jedem Bildlayer eines und die dann wieder überblenden. In den Screenshots habe ich das ja auch immer so gemacht. Aber dann bräuchte man einen Fotoständer und die Kamera dürfte um keinen Millimeter verrutschen usw, also ziemlicher Aufwand wieder.
ein wenig einzulesen in all die GoDot Dokumente aber über die PRG Erstellung habe ich dort nichts gelesen
Du meinst wahrscheinlich das Erzeugen von Bildern, die mitsamt einer Anzeigeroutine abgespeichert werden und einfach per RUN gezeigt werden können? Die gibt es natürlich (wie oben schon erwähnt): für IFLIs ist das der Saver Bitte melde dich an, um diesen Link zu sehen., für Standardbilder ist das der Saver Bitte melde dich an, um diesen Link zu sehen.. Für FLI oder AFLI hat GoDot keinen Saver, der eine Anzeigeroutine mitliefern würde, nur systemimmanente Player-Module (Bitte melde dich an, um diesen Link zu sehen. und Bitte melde dich an, um diesen Link zu sehen., brauchen eine REU). Für IFLI hab ich auch noch eine Bitte melde dich an, um diesen Link zu sehen..
was zählt sind ja die Bildresultate
Ganz genauso seh ich das auch!
eher ein Problem vom IFLI Format sein wird, als eines von Go-Dot
Nein, ein Problem des unermüdlichen Ausprobierens mit GoDot. Ich hab nicht lang genug durchgehalten...
(Man sieht die Einstellungsergebisse nicht unmittelbar, man muss immer zwischendurch neu rendern und hinterher die Einstellungen dafür rekonstruieren bzw. kontrolliert erneuern. Manchmal gehen dadurch Zwischenergebnisse verloren, die dann wieder neu gebaut werden müssen. Mit einer REU kann man permanent drei Bilder im Speicher halten, die dann miteinander kombiniert werden können. Ohne REU wäre das eine Sisyphus-Arbeit.)
Arndt
Du meinst wahrscheinlich das Erzeugen von Bildern, die mitsamt einer Anzeigeroutine abgespeichert werden und einfach per RUN gezeigt werden können? Die gibt es natürlich (wie oben schon erwähnt): für IFLIs ist das der Saver XRay64, für Standardbilder ist das der Saver Autoplay. Für FLI oder AFLI hat GoDot keinen Saver, der eine Anzeigeroutine mitliefern würde, nur systemimmanente Player-Module (DisplayFLI und DisplayIFLI, brauchen eine REU). Für IFLI hab ich auch noch eine Standalone-Diashow.
Sorry für meine Ausdrucksweise, ich lerne noch ![]()
Danke für die Info ich hab gerade mal ein "Testsystem" mit 1581 und 1750 eingerichtet, mal gucken was dabei so rauskommt ![]()
eher ein Problem vom IFLI Format sein wird, als eines von Go-Dot
Nein, ein Problem des unermüdlichen Ausprobierens mit GoDot. Ich hab nicht lang genug durchgehalten...
Das kommt dann, wenn es so war, auch noch dazu. *lol* Ich hatte schon immer viel rumprobiert und an die zehn Bilder jedesmal immer erstellt und neun davon dann immer verworfen. ![]()
Dennoch hat Go-Dot hier in den Vergleichen zu MUFFLON zusätzlich aber einen Nachteil, für den es selbst gar nichts kann, finde ich. Nämlich dass hier IFLI's mit MUIFLI's verglichen werden, obwohl Letzteres ja schon wieder ein verbessertes Bild-Format ist, was mehr Möglichkeiten bietet.
Deshalb ist Go-Dot hier im Vergleich dann eigentlich unfair benachteiligt, wenn man es genau nimmt. Anders wird es sein, wenn auch Go-Dot das MUIFLI Format kann, da bin ich dann echt mal gespannt auf einen Bildervergleich.
Trotzdem schadet ein Standard nicht.
Sage ich auch immer! Welchen schlägst du vor? Colodore? CoCo?
PTOING wäre auch gut. Ist eine schöne Palette, finde ich. Siehe hier:
Bitte melde dich an, um diesen Anhang zu sehen.
PTOING wäre auch gut. Ist eine schöne Palette, finde ich
Ja, die kann GoDot auch. Und mir gefällt sie ebenfalls. 😊
Arndt
Klar.
Danke Dir. Im Anhang die "Screenshots".
Sage ich auch immer! Welchen schlägst du vor? Colodore? CoCo?
Ist in Arbeit. Es gab ja bereits in einem anderem Thread unzählige Messungen und Chip-Die-Shot-Analysen dazu. ![]()
Wir haben jetzt erstmal die VIC20-Palette fertig gemacht, da es dazu bisher nur wenig gab.
PTOING wäre auch gut. Ist eine schöne Palette, finde ich. Siehe hier:Bitte melde dich an, um diesen Anhang zu sehen.
Was ist das für ein Programm? Ich "sammle" ja Paletten.
In dieser Liste die am richtigsten ist mAn. die Christopher Jam.
Sieht schei*e aus!
Arndt
Da musst Du Dich bei Sony beschweren. ![]()
Der TV ist neutral eingestellt und ich würde sagen, es sieht aus wie man/ich es vom C64 kennt.
Das Foto der Screens entspricht farblich auch weitgehend meinem tatsächlichen Seheindruck. Dafür ist die weiße Wand orange. ![]()
Puh, viel Text mein Freund. ![]()
Du meinst bei den Screenshots der bereits konvertierten Bilder hier im Thread, nehme ich an? Ja, da macht es Sinn. Ich hatte nur, wie schon im vorigen Absatz erwähnt, deinen Satz ganz anders verstanden gehabt (auf die Bildvorlagen bezogen) und das merkt man ja auch an der Antwort von mir hier, mit den Amiga Bildern. Da merkt man, was ich oben schon andeutete, dass wir in diesem Punkt etwas aneinander vorbeigeredet haben.
Denn was ich hier schrieb und du in dem Punkt von mir zitiert hast, bezog sich einzig und alleine auf die Vorlagenbilder, weil ich davon ausging, dass du die meinst, mit deiner Aussage "Ihr wisst aber schon, dass das Bildschirmkopien am/für den PC sind...", deshalb ja meine Antwort, wie man es denn sonst machen solle, weil ja jedes Vorlagenbild immer schon in einer bestimmten Palette lief, als dessen Screenshot gemacht wurde. Da haben wir einfach nur aneinander vorbeigeredet.
Scheinbar haben wir das bzw. ich mich nicht klar ausgedrückt. Sorry. ![]()
Ja, ich meinte nur die verwendete "Anzeige"-Palette der schon umgewandelten C64 Bilder. Du speicherst RGB mit AW1 ab, Arndt mit GoDot. Dass die Bilder immer unterschiedlich aussehen, ist klar da nunmal die Farben (teils gravierend) anders sind. Am C64 haben beide Bilddateien dann wieder gleiche Farben. Das meinte ich mit der mangelnden Vergleichbarkeit.
Dass die Urpsrungsbilder ("Bildvorlagen") auch mit irgendeiner Palette abgespeichert wurden, ist klar und auchgut so. Das war nicht mein Thema.
Dass sich die Signale messen lassen ist unbestritten, genauso aber auch, das User schon immer bei sich ganz andere Werte eingestellt und bevorzugt haben. Das sind andere Thematiken. Auch sind wir uns einig, dass die Screenshots hier im Thread am besten in einer einheitlichen Palette sein sollten.
Wo ich aber anderer Meinung bin, das ist, das irgendwie mischen zu wollen mit der Thematik wie die "Konvertierung" selbst funktioniert. Denn das passt dann nicht zum Thema "Konvertierungen von Bildern anderer Retro-Systeme zu C64-Bildern", wie ich finde, sondern ist eine generelle Aussage zur Messbarkeit der C64 Farben oder eben auch, wie man Screenshots hier am besten machen soll.
Hier im Thread geht es um Vorlagenbilder ganz anderer Systeme, etwa Amiga Bilder, die nie in irgendeiner C64-Farbpalette vorher existiert haben. Nun steht man bei einer Konvertierung solch eines Bildes vor der Aufgabe, es in ein Bild eines Systems mit viel weniger Farben umwandeln zu müssen. Was soll einem da irgendeine Referenzpalette bei der Konvertierung nutzen, wenn der C64 eben manche Amiga-Farben nicht richtig hinbekommt, selbst dann nicht, wenn sich zwei Bildlayer überlagern (MUIFLI, IFLI) und man dadurch noch ein paar Vorteile hat? Manche Farben lassen sich, da kann man machen was man will, nicht gut 1-zu-1 in ein C64 Bild übertragen. Das merke ich immer wieder bei den Umwandlungen.
Hier ist dann viel mehr das Augenmaß des Konvertierers gefragt und die Art der Wahl des besten Gesamteindruck-Kompromisses im Ergebnisbild, meiner Meinung nach, und weniger das sture Festhalten an bestimmte Referenz-Paletten am C64.
Wir dürfen ja gerne unterschiedlicher Meinung seien. ![]()
Meine Motivation, mich mit der C64 Palette zu beschäftigen, fing vor gut 20 Jahren an. Ich kannte da noch kein Pepto oder ähnliches. Auslöser war das Programm ConGo. Damit konnte mWn. relativ früh am PC Grafiken für den C64 konvertieren. Nur sahen die umgewandelten Bilder am PC anders aus als am C64. Da fing ich an, eine eigene Palette durch vergleich zu erstellen und final ware die Ergebisse damit dann wesentlich stringenter.
Wie schon mehrmals gesagt, wenn ich die Farbumwandlung anhand der Referenz-Palette mache, muss das keine gute/stimmige Umwandlung werden. Nur sieht man dann sofort, wie es eben auch am C64 aussehen wird. Da sieht man auch gleich, dass verschieden Farben eben mit den begrenzten 16/136 Farben nicht darstellbar sind. GoDot ist durch seine Palette hierbei mMn. oft zu "optimistisch".
Ich wage aber mal unbewiesen die These, dass man mit dem richtigen Farbraum und Algorithmus mit der Referenzpalette ohne große Einstellerei und Nacharbeit das dem Original ähnlichste Ergebnis bekommen wird. Und das kann doch auch EIN Ziel der Konvertierung sein, oder?
DEIN Ziel ist ein möglichst stimmiges Gesamtergebnis, und das ist ja auch wichtiger.
Einigen wir uns darauf, dass man die zur Umrechnung herangezogene Palette wählen können sollte (besonders wenn in sRGB gerechnet wird und nicht in YUV).
Die zur Anzeige (am PC ect.) verwendete Palette sollte aber idealerweise standardisiert sein.
Im NUFLI Format, wo es ja nur ein Bildlayer gibt, schon eher, aber bei MUIFLI so gut wie gar nichts. Das Ergebnisbild sah einfach immer nur mäßig aus, egal was ich auch versuchte in MUFFLON mit dieser Bildvorlage.
Für MUIFLIs ein Bild mit einer 16 Farben-Palette vorzukonvertieren, ist sicher nicht sinnvoll. Dazu muss man eine Palette verwenden, die auch die möglichen/gewünschten Mischfarben eben jener Palette beinhaltet.
Ich hatte das mal für meine "Greyscale" Bilder gemacht, bei denen man die Sättigung rausdrehen muss. Also 9 Helligekeitsstufen und die 8 gemischten Zwischenstufen. Dafür hatte ich eine Palette mit den entsprechenden 17 Graustufen gemacht und das Bild damit reduziert. Die Palette des Bildes habe ich dann mit den 9 echten und 8 gemischten Farben ausgetauscht. Bei dieser "Farbpalette" hab ich Pepto genommen, weil Mufflon die "kennt". Ich hätte aber auch auf Basis von DeeKay machen können, Ergebnis wäre das gleiche gewesen.
Lange Rede, kurzer Sinn: Mufflon hat auch die Mischfarben erkannt und mit den richtigen Farbpaaren die MUIFLI kombiniert.
Daher mein Vorschlag. Du kannst ja aus diesem "The brightest light comes from the darkest place" Amiga Vorlagenbild auch mal eine C64-Konvertierung erstellen und die dann hier posten.
Welches ist das? Wie gesagt einen optimalen Prozess/Software habe ich für mich leider noch nicht gefunden.
Das MUIFLI kommt aber recht gut rüber, finde ich. Auch von den Gesichtsfarben her. So war es auch auf meinem Commodore Monitor im Vorab-Test.
Es weicht farbmäßig auch nicht viel ab, vom Screenshot des Threads und es ist am TV fast noch etwas heller als meine AW1 Palette, von der ja dieser Screenshot stammt. Da sieht man, dass meine Farbpalette, die durch den am PC angesteckten C64er entstand, nicht schlecht ist.
Beim IFLI wirkt es bei den Gesichtsfarben so, als wären zuviele verlorengegangen, was aber wohl eher ein Problem vom IFLI Format sein wird, als eines von Go-Dot, vermute ich jetzt mal.
Was man hier natürlich nicht vergessen darf und es wurde ja schon angesprochen mit dem Interlacing. Dieses Foto hier, kann von den beiden Bildlayern des MUIFLI und des IFLI, ja nur eines zeigen, denn die sind ja nie zugleich sichtbar, wenn man fotografiert, sondern ja zeitlich versetzt. Das ändert dann natürlich auch die Farben wieder etwas, deshalb sieht man beim MUIFLI im Hintergrund auch diese helleren Punkte jetzt stärker am TV. Man müsste eigentlich zwei Fotos machen, von jedem Bildlayer eines und die dann wieder überblenden. In den Screenshots habe ich das ja auch immer so gemacht. Aber dann bräuchte man einen Fotoständer und die Kamera dürfte um keinen Millimeter verrutschen usw, also ziemlicher Aufwand wieder.
Das MUIFLI lässt sich in der Tat seht gut fotografieren. Ich würde sagen, bis auf des fehlende Flimmern ist es dem wirklichen Seheindruck schon sehr nahe.
Beim IFLI klappt das nicht ganz so gut. Der Fabreindruck (bes. der Flächen) ist auf dem Foto schon so wie man es wahrnimmt, aber die Auflösung sieht etwas gröber aus als in echt.
Deshalb ist Go-Dot hier im Vergleich dann eigentlich unfair benachteiligt, wenn man es genau nimmt. Anders wird es sein, wenn auch Go-Dot das MUIFLI Format kann, da bin ich dann echt mal gespannt auf einen Bildervergleich.
Also zumindest bei mir dauert die Umwandlung in Mufflon mit einem nicht-museumsreifen PC schon teilweise realtiv lange, je nach Einstellung zu lange, weil ich da immer abbreche.
Da werden ja zig Kombinationen durchgegangen (brute force).
Ob das am C64 möglich ist, kann nur Arndt beurteilen.
Verdammter Pfeffer, geht das auch noch etwas schärfer?![]()
Ist ein super Bild
nur schärfer müsste es...
Bitte melde dich an, um diesen Anhang zu sehen.
Verdammter Pfeffer, geht das auch noch etwas schärfer?
Ist ein super Bild
nur schärfer müsste es...
Bitte melde dich an, um diesen Anhang zu sehen.
Du siehst doch in deinem Alter eh nix. Da macht das grobpixelige keinen Unterschied ![]()
Da musst Du Dich bei Sony beschweren.
GoDots Palette beruht auf einem (auf Mittelwerte gestellten) 1702…
Verdammter Pfeffer, geht das auch noch etwas schärfer?
Nein, das sind bei IFLI Multicolorpixel. Aber gib das Bild auf deinem 65“-Fernseher aus und stell dich sieben Meter weiter weg hin… ![]()
Arndt
Aber gib das Bild auf deinem 65“-Fernseher aus und stell dich sieben Meter weiter weg hin…
Hat bestens geklappt!! Haste noch so ein Bild?![]()
Haste noch so ein Bild?
Klar, aber ich will hier nicht gesperrt werden! 😇
Guck mal auf Bitte melde dich an, um diesen Link zu sehen. nach (ganz unten) und auf der Bitte melde dich an, um diesen Link zu sehen.…
Arndt ![]()
Guck mal auf dieser Seite nach (ganz unten) und auf der C64-Wiki-Seite von GoDot…
Ach du grüne Neune, ein einziges Sodom und Gomorra an Bildern.
Wahre Schlingel diese beiden Entwickler.![]()