Mehr Farben vom VIC-II

Es gibt 411 Antworten in diesem Thema, welches 52.394 mal aufgerufen wurde. Der letzte Beitrag (17. März 2022 um 20:52) ist von tilobyte.

  • Retrofan das Mufflon GUI war eigentlich (da entsprechend in Python geschrieben) Plattformunabhaengig.

    Ach guck mal, dann hätte ich Mufflon sogar nativ mit GUI laufen lassen können. Ich hatte die alte Version nur mal in einer Windows-VM gestartet.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    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. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Naja aber es ist doch die Aufgabe eines (Flach)fernsehers, ein PAL-Signal moeglichst originalgetreu wiederzugeben, und soweit ich das verstanden habe, machen selbst moderne Flachfernseher eine gewisse "Magic" um genau dieses Verhalten zu simulieren (also das Mischen zweier Farben), sonst wuerde ja keine solche Glotze mehr ein PAL-Signal vernuenftig darstellen.

    Das höre ich hier aber jetzt zum ersten Mal, dass Flachfernseher ein wirklich originalgetreues Rasterstrahlbild mit all seinen Nebenffekten erzeugen können.

    Gegenteiliges war doch eigentlich immer die Meinung und Thema, auch von dir (selbst in diesem Thread).

    Die Machart allein verhindert das ja schon, da könnte der Bildschirm intern so viel vor-"simulieren" wie er will.

  • Naja ich würde nie behaupten, dass ein Flachbildfernseher das CRT-Bild in all seinen Eigenheiten perfekt nachbildet, aber wenn dieses Farbmischen ein stückweit zum PAL-Standard dazugehört und damit Bildfehler unterdrückt werden, dann ist es doch nichts abwegiges, dass ein Flachbildfernseher das auch tut, denn schließlich ist es ja sein Job, mit PAL-Signalen umzugehen. Er muss ja z.B. auch de-interlacen, weil das PAL-Signal interlaced ist und ein Flachbildfernseher das Bild ja nicht per Rasterstrahl aufbaut, also muss er sich ja trotzdem darum kümmern, dass das Bild so auf dem TV erscheint, wie es gedacht ist, sonst würde man ja die typischen Kamm-Artefakte sehen. Und nach meinem Verständnis wird genau beim De-interlacen diese Mischfarbe erzeugt.

    Dass ein Flachbildfernseher das C64-Bild genauso gut darstellt wie eine echte Röhre habe ich jedoch nie behauptet und werde ich auch nie behaupten. Da hat die Röhre ganz klar die Nase vorn.

    - neue Spiele für den C64 -
    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.

  • Naja aber de-interlacen muss er doch auf jeden Fall?

    - neue Spiele für den C64 -
    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.

  • Naja aber de-interlacen muss er doch auf jeden Fall?

    Ja klar. Interlace hat man ja von Anfang an gemacht - also bevor man noch Farbe ins Signal dazugewurschtelt hat.

    AFAiK gab es noch vor NTSC so ein System mit rotierendem Farbfilter, ähnlich wie später DLP Beamer. Wenn da das Farbrad und der CRT nicht mehr synchron liefen, muss es auch lustige Farben gegeben haben. War aber wohl eh zu teuer und schwer.

  • Er muss ja z.B. auch de-interlacen, weil das PAL-Signal interlaced ist und ein Flachbildfernseher das Bild ja nicht per Rasterstrahl aufbaut, also muss er sich ja trotzdem darum kümmern, dass das Bild so auf dem TV erscheint, wie es gedacht ist, sonst würde man ja die typischen Kamm-Artefakte sehen.

    Das PAL-Signal zu dekodieren ist noch relativ einfach. Ich habe noch keinen PAL-fähigen Flachbildschirm gesehen, der damit Probleme gehabt hätte. Das Deinterlacen ist hingegen schon eine Wissenschaft für sich, und da trennt sich in der Tat die Spreu vom Weizen.

    Und nach meinem Verständnis wird genau beim De-interlacen diese Mischfarbe erzeugt.

    Zunächst mal sind das zwei von einander unabhängige Prozesse. Das sollten wir C64-Anwender eigentlich wissen, denn der VIC-II kann gar kein Interlace im Sinne des PAL-Standards (Zeilensprungverfahren). Wie das dann im jeweiligen Anzeigegerät implementiert ist, dürfte schon sehr unterschiedlich sein, denn viele Wege führen nach Rom. Und wie gesagt, nicht alle Wege haben die gleiche Qualität.

  • AFAiK gab es noch vor NTSC so ein System mit rotierendem Farbfilter, ähnlich wie später DLP Beamer. Wenn da das Farbrad und der CRT nicht mehr synchron liefen, muss es auch lustige Farben gegeben haben. War aber wohl eh zu teuer und schwer.

    Das nannte sich CBS-Farbsystem. So ein Farbfilterrad und geeigneter Motor macht sich wohl kaum im Gesamtgewicht eines Röhrenfernsehers bemerkbar, und die Synchronisierung wäre sicher nicht mehr Aufwand gewesen, als ein NTSC-Dekoder. Das große Problem, woran es gescheitert ist, war wohl eher die benötigte Bandbreite und die nicht vorhandene Abwärtskompatibilität. Dinge, die in einem DLP-Projektor keine Rolle spielen, weil es dort in einem geschlossenem System stattfindet, welches keine Norm berücksichtigen muß.

  • Naja dass nicht jeder Flachfernseher das evtl. gleich gut hinbekommt mag ja sein - aber es ging ja jetzt um das Argument, dass SEIN Fernseher ja ein Flachfernseher sei, und daher sei es unmoeglich, dass er hier PAL-Mixing verwendet, weil das ja nur auf CRTs ginge.

    - neue Spiele für den C64 -
    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.

  • Aber vermutlich wird das nur bei PAL HF und Composite Signalen gemacht. Bei YC oder YUV ist das wohl weniger sinnvoll.

    Auch bei YC braucht man einen Decoder für das modulierte Farbsignal. Bei YPbPr (was du vermutlich mit YUV meinst) werden die Farben nicht moduliert, also gibts da auch kein PAL oder NTSC was decodiert werden müsste.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.

  • erst schrieb er, es gäbe kein Programm dazu, und jetzt läuft da doch was im Hintergrund. Er ist Q, denke ich. 😉

  • Er schreibt auch, ja, es waeren abwechselnde Farben, aber im SUBPIXEL-Bereich... :huh:

    - neue Spiele für den C64 -
    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.

  • ok, er glaubt, er wäre Q.

    Jedenfalls warte ich mit Popcorn auf den Storytwist, wie bei dem "Car racing game" mit dem FMV aus der REU...

  • Naja das Car Racing "Game" ist halt ein Video mit 'nem Armaturenbrett unten dran... das ist an sich nix besonderes, ist aber halt auch kein Spiel, und wird auch nicht so leicht eins werden, auch wenn er sagt, "aber ich habe doch erst eine Woche dran gearbeitet!!1"

    - neue Spiele für den C64 -
    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.

  • Ich dachte früher immer, die bunten vertikalen Streifen z.B. in GeOS wären ein Interferenz-Effekt zwischen Bitmuster und Lochmaske des CRT. Ist dem also nicht so?

    Und gestern dachte ich erst, putzi wäre Jason himself. ;) Denn das hatten wir ja auch schon, dass sich diskutierte Personen hier anmelden und Stellung nehmen.

    .. nicht wahr, @franzi? Leg Dich wieder hin; ist nix passiert. :P

  • Und gestern dachte ich erst, putzi wäre Jason himself. ;) Denn das hatten wir ja auch schon, dass sich diskutierte Personen hier anmelden und Stellung nehmen.

    .. nicht wahr, @franzi? Leg Dich wieder hin; ist nix passiert. :P

    Ne, ich bin der hier: Bitte melde dich an, um diesen Link zu sehen. und der hier: Bitte melde dich an, um diesen Link zu sehen.

    :thumbsup:

  • Aber vermutlich wird das nur bei PAL HF und Composite Signalen gemacht. Bei YC oder YUV ist das wohl weniger sinnvoll.

    Auch bei YC braucht man einen Decoder für das modulierte Farbsignal.

    Klar muss man es weiterhin demodulieren, aber der Fehler wird viel geringer sein. Erstens weil es nicht erst vom Y rausgefiltert wird (also keine Artefakte durch Übersprechen von Y und C) und zweitens, weil S-Video ja nicht über lange Strecken - gar terrestrischer Funk - übertragen wird, sondern schlimmstenfalls über Kabel von 1-3m länge.

    Es ist ja kein Zwang, das C Signal mit der vorigen Zeile zu mitteln. Man muss nur die Richtung der Phase kennen und gegebenfalls flippen - und die Info steckt wohl pro Zeile im Colorburst.

    Laut Wikipedia (PAL) wird das Farbdekodieren in modernen, digitalen Decodern auch anders angegangen:

    Zitat

    Moderne (digitale) PAL-Decoder arbeiten wesentlich aufwändiger:

    Es werden vorherige und folgende Zeilen verrechnet, um Helligkeits- und Farbsignal besser zu trennen (2D-Kammfilter).

    Es werden vorherige und folgende Bilder verrechnet, um Helligkeits- und Farbsignal besser zu trennen (3D-Kammfilter).

    Es wird keine Mittlung von Zeilen zur Farbtonkorrektur verwendet, sondern auf Grundlage statistischer Größen eine Korrekturgröße für das Farbsignal berechnet.