Unscharf

Beim Blick zum Himmel dachte ich zuerst, ich hätte plötzlich was an den Augen. Hatte ich aber nicht, die Wolken waren wirklich so verwischt. Anders gesagt: Das ist nicht geschummelt, die Bilder sind gestochen scharf.

Autor: gnaddrig

Querbeet und ohne Gewähr

9 Kommentare zu „Unscharf“

  5. @ Yadgar:
    (20:22) Da hättste Dich fast verplappert, dabei darf das doch keiner wissen!
    (20:23) Natürlich, nur zu. Nur vielleicht nicth verminecraftisieren…

    Like

  6. O.k., los geht’s!

    Als erstes das untere Bild… in C 64-Blockgrafik, ohne Rasterung:

    Der C 64 hat 16 Farben, die Auflösung der Blockgrafik entspricht der Anzahl der auf einem C 64-Bildschirm darstellbaren Textzeichen, also 40 x 25 (hier tatsächlich 35 x 25, die Breite wird nicht voll ausgenutzt)… damit man hier überhaupt etwas erkennen kann, habe ich das Bild 16fach vergrößert.

    Derselbe Modus, diesmal mit Floyd-Steinberg-Rasterung:

    Der Einfachheit halber verwende ich für die Floyd-Steinberg-Rasterung die entsprechend Funktion in GIMP, obwohl ich sie inzwischen auch selbst in yip (Yadgar’s Image Processor) implementiert habe. Der Grund dafür ist, dass yip gegenwärtig nur (unkomprimierte) TGA-Bilder einlesen und speichern kann, mit denen WWW-Browser aber üblicherweise nichts anfangen können…

    Als nächstes der Multicolor-Modus des C 64, ohne…

    …und mit Floyd-Steinberg-Rasterung:

    Der Multicolor-Modus hat eine Auflösung von 160 x 200 Pixeln; daraus ergibt sich, dass die Pixel nicht quadratisch, sondern rechteckig sind. Eine weitere Besonderheit ist, dass trotz einer Gesamtzahl von 16 Farben in jedem 8 x 8 Pixel großen Bildbereich nur jeweils 4 Farben vorkommen dürfen. GIMP kann diese nachträgliche Korrektur nicht durchführen (es sei denn, mit einem Riesenaufwand an Scheme-Skriptprogrammierung – aber Scheme hat m. E. eine derart abstruse Syntax, dass mir der Aufwand, es selbst in C++ zu programmieren, geringer erschien als Scheme zu lernen!), in yip ist sie bis jetzt ebenfalls noch nicht implementiert. Beide Bilder wurden auf doppelte Größe skaliert.

    Allerdings kommen im ungerasterten Bild ohnehin nur insgesamt drei Farben vor, und auch bei der gerasterten Version dürften die 8 x 8-Bereiche mit hoher Wahrscheinlichkeit überall korrekt sein – es händisch zu überprüfen ist ziemlich zeitaufwendig, das dauert pro Bild an die zwei Stunden!

    Weiter geht es mit den Atari-ST-Modi: monochrom, 4 und 16 Farben. Im Prinzip (hardwareseitig so nicht vorgesehen und nur mit einem Trick in Maschinensprache realisierbar) gibt es auch noch einen Modus, der alle 512 erzeugbaren Farben in einem Bild ermöglicht – dies bleibt aber einer zukünftigen Implementierung mit yip vorbehalten, da mit GIMP erzeugte Paletten nur maximal 256 Farben enthalten können.

    512 Farben – das bedeutet rechnerisch, dass jeder der drei Farbkanäle (rot, grün, blau) nur 8 verschiedene Werte annehmen kann (8 hoch 3 = 512, bei RGB sind es pro Kanal bekanntlich 256 Werte), es sich also um eine Farbtiefe von 9 Bit (3 x 3 Bit) handelt. Unter der Annahme (!), dass sich diese Werte gleichmäßig über den Intensitätsbereich des analogen Bildsignals verteilen, ergeben sich damit die RGB-Bytewerte 0, 36, 72, 109, 145, 182, 218 und 255. Tatsächlich dürfte die Verteilung allerdings nicht derart linear sein, da der Atari ST sehr wahrscheinlich unterschiedliche Gamma-Werte für die einzelnen Farbkanäle verwendet, mehr dazu gleich.

    Der Monochrom-Modus des Atari ST (640 x 400 Pixel). ohne und mit Floyd-Steinberg-Rasterung:

    Jetzt wird es interessant, mit den beiden Multicolor-Modi (4 Farben bei 320 x 400 und 16 Farben bei 320 x 200 Pixel) des Atari ST: wenn ich als ersten Schritt mit GIMP eine 4- bzw. 16-farbige Palette erzeugen lasse und dann mit mtPaint (GIMP lässt das nächträgliche Verändern von Palettenfarben leider nicht zu) jedem Paletteneintrag die jeweils nächstliegenden der oben aufgelisteten Intensitätswerte zuweise, erhalte ich für manche Originalfarben regelmäßig zu niedrige Blau-, mitunger auch Grünwerte (siehe unten). Ich vermute daher, dass der Grafikchip des Atari ST für Grün und Blau einen höheren Gammawert als für Rot verwendet… das müsste ich einmal genau recherchieren und dann in der weiteren Programmierung von yip berücksichtigen.

    Das Originalbild auf 4 Farben optimiert, ohne Rasterung, noch ohne Anpassung an die 9-Bit-Werte:

    Die Pixel sind diesmal ebenfalls nicht quadratisch, sondern hochkant stehende Rechtecke.

    Die vier Paletteneinträge (von dunkel nach hell sortiert) haben die RGB-Werte:

    1. 5, 36, 74
    2. 47, 66, 89
    3. 103, 104, 105
    4. 141, 133, 123

    Ordne ich jedem einzelnen RGB-Farbwert den jeweils nächsten 9-Bit-Wert zu, ergibt sich folgendes Bild:

    1. 5, 36, 74 -> 0, 36, 72
    2. 47, 66, 89 -> 36, 72, 72
    3. 103, 104, 105 -> 109, 109, 109
    4. 141, 133, 123 -> 145, 145, 109

    Visuell sieht das dann so aus:

    Man erkennt sofort, dass die zweite und die vierte Farbe der Liste jetzt einen deutlichen Grün- bzw. Gelbstich haben, da die Blauwerte offensichtlich eine 9-bit-Stufe zu niedrig gewählt wurden… ein originalgetreueres Bild ergibt sich bei folgender, von der ursprünglichen Regel abweichenden Konvertierung:

    1. 5, 36, 74 -> 0, 36, 72
    2. 47, 66, 89 -> 36, 72, 109
    3. 103, 104, 105 -> 109, 109, 109
    4. 141, 133, 123 -> 145, 145, 145

    Das auf die gleiche Weise korrigierte Bild mit Floyd-Steinberg-Rasterung:

    Die Bilder im 4-Farben-Modus werden hier in Originalgröße dargestellt.

    Schließlich der 16-Farben-Modus, jetzt wieder 2-fach vergrößert, ohne Rasterung und mit Floyd-Steinberg-Rasterung:

    Die Originalfarben und ihre Konversionen:

    1. 0, 23, 58 -> 0, 36, 72
    2. 0, 29, 58 -> 0, 36, 72
    3. 0, 30, 68 -> 0, 36, 72
    4. 4, 39, 78 -> 0, 36, 72
    5. 9, 45, 86 -> 0, 36, 72
    6. 20, 45, 74 -> 36, 36, 72
    7. 15, 48, 82 -> 36, 36, 72
    8. 27, 47, 71 -> 36, 36, 72
    9. 34, 59, 87 -> 36, 72, 72
    10. 51, 72, 95 -> 36, 72, 109
    11. 65, 78, 91 -> 72, 72, 109
    12. 89, 94, 101 -> 72, 109, 109
    13. 100, 99, 97 -> 109, 109, 109
    14. 114, 113, 109 -> 109, 109, 109
    15. 137, 130, 120 -> 145, 145, 109
    16. 157, 147, 133 -> 145, 145, 145

    Bei diesem Bild habe ich die Farbverfälschungen zumeist nicht korrigiert – häufig musste ich mich nämlich zwischen verfälschter Farbe und faktischer Verringerung der Farbenanzahl (weil die einzelnen Originalfarben einander zu ähnlich waren, wie man z. B. bei den Paletteneinträgen 1 bis 5 gut sieht) entscheiden. Man erkennt ebenfalls, dass das Problem der mutmaßlich nicht passenden Gammawerte nicht unbedingt nur den Blaukanal betrifft – der Paletteneintrag 7 wäre regelgerecht eigentlich nach 0, 36, 72 zu konvertieren gewesen, was allerdings einen seltsamen Sprung in der Helligkeit ergeben hätte, eigentlich sollten die Jahren ja zum Zentrum der Zirruswolke hin immer heller werden. Ich entschied mich daher, den Rotwert eine Stufe höher zu setzen, wohl wissend, dass diese Variante auch nicht befriedigend ist. Die (regelgerechten) Paletteneinträge 9 und 12 zeigen wieder den bekannten Grünstich, während bei Paletteneintrag 11 der Rotwert zu hoch ist.

    Zum Schluss die ganze Prozedur ohne weitere Kommentare für gnaddrigs zweites Wolkenbild – C 64-multicolor-Versionen sind nicht 8×8-korrigiert, Atari ST-4- und -16-Farben-Modus mit regelgerechter Konvertierung:

    Bis bald im Khyberspace!

    Yadgar

    Gefällt 1 Person

  8. @gnaddrig:

    Ja, das kann man wohl sagen… das würde natürlich alles viel schneller gehen, wenn die entsprechenden Funktionen vollständig in yip enthalten wären (insbesondere auch das Laden und Speichern anderer Grafikformat als TGA)!

    Like

In den Wald hineinrufen

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden..