Surface Stream

[sx2008]

Um jetzt vielleicht die

Delphi-Quellcode:

Read()

versus

Delphi-Quellcode:

ReadBuffer()

Diskussion abzuschliesen:

Delphi-Quellcode:

// Das ist der Sourcecode von ReadBuffer
procedure TStream.ReadBuffer(var Buffer; Count: Longint);
begin
  if (Count <> 0) and (Read(Buffer, Count) <> Count) then
    raise EReadError.CreateRes(@SReadError);
end;

Wie man sieht, wird eine Exception geworfen wenn man mehr Bytes lesen möchte als der Stream liefern kann.
Das ist ein äusserst nützliches Sicherheitsfeature. :thumb:
Wenn ein Programmierer z.B. eine Struktur aus einer Datei liest aber die Datei nicht genügend Bytes dafür hat dann hat das sehr unangenehme Folgen.
Die fehlenden Bytes sind dann einfach undefiniert was zu extrem schwer zu findenden Bugs führt.

Wann immer man die Funktionen

Delphi-Quellcode:

Read()

oder

Delphi-Quellcode:

Write()

benützt ist man verpflichtet den Returnwert auszuwerten.
Tut man das nicht handelt man grob fahrlässig.
Das ist vergleichbar mit einem PKW-Fahrer der seinen Sicherheitsgurt nicht benützt obwohl er direkt neben seiner Schulter hängt.

Ich habe hier auf der DP noch nie Sourcecode gesehen, der den Returnwert von Read() oder Write() korrekt auswertet.
Diese Leute möchte ich am liebsten durchschütteln und zurufen "Anschnallen! Nehmt den Sicherheitsgurt!". :wall:


Bleibt vielleicht noch eine Frage offen:
Warum hat Borland die Funktionen

Delphi-Quellcode:

Read()

und

Delphi-Quellcode:

Write()

dann überhaupt

Delphi-Quellcode:

public

gemacht,

Delphi-Quellcode:

protected

hätte ja auch gereicht ?
Nun, neben dem häufig verwendeten

Delphi-Quellcode:

TFileStream

gibt es auch Streams, bei denen man nicht im Vorraus weiss oder erwartet wieviele Bytes denn noch vorhanden sind.
Man liest auf Verdacht einen grossen Block (z.B. 4kB) und wertet dann den Returncode aus weil man sich im Klaren darüber ist dass auch 0 Bytes gelesen worden sein könnten.

[Zacherl]

Keine Ahnung, was du bisher hast, aber zum Auslesen der Bildinformationen kannst du IDirect3DSurface9::LockRect verwenden. Dann schreibst du den Wert aus LockedRect.Bits komplett in den Stream (Gröse = Surface.Width * Surface.Height * BytesPerPixel). Bei ARGB (oder jedem anderen "4 Byte per Pixel" Format) musst du den zum padden verwendeten Pitch Wert nicht beachten.

Um jetzt an die einzelnen Pixel zu kommen, berechnest du erstmal die Position des Pixels:
Stream.Position := (YPos * Surface.Width + XPos) * 4;

Danach liest du ein komplettes DWord aus:
Stream.ReadBuffer(Pixel, 4);

Und schließlich decodierst du den Pixel folgendermaßen über eine simple Bitmaske:

Delphi-Quellcode:

procedure COLOR_DECODE_ARGB(Color: DWord; var A, R, G, B: Byte); inline;
begin
  A := (Color and $FF000000) shr 24;
  R := (Color and $00FF0000) shr 16;
  G := (Color and $0000FF00) shr  8;
  B := (Color and $000000FF);
end;

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1241401)

Keine Ahnung, was du bisher hast, aber zum Auslesen der Bildinformationen kannst du IDirect3DSurface9::LockRect verwenden. Dann schreibst du den Wert aus LockedRect.Bits komplett in den Stream (Gröse = Surface.Width * Surface.Height * BytesPerPixel). Bei ARGB (oder jedem anderen "4 Byte per Pixel" Format) musst du den zum padden verwendeten Pitch Wert nicht beachten.

Um jetzt an die einzelnen Pixel zu kommen, berechnest du erstmal die Position des Pixels:
Stream.Position := (YPos * Surface.Width + XPos) * 4;

Danach liest du ein komplettes DWord aus:
Stream.ReadBuffer(Pixel, 4);

Und schließlich decodierst du den Pixel folgendermaßen über eine simple Bitmaske:

Delphi-Quellcode:

procedure COLOR_DECODE_ARGB(Color: DWord; var A, R, G, B: Byte); inline;
begin
  A := (Color and $FF000000) shr 24;
  R := (Color and $00FF0000) shr 16;
  G := (Color and $0000FF00) shr  8;
  B := (Color and $000000FF);
end;

Danke .. Hab ich alles schon

Ich speichere das Bitmap

Delphi-Quellcode:

D3DXSaveSurfaceToFileW('D:\paper.bmp', D3DXIFF_BMP, scrSurface, nil, @ARect);

lade es zurück.. in den Stream

Delphi-Quellcode:

gs := TFileStream.Create('D:\paper.bmp', fmOpenRead or fmShareDenyNone);

und werte es mit meiner function GetColor aus.

Das Ergebnis ist aber nicht das was auf die Platte geschrieben wurde denn dann müßten die Farben stimmen.

Delphi-Quellcode:

pos := (y * Screen.PrimaryMonitor.BoundsRect.Right + x) * 4;
Stream.Position := pos

Delphi-Quellcode:

bu : Array[0..3] of byte;
gs.Read(bu, sizeof(bu));

Delphi-Quellcode:

function ColorARGB(AlphaChannel: byte; ColrRGB: COLORREF): COLORREF;
var
  bytestruct: COLORBYTES;
begin

  bytestruct.A := AlphaChannel;
  bytestruct.R := GetRValue(ColrRGB);
  bytestruct.G := GetGValue(ColrRGB);
  bytestruct.B := GetBValue(ColrRGB);

  Result := MakeColor(bytestruct.A, bytestruct.R, bytestruct.G, bytestruct.B);
end;

IDirect3DSurface9::LockRect brauche ich nicht da die Daten über D3DXSaveSurfaceToFileW abgespeichert werden.
Aber auch damit habe ich es versucht.

Delphi-Quellcode:

  p := Cardinal(LockedRect.pBits);

  for i := 0 to Screen.Height - 1 do
  begin
    CopyMemory(BMP.ScanLine[i], Ptr(p), Screen.Width * BitsPerPixel div 8);
    p := p + LockedRect.Pitch;
  end;

Und dann das BMP in eine Datei geschrieben.
Wie ich das jetzt direct in den Stream schreibe ist mir noch nicht klar. (so das ich sie im Speicher habe)

aber alle Versuche schlagen fehl die Farben stimmen nicht.
Sobald ich diese wieder einlade.

gruss

[Zacherl]

Versuche mal bitte die Daten wirklich per LockRect in den Stream zu schreiben und nicht den Umweg über das Bitmap zu nehmen. Hierbei lädst du dir nämlich zusätzlich den Bitmap Header in deinen Stream. Wenn die Länge des Bitmap Headers nicht durch 4 teilbar ist, sorgt das dafür, dass sämtliche Pixelinformationen verschoben werden. Desweiteren bin ich mir nicht sicher, ob die D3DX... Funktion das Bitmap nicht einfach (ohne Alpha Channel) als 24-Bit Bitmap speichert.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1241403)

Versuche mal bitte die Daten wirklich per LockRect in den Stream zu schreiben und nicht den Umweg über das Bitmap zu nehmen. Hierbei lädst du dir nämlich zusätzlich den Bitmap Header in deinen Stream. Wenn die Länge des Bitmap Headers nicht durch 4 teilbar ist, sorgt das dafür, dass sämtliche Pixelinformationen verschoben werden. Desweiteren bin ich mir nicht sicher, ob die D3DX... Funktion das Bitmap nicht einfach (ohne Alpha Channel) als 24-Bit Bitmap speichert.

Danke..

Würde ich gerne tun nur habe ich mit streams noch nicht die Erfahrung..
Wie kann ich die Daten direkt da reinschreiben ohne Umweg auf die Platte?

Zitat:

dass sämtliche Pixelinformationen verschoben werden.

Davon muss ich mittlerweile ausgehen denn ansonsten müßten die Daten ja stimmen
da mein Bitmap ansich richtig dargestellt wird.


gruss

[Zacherl]

Nur auf die Schnelle geschrieben und ungetestet. Sollte aber so in der Art funktionieren:

Delphi-Quellcode:

var
  LockedRect: TD3DLockedRect;
  MS: TMemoryStream;
  I: Integer;
  Color: DWord;
  A, R, G, B: Byte;
begin
  MS := TMemoryStream.Create;
  try
    if (Surface.LockRect(LockedRect, nil, D3DLOCK_READONLY) = D3D_OK) then
    try
      for I := 0 to SurfaceHeight - 1 do
      begin
        // Pitch = Anzahl Bytes per "Zeile", also SurfaceWidth * SizeOf(Pixel)
        MS.WriteBuffer(Pointer(NativeUInt(LockedRect.pBits) + I * LockedRect.Pitch)^, LockedRect.Pitch);   
      end;
    finally
      Surface.UnlockRect;
    end;
    // Pixel (24,6) auslesen [*4 ausgehend davon, dass das PixelFormat = ARGB ist]
    MS.Position := (6 * SurfaceWidth + 24) * 4;
    MS.ReadBuffer(Color, SizeOf(Color));
    COLOR_DECODE_ARGB(Color, A, R, G, B);
    // ..
  finally
    MS.Free;
  end;
end;

[EWeiss]

Das ist nett von dir werde es mal testen.

gruss

[EWeiss]

Danke für deine Hilfe

Hmmm... jetzt geht's nach einer kleinen Anpassung der Farbkonvertierung.
Jetzt muss ich mal sehen was da mit meiner Funktion im argen ist.

gruss

[EWeiss]

Zitat:

@Zacherl
Danke nochmal für deine Hilfe die Daten in den MemoryStream zu packen.

Wer es Testen will Bitte schön.

Es wird nichts auf die platte geschaufelt.
das Teil emuliert Ambilight und soll nachher in meiner Lib als Dummy Window arbeiten.

PS: Man sollte schon einen bewegten Desktop haben..
Also Winamp starten Milkdrop im Desktop Modus verwenden und das Teil hier starten.

Ob man da an der Auslastung noch was Kitzeln kann?

gruss

[Medium]

Das Problem mit deiner Funktion ist einfach, dass du das Bild als Windows-Bitmap speicherst, aber beim laden davon ausgehst, dass in der Datei die Rohdaten der Quell-Streams stehen. Tun sie aber nicht, da das Bitmap-Format zum einen einen eigenen Header (Meta-Daten vor den eigentlichen Bilddaten) in die Datei bringt, und zudem der Standard nicht alle Pixelformate vorsieht, die ein DX Surface haben könnte, weshalb da im schlimmsten Fall sogar noch konvertiert wird. Der Dateiinhalt hat nachher also potenziell kaum noch etwas mit den ursprünglichen Rohdaten im Surface-Buffer gemein.

Wenn du mittels eines Filestreams die Datei liest, und darin gerne genau die Rohdaten des Surfaces haben willst, musst du diese auch genau so in die Datei schreiben - nicht in ein Windows-Bitmap umgewandelt. Entsprechende Stream-Klassen gibt es in C#, und die arbeiten sehr ähnlich wie in Delphi. Da gibt es also einigen Wiedererkennungswert im Umgang. Praktischerweise ist das was SlimDX da liefert ja schon ein Stream :)

Edit: Eventuell ließe sich die IPC hier am besten mit einer Named Pipe, statt einer Datei lösen. Erleichtert vor allem das Gehampel mit den Zugriffsmodi wenn 2 Prozesse um sie dauernd konkurrieren, ist aber im Umgang einer Datei nicht unähnlich, und ohne viel Zutun schon sehr "Stream-Freundlich".

Edit2: Ich hatte es bis gerade so verstanden, dass du ein Surface aus einer C#-Anwendung in eine Delphi-Anwendung schaufeln willst. Ich glaube, da habe ich geirrt :stupid:. Vergiss in diesem Fall mein Edit einfach. Ich war von der Nutzung einer Datei für den Datenaustausch innerhalb ein und des selben Prozesses und dem ganzen geposteten C#-Code ggf. verwirrt.