PNG in TImage falsch dargestellt

[Rolf Frei]

@OP
Hast du denn nun schon mal die VCL.Imaging.PNGimages.pas in dein loakels Anwendungsverzeichnis kopiert und die beiden von mir erwähnten Zeilen gelöscht und neu kompiliert?

@venice2
TImage und TPNGImage haben nichts miteinander zu tun. TPNGImage ist die Grafikklasse (TGraphic), die ein PNG Bild rendert und darstellt. TImage ist eine allgmeine Darstellungskomponente (TControl), die nichts anderes macht als die Paint Funktion der geladenen Graphic-Klasse aufzurufen. Dieses Problem hier hat mit der TImage Komponente nichts zu tun, sondern betrifft die Implementation der TPNGImage Klasse.

[tumo]

@Rolf Frei
Ach ja. Das ist im Eifer des Gefechtes etwas in Vergessenheit geraten. Hab es gerade mal probiert, ändert leider nichts an der Situation, besagte PNG wird mit schwarzem Hintergrund dargestellt :/.
Hier mein Quellcode:

Delphi-Quellcode:

png := TPNGImage.Create;
    png.LoadFromFile(Path);
    bmp := TBitmap.Create;
    bmp.Assign(png); // <-- TPNGImage AssignTo() ist modifiziert. Es fehlen das Brush.Color := 0 sowie das FillRect.
    Image3.Picture.Graphic := bmp;

@Redeemer
Dieser Code funktioniert . So oder so ähnlich hätte ich es natürlich auch gelöst . Spaß beiseite, vielen Dank!
Dass die Bilder nicht optimal gespeichert sind, hab ich auch schon gemerkt. Wie gesagt, manche sind mir so gegeben, andere sind von mir in Paint.net erstellt, keine Ahnung, warum es da solche Späßchen generiert.

Jetzt hat das Problem einen Workaround. Warum Delphi überhaupt eine Unterscheidung zwischen Partial- und BitTransparency macht, bleibt mir ein Rätsel. Hat das einen entscheidenden Vorteil?
Mein Problem ist jetzt jedenfalls behoben bzw. umgangen. Danke euch.

Habe es jetzt folgendermaßen gelöst (mit der Prozedur von Redeemer):

Delphi-Quellcode:

var
  gfx: TPicture;
begin
  gfx := TPicture.Create;
  gfx.LoadFromFile(Path);
  if gfx.Graphic is TPNGImage then
    Deindex(gfx.Graphic as TPNGImage);
  Image3.Picture.Assign(gfx);
end;

[Redeemer]

Zitat von tumo:

Jetzt hat das Problem einen Workaround. Warum Delphi überhaupt eine Unterscheidung zwischen Partial- und BitTransparency macht, bleibt mir ein Rätsel. Hat das einen entscheidenden Vorteil?[/DELPHI]

ptmBit ist deutlich einfacher (performanter) zu zeichnen als ptmPartial, wo man Alpha Blending (Porter-Duff OVER) durchführen muss.

Unterstützt dein PNGDelphi ohne meinen Algorithmus 4-Bit+Alpha und 1-Bit+Alpha? Ich hab mal zwei Beispiele angehängt.

[TurboMagic]

Zitat von Redeemer:

Zitat von tumo:

Jetzt hat das Problem einen Workaround. Warum Delphi überhaupt eine Unterscheidung zwischen Partial- und BitTransparency macht, bleibt mir ein Rätsel. Hat das einen entscheidenden Vorteil?[/DELPHI]

ptmBit ist deutlich einfacher (performanter) zu zeichnen als ptmPartial, wo man Alpha Blending (Porter-Duff OVER) durchführen muss.

Unterstützt dein PNGDelphi ohne meinen Algorithmus 4-Bit+Alpha und 1-Bit+Alpha? Ich hab mal zwei Beispiele angehängt.

Fehlten da die Anhänge?
Bei mir war nur der Rahmen um den Bwereich herum da, aber kein Inhalt.

[Redeemer]

Bei mir sind da Bilder. Was für einen Browser benutzt du? Ich habe Firefox 75.
Hab es dir aber nochmal aus 7z angehängt.

[tumo]

Zitat von Redeemer:

ptmBit ist deutlich einfacher (performanter) zu zeichnen als ptmPartial, wo man Alpha Blending (Porter-Duff OVER) durchführen muss.

Stimmt.
Aber auch nur, wenn es korrekt geht .

Was deine Bilder angeht, mein Delphi (bzw. mein pngimage) kann die problemlos darstellen. Ist wohl wirklich nur bei BitTransparency.

[tumo]

Ich muss leider noch mal stören.

@Redeemer
Dein Code hat ein Problem mit 2bit Palettenbildern. Beim drüberschauen ist mir jedoch kein Fehler aufgefallen. 8bit und 4bit geht dafür aber super
Falls es hilfreich ist, in deinem Code scheinen tatsächlich keine Fehler zu sein, die Daten von der Source-Scanline sind falsch(?). Bei meinem Testbild in Zeile y=4 hat er für x2=1 den Scanline-Wert 50 (oder 0011 0010). Abgesehen davon, dass die damit korrespondierenden Pixel die Farbreihenfolge (nach Chroma) von 01 01 10 11 haben müssten (was in den Scanline-Daten gleich garnicht stehen kann, aufgrund der Transparenz von 00 und 01 aber nicht auffällt), scheint etwas an ebendiesem Punkt falsch zu laufen.