Bit-Tiefe in PNG ermitteln

[Harry Stahl]

Ich möchte unter Linux (mit CrossVCL) eine PNG-Datei in die TImage-Komponente mit TImpage.picture.loadFromFile (FileName) laden.

Leider werden Dateien mit Bit-Tiefe 8 bit nicht unterstützt (selbst die Linux-Standard-Anzeigen verweigern die Anzeige der Grafik), daher schmiert das Programm beim Laden (bzw. bei der Anzeige) gnadenlos ab. Als Workaround möchte ich zunächst mal das abschmieren verhindern und daher das Laden sein lassen, wenn ich eine 8-Bit-Png vor mir habe.

Wie kann ich das ermitteln?
Alternativ ein PNGImage zum Laden verwenden geht auch nicht, das gleiche Problem.

Müsste eigentlich nur die Datei binär öffnen und die entsprechende Information zur Bit-Tiefe auslesen.

Weiß jemand, wie ich an die Info komme?

[Delphi.Narium]

Spezifikation: http://www.libpng.org/pub/png/spec/1...-Contents.html

Wikipedia: https://en.wikipedia.org/wiki/Portab...s#Pixel_format

Dort nach "Pixel format" suchen.

Kurz dahinter steht in einer Tabelle sowas:

3 (0112) indexed: channel containing indices into a palette of colors

Diese nun in der Spezifikation suchen, um daraus zu schließen, wo das im Header der PNG steht.

Dann entsprechend reagieren.

Auf die Schnelle hab' ich das nicht herausbekommen :-(

[HolgerX]

Hmm..

Das Image als FileStream öffnen und dann nach dem Header (signature) den Chunk 'IHDR' suchen.

http://www.libpng.org/pub/png/spec/1...Structure.html
http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html

Zitat:

The IHDR chunk must appear FIRST. It contains:

Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Width and height give the image dimensions in pixels. They are 4-byte integers. Zero is an invalid value. The maximum for each is 231 in order to accommodate languages that have difficulty with unsigned 4-byte values.

Bit depth is a single-byte integer giving the number of bits per sample or per palette index (not per pixel). Valid values are 1, 2, 4, 8, and 16, although not all values are allowed for all color types.

... und dann hast Du hier schon deine Bit depth...

[Redeemer]

Hab eine Schleife in Uralt-Code von 2011 gefunden. Hab das jetzt etwas angepasst, aber nicht getestet.

Delphi-Quellcode:

type
  TChunkname = array[0..3] of AnsiChar;
  
function SwapEndianness(i: Integer): Integer;
begin
  Result := ((i and $FF000000) shr 24) or
            ((i and $00FF0000) shr 8) or
            ((i and $0000FF00) shl 8) or
            ((i and $000000FF) shl 24);
end;

var
  i: Integer;
  Nutzdaten: Pinteger;
  bs: TBytesStream;
  m: TBytes;
  Chunkname: ^TChunkname;
  Farbtiefe: PByte;
begin
  bs := TBytesStream.Create();
  bs.LoadFromFile('bla.png');
  m := bs.Memory;
  try
    i := 8; // skip header
    while i < bs.Size - 8 do
    begin
      Nutzdaten := @m[i];
      Chunkname := @m[i+4];
      
      if Chunkname^ = 'IHDR' then
      begin
        Farbtiefe := @m[i+8+8];
        Break;
      end;
      
      inc(i, SwapEndianness(Nutzdaten^)+12);
    end;
  finally
    m := 0;
    bs.Free();
  end;
  // Tu was mit Farbtiefe^, in deinem Fall mit 3 vergleichen
end;

[himitsu]

Aber für den Ressourcenschutzblock sollte jemand gesteinigt werden.

Zitat:

Delphi-Quellcode:

  bs := TBytesStream.Create();
  bs.LoadFromFile('bla.png');
  m := bs.Memory;
  try
    ...
  finally
    bs.Free;
  end;

Delphi-Quellcode:

  bs := TBytesStream.Create();
  try
    bs.LoadFromFile('bla.png');
    m := bs.Memory;
    ...
  finally
    bs.Free;
  end;

Denn wenn es im LoadFromFile knallt, dann war's das.

[Harry Stahl]

Hey, danke für den Source.

Ich habe bs.Menory durch bs.bytes ersetzt, dann läuft es.

Allerdings erhalte ich als Wert für FarbTiefe^ immer "8" zurück, egal ob es ein PNG mit 24 Bit-Tiefe oder 8 Bit-Tiefe ist (laut Windows Eigenschaftsanzeige).

Was stimmt da noch nicht?

Sieht so aus, als ob das in dem Fall des 8-Bit PNG ein eine Angabe für den Palleten-Index ist.
Wie finde ich das raus? Abhängig vom Colortype?

Unter Linux scheitert das Einlesen in TImage.Picture, weil die Funktion CreateHalftonePalette nicht unterstützt wird, daher meine Vermutung, dass es ein Wert für die Palette sein könnte (mit Bezug auf die Erklärung oben : "Bit depth is a single-byte integer giving the number of bits per sample or per palette index (not per pixel). Valid values are 1, 2, 4, 8, and 16, although not all values are allowed for all color types.")

[Delphi.Narium]

Vermutlich liest Du ein Byte zuwenig.

Habe mal 'ne Reihe von PNGs im Hexeditor angeschaut.

Bei allen steht der Colortype im 26. Byte. Dort finde ich entweder den Wert 2 oder den Wert 3. Bei allen PNGs enthält das 25. Byte eine 8.

Wenn ich es richtig sehe, müsste es

Delphi-Quellcode:

Farbtyp := @m[i+8+8+1];

sein.

[Harry Stahl]

Ja, genau, das habe ich gerade auch rausgefunden. Dann erhält man den Wert für Colortype. Ist er 3, dann sind es Paletteneinträge, also auf jedenfall etwas, was da gerade unter Linux nicht gelesen werden kann.

Prima, danke, damit ist der WorkAround erst mal erledigt...

[Delphi.Narium]

Jain,

Farbtiefe ist bei i+8+8 schon korrekt. Aber Farbtiefe ist ja nicht Colortype. Der steht im Byte dahinter.

Also könnte sowas dadraus werden (nur hingedaddelt):

Delphi-Quellcode:

type
  TChunkname = array[0..3] of AnsiChar;
  
function SwapEndianness(i: Integer): Integer;
begin
  Result := ((i and $FF000000) shr 24) or
            ((i and $00FF0000) shr 8) or
            ((i and $0000FF00) shl 8) or
            ((i and $000000FF) shl 24);
end;

var
  i: Integer;
  Nutzdaten: Pinteger;
  bs: TBytesStream;
  m: TBytes;
  Chunkname: ^TChunkname;
  Farbtiefe: PByte;
  Farbtyp: PByte;

begin
  bs := TBytesStream.Create();
  try
    bs.LoadFromFile('bla.png');
    m := bs.Memory;
    i := 8; // skip header
    while i < bs.Size - 8 do
    begin
      Nutzdaten := @m[i];
      Chunkname := @m[i+4];
      
      if Chunkname^ = 'IHDR' then
      begin
        Farbtiefe := @m[i+8+8];
        Farbtyp   := @m[i+8+8+1];
        Break;
      end;
      
      inc(i, SwapEndianness(Nutzdaten^)+12);
    end;
  finally
    m := 0;
    bs.Free();
  end;
  // Tu was mit Farbtyp^, in deinem Fall mit 3 vergleichen
end;

[Amateurprofi]

Zitat:

Zitat von himitsu (Beitrag 1460581)

Aber für den Ressourcenschutzblock sollte jemand gesteinigt werden.

Zitat:

Delphi-Quellcode:

  bs := TBytesStream.Create();
  bs.LoadFromFile('bla.png');
  m := bs.Memory;
  try
    ...
  finally
    bs.Free;
  end;

Delphi-Quellcode:

  bs := TBytesStream.Create();
  try
    bs.LoadFromFile('bla.png');
    m := bs.Memory;
    ...
  finally
    bs.Free;
  end;

Denn wenn es im LoadFromFile knallt, dann war's das.

Und wenn es schon beim Create kracht?
Ich habe mir angewöhnt, in etwa so zu formulieren:

Delphi-Quellcode:

var BS:TBytesStream;
begin
   BS:=Nil;
   try
      try
         BS:=TBytesStream.Create();
         ...
         ...
      except
         on E:Exception do ShowMessage(E.Message);
      end;
   finally
      BS.Free;
   end;
end;

Mache ich da einen Denkfehler?

[himitsu]

Kann man auch machen, aber lohnt sich nur, wenn das Create erst irgendwo in der Mitte kommt, bzw. wenn man mehrere Sachen erstellen will.

Wenn es im Create kracht, dann wird der Varible nichts zugewiesen und da es nicht mehr bis zum TRY kommt, ist das Finally auch egal ... also alles OK.
Wenn es dort kracht, dann wird bereits im Constructor die Instanz wieder freigegeben ... dort ist quasi ein Try-Except integriert.



Zusammenfassen von mehreren Try-Finally/Except (einfaches Beispiel) :

Im StringList.Free kann es eigentlich nicht knallen
und auch ein TStringList.Create kann "eigentlich" keinen Fehler erzeugen. (außer es ist garkein RAM mehr frei oder der Speichermanager ist kaputt)
Eigentlich: Falls doch, dann ist so viel im Argen, dass man eh alles vergessen kann.

Delphi-Quellcode:

a := TFileStream.Create('dat.ei');  // hier natürlich das "eine" Schlimme vor dem einen/mehreren Ungefährlichen
b := TStringList.Create;
try
  ...
finally
  b.Free;
  a.Free;
end;

oder eben

Delphi-Quellcode:

b := nil;
a := TFileStream.Create('dat.ei');
try
  b := TStringList.Create;
  ...
finally
  b.Free;
  a.Free;
end;

oder

Delphi-Quellcode:

a := nil;
b := nil;
try
  a := TFileStream.Create('dat.ei');
  b := TStringList.Create;
  ...
finally
  b.Free;
  a.Free;
end;

oder wer ganz auf nummer sicher gehn will

Delphi-Quellcode:

a := TFileStream.Create('dat.ei');
try
  b := TStringList.Create;
  try
    ...
  finally
    b.Free;
  end;
finally
  a.Free;
end;

[Amateurprofi]

Danke himitsu.

[Harry Stahl]

Zitat:

Zitat von Redeemer (Beitrag 1460580)

Hab eine Schleife in Uralt-Code von 2011 gefunden. Hab das jetzt etwas angepasst, aber nicht getestet.

[/DELPHI]

Hast Du evtl. auch noch fertigen Uralt-Code für .BMP? Die können ja auch nur 256 Farben oder weniger und somit dann mit Palette haben, hier muss ich leider die gleiche Prüfung vornehmen...

[Harry Stahl]

Hab hier was gefunden, damit sollte ich zurecht kommen:

http://delphidabbler.com/tips/19

[venice2]

Zitat:

Zitat von Harry Stahl (Beitrag 1460630)

Hab hier was gefunden, damit sollte ich zurecht kommen:

http://delphidabbler.com/tips/19

Das war immer schon so und sagen wir mal recht simple.
Dein Problem oder warum ich nicht geantwortet habe ist! "Linux"
Linux und Win32API ? schon recht verwirrend.

[Harry Stahl]

Zitat:

Zitat von venice2 (Beitrag 1460632)

Zitat:

Zitat von Harry Stahl (Beitrag 1460630)

Hab hier was gefunden, damit sollte ich zurecht kommen:

http://delphidabbler.com/tips/19

Das war immer schon so und sagen wir mal recht simple.
Dein Problem oder warum ich nicht geantwortet habe ist! "Linux"
Linux und Win32API ? schon recht verwirrend.

Ja, das ist in der Tat recht simple. Hatte ich bislang nicht gebraucht, da man nach Einlesen des Bitmaps (per TBitmap.loadfromfile (FN)) ja quasi alle Eigenschaften hat.

Ich habe ja am Anfang erwähnt, dass es um CrossVCL geht. Alle Windows-Funktionen können natürlich nicht durch RTL-Funktionen ersetzt werden, daher ist in CrossVCL auch vieles aus der Win-API nachgebildet, teilweise recht gut, teilweise unvollständig (wie hier in diesem Falle).

So weit ich das jetzt getestet habe, werden folgende Bitmap-Formate unter CrossVCL unterstützt: '*.jpg;*.ico;*.bmp;*.gif;*.tif;*.tiff;*.png'

Nur halt heben nicht, wenn Bilder weniger als 24-Bit haben bzw. eine Farbpalette benötigen.

Die muss ich jetzt halt erst mal ignorieren und zeige statt des Bildes einen entsprechenden Hinweis an (siehe anlg. Screenshot, die Linux-Version meines Dateimananger-Programms).

[venice2]

Zitat:

Nur halt heben nicht, wenn Bilder weniger als 24-Bit haben bzw. eine Farbpalette benötigen.

Um was geht es dir denn?

Du möchtest das Bild anzeigen auch dann wenn es < 24 Bit ist?
Dann konvertiere es doch im Speicher und zeige es dann, ein Hinweis nicht Unterstützt ist nicht die eleganteste Methode.

Wenn viele WinAPI32 Funktionen implementiert werden\sind dann sicherlich auch CreateDIBSection.

Ein Ansatz:
https://stackoverflow.com/questions/...bits-correctly

und schaue mal hier, kann dir aber nicht sagen ob da etwas relevantes für dich enthalten ist.
https://www.delphipraxis.net/1074736-post1.html

Wenn alle stricke reißen (bzgl. des HDC) dann würde ich für CrossVCL, wxWidgets empfehlen.

[Redeemer]

Bei Bitmaps ist die Farbtiefe ein Word an Position 28.
Wenn man davon ausgeht, dass entsprechend der PNG-Spezifikation IHDR der erste Chunk ist, steht der Farbmodus dort immer an Position 25, die Iteration aus meinem Code ist somit überflüssig.