Scanline erklären

[steppo]

Hi Leute,

kann mir jemand erklären wie Scanline funktioniert?

Habe in diversen Beispielen zwar Code gefunden, werde aber nicht schlau daraus.
Was für mich unverständlich ist,
wofür brauche ich Scanline.

In der Funktion wird doch über For-Schleifen jedes Pixel ausgelesen. Das heißt über die x und y Koordinaten. Wofür brauche ich da noch Scanline.

Auch habe ich bei der Benutzung von Scanline (welches sich ja immer noch in zwei for-schleifen befindet, keine Performancesteigerung festgestellt. Es wird immer noch jedes Pixel durchlaufen.

Welches Ergebnis soll Scanline eigentlich liefern.
1. Die Farbe eines Pixels?
2. Eine Kombination aus allen Farbwerten in einer Reihe?

Keine Ahnung!

Wer kann helfen?

Gruß
Steppo

[Khabarakh]

Scanline gibt dir einen Pointer auf das erste Pixel einer Zeile zurück, durch Inkrementieren von diesem kannst du auch die anderen Pixel ansprechen. Es wird also jeweils ein Pixel abgefragt.
Die Pixel-Property ist seehr langsam und macht intern noch einige Umwege. Über Scanline kannst du aber sofort auf den Speicher zugreifen, dadurch ist diese Variante viel schneller.
Noch schneller kannst du mit der GR32-Lib auf Pixel zugreifen, die bietet auch noch andere nette Sachen (Transparenz, Layer, Float-Koordinaten...).

[sniper_w]

Zitat:

Noch schneller kannst du mit der GR32-Lib auf Pixel zugreifen,

Oh ja. :love:

[Muetze1]

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

[steppo]

Das heißt, wenn ich etwas suche und wirklich jeden Pixel überprüfen muß, sind alle Funktionen gleich langsam.
Richtig?

[dizzy]

Nein!

Pixels ist imho eigentlich immer die schlechteste Wahl, vor allem wenn du jeden Pixel wirklich "von Hand" anpacken musst. Meine Empfehlung ist für Bitmap-basierte Dinge auch immer die G32 ;). (Weil ich den Umgang mit Scanline nicht sehr komfortabel finde, und ich zumindest eigentlich immer mit 32-Bit Bildern zu tun hab.)
Die Pixels-Property eines TBitmap32 (der G32-Lib) dürfte etwa gleich schnell sein wie Scanline.

[Muetze1]

Moin!

Sie sind gleich schnell, da TBitmap32 auch über GetDIBits() geht.

Und nein, ScanLine ist nicht langsamer. Pixels[] nutzt nicht die ScanLine Eigenschaft sondern die WinAPI um die Farbes eines Pixels zu ermitteln und diese Funktion ist mehr als lahm. Die ScanLine[] Methode ist in so fern schon schneller, da sie einen Zeiger auf alle Pixel einer Zeile liefert. Du musst nur noch den Zeiger erhöhen. Dieses ist ein immenser Geschwindigkeitsvorteil gegenüber Windows jedesmal mit 'zig Aufrufen erneut für jeden Pixel zu fragen...

MfG
Muetze1

[steppo]

Ok Leute,
das ist der Qelltext, den ich bis jetzt habe.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  BitMap: TBitMap;
  y, x: integer;
  P: PByteArray;
begin
  BitMap := TBitMap.create;

  try
    BitMap.LoadFromFile('Datei.bmp');

      BitMap.PixelFormat:= pf24Bit;

    for y := 0 to BitMap.Height - 1 do
    begin
      P := BitMap.ScanLine[y];
      ProgressBar1.StepIt;
      for x := 0 to BitMap.Width - 1 do
      begin
        P[x] := y;
        Caption := inttostr(x) + ' \ ' + inttostr(y) + ' \ ' +
          ColorToString(Canvas.Pixels[x, y]) + ' \ ' + inttostr(P[x]);
        if (Canvas.Pixels[x, y] = clblack) or (ColorToString(Canvas.Pixels[x,
          y]) = '#000000') then
          Sleep(1000);
        Canvas.Pixels[x, y] := clBlue;
      end;
    end;

  finally
    BitMap.Free;
  end;
end;

Ich färbe einfach jedes gelesene weiße Pixel in ein blaues Pixel ein.
Womit arbeite ich jetzt im Endeffekt.

Mit ScanLine oder mit Pixel?
Meiner Meinung nach kann ich diesen Vorgang auch mit zwei einfachen Schleifen verwirklichen.
Mit gleicher Performance.
Oder?

[Muetze1]

Moin!

Du arbeitest mit dem langsamen Pixels[] Zugriff. Den Wert den du aus ScanLine rausholst benutzt du nicht. Ausserdem hast du bei 24 Bit 3 Bytes pro Pixel, somit greifst du völlig falsch auf die Pixeldaten zu. Und 24 Bit sind von Haus aus langsam, da der Prozessor extra Lesezyklen pro Pixel einfügen muss...

Ok, ScanLine, weisse Pixel in blaue:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  BitMap: TBitMap;
  y, x: integer;
  P: PRGBQuad; // definiert in Windows.pas
begin
  BitMap := TBitMap.create;

  try
    BitMap.LoadFromFile('Datei.bmp');
    BitMap.PixelFormat:= pf32Bit;

    for y := 0 to BitMap.Height - 1 do
    begin
      P := BitMap.ScanLine[y];

      for x := 0 to BitMap.Width - 1 do
      begin
        If ( P^.rgbRed = $ff ) And ( P^.rgbGreen = $ff ) And ( P^.rgbBlue = $ff ) Then
        Begin
          P^.rgbRed   := 0;
          P^.rgbGreen := 0;
          // P^.rgbBlue  := $ff;  <-- haben wir ja schon, siehe IF Bedingung
        End;
        Inc(P);
      end;
    end;
  finally
    BitMap.Free;
  end;
end;

Und dazu eine reine Pixels[] Routine:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
  BitMap: TBitMap;
  y, x: integer;
begin
  BitMap := TBitMap.create;

  try
    BitMap.LoadFromFile('Datei.bmp');
    BitMap.PixelFormat:= pf32Bit;      // gleiche Grundlagen schaffen

    for y := 0 to BitMap.Height - 1 do
    begin
      for x := 0 to BitMap.Width - 1 do
      begin
        If ( BitMap.Canvas.Pixels[x, y] = clWhite ) Then
          Bitmap.Canvas.Pixels[x, y] := clBlue;
      end;
    end;
  finally
    BitMap.Free;
  end;
end;

So, vergleiche die beiden Routinen mal nach Geschwindigkeit - und benutze dabei am besten aucb Bilder die deutlich grösser als 300x300 sind...

MfG
Muetze1

[steppo]

Ich sehe nichts. Das Programm läuft zwar aber ich sehe keine Farbänderung.
Wo änderst du die Pixelfarbe?