Kolophon

Kolophon – (Technische) Bild­bearbeitung

Kapitelinhalt:[  Überspringen ]

• Erstellen der Oszillo­gramme •
• Erstellen der Abbildungen •
• Verwendung von Wasser­zeichen

Nach der eher anschau­lichen Dar­stellung, wie einige der Artikel­vignetten entstanden sind, wird es jetzt deut­lich trockener und abstrakter – es geht um die Auf­bereitung von Oszillo­grammen (Screen­shots, Aus­schneiden, Um­färben, Klein­rechnen und Wasser­zeichen) sowie von Artikel­bildern und Illustrationen (Zeich­nungen vs. Screen­shots, Gut- und Schön­rastern, Klein­rechnen und Wasser­zeichen): 

nach oben

Erstellen der Oszillo­gramme

Kapitelinhalt:[  Überspringen ]

• Anforderungen •
• Programme und Abläufe •
• Screen­shots erstellen und Beschneiden •
• Invertieren und nicht Farbinvertieren •
• Skalieren und „Fett­rechnen“ •
• „Source­sets“ und Bilder­tabellen

Anforderungen

Es bestand der Wunsch, Reihen von Oszillo­grammen (Zeitfunktionen, Lissajous-Figuren, Spektren) tabellarisch dargestellt in die Seite einzubinden.  Das verwendete Oszilloskop-Programm, Christian Zeilitz' „Sound­card Oscilloscope“, ließ (zumindest in der Testversion) keinen Datenexport von Messwerten zu, so dass mit Screen­shots gearbeitet werden muss.  Für diese Screen­shots sind folgende Bearbeitungsschritte nötig: 

Sammeln und mit Namen versehen: 

Die Screen­shots werden mit dem Windows-Programm Irfanview gesammelt; dabei werden systematisch sinnvolle Dateinamen vergeben (die bspw. unter­schied­liche Stellgrößen und / oder Schaltungs­einstellungen be­inhalten und auf den Bildtyp – bspw. auf „_osc“ oder „_osc“ – enden).  Dieser Vorgang er­fordert Fleiß und ist bis jetzt nicht sinn­voll auto­ma­ti­sier­bar. 

Ausschneiden: 

Das Oszillo­gramm ist nur ein Teil des Screen­shots und muss ausgeschnitten werden.  Das händische Aus­schneiden ist eine ziem­liche Fummelei, deswegen sollte automatisiert aus­ge­schnitten werden.  Dazu sollten für jeden Monitor und jeden Typ des Programmfensters (Oszillo­gramm, Lissajous-Figur, Spektrum) die Koordinaten notiert und mit in eine ent­sprechende Konfigura­tions­datei eingetragen werden. 

Invertieren, aber nicht Farbinvertieren: 

Die Oszillo­gramme haben einen schwarzen Hinter­grund, was für eine Internetseite, insbesondere dann, wenn sie vielleicht ausgedruckt werden soll, ungünstig ist – die Bilder sollten invetiert werden.  Gleichzeitig sollen die Farben der Graphen (rot und grün) nicht zu den Kom­plemen­tär­farben Cyan und Magenta farb­invertiert werden. 

Verkleinern und „fett­rechnen“: 

Die Screen­shots müssen deut­lich verkleinert werden, ohne dass die relativ feinen Graphen zu dünn werden, soll heißen, die Graphen müssen irgend­wie „fett­gerechnet“ werden.  Das heißt, die Oszillo­gramme sollen im Browser (zum Beispiel in einem sogenannten Source­set) in mehreren Größen mit unter­schied­licher Detail­tiefe zur Ver­fügung stehen, abhängig vom Gebrauch (in der Übersicht oder in der Einzeldarstellung) und dem Gerät des Anwenders bzw. der Daten­verbindung. 

Wasser­zeichen, das nicht stört: 

In jedes Bild soll ein Wasser­zeichen ein­multipliziert werden, damit nicht Dritte an­geb­liche Ur­heber­rechte an den Bilder gelten machen können. 

nach oben

Programme und Abläufe

Die eigent­liche Bild­be­arbeitung erfolgte mit dem Kommando­zeilen­programm Image­Magick, das von einem Python-Script gesteuert wird; d. h. das Python-Script liest Konfigurations­dateien (meist *.json-Dateien) ein und erstellt Programm­aufrufe, die Image­Magick ausführt. 

nach oben

Screen­shots erstellen und Beschneiden

Für jede „Mess- und Testsession“, in der Screen­shots mit Oszillo­grammen aufgezeichnet wurden, wird eine Art Dateiliste mit verschiedenen Parametern geschrieben.  Diese müssen vom Anwender selbst gepflegt werden – hier müssen u. a. die Namen der Screen­shot-Dateien wie auch die Koordinaten für das Ausschneiden der eigent­lichen Oszillo­gramme eingetragen werden. 

Auswahl von Parameter in der Bilderliste der Screen­shots: 

Wunschgrößen für die kleineren Bilder

Wunschgrößen für die größeren, die kleineren und die Mini­bilder finden sich in den Parametern grosz_w und grosz_h, klein_w und klein_h sowie mini_w und mini_h. 

Bereiche _liss und _osc: 

Diese beiden Unterbereiche enthalten Screen­shots für Oszillo­gramme oder Lissajous-Figuren, welche unterschied­lich bearbeitet werden müssen (unter­schied­liche Koordinaten beim Ausschneiden aus dem Screen­shot, unter­schied­liche herein­montierte senkrechte vs. waagerechte Linien).  Jeder Bereich enthält: 

Parameter für das Ausschneiden: 

Das sind die Parameter x und y (Position der linken oberen Ecke des Ausschnittes) sowie w und h (Länge und Breite des Ausschnittes). 

Koordinaten für einen „Orientierungsbalken“: 

In den Oszillo­grammen kann eine fette waagerechte Linie (Signal gleich null) und in die Lissajous-Figuren eine fette senkrechte Linie (Eingangs­signal gleich null) eingezeichnet werden, die Parameter rect_x1, rect_x2, rect_y1 und rect_y2 sind die Koordinaten eines einzuzeichnenden Recht­ecks. 

Wasser­zeichen­dateien: 

Die zugehörigen Wasser­zeichen­dateien (die sich neben der Größe vor allem in der Farbe unterscheiden) werden in den Parametern grosz_WM, klein_WM und mini_WM angegeben. 

Bereich files: 

Enthält eine Liste der zu verarbeitenden Screen­shots. 

Das eigent­liche Beschneiden erfolgt dann durch Image­Magick – der letzt­end­liche Befehls­string könnte so aussehen (der Backslash steht für den hier eingefügten Zeilenumbruch) : 

C:\…\magick.exe quelle.gif \
  -crop 938x734+25+35 ausschnitt.gif

wobei ein Recht­eck der Größe 938 mal 734 Pixel, dessen linke obere Ecke bei den Koordinaten [25 ; 35] beginnt, ausgeschnitten wird. 

nach oben

Invertieren und nicht Farbinvertieren

Zum Verständnis dieses Programm­schrittes ist ein kleiner Blick in Farben­lehre notwendig – das mensch­liche Auge besitzt, grob gesagt, (Farb)­seh­zell­typen mit drei verschiedenen Empfind­lich­keiten; näm­lich mit Empfind­lich­keiten für Rot, für Grün und für Blau.  Die anderen Farben werden zunächst über die Reizung mehrerer Farb­seh­zell­typen wahrgenommen – wenn wir beispielsweise Gelb sehen, werden zugleich die Zellen für Rot und Grün gereizt, die Wahr­nehmung von weiß wiederum erfolgt nach Reizung aller verschiedenen Farb­seh­zell­typen. 

Daraus ergibt sich im Groben eine Art Farb­kreis zum Rechnen – Gelb kann, wie gesagt, als Addition von Rot und Grün verstanden werden, aber auch als Subtraktion von Weiß (Rot plus Grün plus Blau) abzüg­lich Blau.  Gelb wird dadurch zu einer Art „Minus-Blau“ bzw. ist die Komplementär­farbe von Blau.  Genauso wird Cyan zur Komplementär­farbe von Rot wie auch Magenta zur Komplementär­farbe von Grün: 

Im Farbkreis bilden sowohl Rot, Grün und Blau (die Grund­farben der additiven Farb­mischung – Misch­farben entstehen durch gemeinsames Auf­hellen von Schwarz) als auch Cyan, Magenta und Gelb (die Grund­farben der subtraktiven Farb­mischung – Misch­farben entstehen durch gemeinsames Ab­dunkeln von Weiß) jeweils ein Drei­eck, wobei sich Rot und Cyan, Grün und Magenta sowie Blau und Gelb paar­weise gegen­über­liegen. 

Wozu das Ganze?  Es ging darum, einen Rechen­vor­gang zu finden (den Image­Magick ausführen kann), mit dem bei der Invertierung der Hellig­keiten (schwarzer zu weißer Hinter­grund) nicht auch noch die Farbe invertiert wird. 

Ableitung des Verfahrens zu farbneutraleren Invertierung: 

Zum Verständnis des vor­gestellten Ver­fahrens ist es sinn­voll kurz zu er­läutern, wie in einem Bild­be­arbeitungs­programm wie Image­Magick eine in RGB definierte Farbe üb­licher­weise invertiert wird.  Es wird für jeden Farb­bestand­teil (Rot, Grün oder Blau) nur der Wert von 100 % abzüg­lich des alten Wertes berechnet  (In den folgenden Gleichungen steht P für ein Pixel sowie p_R, p_G und p_B für die Rot-, Grün- und Blauwerte dieses Pixels; jeweils zwischen null und eins): 

\( \begin{eqnarray} \left[ \begin{array}{c} p_{\textrm{neg,R}} \\ p_{\textrm{neg,G}} \\ p_{\textrm{neg,B}} \end{array} \right] & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} p_{\textrm{R}} \\ p_{\textrm{G}} \\ p_{\textrm{B}} \end{array} \right] \tag{1}\end{eqnarray} \)

Das heißt, aus einem „schwarzen“ Pixel würde ein weißes,

\( \begin{eqnarray} P_{\textrm{schwarz}} & = & \left[ \begin{array}{c} p_{\textrm{schwarz,R}} \\ p_{\textrm{schwarz,G}} \\ p_{\textrm{schwarz,B}} \end{array} \right] = \left[ \begin{array}{c} 0 \\ 0 \\ 0 \end{array} \right] \\~\\ P_{\textrm{schwarz,neg}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} p_{\textrm{schwarz,R}} \\ p_{\textrm{schwarz,G}} \\ p_{\textrm{schwarz,B}} \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] = P_{\textrm{weiß}} \tag{2}\end{eqnarray} \)

aus einem „weißen“ Pixel ein schwarzes und aus einem „rein­roten“ Pixel (p_R = 1 , p_G = 0 , p_B = 0) ein cyan­farbenes (p_R = 0 , p_G = 1 , p_B = 1)

\( \begin{eqnarray} P_{\textrm{rot}} & = & \left[ \begin{array}{c} p_{\textrm{rot,R}} \\ p_{\textrm{rot,G}} \\ p_{\textrm{rot,B}} \end{array} \right] = \left[ \begin{array}{c} 1 \\ 0 \\ 0 \end{array} \right] \\~\\ P_{\textrm{rot,neg}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} p_{\textrm{rot,R}} \\ p_{\textrm{rot,G}} \\ p_{\textrm{rot,B}} \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 1 \\ 0 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 0 \\ 1 \\ 1 \end{array} \right] = P_{\textrm{cyan}} \tag{3}\end{eqnarray} \)

sowie aus einem „knall­grünen“ Pixel (p_R = 0 , p_G = 1 , p_B = 0) ein magenta­farbenes (p_R = 1 , p_G = 0 , p_B = 1)

\( \begin{eqnarray} P_{\textrm{grün}} & = & \left[ \begin{array}{c} p_{\textrm{grün,R}} \\ p_{\textrm{grün,G}} \\ p_{\textrm{grün,B}} \end{array} \right] = \left[ \begin{array}{c} 0 \\ 1 \\ 0 \end{array} \right] \\~\\ P_{\textrm{grün,neg}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} p_{\textrm{grün,R}} \\ p_{\textrm{grün,G}} \\ p_{\textrm{grün,B}} \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 \\ 1 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 0 \\ 1 \end{array} \right] = P_{\textrm{magenta}} \tag{4}\end{eqnarray} \)

Es wird also nicht nur Schwarz zu weiß, sondern auch jede „echte Farbe“ farb­invertiert, d. h. durch ihre Komplementär­farbe ersetzt.  Wenn man jetzt eine derartige Farb­invertierung dadurch „verdoppelt“, man vor der eigent­lichen Invertierung „180° am Farb­kreis dreht“ (d. h. eine Farb­invertierung ohne Helligkeits­invertierung vollzieht), könnten die ursprüng­lichen Farben erhalten bleiben. 

Das kann, zumindest für die reinen additiven Grund­farben (Rot, Grün, und Blau) dadurch erreicht werden, dass sie in einer Vektor­multi­plikation des Farb­vektors mit einem speziellen Vektor durch ihre Komplementär­farben (d. h. durch eine Mischung der jeweils anderen beiden der drei additiven Grund­farben) ersetzt werden.  Das heißt, durch die Vektor­multiplikation wird Rot zu Cyan (Grün plus Blau), Grün zu Magenta (Rot plus Blau) und Blau zu Gelb (Rot plus Grün).  Und natür­lich bleibt Schwarz ([0 0 0]) nach Multiplikation auch noch Schwarz. 

Die Gesamt­operation (Invertieren ohne Farb­invertierung) sähe dann so aus: 

\( \begin{eqnarray} P_{\textrm{neg,180°}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{array} \right] \cdot{} \left[ \begin{array}{c} p_{\textrm{R}} \\ p_{\textrm{G}} \\ p_{\textrm{B}} \end{array} \right] \tag{5}\end{eqnarray} \)

Ein schwarzes Pixel würde ein schwarzes Pixel bleiben,

\( \begin{eqnarray} P_{\textrm{schwarz,neg,180°}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{array} \right] \cdot{} \left[ \begin{array}{c} 0 \\ 0 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 \\ 0 \\ 0 \end{array} \right] = \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] = P_{\textrm{weiß}} \tag{6}\end{eqnarray} \)

ein „knall­grünes“ Pixel bliebe ein „knall­grünes“ Pixel 

\( \begin{eqnarray} P_{\textrm{grün,neg,180°}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{array} \right] \cdot{} \left[ \begin{array}{c} 0 \\ 1 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 1 \\ 0 \\ 1 \end{array} \right] = \left[ \begin{array}{c} 0 \\ 1 \\ 0 \end{array} \right] = P_{\textrm{grün}} \tag{7}\end{eqnarray} \)

und ein „rein­rotes“ Pixel ebenfalls ein „rein­rotes“: 

\( \begin{eqnarray} P_{\textrm{rot,neg,180°}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{array} \right] \cdot{} \left[ \begin{array}{c} 1 \\ 0 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 \\ 1 \\ 1 \end{array} \right] = \left[ \begin{array}{c} 1 \\ 0 \\ 0 \end{array} \right] = P_{\textrm{rot}} \tag{8}\end{eqnarray} \)

Für gesättigte Misch­farben wie Gelb (die Lissajous-Figuren im verwendeten Oszilloskop-Programm sind u. U. gelb) funk­tio­niert das Verfahren aufgrund der „Übersteuerung“ eher nicht.  Das liegt daran, dass Image­Magick nicht „über­steuerungs­fest“ ist – Farb­bestand­teile unter null und über eins bzw. über 100 % existieren für das Programm nicht: 

\( \begin{eqnarray} P_{\textrm{gelb,neg,180°}} & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 & 1 & 1 \\ 1 & 0 & 1 \\ 1 & 1 & 0 \end{array} \right] \cdot{} \left[ \begin{array}{c} 1 \\ 1 \\ 0 \end{array} \right] \\~\\ & = & \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 1 \\ 1 \\ 2 \end{array} \right] = \left[ \begin{array}{c} 0 \\ 0 \\ -1 \end{array} \right] \\~\\ & ≙ & \left[ \begin{array}{c} 0 \\ 0 \\ 0 \end{array} \right] ≙ P_{\textrm{schwarz}} \tag{9}\end{eqnarray} \)

Das war oder ist aber aus Anwendungssicht kein großes Problem – die Lissajous­figuren, die (imScreenshot der Oszillo­gramm-Software) gelb auf schwarz sind, werden in der Invertierung nicht dunkelbraun, sondern schwarz und sind so noch von den grünen und roten Linien im Oszillo­gramm zu unter­scheiden. 

Nach dem grundlegenden Ansatz, wie die Screen­shots invertiert werden können, wurde noch herum­probiert und sowohl die Farb­rotations­matrix als auch das End­ergebnis skaliert – die folgende Gleichung 10 zeigt, was letzt­end­lich im Script umgesetzt wurde.  (Der zweite Skalier­ungs­vektor mit Faktor 1,2 kann in der oben beschriebenen Datei­liste für eine Serie von Screen­shots angepasst werden – Parameter negColMatr.) 

\( \begin{eqnarray} P_{\textrm{BG,wß}} & = & \left[ \begin{array}{c} 1{,}2 \\ 1{,}2 \\ 1{,}2 \end{array} \right] \cdot{} \left( \left[ \begin{array}{c} 1 \\ 1 \\ 1 \end{array} \right] - \left[ \begin{array}{c} 0 \!&\! 1{,}5 \!&\! 1{,}5 \\ 1{,}5 \!&\! 0 \!&\! 1{,}5 \\ 1{,}5 \!&\! 1{,}5 \!&\! 0 \end{array} \right] \cdot{} P_{\textrm{BG,sw}} \right)\!\! \tag{10}\end{eqnarray} \)

nach oben

Skalieren und „Fett­rechnen“

Für die Präsentation der Oszillo­gramme in Bilder­tabellen werden kleine und trotzdem aussage­kräftige „Bildchen“ der Oszillo­gramme gebraucht – die gewünschten Bild­breiten sind 462 Pixel für die mittlere Bildgröße und 318 Pixel für die Mini-Screen­shots. 

Da die Graphen in den Original-Screen­shots (Bild­breiten z. Z. knapp 800 Pixel) sehr fein sind (Breite etwa 1 Pixel), ist beim Herunter­skalieren damit zu rechnen, dass die Graphen bis zur Un­kennt­lich­keit verblassen.  Deswegen erschien es sinnvoll, die Graphen vor dem Herunter­skalieren zu ver­breitern. 

Da eine „richtige“ Faltung (Multiplikation jedes Pixels mit einer Fläche – z. B. in Form eines Pinsel­abdrucks) ziem­lich rechenintensiv sein kann, wurde auf eine eher rustikale Art der Faltung zurückgegriffen, die RGB-Werte jedes Pixel werden den Farbwerten seiner vier Nachbarn (Pixel oben, rechts, unten und links) aufmultipliziert; was im Grunde genommen der Faltung mit einem einfachen Pixel­kreuz entspricht. 

Das wird realisiert, indem das eigent­liche Oszillo­gramm fünfmal ausgeschnitten wird – einmal wie vorgesehen und noch weitere vier Mal mit jeweils einem Pixel Versatz in jede Richtung.  Diese fünf Bilder werden nun Eines nach dem Anderen miteinander multipliziert.  Danach sind die Graphen des Oszillo­gramms so breit, dass sich auch nach dem Herunterskalieren noch gut zu erkennen sind. 

Für stärkeres Herunterskalieren wird das „Fett­rechnen“ noch einmal gesteigert, jedes Pixel wird nicht nur mit seinen Nachbarpixeln, sondern auch mit denen, die zwei Pixel weit diagonal entfernt sind, multipliziert.  So sind dann auch die sehr kleinen Vorschaubilder (mit Breite 318 Pixel) gut zu erkennen. 

In Anschluss an das „Fett­rechnen“ werden die Oszillo­gramme proportional auf die Bild­breiten 664 Pixel, 462 Pixel und 318 Pixel herunter­gerechnet. 

nach oben

„Source­sets“ und Bilder­tabellen

Soviel zur Bild­auf­bereitung, nun zu den Gründen für den Bedarf an unterschiedlich großen Bilder und Bildchen – und zu Source­sets und Bilder­tabellen. 

Zum einen werden die Oszillo­gramme in den Bilder­tabellen als kleine Bildchen (hier 234 Pixel) und groß für die Detailansicht gebraucht.  Zum anderen bietet das „Source­set“-Attribut des <img />-Tags (zumindest im Firefox) die Mög­lich­keit, dem Browser mehrere Datei zum Download und zur Darstellung vorzuschlagen, so dass dieser sich die für die aktuelle Darstellungs­größe am besten geeignete Bild­datei selbst aussuchen kann. 

Dazu hier ein (verkürztes) Beispiel aus der Seite, zunächst nur der Aus­schnitt mit der eigent­lichen Einbindung der Bild­dateien: 

<a href="scrn/bild_grosz.gif" …>
  <img width="234"
      height="195"
         src="bild_klein.gif"
      srcset="bild_mini.gif  318w,
              bild_klein.gif 462w"
  />
</a>

Das <img />-Tag ist Teil eines Links, mit dem der Anwender die Darstellung des großen Bildes bild_grosz.gif erreichen kann. 

Innerhalb des <img />-Tags, in dem eine Bildgröße von 234 Pixel (bei Darstellungs­größe 100 %) vorgeschrieben wird, sollte der Browser Bild­datei bild_mini.gif (mit einer Breite von 318 Pixeln) verwenden.  Stellt der Anwender die Darstellungsgröße jedoch auf beispielsweise 150 %, so muss der Browser das Bild mit 351 Pixeln Breite darstellen und kann in diesem Source­set auch die Bilddatei bild_klein.gif (mit einer Breite von 462 Pixeln) verwenden, denn die kleinere Bild­datei bild_mini.gif (mit Bild­breite 318 Pixeln) müsste der Browser schon hochskalieren. 

Soweit zum Sinn des Source­sets; es folgt die Beschreibung der Anordnung in Bilder­tabellen.  Um die Erläuterungen plausibler zu machen, wird hier ein kleiner Ausschnitt einer Bilder­tabelle als Beispiel eingebunden: 

Bilder­tabelle 1: Signal­verläufe und Lissajous-Figuren, aufgezeichnet im Eingangs­kreis von Mess­schaltung D1:  (Zum Öffnen und Schließen hier klicken)

Oszillo­gramme
Mess­schaltung D.1: 
u_eing. und u_G

X-Y-Graphen
Mess­schaltung D.1: 
u_G vs. u_eing.

Eingangs­signal­spannung:  u_eing.,eff = 24 mV

u_eing. (grün): 10 mV / Div,
u_G (rot): 10 mV / Div 

u_eing. (hor.): 10 mV / Div,
u_G (vert.): 5 mV / Div 

Zu sehen ist also in einem <details>-Bereich (der auf- und zu­ge­klappt werden kann): 

• Ein Tabellen­kopf mit zwei Spalten­titeln,

• Eine doppelte Tabellen­zelle mit einer Überschrift über

• zwei einzelne Tabellenzellen, jeweils mit einem Oszillo­gramm und ergänzenden Informationen darunter. 

Die eigent­liche Bilder­tabelle ist in einen <details>-Tag (man kann den Bereich durch Maus­klick auf- und zu­klappen) eingeschlossen.  Dieser Tag enthält eine <summary> als Titel­zeile: 

<details class="bildertabelle" open="open">
  <summary id="details_D1_2"
        class="TableCaption">
    <span class="Title">Tabelle D1.2</span>: 
    Signal­verläufe …
    (<em>Zum Öffnen und Schließen … </em>)
  </summary>

  <!-- die eigent­liche Bilder­tabelle … -->

</details>

Für die eigent­liche Bilder­tabelle wurde auf das Bootstrap-Frameworks zu­rück­ge­griffen – eine Konstruktion von Reihen gleich­breiter Recht­ecke in einem Raster von zwölf gleich­breiten Feldern – es werden also in jeder Tabellen­zeile zwei Tabellen­zellen mit einer Breite von je sechs Raster­feldern deklariert.  Im Bilder­tabellen­kopf sieht das so aus: 

<div class="bildertabelle"
     id="bildtab_0815_D1_2">

  <!-- Kopf Bilder­tabelle Tabellenzeile -->
  <div class="row">

    <!-- Bilder­tabellenzelle links -->
    <div class="zweizellenheadline col0
                                   col-sm-6
                                   col-md-6
                                   col-lg-6">
      <strong>Oszillo­gramme <br />
        Mess­schaltung D.1 – <br />
        <em>u</em><sub>eing.</sub> und
        <em>u</em><sub>G</sub>
        </strong>
    </div>
    <!-- Bilder­tabellenzelle rechts -->
      …
  </div>
</div>

Die Klasse „row“ setzt den Inhalt des Divs in eine neue Box mit Satz­spiegel­breite und die Klassen „col-sm-6“, „col-md-6“ und „col-lg-6“ die enthaltenen Boxen (d. h. Bilder­tabellen­zellen) auf die Breite von sechs Raster­feldern, und zwar in Darstellungs­modus „small“, „medium“ und „large“. 

Soweit zum Kopf der Bilder­tabelle.  Für jeweils zwei Oszillo­skopen-Bilder (ein Oszillo­gramm und eine Lissajous-Figur) wird in der Bilder­tabelle eine Doppel­zeile vorgesehen, wobei in der oberen Bilder­tabellen­zeile In­form­ationen enthalten sind, die beide Bilder in der unteren Bilder­tabellen­zeile betreffen (im konkreten Fall die Eingangs­signal­spannung): 

<div class="doublerow">

  <!-- Doppelzelle Bilderueberschrift -->
  <div class="row">
    <div class="col1 FullWdthTitle">
      <strong>Eingangs­signal­spannung:
        <em>u</em><sub>eing.,eff</sub> = 24 mV
      </strong>
    </div>
  </div>
  
  <!-- Zwei Tabellenzellen mit Bildern -->
  <div class="row">
    …
  </div>

</div>

Die untere Bilder­tabellen­zelle enthält, wie gesagt, die beiden Oszillo­gramme (als Minibilder wie als Links zu größeren Bildern) zuzüg­lich einiger Informationen: 

<!-- Zwei Tabellenzellen mit Bildern -->
<div class="row">
  
  <!--  Bilder­tabellenzelle  -->
  <div class="col1
              col-sm-6
              col-md-6
              col-lg-6">
    
    <!--  Link zum Großbild  -->
    <a href="scrn/bild_grosz.gif"
   data-lightbox="SWscopescreenshots"
      data-title="Oszillo­gramm 1
                  von Tabelle D1.2
          <br />u_{eing.} (grün): 10 mV / Div
          <br />u_G       (rot):  10 mV / Div">
      
      <!--  Dargestelltes Kleinbild  -->
      <img width="234"
          height="195"
             src="scrn/bild_klein.gif"
          srcset="scrn/bild_mini.gif  318w,
                  scrn/bild_klein.gif 462w"
           class="OsziTabMiniBild"
             alt="Oszillo­gramm"
       />
    </a>
    
    <!--  Minicaption unter dem Bild  -->
    <span class="minicaption">
      <em>u</em><sub>eing.</sub> (<em>grün</em>):
        10 mV / <span lang="en">Div</span>,
          <br />
      <em>u</em><sub>G</sub> (<em>rot</em>):
        10 mV / <span lang="en">Div</span>
    </span>
  </div>
  
  <!-- zweite Bilder­tabellenzelle -->
  …
</div>

Im Link zum größeren Bild enthalten sind zwei Parameter, die vom Javascript-Plugin Light­box genutzt werden – „data-lightbox“ und „data-title“.  Light­box stellt die angeklickten Bilder in einem Popup groß dar und ermög­licht es, sich vor- oder rückwärts zwischen den großen Bildern zu bewegen. 

Der Inhalt des Parameters „data-lightbox“ dient dabei als gemeinsames Label für mehrere Bilder, zwischen denen in der vergrößerten Dar­stellung ge­wechselt werden kann, während der Inhalt des Parameters „data-title“ die Text­in­form­ationen unter die vergrößerten Dar­stellung des Bildes platziert wird. 

Die „Mini­caption“ wiederum liegt in der Bilder­tabelle unter dem (kleinen) Bild. 

nach oben

Erstellen der Abbildungen

Kapitelinhalt:[  Überspringen ]

• Größen­vorgaben •
• Programmtechnische Umsetzung •
• Das Rasterproblem •
• Bildgestaltung •
• Arbeiten mit Gradations­kurven

Größen­vorgaben

Nach den in CSS-Bilder­tabellen zusammengefassten Oszillo­grammen nun die „normalen“ Abbildungen und Illustrationen. 

Worum geht es?  Um die Aufbereitung von Grafiken, Schalt­plänen, Dia­grammen, die dem Browser in einem sogenannten Source­set in mehreren Darstellungsgrößen zur Verfügung gestellt werden.  Außerdem um die Mög­lich­keit, auf Satzspiegelbreite skalierte Abbildungen nach Anklicken in größerer Darstellung sehen zu können (Um­setzung über das Light­box-Plugin). 

Für die Breite der Bilder gab es dadurch mehrere Vorgaben: 

• 960 Pixel als (ältere) Vorgabe für große Bilder (für eine Fensterbreite von mindestens 1024 Pixel),

• 318 Pixel als kleinste Vorgabe für kleine Telefone (mit 320 Pixel) Fensterbreite,

• Eine Bild­breite, die mehrere zehn Prozent größer ist als der Satz­spiegel, damit der Browser beim Herunter­skalieren / Anpassen der Bild­breite noch etwas „Luft“ hat.  Bei einer Satz­spiegel­breite von 36 em und einer Standard­schrift­größe von 14 px ergibt sich hier eine Bild­breite zwischen 600 px und 700 px. 

Daraus ergeben sich – bei einer geometrischen Reihe – vier sinnvolle Bild­breiten: 

Breite 318 Pixel – Suffix „_mini“

Für kleine Bilder auf kleinen Telefonen,

Breite 460 Pixel – Suffix „_klein“

Zwischenbreite, 45 % Prozent breiter als „_mini“;

Breite 664 Pixel – Suffix „_mitte“

Zwischenbreite, 45 % Prozent breiter als „_klein“;

Breite 700 Pixel – Suffix ebenfalls „_mitte“

Für Datenblattauszüge, 

Breite 960 Pixel – Suffix „_grosz“

Standard­breite, 45 % Prozent breiter als „_mitte“.  Für die in der Bildansicht verlinkten großen Bilder, sowie 

Später kamen noch zwei weitere Größen dazu: 

Breite 192 Pixel – Suffix „_icon“

Für die Teaser­bildchen; z. B. in der index.html

Breite größer als 960 Pixel – Suffix „_riesig“

Für Bilder, die größer als 960 Pixel sein müssen, weil sonst Details verlorengingen. 

Die vier erst­genannten Größen werden Firefox im Source­set-Attribut des <img />-Tags angeboten, so dass sich der Browser die kleinste passende Bild­datei für die berechnete Bilderbreite aussuchen kann: 

<img alt="EXCEL-Diagramm"
   width="480"
  height="310"
     src="bilder/GIFbild_244_grosz.gif"
  srcset="bilder/GIFbild_244_mini.gif  318w,
          bilder/GIFbild_244_klein.gif 460w,
          bilder/GIFbild_244_mitte.gif 664w,
          bilder/GIFbild_244_grosz.gif 960w"
   title="Zum Vergrößern klicken" />

Für JPEG-komprimierte Bilder wurde die Zahl der unter­schied­lichen Auf­lösungen kleiner gehalten – hier sind kleinere Bilder nicht unbedingt kleinere Dateien, so dass es auch nicht sinn­voll ist, jede Bild­breite an­zu­bieten. 

nach oben

Programmtechnische Umsetzung

Die unter­schied­lichen Bild­größen werden auch hier über ein Python-Script, das dann Image­Magick aufruft, erzeugt.  Dabei werden außerdem noch Wasser­zeichen ein­multipliziert.  Die Be­schreibung der unter­schied­lichen Wasser­zeichen, -größen und -farben findet sich weiter unten. 

Das Python-Script wird im Wesent­lichen über zwei Konfigurations­dateien gesteuert – eine Liste aller Bilder (__bilderliste.json) sowie eine Konfigurations­datei __bildersettings.json. 

In der Datei (__bilderliste.json) – eine große Tabelle, werden die Einstellungen für jede Quell­bild­datei hinterlegt (im Folgenden die Spalten / Einstellungen für eine Datei): 

{"job":        "skal"   /* Skalieren|Kopieren */
,"wm":         "STD"    /* Welches Wasserzeichen */
,"transpFrom": "grayF4" /* Hintergr. Quellbild */
,"transpTo":   "grayF4" /* Transparenz Zielbild */
,"sz":         "grosz"  /* Groesze Quellbild */
,"minSz":      "mini"   /* Runterskalieren bis */
,"name":       "r-dose_schem"
,"ext":        "gif"
,"w":          960
,"h":          282 }

Der Parameter „sz“ dient auch als Datei­namen­suffix für die Quell­bild­datei; er muss mit Unter­strich an den eigent­lichen Datei­namen angehängt werden. 

In der Konfigurations­datei __bildersettings.json werden verschiedene Einstellungen festgelegt, zunächst die Einstellungen für die zu erstellenden Source­set-Bilder – jeweils für *.gif- und *.jpg-Dateien: 

… "srcset":
{"jpg":
 {"icon"  :["icon",""   ,""     ,""     ,""      ,""]
 ,"mini"  :[""    ,"mini",""     ,""     ,""     ,""]
 ,"klein" :[""    ,""    ,"klein",""     ,""     ,""]
 ,"mitte" :[""    ,"mini",""     ,"mitte",""     ,""]
 ,"grosz" :[""    ,""    ,"klein",""     ,"grosz",""]
 ,"riesig":[""    ,""    ,"klein",""     ,"grosz",""]
 }
, "gif":
 {"icon"  :["icon",""   ,""     ,""     ,""      ,""]
 ,"mini"  :[""    ,"mini",""     ,""     ,""     ,""]
 ,"klein" :[""    ,"mini","klein",""     ,""     ,""]
 ,"mitte" :[""    ,"mini","klein","mitte",""     ,""]
 ,"grosz" :[""    ,"mini","klein","mitte","grosz",""]
 ,"riesig":[""    ,"mini","klein","mitte","grosz",""]
 }"
}

Abgesehen davon, dass „icon“-Dateien weder herunter­skaliert noch erstellt werden, reichen im Falle von „*.jpg“-Dateien zwei Größen für das Source­set aus.  „riesig“-Dateien werden immer herunter­skaliert und sind nie im Source­set ent­halten. 

Im Abschnitt downscaleSrc wird festgelegt, welche Bildgrößen aus welchen Bildgrößen berechnet werden: 

… "downscaleSrc":
{"jpg":
 {"icon"  :["","","","mitte","grosz","riesig"]
 ,"mini"  :["","","","mitte","grosz","riesig"]
 ,"klein" :["","","",""     ,"grosz","riesig"]
 ,"mitte" :["","","",""     ,"grosz","riesig"]
 ,"grosz" :["","","",""     ,""     ,"riesig"]
 ,"riesig":["","","",""     ,""     ,""      ]
 }
,"gif":
 {"icon"  :["","mini","klein","mitte",""     ,""      ]
 ,"mini"  :["",""    ,"klein","mitte",""     ,""      ]
 ,"klein" :["",""    , ""    ,"mitte","grosz",""      ]
 ,"mitte" :["",""    , ""    ,""     ,"grosz","riesig"]
 ,"grosz" :["",""    , ""    ,""     ,""     ,"riesig"]
 ,"riesig":["",""    , ""    ,""     ,""     ,"riesig"]
 }
}

So müssen die „*.jpg“-Dateien, die weiter herunter­skaliert werden, eine Mindest­größe „mitte“ haben, während „*.gif“-Dateien nur aus den ein oder zwei Stufen größeren Bild­dateien herunter­skaliert werden können (das dieser Vor­gabe zugrunde­liegende „Raster­problem“ wird im nächsten Abschnitt beschrieben). 

In der Konfigurations­datei __bildersettings.json werden außerdem noch grundsätzlichen Einstellungen (Namen, Größen und Reihen­folge der verschiedenen Größen­modi und der Wasser­zeichen, Grau­werte der Transparenz­farben etc.) hinterlegt. 

nach oben

Das Rasterproblem

Kapitelinhalt:[  Überspringen ]

• Das Problem an sich •
• Lösungs­versuche – Höher­rastern und Skalieren

Das Problem an sich

Einige Schalt­pläne und Skizzen wurde in einem Vektor­zeichen­programm (Corel­DRAW) gezeichnet oder auf­ge­arbeitet und anschließend in ein Pixel­bild (*.gif) exportiert.  Die dabei entstandenen Bild­dateien waren nicht besonders schön – wie mit einem zer­faserten, manchmal halb­leeren Filz­stift gezeichnet (siehe dazu auch im Folgenden Abbildung 2 und Abbildung 3). 

Das Problem ver­langt nach einer Er­läuterung anhand einer Beispiel­datei.  Der obige Schalt­plan (eine etwas eigenwillige Interpretation der Box of Rock) ist in Corel­DRAW als Bild­datei ein­schließ­lich des weißen Hinter­grundes 195 mm breit und 70 mm hoch (entspricht einem Format von 7,68 × 2,75 Zoll bzw. 553 × 198 Punkten), die Schrift­größe ist gleich 10 Punkte und die Linien­breite gleich einem Punkt. 

Das Bild wurde auf eine Größe von 460 × 165 Pixeln gerastert.  Dabei wird quasi ein Raster bzw. ein Netz von 460 × 165 Maschen über das Bild gelegt und für jede Masche die durch­schnitt­liche Hellig­keit ermittelt.  Dabei sind die wenigen Maschen sehr groß bzw. die Details des Bildes recht klein gegenüber dem Raster der Maschen – die Groß­buchstaben der Schrift von Schrift­größe 10 pt (Groß­buchstaben mit 70 % der Schrift­größe) wären dann etwa sechs Pixel bzw. Maschen hoch (10 pt ⋅ 70 % ⋅ 460 px / 553 pt), die Strich­breite läge bei weniger als 1 Pixel bzw. 1 Masche (1 pt ⋅ 460 px / 553 pt).  Diese Art der Darstellung ist zwangs­läufig schlecht, wie ein Blick auf die beiden Bilder in Abbildung 3 beweist: 

Hier sind die Probleme der groben Rasterung schon zu erkennen: 

Schriftgröße: 

Die Buchstaben sind mit etwa sechs Pixeln Versal­höhe gerade so lesbar – Kleinbuchstaben oder Indizes wären es nicht mehr. 

Linien: 

Die Abstände der Rasterlinien korrelieren nicht mit den Abständen der Linien in der Zeich­nung; manchmal sind liegen Linien / Verbindungen der ursprüng­lichen Zeich­nung genau auf dem Raster (dann sind auch die gerasterten Linien / Verbindungen klar und schwarz, wie z. B. über bzw. unter dem Potentiometer), manchmal liegen die Linien / Verbindungen genau zwischen zwei „Raster­maschen“, und man sieht anstelle einer klaren schwarzen Linie eine verwaschene graue. 

Details: 

Die beiden Kondensatoren C₇ und C₈ bspw. sind kaum mehr als ein verschmierter Klumpen.  Das heißt, wenn die Details zu fein sind (z. B. der Abstand der Kondensator­platten nicht deut­lich größer als das Raster), gehen sie beim Rastern verloren. 

nach oben

Lösungs­versuche – Höher­rastern und Skalieren

Der grundlegende Ansatz besteht nun darin, die Vektorgrafik in einer wesent­lich höheren Auf­lösung zu rastern (hier mit 600 ppi) und dieses Pixelbild dann auf unter­schied­lichen Weg „kleinzurechnen“.  Dabei wurden mehrere Ansätze verfolgt: 

Direkt herunter­skalieren: 

Das Bild wurde aus Corel­DRAW mit 600 ppi (Bildbreite 4606 Pixel) exportiert und in einem Schritt von Bildbreite 4606 Pixel auf Bildbreite 960 Pixel (etwa 20,8 %) herunter­gerechnet. 

Hier ist natür­lich mit vergleichbaren Problemen wie bei oben beschriebenen direkten Rastern zu rechnen – die Position des Details entscheidet mit über dessen Darstellung.  In der folgenden Abbildung 5 rechts zeigt sich das in der unter­schied­lichen Darstellung der beiden Kondensatoren C₇ und C₈. 

In kleinen Schritten herunter­skalieren: 

Im nächsten Versuch / Ansatz wurde das in hoher Au­flösung gerasterte Bild in sehr kleinen Schritten herunter­gerechnet (acht Durchläufe, bei denen das Bild jeweils auf etwa 82 % verkleinert wurde). 

Die Darstellung insbesondere der beiden Kondensatoren wirkt etwas aus­ge­glichener, wenn­gleich alle Linien ein grauer Saum umgibt, eine Folge der häufigen Neuberechnung des Bildes.  Es entsteht eine Art Patina, die an ältere Fachbücher (mit billigem Papier) erinnert. 

Im goldenen Schnitt herunter­skalieren: 

Im letzten Versuch wurde die in hoher Auf­lösung gerasterte Zeich­nung in mehreren Schritten kleiner gerechnet, wobei alle Schritte bis auf den ersten das Bild im Verhältnis des goldenen Schnittes (hier abwechselnd auf 61 % bzw. 62 %; ansonsten ist der Goldene Schnitt gleich √1,25 ±0,5 ≈ 0,618). 

Auch wenn die Unterschiede minimal sind, scheint das der sinnvollste Ansatz zu sein: 

nach oben

Bildgestaltung

Aus dem oben beschriebenen Problem des Aufrasterns ergeben sich natür­lich auch bestimmte Anforderungen in den Zeich­nungen wie z. B. Mindest­schrift­größen und Mindest­linien­stärken in den Zeich­nungen. 

Die Lösung des Autors für dieses Problem ist hochgradig unspektakulär – Dreisatz und EXCEL.  Das heißt, anhand sinnvoller Vorgaben (bei einem aufgerasterten, 480 Pixel breit dargestellten Bild sollten die Schriften mindestens acht Pixel groß und die Linien etwa ein bis eineinhalb Pixel breit sein) lassen sich für Zeich­nungen gegebener Breite angemessenen Werte für Schriftgröße und Linien­dicke berechnen. 

nach oben

Übernahme der Schaltpläne aus PSPICE

Kapitelinhalt:[  Überspringen ]

• Herunterskalieren der Screen­shots •
• Korrekturen und Ergänzungen

In einem Blog zum Thema Gitaren­elektronik sind natür­lich auch Schalt­pläne enthalten.  Der Autor hat dabei sehr lange mit einer Studenten­version des Programms PSPICE ge­arbeitet – sei es, um Schaltungen zu simulieren, sei es, um sie einfach nur zu zeichnen, und die Schaltungen dann in die Artikel übernommen. 

Allerdings wurde bei der Über­nahme der Schalt­pläne aus PSPICE über die Jahre kräftig „abgespeckt“ – anstelle eines Exports über das AutoCAD-Format in Corel­DRAW und einem um­ständ­lichen Neubau der Bilder (Linien und Schriften müssen in Corel­DRAW in unterschied­liche Ebenen sortiert werden, um den Linien sinnvolle Linien­stärken und den Schriften keine Linien­stärken zu­zu­weisen) mit anschließenden Rastern wurden die Display­einstellungen in PSPICE so geändert (größere Schrift in passender Schrift­art, fettere Linien, aus­schließ­lich Sch­warzweiß), dass sich auch aus den Screen­shots verwendbare Illustrationen erstellen lassen. 

nach oben

Herunterskalieren der Screen­shots

Diese Screen­shots müssen allerdings noch für die Verwendung auf der Seite optimiert (zugeschnitten und skaliert) werden.  Auch hier wurden mehrere Ansätze des Kleinrechnens der Bilder ausprobiert: 

Direkt herunter­skalieren: 

Der Schalt­plan wurde in PSPICE etwa auf Bild­schirm­breite (Bild­schirm­auf­lösung 1280 × 1024) vergrößert und als Screen­shot gespeichert und zugeschnitten (Programm­menüs, Scroll­balken und breite weiße Ränder wurden entfernt).  Das zwischen 1000 Pixel und 1200 Pixel breite Bild wurde anschließend in einem Schritt auf Bild­breite 960 Pixel herunter­gerechnet. 

An einigen unschönen Details (stufiger Kreis bei der Eingangs­spannungs­quelle, stufige Außenkanten bei den Operations­verstärkern) ist schon hier zu erkennen, dass diese Methode des Kleinrechnens nicht optimal ist. 

In kleinen Schritten herunter­skalieren: 

Im nächsten Versuch / Ansatz wurde der zugeschnittene Screen­shot vergrößert (die Pixelzahl verdoppelt) und das Bild dann in sehr kleinen Schritten auf die Breite von 960 Pixel herunter­gerechnet (sechs Durchläufe, bei denen das Bild jeweils auf etwa 86 % bis 87 % verkleinert wurde). 

Das sieht schon besser aus, auch wenn die Details (zum Beispiel die Schrift) einen leichten Saum haben. 

Im goldenen Schnitt herunter­skalieren: 

Im letzten Versuch wurde zugeschnittene Screen­shot zuerst mit ganz­zahligem Ver­größerungs­faktor auf eine Breite von deut­lich über vier­tausend Pixel hoch­skaliert (z. B. auf die vierfache Breite) und an­schließend einer vorher berechneten Reihe von Größen (4066 Pixel, 2513 Pixel und 1553 Pixel auf 960 Pixel) folgend mehrmals im Verhältnis des goldenen Schnitts herunter­skaliert. 

Sofern das hier überhaupt genau erkennbar ist, scheint dieser Weg der mit der brauchbarsten Darstellungs­qualität zu sein. 

nach oben

Korrekturen und Ergänzungen

Soweit das Groß- und Klein­rechnen von fertig erstellten Schalt­plänen.  Allerdings sind bei diesen Schalt­plänen hin und wieder auch Korrekturen und Ergänzungen notwendig – sei es, dass beim Zeichnen Fehler gemacht wurden, sei es, dass Bauelemente ergänzt oder modifiziert werden müssen (Schalter, Laut­sprecher).  Außerdem können Modifikationen notwendig sein (farb­liche Hintergründe, Schrift in anderen Farben). 

Zeich­nungs- und Schrift­korrekturen erfolgen am besten vor dem Klein­rechnen / Neu­rastern, damit die Unterschiede durch das mehr­malige Neu­rastern ein wenig ab­ge­schliffen werden und so weniger auffallen.  Farb­änderungen (zumindest flächige Um­färbungen) sollten danach erfolgen, da sonst an Linien über Farb­kanten häss­liche Un­schärfen entstehen. 

Schließ­lich ist es sinnvoll darauf zu achten, dass die Hinter­gründe der Vor­lagen vor dem Herunter­skalieren immer weiß sind – ansonsten können es beim Herunter­skalieren insbesondere an Kanten häss­liche Arte­fakte („Über­schwingen“) entstehen – direkt an der herunter­skalierten Kante ist der Kontrast erhöht und der Hintergrund noch heller als sonst. 

nach oben

Arbeiten mit Gradations­kurven

Kapitelinhalt:[  Überspringen ]

• Seitenhintergrund für Bilder •
• Schriftfarbe Schwarz zu Rot •
• Gelber Hintergrund

Zu den wichtigsten Werk­zeugen in der Bildbearbeitung gehören Gradations­kurven.  In ihnen ist ein Zusammenhang zwischen der Hellig­keit eines Bildes (oder einer Teil­farbe eines Bildes wie z. B. Rot, Grün oder Blau) vor und nach der Behand­lung mit der Gradations­kurve.  Verständ­licher ist das mög­licher­weise an einem Beispiel: 

nach oben

Seitenhintergrund für Bilder

Im Grund­design der Seite wurde als Hinter­grund­farbe ein helles Grau (#f4f4f4 bzw. [244 , 244 , 244] oder 95 % weiß) festgelegt.  Alle „Strich­zeichnungen“ (Schalt­pläne, Skizzen, Dia­gramme) sollten weitest­gehend diese Hinter­grund­farbe haben. 

Der einfachste Weg, das bei einer Schwarz-weiß-Grafik zu erreichen, ist das Abdunkeln der gesamten Grafik auf etwa 95 % weiß (genaugenommen auf 244 von maximal 255).  Im folgenden Dia­gramm in Abbildung 13 entspricht der braune Graph mit dem Label website_244 diesem Vor­gehen – jeder Hellig­keit im Ausgangs­bild wird eine etwa 5 % geringere Hellig­keit im Ergebnis­bild zugeordnet. 

Allerdings hatte der Autor zu Beginn des Blogs einigen EXCEL-Dia­grammen diese Hinter­grund­farbe #f4f4f4 schon bei der Grafik­erstellung in EXCEL zugewiesen, wobei EXCEL diese Hinter­grund­farbe nicht unbedingt getroffen hat.  Hier wäre also Nachdunkeln keine Option gewesen, außerdem sollten die Fehler von EXCEL korrigiert werden.  Daraus leitete sich die zweite Gradations­kurve in obigem Dia­gramm ab: 

• Helles Grau von zwischen 92 % und 100 % wird auf die gewünschte Hinter­grund­farbe von 95 % bzw. #f4f4f4 festgesetzt (oberer ebener Abschnitt der schwarzen Gradations­kurve). 

• Grau zwischen 82 % bis 92 % wird so leicht im Kontrast verstärkt, dass es sich im Ergebnis­bild zwischen 82 % bis 95 % bewegt (oberer, steilerer Abschnitt der schwarzen Gradations­kurve). 

• Dunklere Farben (dunkler als 82 % weiß) werden nicht verändert (Haupt­teil der schwarzen Gradations­kurve). 

nach oben

Schriftfarbe Schwarz zu Rot

Nun zu etwas weniger technischen Basteleien, dazu mit den Gradations­kurven für die einzelnen Farben: 

Zunächst war es gewünscht, einige Schrift­zeichen bzw. Teile einer Strich­zeichnung von Schwarz auf Weinrot umzufärben.  Das heißt, weiß sollte weiß bleiben und schwarz zu wein­rot bzw. dunkel­rot geändert werden.  Dazu wurde der ent­sprechende Teil des Bildes maskiert.  Anschließend wurden die in folgender Abbildung 3 dargestellte Gradations­kurven angewendet: 

Es zeigt sich, dass (im maskierten Bereich) die Helligkeiten von Grün und Blau nicht verändert werden – für Grün und Blau läuft der Graph gerade von [0 , 0] bis [256 , 256].  Anders für Rot, hier ist der dunkelste Wert für das Ergebnis­bild 113, so dass dort die Farbe Schwarz #000000 durch ein Weinrot #71ffff ersetzt wird. Dazu kommt, dass auch die Grautöne immer mehr Rot als Grün und Blau enthalten, also graue Ränder bzw. Übergänge von Schwarz auf Weiß auch umgefärbt werden. 

nach oben

Gelber Hintergrund

Nun quasi das Gegen­teil des eben beschriebenen – das Auf­füllen bzw. Ab­dunkeln eines Hinter­grundes in einer bestimmten Farbe.  Das kann, z. B. in einem großen Schalt­plan, sinnvoll sein, um bestimmte Teile des Plans (wie verschiedene Bau­gruppen) zu kenn­zeichnen.  Siehe dazu das folgende Dia­gramm (Abbildung 15): 

Die Gradations­kurven für alle drei Farben Rot, Grün und Blau beginnen im (schwarzen) Null­punkt und laufen zu verschiedenen Maximal­werten – 237 von 255 für Rot, 212 von 255 für Grün und 131 von 255 für Blau, was einem Farb­ton #edd483 bzw. (ungefähr) einem warmen Gelb oder einem dezenten „Gold­ocker“ ent­spricht.  Das heißt, im so behandelten Teil eines Schwarz-Weiß-Bildes werden die einzelnen Farb­werte der Hinter­grund­farbe als Maximal­farben in die drei Gradations­kurven eingetragen und so die vorherige Hinter­grund­farbe Weiß durch die neue Hinter­grund­farbe (in diesem Falle Gelb) und der Schwarz-Weiß-Über­gang durch einen Über­gang von Schwarz zur neuen Hinter­grund­farbe ersetzt. 

Es empfiehlt sich, derartige Um­färbungen als letzten Schritt der Bild­be­arbeitung (nach dem Skalieren / Neurechnen der Bilder) durchzuführen. 

nach oben

Verwendung von Wasser­zeichen

Die Wasser­zeichen lassen sich kurz abhandeln – für die gesamte Seite werden Bilddateien, sofern es sich nicht um geistiges Eigentum Dritter handelt bzw. in ihnen geistiges Eigentum Dritter dargestellt wird, mit dem Motto / Label der Seite „gitarre & basteln“ versehen.  Geistiges Eigentum Dritter wird entweder nicht (inhalt­lich) verändert oder mit einem roten Wasser­zeichen / Warn­hinweis „Private use only!“ versehen. 

Technisch gesehen handelt es sich bei den Wasser­zeichen um RGB-Bild­dateien mit weißem Hinter­grund (d. h. im Hintergrund des Wasser­zeichens sind alle drei Farbwerte gleich 100 % bzw. eins), die horizontal und vertikal zentriert in das Bild ein­multipliziert werden. 

Der Name jeder Wasser­zeichen­datei enthält Hinweise auf die Größe des Bildes, in das es ein­multipliziert werden kann, und auf die Farbe – letztere abhängig vom Einsatzzweck: 

Unter­schied­liche Stempelgrößen: 

• „huge“:  Größe 840 × 280 Pixel; Schrift­größe 112 Punkte; für große Bilder (960 Pixel breit)

• ohne Größen­label:  600 × 200 Pixel; Schrift­größe 80 Punkte; für Datenblatt-Faksimile (700 Pixel breit)

• „medi“:  450 × 150 Pixel; Schrift­größe 60 Punkte; für mittelgroße Bilder (664 Pixel breit)

• „mini“:  360 × 120 Pixel; Schrift­größe 48 Punkte; für kleine Bilder (462 Pixel breit)

• „tiny“:  225 × 75 Pixel; Schrift­größe 30 Punkte für sehr kleine Bilder (319 Pixel breit)

Unter­schied­liche Schrift­farben (und Texte): 

• Ohne Farb­label – Farbe: #dededd (Dezimal: 222, 222, 200):  Standard­farbe.  Text: „gitarre & basteln“

• Label „blk“:  Farbe: „black“; Text: „gitarre & basteln“; für Schwarzweißfotos. 

• Label „red“:  Farbe: „brown“ (gemeint ist ein dunkles Wein­rot); Text: „gitarre & basteln“; für Fotos. 

• Label „grau“:  Farbe: #979797 (Dezimal: 151, 151, 151); Text: „gitarre & basteln“; Für dunkle Skizzen, um nicht übersehen zu werden. 

• Label „lgt“:  Farbe: #e9e9d8 (Dezimal: 233, 233, 216) Text: „gitarre & basteln“ Für helle und / oder filigrane Dia­gramme, um nicht zu stören. 

• Label „XXX“:  Farbe: „red“; Für Warnhinweis; z. B. „For private use only!“ (d. h. der dargestellte Inhalt darf nicht kommerziell weiter­ver­wendet werden). 

Alle Wasser­zeichen wurden mit Image­Magick, gesteuert über ein Batch-Skript, vor­produziert und als Bitmaps in einem gemein­samen Verzeichnis abgelegt.