PNG in TImage falsch dargestellt

[Medium]

Zitat von Rolf Frei:

Mit der PNG Unit von D7 kann man transparente PNG problemlos laden und anzeigen. Dass das in Rio nicht mehr geht hat ganz andere Gründe. Da hat nämlich irgend ein Witzbold einfach den transparenten Teil auf fix schwarz gesetzt.

Ja Moment, das stimmt nur teilweise. Die Farbe wird auf "0" gesetzt, d.h. 100% transparent Schwarz! Sichtbares Schwarz wäre clBlack, oder rgb(0, 0, 0) oder $FF000000 oder 4278190080. Das ist meines Erachtens nach richtig, und letztlich nur ein Initialisieren des soeben ggf. in der Größe geänderten Bitmaps um Restmüll aus dem Speicherbereich sicher zu entfernen.

Das Problem müsste später auftreten; da wo dieses Bitmap auf einen Bildschirm-Canvas gemalt wird. Und DAS ist wiederum Aufgabe der GDI. Eventuell wurde hier etwas an den Aufrufen geändert, das kann ich grad nicht prüfen, aber ich habe gute Erinnerung daran, dass ich mit Alphakanälen unter purer GDI immer irgendwo Probleme hatte. Mindestens in Delphi 7, aber auch noch in 2007. Mit neueren hatte ich bislang nicht mit Transparenzen zu tun.

[Redeemer]

BMP.Assign(PNG) klappt auch in D2009 schon nicht richtig. Die PNG wird zu Schwarz geglättet, die Transparenz bleibt aber. Sprich aus zu 50% deckendem Weiß wird zu 50% deckendes Mittelgrau. Man darf sich nach Assign dann die Scanlines kopieren. Ganz toll.

In Delphi 2005 gab es meines Wissens kein PNG, da musste man PNGDelphi installieren.

[Medium]

Da wird das Problem dann sein, dass .Draw() vermutlich die Transparenzen des Originalbildes wirklich zum Zeichnen benutzt, und ein Blend aus BMP und PNG erstellt. Das wäre für .Draw() auch richtig - aber nicht für .Assign()! Dank Alpha unterscheidet sich Zeichnen erheblich von Kopieren, und das ist in der Tat ein dicker Fehler in der gezeigten Methode. Allerdings auch schon in der alten Version... bei der ich fast vermute, dass .Draw() eigentlich falsch mit Transparenz umgegangen ist, sodass das richtige Verhalten für .Assign() entstand, und gleichzeitig für meine Probleme verantwortlich war.

Klingt für mich jetzt erstmal schlüssig.

[Rolf Frei]

Das Problem ist, dass nun, wenn man ein transparentes PNG auf eine Bitmap assigned eben der Hintergrund schwarz wird. Das war in einer älteren Version der PNGImage nicht so und da hat das mit der Trnasparenz und dem Alphachannel einwandfrei funktioniert. Da war der Hintergrund weiss, nähmlich so wie ein leeres Bitmap eben ist. Durch das fixe setzen der Farbe und einem FillRect wird die "leere" Bitmap mit schwarz "übermmalt" und der Transparente Teil wird schwarz. Meiner Meinung nach ist das falsch oder müsste zumindest mit einem Property gesteuert werden können, welche Farbe man da will.

Durch diese fixe Setzen auf die Farbe 0 (schwarz) ist der AssingTo praktisch unbrauchbar geworden. Ich musste mir dafür eine eigene Routine schreiben, die diese 2 Zeilen nicht enthält, damit mein D7 Programm nach der Migration auf 10.3 noch richtig mit den PNG's umgehen kann. Mir ist echt ein Rätsel wer das da mit fixem schwarzen Hintergund überhaupt so nutzen kann?!

[Medium]

Es gibt bei transparenten Bitmaps eigentlich keinen richtigen oder falschen Hintergrund - zumindest, solange es noch nicht auf das finale Bild gezeichnet wurde, auf dem es angezeigt werden soll. Weiß ist genauso falsch wie Schwarz (und technisch gesehen ist transparent-schwarz (=0) richtiger für "leer" als nicht-transparent-weiß (=$FFFFFFFF)). Was man eigentlich in dieser Situation haben will ist, dass sowohl Farbe als auch Alpha unverändert übernommen werden. "Assigned" eben, im Gegensatz zu "Drawn" wo die Farbwerte anhand der Transparenz miteinander verrechnet werden. Es ist schlicht nicht okay in einer Assign-Methode intern Draw(To) zu verwenden. Stattdessen müssten die Pixel 1:1 kopiert werden.

[Redeemer]

Ich muss meine Aussage von vorhin korrigieren: Mir fällt nämlich auf, dass der von mir beschriebene Bug nur mit TImageList.AddMaked(BMP, clNone) und InsertMasked auftritt (ReplaceMasked unterstützt allgemein keine Alphakanäle), nicht jedoch mit TImage, während mein Bugfix (Kopieren der Scanline-Bytes) in TImageList fehlerfrei funktioniert aber in TImage unter bestimmten Umständen zu einem extrem lustigen Fehler führt (siehe *):

-	Einfach nur Original-Assign	mit Korrektur von Rolf	mit manuellem Kopieren der Scanline-Bytes	mit manuellem Kopieren der Scanline-Bytes und Korrektur von Rolf
TImage.Picture.Graphic := BMP	fehlerfrei mit fehlerfreiem Alphakanal	zu Weiß geglättet komplett ohne Alphakanal	siehe *	Alphakanal wird komplett ignoriert, also alle Pixel in gespeicherter Farbe vollständig deckend
TImageList.AddMasked(BMP, egal)	zu Schwarz geglättet mit fehlerfreiem Alphakanal	zu Weiß geglättet komplett ohne Alphakanal	fehlerfrei mit fehlerfreiem Alphakanal	Alphakanal wird komplett ignoriert, also alle Pixel in gespeicherter Farbe vollständig deckend

* ohne RDP: Die TBitmap zeichnet sich selbst wie folgt auf den Hintergrund, auf dem das TImage liegt: Pixel mit Deckkraft > 0 haben korrekten Alphakanal. Bei Pixeln mit Deckkraft = 0 wird für jeden Kanal einzeln (d.h. ohne Überlauf) der Kanal zum jeweiligen Kanal des Hintergrunds addiert. Das sieht lustig aus, tritt aber normalerweise nicht auf, da die meiste Software es nicht erlaubt, Farben außer Schwarz in transparenten Pixeln zu speichern, und Schwarz fehlerfrei dargestellt würde (Hintergrund + clBlack = Hintergrund).
* in einer RDP-Sitzung: Bild zeichnet nicht vollständig deckende Pixel zwar mit korrektem Alphakanal, aber als ob die Farbe des in der PNG gespeicherten Pixels komplett schwarz wäre. Vollständig deckende Pixel sind fehlerfrei. GDI macht über RDP wirklich was es will.

Mich wundert vor allem, dass TCanvas.Draw überhaupt den Alphakanal des Zielbitmaps schreibt. In TPNGImage.Draw wird in dem Fall TPNGImage.DrawPartialTrans aufgerufen, das wahrscheinlich eine Spezialbehandlung für Bitmaps bietet, die ich aber nicht verstehen/finden kann.
Und mich wundert, dass frischt assignte Bitmaps in TImage fehlerfrei dargetellt werden, in TImageList aber nicht. Die Daten müssen also irgendwo fehlerfrei vorhanden sein.
Auch seltsam: Der zweite Parameter von AddMasked wird in allen oben getesteten Fällen ignoriert.

Ich hab mal mein Beispielprojekt angehängt. imagelist.png enthält drei 16x16-Bilder nebeneinander:

1. weißer Kreis, linke Hälfte ist nur 50% deckend
2. schwarzer Kreis, linke Hälfte ist nur 50% deckend
3. die 16 Standardfarben in der unteren Hälfte sind in der oberen Hälfte mit 0 Deckkraft gespeichert

Das enthaltene Kompilat ist aus D2009 (sieht bei D10.3 genau so aus, ebenso unter Windows 10) und stellt den Zustand aus der vorletzten Spalte (mit manuellem Kopieren der Scanline-Bytes). Davon habe ich auch zwei Bilder angehängt (jeweils ohne RDP).
(Ich weiß, dass der Code Memoryleaks hat.)

[Uwe Raabe]

Zitat von Redeemer:

(Ich weiß, dass der Code Memoryleaks hat.)

Hast du vergessen zu speichern? Der Code ist faktisch nicht existent:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;

type
  TForm1 = class(TForm)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

[scrat1979]

Ich klinke mich mal kurz ein da ich gerade auch einen Code erstellt habe um aus einen Stream (genauer gesagt ein im Stream gespeichertes PNG) in einem TImage anzuzeigen. Das (transparente) PNG wird über LoadFromStream in ein TPNGImage geladen und anschließend in einem TImage angezeigt. Sofern ich nicht völlig blind bin klappt die Darstellung der Transparenzen problemlos... Delphi 10.3.3

[tumo]

Nach weiterem überlegen, probieren und googlen habe ich "herausgefunden", dass der Anzeigefehler nur auftritt, wenn die PNG im ColorMode 3 (Paletten-Modus) geladen wird. @Redeemer hatte also den richtigen Riecher (oder womöglich schon eine Lösung?). Warum genau dadurch Ränder schwarz angezeigt werden, wo die Pixeldaten eig. richtig sind, bleibt mir aber ein Rätsel. Mit der Graphics32 Library habe ich jetzt ein wenig rumprobiert. Sie geht, aber recht umständlich in manchen Belangen. Die essentielle Funktion für mich (PNGs laden) geht nur mit einer extra Unit, die man noch dazu installieren muss :/. Sollte es also eine Lösung für die VCL TImages geben, wäre ich sehr erfreut, diese zu erfahren.

@scrat1979
Wie gesagt, es ist nur bei manchen PNGs. Um genau zu sein bei PNGs im ColorMode 3 (Paletten-Modus)