Icons mit Delphi erstellen

[xaromz]

Hallo,

Zitat von Martin K:

Danke.

Hab grad was sehr merkwürdiges festgestellt und ich habe keine Ahnung warum das so ist:

Irgendwie müssen die Rot- und Blauwerte vertauscht sein.
Hab einfach mal ein paar Farben eingetragen und in die Palette gespeichert.
Dann mit meinem anderen Programm die Palette angeschaut - und:
Aus blau wurde rot und aus rot wurde blau.
Das Grün hat immer gestimmt, nur eben Rot und blau war immer vertauscht.

Beispiel:
Aus der Farbe RGB(64,128,255) im Quellcode wurde RGB(255,128,64) im Programm.

Den Fehler zu beheben ist ja sehr einfach, ich frage mich nur woher er kommt...

Das kann ich Dir sagen:
Der Mensch verwendet die Reihenfolge RGB. So steht sie vermutlich auch in Deiner Paletten-Datei. Da aber die Speicherverwaltung von PCs etwas anders läuft als beim Menschen, werden die Farben hier so gespeichert (in einem DWORD): ABGR, also Alpha (bzw. Dummy-Byte), Blau, Grün, Rot. Wie Du siehst, ist die Reihenfolge genau anders herum, wie man erwarten würde. Wenn Du Dir den Record TPaletteEntry ansiehst, wirst Du feststellen, dass dort auch die Reihenfolge umgedreht ist.

Gruß
xaromz

[Martin K]

Zitat von xaromz:

Wenn Du Dir den Record TPaletteEntry ansiehst, wirst Du feststellen, dass dort auch die Reihenfolge umgedreht ist.

Hm..
Also wenn ich mir eine Variable vom Typ TPaletteEntry anlege, gebe den Variablenname dann im Quellcode ein und drücke einen Punkt dahinter, dann erscheinen die Einträge aber genau in der Reigenfolge: peRed, peGreen und peBlue - ...nicht umgekehrt



Übrigens, betreffende Teile im Quellcode geändert:

Delphi-Quellcode:

//Speichern: 
  for i := 0 to High(Palette^) do 
  begin 
    lpPal^.palPalEntry[i].peRed  := GetBValue(ColorToRGB(Palette^[i])); 
    lpPal^.palPalEntry[i].peGreen:= GetGValue(ColorToRGB(Palette^[i])); 
    lpPal^.palPalEntry[i].peBlue := GetRValue(ColorToRGB(Palette^[i])); 
  end; 

//Laden: 
  for i := 0 to Count-1 do 
    Palette^[i] := RGB(lpPal^.palPalEntry[i].peBlue, 
      lpPal^.palPalEntry[i].peGreen, lpPal^.palPalEntry[i].peRed);

Also an die Reihenfolge BGR anstatt RGB muss ich mich erst gewöhnen, das hab ich ja sonst noch nie gehört/gelesen.....

[xaromz]

Hallo,

Zitat von Martin K:

Zitat von xaromz:

Wenn Du Dir den Record TPaletteEntry ansiehst, wirst Du feststellen, dass dort auch die Reihenfolge umgedreht ist.

Hm..
Also wenn ich mir eine Variable vom Typ TPaletteEntry anlege, gebe den Variablenname dann im Quellcode ein und drücke einen Punkt dahinter, dann erscheinen die Einträge aber genau in der Reigenfolge: peRed, peGreen und peBlue - ...nicht umgekehrt

Da hast Du recht, hab ich verwechselt . In TColor ist die Reihenfolge so. Ich dachte, in TPaletteEntry ist das genauso.

Gruß
xaromz

[Martin K]

Zitat von xaromz:

In TColor ist die Reihenfolge so. Ich dachte, in TPaletteEntry ist das genauso.

Gruß
xaromz

Stimmt, jetzt wo Du's sagst...

Da hab ich mich schon immer gewundert, warum das bei TColor umgekehrt ist...
da wollt ich nämlich immer den HTML-Farbcode nehmen (ist ja genauso in Hexadezimal, wie TColor) und hab mich gewundert, warum da immer eine andere Frabe raus kam...

-----

Zitat von xaromz:

Da aber die Speicherverwaltung von PCs etwas anders läuft als beim Menschen, werden die Farben hier so gespeichert (in einem DWORD): ABGR, also Alpha (bzw. Dummy-Byte), Blau, Grün, Rot.

Jetzt weiß ich auch, warum die Datei 1024 Byte groß ist:
256 Fraben * (3 Byte pro RBG-Farbe + 1 Byte Alpha pro Farbe) = 1024 Byte !!!

Komisch, dabei gibts den Alpha doch nur bei 32 Bit und nicht bei der 8 Bit Farbpalette ?

//Edit:
Oder kann man am End ein 8 Bit Icon mit Alpha-Channel erstellen?????

[xaromz]

Hallo,

Zitat von Martin K:

Jetzt weiß ich auch, warum die Datei 1024 Byte groß ist:
256 Fraben * (3 Byte pro RBG-Farbe + 1 Byte Alpha pro Farbe) = 1024 Byte !!!

Komisch, dabei gibts den Alpha doch nur bei 32 Bit und nicht bei der 8 Bit Farbpalette ?

//Edit:
Oder kann man am End ein 8 Bit Icon mit Alpha-Channel erstellen?????

Nein, das "Alpha"-Byte ist in diesem Fall einfach ein Füll-Byte, damit das Alignment stimmt. Die x86er CPUs arbeiten eben am schnellsten, wenn die Daten auf vier bzw. acht Byte ausgerichtet sind.

Gruß
xaromz

[Martin K]

Achso...

Also hab ich bei jedem Bild, was keine 32 Bit hat, ein Viertel der Dateigröße nur Datenmüll