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.