Wie Image aus VCL-Formular-Datei (.dfm) auslesen

[Harry Stahl]

Weiß jemand, in welchem Format Delphi die Images in der Formulardatei speichert? In der Textfassung sieht das ja ungefähr so aus:

Code:

object Image1: TImage
    Left = 48
    Top = 40
    Width = 105
    Height = 105
    HelpType = htKeyword
    HelpKeyword = 'g'
    Picture.Data = {
      07544269746D6170E6040000424DE60400000000000036000000280000001400
      0000140000000100180000000000B00400000000000000000000000000000000

Ich würde nun gern die Image mit einem externen Programm laden, manipulieren und wieder zurückschreiben. Kennt jemand einen einfachen Weg?

[Bernhard Geyer]

Die Daten sind Hex-Codiert.
In deinem Beispiel steht TBitmap + den Binärstream des Bitmaps drin.

[himitsu]

Mit TReader einlesen, in TWriter kopieren und dabei das Gewünschte verändern.
(man muß nur mal nachsehn, ob bei dem Textformat etwas beachtet werden muß, da das Format grundsätzlich erstmal binär ist ... eventuell gibt es auch irgendwo ein paar Konvertierungsfunktionen)

Man könnte auch ganz böse die DFM "laden", also eine Form-Insttanz erstellen (die Methodenzeiger müssen aber beachtet werden), ändert dann in der TImageInstanz das Bild und speichert die DFM danach wieder ab.

[Harry Stahl]

Zitat von himitsu:

Mit TReader einlesen, in TWriter kopieren und dabei das Gewünschte verändern.

Leider habe ich mit TReader und TWriter gar keine Erfahrung (vermute mal, das verwendet man im Rahmen der Komponenten-Entwicklung?).

Ich habe mal versucht, ein Programm zu erzeugen, das zwei Images auf der Form hat. Nun wollte ich erst mal die Image2 laden und dann "kopieren" (wie Du schreibst) und in Image1 schreiben (die Image-Manipulation habe ich mir also erst einmal geschenkt).

So sieht der Source-Code aus:

Code:

procedure TForm43.FormCreate(Sender: TObject);
var
  writer: TWriter;
  reader : TReader;
  msr, msw: TMemorystream;
begin
  msr:= TMemorystream.create;
  msw := TMemorystream.create;

  reader := TReader.Create (msr,0);
  // Liest Komponente "Image2"
  reader.ReadComponent (Image2); // Hier kommt stream-lesefehler

  Writer := TWriter.Create (msw, 0);

  msr.position := 0;
  msw.CopyFrom (msr, msw.size);
  writer.WriteComponent (Image1);
end;

Bei der gekennzeichneten Zeile kommt der Fehler wie beschrieben.

Was mache ich falsch, bzw. muss ich anders machen?

[Harry Stahl]

Zitat von Bernhard Geyer:

Die Daten sind Hex-Codiert.
In deinem Beispiel steht TBitmap + den Binärstream des Bitmaps drin.

Ja, das stimmt, kann ich nun so bestätigen.

Handelt es sich z.B. um ein TSpeedButton mit einem Glyph, dann beginnt in dem Datenstream ab Offset 5 das eigentliche Bitmap. Vorher sind 4 Bytes, die Delphi anscheinend intern für die Komponente verwendet (nennen wir das mal "Komponentenheader"). So kann ich also ohne Probleme die Bitmap ab Position 5 auslesen.

Das Problem entsteht nun, wenn ich eine geänderte Bitmap zurückschreiben will. Denn die ersten 4 Bytes unterscheiden sich, je nach dem, welche Bit-Tiefe und welches Ausmaß die Bitmap hat. Eine echte Logik konnte ich da selber leider nicht erkennen.

Ist jemanden eine Beschreibung bekannt, nach welcher Systematik die ersten 4 Bytes in dem Stream ("Komponentenheader") für "Glpyh.data" (Tspeedbutton), "Picture.data" (TImage) oder "Bitmap" (TImagelist) geschrieben werden müssen?

[Bernhard Geyer]

Ich würde sagen das ist die Längenangabe:
In deinem Fall: E6040000
Intel (Little-Endian) Reihenfolge, also 000004E6 = 1254 Byte Datenlänge

[Harry Stahl]

Nein, Größenangaben können das m.E. nicht sein.

Ein 16x16 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als "Komponentenheader":

Code:

 Glyph.Data = {
    36030000...

Ein 16x16 großes 32-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
    36040000...

Ein 24x24 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
   F6060000...

[Bernhard Geyer]

Zitat von Harry Stahl:

Nein, Größenangaben können das m.E. nicht sein.

Ein 16x16 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als "Komponentenheader":

Code:

 Glyph.Data = {
    36030000...

Ein 16x16 großes 32-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
    36040000...

Ein 24x24 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
   F6060000...

Wieso nicht?

16*16*24 Bit = 768 Byte <-> 0x0336 -> 822 Bildaten inkl. den 54 Byte BMP-Header
16*16*32 Bit = 1024 Byte <-> 0x0436 = 1078 Bildaten inkl. den 54 Byte BMP-Header
24*24*24 Bit = 1728 Byte <-> 0x06F6 = 1782 Bildaten inkl. den 54 Byte Bmp-Header

[Perlsau]

Mich würde interessieren, was der Hintergrund dieser Anforderung ist: Um an die Bitmap- bzw. Picture-Daten zu kommen, genügt doch einfach ein Image1.Picture.SaveToFile(Dateiname); ... wozu benötigt man dann die DFM, um dort umständlich die Picture-Daten auszulesen und zu interpretieren?

[Bernhard Geyer]

Zitat von Perlsau:

Mich würde interessieren, was der Hintergrund dieser Anforderung ist: Um an die Bitmap- bzw. Picture-Daten zu kommen, genügt doch einfach ein Image1.Picture.SaveToFile(Dateiname); ... wozu benötigt man dann die DFM, um dort umständlich die Picture-Daten auszulesen und zu interpretieren?

Stimmt. Das wäre die Frage.
Wenn sowas austauschbar gestaltet werden soll gibt es 100 bessere und einfachere Lösungen als das im DFM zu machen.