Icons "fransen" mit der Zeit aus?

[PeterPanino]

Hallo!

Ich verwende eine 16x16 TImageList für die Menü-Icons, mit DrawingStyle = dsTransparent, da ich ausschließlich 32Bit-PNG-Images mit AlphaChannel-Transparenz verwende. Zum Bearbeiten verwende ich den CnWizards TImageList Property-Editor, in dem die Option "Use XP Style Image with Alpha channel" aktiviert ist (was wohl nichts anderes ist als dass die Property DrawingStyle intern auf dsTransparent gesetzt wird?).

Nun haben sich in einer ImageList bis zu 90 Images angesammelt. Dabei ist mir ein merkwürdiger Effekt aufgefallen: Viele der Icons verschlechtern mit der Zeit (nach vielen Hinzufügungen, Ersetzungen und Kompilierungen) ihre Qualität, kriegen fransige Ränder, werden "blurred" und unansehlich.

Hat jemand von euch schon mal diesen Effekt beobachtet? Bei einer Google-Suche habe ich bemerkt, dass andere Leute auch schon dieses Problem hatten, aber nirgends war ein Hinweis auf die Ursache zu finden.

Könnte es sein, dass es durch häufiges Hinzufügen, Ersetzen und Löschen von Icons innerhalb der ImageList zu Bit-Verschiebungen innerhalb der ImageList kommt?

EDIT:

Ich habe jetzt die Probe aufs Exempel gemacht:

1. Die ImageList mit Edit -> Copy in die Zwischenablage kopiert und in die LINKE Textvergleichs-Seite von Beyond Compare eingefügt.

2. Die ImageList im Property-Editor geöffnet und einfach mit OK wieder geschlossen, danach gespeichert.

3. Danach nochmals die ImageList mit Edit -> Copy in die Zwischenablage kopiert und in die RECHTE Textvergleichs-Seite von Beyond Compare eingefügt.

4. In Beyond Compare war jetzt eine Differenz von einem Zeichen zwischen den beiden Versionen zu sehen (s. angehängte Grafik)!

Je öfter man die ImageList also bearbeitet und abspeichert, desto mehr Bitfehler ergeben und summieren sich!!!

Könnt ihr bitte für euch das mal ausprobieren und den Versuch wiederholen? Evtl. müsst ihr eine ImageList mit vielen Images (etwa 90) nehmen und sie öfters ohne etwas zu ändern abspeichern.

Leider kann ich meine ImageList nicht hochladen, da die Bilder Copyright-geschützt sind.

Das sind die Eigenschaften der ImageList:

Code:

object ilBookmarks_Flat: TImageList
  ColorDepth = cd32Bit
  DrawingStyle = dsTransparent

[DeddyH]

Keine Lösung, aber das Problem kenne ich auch mit FMX. Von Zeit zu Zeit muss ich die Images wieder neu in die Liste laden, dann geht es erst einmal wieder, trotzdem extrem nervig.

[madas]

Einfach die Images via res-Datei als Resource in eine DLL packen und dann an gewünschter Stelle im Programm in die ImageList laden.
DrawingStyle der ImageList auf dsTransparent setzen. Die Abmessungen der Bilder in der DLL sollten zu denen der ImageList passen. :)
Zum Erstellen der res-Datei verwenden wir den XN-Resource-Editor.

Projekt für die DLL erstellen mit einer pas-Datei, die alle Konstanten für die Namen der einzelnen Bilder pflegt

Code:

const
  RES_TOOLBAR_BTN_PNG = 'RESOURCE_IDENTIFIER'; // name des Bildes/der Resource in der DLL
  ...

und in der Projektdatei, diese pas-Datei und die res-Datei einbindet.

Code:

library imageContainingResource;

uses
  SysUtils,
  Classes,
  ToolbarImages in 'ToolbarImages.pas';

{$R imageContainingResource.res}
{$R ToolbarImages.res} //Datei mit Images

begin
end.

Und dann im eigentlichen Programm darauf zugreifen.

Code:

uses
  ..., ToolbarImages, ...

const
  TOOLBAR_IMG_RESOURCE_DLL = 'imageContainingResource.dll';

...

procedure LoadPNGFromResourceDll(png: TPNGObject; ResDll: string; const ResName: string);
var
  h: THandle;
begin
  h := 0;
  try
    h := LoadLibrary(PChar(ResDll));
    if (h <> 0) then
      png.LoadFromResourceName(h, ResName);
  finally
    FreeLibrary(h);
  end;
end;

...

procedure TFormTest.InitImgList;
var
  png: TPngImage;
  bmp: TBitmap;
begin
  png := TPngImage.Create;
  bmp := TBitmap.Create;
  try
    LoadPNGFromResourceDll(png, TOOLBAR_IMG_RESOURCE_DLL, RES_TOOLBAR_BTN_PNG);
    bmp.Assign(png);

    // Variante 1
    imgList.Add(bmp, nil);
    // Variante 2
    imgList.AddMasked(bmp, clWhite);

    png.Assign(nil);
    bmp.Assign(nil);
  finally
    bmp.Free;
    png.Free;
  end;

madas

[bra]

Das hängt vermutlich damit zusammen, dass beim Öffnen eines Forms mit Bildern diese in der DFM fast jedesmal geändert werden. Ist bei Versionscontroll-Systemen sehr nervig.

[himitsu]

TImageList (VCL) arbeitet mit der WinAPI und je nach Windowsversion/Updates ergibt das ein anderes Speicherformat, womit sich in der DFM ab und an mal was ändert.

ABER, das Bild wird doch als Bitmap (unkomprimiert) gespeichert und wenn die Bildbearbeitung auch unkomprimiert schuftet, dann dürfte es es keine Verluste geben.

Weiß nicht wie es jetzt ist, aber es klingt noch danach.
"Früher" wurden alle Images in EINEM großen Bild gespeichert, als Raster in einem großen Quadrat, mit X:Y abhängig von der Anzahl der Einzelbilder.
Bei JPEG könnten sich dann benachbarte Bilder beeinflussen und beim bearbeiten/verschieben/neuspeichern würde jedes Mal was verloren gehen.

[PeterPanino]

Entsetzen!! (Noch kein Smiley für diesen Gesichtsausdruck).

Vielen Dank an alle für die Tipps!

Es gehen systematisch Daten verloren, das Problem ist schon länger bekannt und niemand hat bisher etwas dagegen unternommen?? Ich fasse es nicht!! Ein Programm wie die Delphi IDE müsste doch in der Lage sein, Daten fehlerfrei abzuspeichern??

Gibt es denn noch keinen Quality Report bei Embarcadero für diesen Horror?

Leider ist der Tipp mit der DLL zu aufwendig, da ich in der gegenwärtigen Phase sehr häufig Bilder in der ImageList ändere.

[Bernhard Geyer]

Zitat:

Zitat von PeterPanino (Beitrag 1331767)

Entsetzen!! (Noch kein Smiley für diesen Gesichtsausdruck).

Vielen Dank an alle für die Tipps!

Es gehen systematisch Daten verloren, das Problem ist schon länger bekannt und niemand hat bisher etwas dagegen unternommen?? Ich fasse es nicht!! Ein Programm wie die Delphi IDE müsste doch in der Lage sein, Daten fehlerfrei abzuspeichern??

Gibt es denn noch keinen Quality Report bei Embarcadero für diesen Horror?

Was kann Emba dafür das MS meint mit jeder Windows-Version hier das Speicherformat ein bischen anders zu handhaben?

Zitat:

Zitat von PeterPanino (Beitrag 1331767)

Leider ist der Tipp mit der DLL zu aufwendig, da ich in der gegenwärtigen Phase sehr häufig Bilder in der ImageList ändere.

Wir haben bein uns alle Images auf einem zentralen Formular als "ressourcen-dll".
Mit ein paar Helperfunktionen werden dies Images zur laufzeit überall dort geholt wo sie in ImageListe, Button-Images, ... benötigt werden.

[PeterPanino]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1331769)

Was kann Emba dafür das MS meint mit jeder Windows-Version hier das Speicherformat ein bischen anders zu handhaben?

Das hat nichts mit dem Windows-Speicherformat zu tun. In meinem Bericht habe ich beschrieben, dass die Speicherfehler innerhalb kürzester Zeit auftreten.

[Zacherl]

Zitat:

Zitat von PeterPanino (Beitrag 1331773)

Das hat nichts mit dem Windows-Speicherformat zu tun.

Mit dem Speicherformat sicher nicht, aber theoretisch könnte der Fehler trotzdem bei Windows liegen. Müsste mal jemand in der VCL nachschauen, wie der Editor die Daten letztendlich speichert. Wird zur Design-Time tatsächlich ImageList_Write bzw. ImageList_WriteEx verwendet, oder verwaltet Delphi das Bitmap am Ende doch selbst?

Edit:
Habe nachgesehen und es wird tatsächlich ImageList_WriteEx verwendet. Allerdings konnte ich das Problem mit den Bitfehlern bei mir nicht reproduzieren. Du hast zwar Recht, dass sich ein einzelnes Byte beim Abspeichern immer ändern, aber dieses Byte befindet sich noch in den 29 Bytes des ImageList Headers. Über das Format konnte ich nicht viel herausfinden, aber ich nehme mal an, dass es sich schlicht und einfach um einen Timestamp oder sowas handelt. An den RAW Daten der Bitmaps ändert sich bei mir zumindest nichts.

[PeterPanino]

Zitat:

Zitat von Zacherl (Beitrag 1331774)

Habe nachgesehen und es wird tatsächlich ImageList_WriteEx verwendet. Allerdings konnte ich das Problem mit den Bitfehlern bei mir nicht reproduzieren. Du hast zwar Recht, dass sich ein einzelnes Byte beim Abspeichern immer ändern, aber dieses Byte befindet sich noch in den 29 Bytes des ImageList Headers. Über das Format konnte ich nicht viel herausfinden, aber ich nehme mal an, dass es sich schlicht und einfach um einen Timestamp oder sowas handelt. An den RAW Daten der Bitmaps ändert sich bei mir zumindest nichts.

Vielen Dank! Könnte es sein, dass es am CnWizards ImageList-Property-Editor liegt? Ich habe bisher immer diesen verwendet, da die Images im Delphi ImageList-Editor nicht in Originalgröße dargestellt werden und man deshalb zur Beurteilung des Aussehens der Images immer den ImageList-Editor verlassen muss. Beim CnWizards ImageList-Property-Editor hingegen werden die 16x16 Bilder in Originalgröße dargestellt.

[Luckie]

Dann aber bitte dei DLL mit LoadLibraryEx und dem Flag LOAD_LIBRARY_AS_IMAGE_RESOURCE laden.

[himitsu]

Der "Fehler" ist in so weit bekannt, dass sich Leute mit Code-Versionierung (SVN, Git usw.) "aufregen".
Am Bild ändert sich eigentlich nichts (nicht dass mir was aufgefallen wäre), aber die gespeicherten Daten sehen anders aus. (so als würde man mit einem anderen Passwort verschlüsseln)

[madas]

Zitat:

Zitat von Luckie (Beitrag 1331781)

Dann aber bitte dei DLL mit LoadLibraryEx und dem Flag LOAD_LIBRARY_AS_IMAGE_RESOURCE laden.

Danke für den Hinweis. :)

[PeterPanino]

Ich habe jetzt einige Versuchsreihen jeweils mit dem CnWizards ImageList-Property-Editor und mit dem Delphi-ImageList-Editor gemacht. Es scheint so zu sein, dass die Bit-Fehler beim CnWizards ImageList-Property-Editor auftreten.

Das ist ärgerlich, da der Delphi-ImageList-Editor eigentlich ein "prähistorisches" Werkzeug ist und die Bilder nicht in Originalgröße darstellen kann.

So sehen 16x16-Bilder bei mir jeweils im CnWizards ImageList-Property-Editor und im Delphi-ImageList-Editor aus: Siehe angehängte Grafik.

Kennt jemand eine Möglichkeit, 16 x 16 Pixel Bilder im Delphi-ImageList-Editor in Originalgröße darzustellen?

Oder kennt jemand einen besseren ImageList-Editor?

Hier ist nochmals die Vergleichsgrafik:

http://i.imgur.com/9lZs5VM.png

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1331783)

Am Bild ändert sich eigentlich nichts (nicht dass mir was aufgefallen wäre), aber die gespeicherten Daten sehen anders aus. (so als würde man mit einem anderen Passwort verschlüsseln)

Selbst das war bei mir nicht der Fall. In den Binärdaten hat sich zuverlässig immer nur ein Byte geändert, alles andere blieb unverändert. Fürs Versioning ist das natürlich trotzdem ärgerlich.

Zitat:

Zitat von PeterPanino (Beitrag 1331794)

Oder kennt jemand einen besseren ImageList-Editor?

Falls du zufällig sowieso im Besitz der DevExpress Komponenten bist, könntest du die cxImageList verwenden. Deren Editor zeigt die Bilder auch in der richtigen Größe an.

[himitsu]

16x16, aber im Delphi-Editor wird es mit 24x24 angezeigt ... da muß die Ansicht natürlich unscharf sein. :roll:

Also wie groß sind denn nun die Icons und welche Größe ist bei der ImageList eingestellt?

[PeterPanino]

Zitat:

Zitat von himitsu (Beitrag 1331798)

16x16, aber im Delphi-Editor wird es mit 24x24 angezeigt ... da muß die Ansicht natürlich unscharf sein. :roll:

Also wie groß sind denn nun die Icons und welche Größe ist bei der ImageList eingestellt?

Die Größendarstellung der 16x16 Bilder im Delphi-ImageList-Editor hat nichts mit meiner Ausgangsfrage zu tun.

In meinem Eingangsbericht habe ich einen Screenshot der ImageList-Eigenschaften gepostet. Lies dir diesen bitte nochmals durch.

[himitsu]

Das geänderte Byte im Eingangspost ist im Header der ImageList-Daten, aber nicht im Datenbereich der ganzen Bitmap-Pixel.
Und der Grund wurde bereits gerwähnt.

Kompiliere zwei Mal deine Anwendung.
Die EXEn haben zwar paar Unterschiede, aber beide Kompilate machen (standardmäßig) genau das Selbe.

Ansonsten hatte ich noch kein Bild der "veränderten" Icons gesehen.
Nur in dem einen Post mit den Editorvergleichen, wo die Bilder verpixelt sein müssen, da sie mit +50% skaliert dargestellt werden., ohne Antialiasing.

[PeterPanino]

Zitat:

Zitat von himitsu (Beitrag 1331798)

16x16, aber im Delphi-Editor wird es mit 24x24 angezeigt ... da muß die Ansicht natürlich unscharf sein. :roll:

Du unterstellst mir, ich würde die vergrößerte Darstellung im Delphi ImageList Editor mit dem Datenverlust beim Speichern der ImageList verwechseln? Obwohl ich die vergrößerte Darstellung ausdrücklich als unabhängig von meiner Fragestellung bezeichnet habe?

Selten ein so destruktiv-unlogisch-gehässiges Posting gelesen.

[himitsu]

Nein, hab nur gesagt dass dort die Icons "verpixelt" sein müssen, ich keinen Unterschied zwischen den beiden Editoren sehe (außer dem Zoom)
und dass ich sonst kein Bild sah (entweder nicht da oder übersehn), welches das zeigt, was du beschrieben hast ... am Besten noch mit Vorher/Nachher-Vergleich.


Sieht nicht ganz genau gleich aus, da Paint Antialiasing verwendet.

[PeterPanino]

Zitat:

Zitat von Zacherl (Beitrag 1331795)

Falls du zufällig sowieso im Besitz der DevExpress Komponenten bist, könntest du die cxImageList verwenden. Deren Editor zeigt die Bilder auch in der richtigen Größe an.

Habe mir jetzt die DevExpress Trials heruntergeladen. Sieht großartig aus!

[PeterPanino]

Zitat:

Zitat von himitsu (Beitrag 1331814)

Nein, hab nur gesagt dass dort die Icons "verpixelt" sein müssen, ich keinen Unterschied zwischen den beiden Editoren sehe (außer dem Zoom)
und dass ich sonst kein Bild sah (entweder nicht da oder übersehn), welches das zeigt, was du beschrieben hast ... am Besten noch mit Vorher/Nachher-Vergleich.


Sieht nicht ganz genau gleich aus, da Paint Antialiasing verwendet.

Du hast offenbar noch immer nicht kapiert, um was es hier geht. Hast du dir überhaupt mein Eingangs-Posting durchgelesen? Dort geht es darum, dass die Qualität der Bilder sich durch Abspeichern im CnImageList-Editor (wie sich herausgestellt hat) mit der Zeit immer mehr verschlechtert. Es geht überhaupt nicht um die Größe der Bilder in ImageList-Editoren (das war lediglich eine spätere Nebenfrage).

[Sherlock]

Vom CnPack nutze ich nur die IDE-Erweiterungen, vom Rest lasse ich die Finger, da hatte ich in der Vergangenheit leider immer wieder Probleme bemerken müssen, die erst nach mühseliger Suche zum Cn führten...

Sherlock

[PeterPanino]

Zitat:

Zitat von Sherlock (Beitrag 1331850)

Vom CnPack nutze ich nur die IDE-Erweiterungen, vom Rest lasse ich die Finger, da hatte ich in der Vergangenheit leider immer wieder Probleme bemerken müssen, die erst nach mühseliger Suche zum Cn führten...

Sherlock

Da ist der GExperts "Expert Manager" bei der Fehlersuche hilfreich, mit dem man die einzelnen Addins ein- und ausschalten kann.

[Devil1925]

@PeterPanino:
Ich will jetzt niemandem auf die Füsse treten, aber ich glaube was Himitsu sagen wollte ist, dass wir noch keinen Vergleich der Bilder gesehen haben, einmal das Originale und einmal das Sich verschlechterte, welches nach dem Mehrmaligen laden und Speichern entstanden ist.

[PeterPanino]

Zitat:

Zitat von Devil1925 (Beitrag 1331879)

@PeterPanino:
Ich will jetzt niemandem auf die Füsse treten, aber ich glaube was Himitsu sagen wollte ist, dass wir noch keinen Vergleich der Bilder gesehen haben, einmal das Originale und einmal das Sich verschlechterte, welches nach dem Mehrmaligen laden und Speichern entstanden ist.

Hier ist der Vergleich der Bilder:

http://i.imgur.com/VVdzycu.png

[PeterPanino]

Ich habe jetzt nochmals mit einer ImageList, die etwa 100 16x16 Images enthält, eine Versuchsreihe mit mehreren hundert Durchgängen gemacht:

1. ImageList im CnWizards ImageList Editor öffnen
2. Eines der Bilder ersetzen oder ein Bild hinzufügen
3. Schließen mit OK
4. Zwischendurch auch mal das Projekt schließen und wieder öffnen

Dabei habe ich immer mal wieder von einigen gleichbleibenden Bildern einen Screenshot des Selected Image gemacht. Das sind die Ergebnisse:

http://i.imgur.com/Q1gZkRGl.jpg

Man beachte, dass sich nur die Bereiche mit partieller Transparenz verschlechtern.

[himitsu]

Aaaaaaaalso, wenn man das so sieht, dann ware meine Vermutung, dass der Editor zwar mit Teiltransparenzen klar kommt, aber beim Kopieren der Bilddaten ebenfalls die Transparenzen auf die Bilddaten anwendet, welche parallel nochmal als "Maske"/AlfaKanal vorhanden sind.
Die Transparenz multipliziert sich oder die Farben in den Bilddaten werden "schwächer" (transparenter).

Für den Anfang könnte man die Bilder wieder exportieren und mit einem Bildprogramm sich die Bilddaten und den Alfakanal ansehen, wo nun die Veränderung auftritt.