Einzelnen Beitrag anzeigen

Muetze1
(Gast)

n/a Beiträge
 
#4

Re: Scanline erklären

  Alt 11. Mär 2005, 21:21
Moin!

Und wie die Daten bei dem Zeiger von ScanLine[] vorliegen hängt von der PixelFormat Property ab.

pf1bit - jedes Byte enthält 8 Pixel, jedes Bit des Bytes ist ein Pixel
pf4bit - jedes Nibble enthält einen Index für die Farbpalette des Bildes. Die RGB Werte erhälst du, wenn du die Farbpalette für den im Nibble gefundenen Index abfragst. (Nibble = Halbbyte = 4 Bit; ergo: 2 Pixel pro Byte)
pf8bit - jedes Byte stellt ein Pixel da und das Byte enthält wieder einen Index für die Palette des Bildes.
pf15bit - Ein Pixel besteht auf einem Word (16 Bit) wobei aber nur 3x 5 Bit benutzt werden - 5 Bit pro Farbanteil (rot, grün, blau). Dies sind direkt die Farben.
pf16bit - wie pf15Bit, nur das diesmal der AFAIR grüne Farbanteil als Ausnahme 6 Bit anstatt 5 Bit zur Verfügung hat. Grund: Das Auge ist empfindsamer auf dem Farbanteil...
pf24bit - ein Pixel besteht aus 3 Bytes (rot, grün, blau) und enthalten die direkten RGB Farben. Diese Farbtiefe ist nicht zu empfehlen, da jeder 2. Pixel an einer ungeraden Adresse liegt. Besser ist es 32 Bit zu nutzen, dort ist jeder Pixel aligned und der Prozessor muss keine extra Lesezyklen einlegen um die Farbwerte des Pixels zu ermitteln.
pf32bit - genauso wie 24 Bit, nur das hier noch ein Füllbyte vorhanden ist (im Normalfall ohne Funktion) und somit ein Pixel auf 4 Byte kommt, was dem Alignment von einem 32 Bit Prozessor entspricht. Es gibt z.B. bei DirectX Farbmodien wo das 4. Byte für den Alphakanal benutzt wird (und auch bei der WinAPI: AlphaBlend).

Im Normalfall musst du die bei pf15bit und pf16bit gefundenen RGB Werte noch um 2 Bits nach links shiften um ordentliche RGB Werte zu erhalten...

So, das war ein Kurzanriss...

MfG
Muetze1
  Mit Zitat antworten Zitat