- Wie verhalten sich Pixelwert, VDI-Index und
Farbtabellen-Index zueinander?
Der Pixelwert ist der Wert, den das VDI in den Bildschirmspeicher
oder in eine Bitmap schreibt, wenn ein Pixel in einer bestimmten Farbe
ausgegeben werden soll. Er hängt von der Farbtiefe der Bitmap und
deren Pixelformat ab. So hat z.B. bei 8 Bit Farbtiefe ein weißes
Pixel i.a. den Pixelwert $00, bei 32 Bit Farbtiefe aber den Pixelwert
$00ffffff.
Der Farbtabellen-Index indiziert - wie es der Name bereits
andeutet - eine Farbtabelle (eine COLOR_TAB-Struktur), d.h. Index 0
verweist auf Farbeintrag 0 (eine COLOR_ENTRY-Struktur) und Index 1
verweist auf Eintrag 1 der Tabelle. Die Farbtabellen werden für
Bitmaps mit bis zu 8 Bit Farbtiefe benötigt und legen für
jeden Pixelwert den Farbwert fest; der Farbtabellen-Index entspricht
bei bis zu 8 Bit Farbtiefe also letztendlich dem Pixelwert.
Bei mehr als 8 Bit Farbtiefe wird die Farbe direkt durch den
Pixelwert angegeben. Man spricht z.B. bei 32 Bit Farbtiefe auch von
xRGB-Pixeln, weil der Pixelwert aus einem unbenutzten Byte (x) und
drei Bytes für die Farbkomponenten Rot (R), Grün (G) und
Blau (B) besteht.
Der VDI-Index ist eine Altlast aus der VDI-Definition von DRI und
wird bei Funktionen wie vst_color() oder vsf_color() übergeben.
Er ist letztlich ein "verkappter" Farbtabellen-Index, d.h.
VDI-Index 0 verweist auf Farbeintrag 0, aber VDI-Index 1 verweist z.B.
auf Farbeintrag 255 oder 15 (abhängig von der Farbtiefe).
VDI-Index und Pixelwert sind nicht identisch!
- Was ist eine inverse Farbtabelle?
Damit Bitmaps in unterschiedlichen Bittiefen und mit
unterschiedlichen Farbtabellen schnell umgewandelt werden können,
werden sogenannte "inverse Farbtabellen" benötigt.
Daraus wird die Information entnommen, welcher Pixelwert der
Zielbitmap eine ähnliche Farbe hat wie ein Pixelwert aus der
Quellbitmap.
Sobald die Farben des Bildschirms (oder einer anderen Zielbitmap
von vr_transfer_bits) verändert werden, muß NVDI bei der
nächsten Bitmapausgabe diese inverse Farbtabelle wieder
aktualisieren, damit die Zuordnung von Farbwert zu bestem Pixelwert
stimmt.
Damit diese Synchronistation zwischen Farbtabelle und inverser
Farbtabelle klappt, haben die Farbtabellen eine Kennung
<map_id>. Wenn ein Programm selber eine Zielbitmap verwaltet,
für die eine Referenz auf eine inverse Farbtabelle angefordert
wurde, und das Programm die Einträge in der Farbtabelle
verändert, so muß bei v_get_ctab_id() eine neue Kennung
für die Farbtabelle angefordert werden, damit die inverse
Farbtabelle ggf. aktualisiert wird.
- Wieso kann die inverse Farbtabelle verschiedene
Auflösungen haben?
Von der Auflösung der inversen Farbtabelle (3, 4 oder 5 Bit)
hängt es ab, wie genau die Zuordnung von Farbwert zu Pixelwert
ist. Bei 3 Bit wird vereinfacht gesagt ein Feld rgb_to_pixel[8][8][8]
aufgebaut, daß mit den drei obersten Bits (2^3 ergibt 8
Einträge pro Dimension) jeder Farbkomponente indiziert wird.
Es gehen also effektiv 5 Bit verfügbarer Farbinformation
verloren und farblich nahe beieinanderliegende Pixel können in
dieser Tabelle evtl. nicht auseinandergehalten werden. Nachteil ist
also, daß bei geringerer Auflösung der inversen Farbtabelle
das Dithering oder die arithmetischen Verknüpfungen nicht immer
die bestmögliche Wandlung vornehmen können. Vorteil ist der
geringere Speicherverbrauch und der schnellere Aufbau der Tabelle.
Falls eine Zielbitmap Pixel mit direkten Farbwerten hat (also 15,
16, 24 oder 32 Bit xRGB), so ist die inverse Farbtabelle nur ein
Dummy, da die Zuordnung von Farbwert von Pixelwert eindeutig ist und
sich nicht ändern kann. Aus diesem Grund ist bei
vr_transfer_bits() auch dokumentiert, daß für solche
Bitmaps keine inverse Farbtabelle vorhanden sein muß.
- Wenn ich die aktuelle Palette per vq_ctab() ermittle,
muß die COLOR_TAB dabei in irgendeiner Art vorinitialisiert
sein? Bisher gibt es nur CSPACE_RGB, aber was, wenn es mal z.B.
CSPACE_CMY gibt?
Die Farbtabelle muß vor dem Aufruf von vq_ctab() nicht
vorinitialisiert sein. Sie wird immer in dem Farbraum
zurückgeliefert, der für die Workstation (das
übergebene VDI-Handle) eingestellt ist.
Für die Farbräume ist vorgesehen, daß auch in
Zukunft (wenn einmal mehr Farbräume verfügbar sind) jede
Workstation im RGB-Farbraum geöffnet wird (ggf. dann mit dem
Farbprofil des entsprechenden Geräts verknüpft - aber das
ist dann für die Applikation vollkommen unwichtig). Wer auf dem
jeweiligen Gerät mit einem anderen Farbraum arbeiten möchte,
kann für seine Einstellungen einen anderen Farbraum verwenden
(bei vsX_XX_color()) oder kann dann für die Workstation einen
anderen Farbraum einstellen, so daß auch die Rückgabe z.B.
bei vq_ctab() in diesem anderen Farbraum erfolgt. In jedem Fall wird
es dabei aber keine Kompatibilitätsprobleme geben.
- Ich habe für eine Bitmap eine inverse Farbtabelle
angelegt. Wenn ich jetzt ein IMG in die Bitmap kopiere und die Bitmap
anschließend auf dem Schirm ausgebe, wird das Bild mit falschen
Farben ausgegeben.
Wenn man eine Referenz auf eine inverse Farbtabelle anfordert, ist
eigentlich nur wichtig, daß die übergebene Farbtabelle
bereits sinnvolle Werte enthielt (d.h. <map_id>,
<color_space>, <no_colors>, etc. müssen sinnvolle
Werte enthalten; die Anzahl der Einträge in der Farbtabelle
muß in Bezug auf die Bittiefe stimmen).
Falls man nach dem Aufruf von v_create_itab() noch die
Einträge in der Farbtabelle ändert (d.h. andere Farben
einstellt), muß für die Farbtabelle umbedingt mit
v_get_ctab_id() eine neue Kennung angefordert werden, damit das VDI
erkennt, daß die inverse Farbtabelle aktualisiert werden
muß.
- Was passiert in den jeweiligen Transfermodi?
In der Beschreibung von vr_transfer_bits() sind die Operationen
der logischen und arithmetischen Transfermodi in symbolischer
Schreibweise aufgeführt.
- Wo finde ich ein Binding für die neuen Funktionen?
In der Datei VDICOL.C und der zugehörigen Headerdatei
VDICOL.H.
- Muß man, wenn man eine Referenz auf eine inverse
Palette anfordert, diese dann erst selbst irgendwie
initialisieren?
Nein. Das Format der inversen Farbtabelle ist aus guten
Gründen nicht dokumentiert. Es ist nicht einmal garantiert,
daß sich hinter der Referenz auf eine inverse Farbtabelle ein
Zeiger verbirgt; es könnte auch ein Handle oder irgendetwas
anderes sein. Darum kann man die Referenz nur von NVDI anfordern und
auch nur über NVDI wieder freigeben.
- Wenn ich eine Offscreen-Bitmap zum Reinzeichnen
benötige, die eigentlich nur 4 Farben braucht, was geht
schneller: Tatsaechlich eine 2-Bit (oder 4-Bit) Offscreenbitmap zu
oeffnen oder gleich eine 8-Bit?. Die Bitmap soll dann anschliessend im
T_TRANSPARENT-Modus auf eine 8- bzw. 32-Bit-Bitmap kopiert werden.
Diese Frage läßt sich nicht pauschal beantworten.
Für eine schnelle Ausgabe sollte grundsätzlich eines der
"packed pixel"-Formate (1,2,4,8,16,32 Bit) verwendet werden.
Wird eine arithmetische Operation durchgeführt, so
ist das 32 Bit "packed pixel"-Format am schnellsten. Liegt
die Bitmap in geringerer Farbtiefe (8 oder weniger Bits) vor, so
muß jedes Pixel vor der arithmetischen Operation erst der
RGB-Farbwert ermittelt werden. Wenn die Wahl zwischen 2,4 oder 8
Bit-Offscreenbitmap fallen muß, dann ist das 8 Bit "packed
pixel"- Format bei arithmetischen Operationen am schnellsten.
Wenn nur eine logische Operation durchgeführt werden
muß und die meiste Zeit für die Expansion benötigt
wird, so ist es besser die geringstmögliche Farbtiefe zu nehmen
(die Expansion von 4 Bit -> 32 Bit verläuft doppelt so schnell
wie die von 8 -> 32 Bit).
- Muß ich immer mit Farbtabelle und inverser Farbtabelle
arbeiten?
Nein. Damit vr_transfer_bits() leichter gehandhabt werden kann,
gibt es für häufige Sonderfälle Vereinfachungen beim
Aufruf:
- Wenn die Quelle keine Farbtabelle hat (0L), wird die Farbtabelle
des Geräts genommen, wenn dieses die gleiche Bittiefe hat. Ist
das nicht der Fall, wird die Systemfarbtabelle für die Bittiefe
der Quelle benutzt.
- Wenn das Ziel keine (inverse) Farbtabelle hat (0L), wird die
(inverse) Farbtabelle des Geräts genommen, wenn dieses die
gleiche Bittiefe hat. Ist das nicht der Fall, wird die
Systemfarbtabelle für die Bittiefe des Ziels benutzt und für
jeden Aufruf wird extra intern eine inverse Farbtabelle
aufgebaut. Daher sollten Zielbitmaps, wenn sie keine inverse
Farbtabelle haben, umbedingt die gleiche Bittiefe wie das zum
VDI-Handle gehörende Gerät haben. Andernfalls dauern die
Aufrufe von vr_transfer_bits() unnötig lange.
Hinweis: Es empfiehlt sich, für Bitmaps
außerhalb des Bildschirms mit v_open_bm() oder v_opnbm() eine
Bitmap vom VDI erzeugen zu lassen, da man sich in diesem Fall nicht um
die Verwaltung von Farbtabellen und inversen Farbtabellen kümmern
muß.