![]() |
High Color --> TrueColor
Hi,
Ich versuche gerade einen 16-Bit HighColor Wert in eine 32-Bit TrueColor Farbe zu konvertieren. Aber irgendwas stimmt da was nicht. Meinen Informationen zufolge ist eine 16-Bit Farbe so aufgebaut: RRRRR GGGGGG BBBBB Meine Funktion sieht so aus:
Delphi-Quellcode:
Das müsste meinen Berechnungen zufolge auch hinhauen... Jetzt habe ich mir mal mit Photoshop ein pinkes 16-Bit Bitmap erstellt und im Hex-Editor geladen:
function HighColorToTrueColor(AColor: Word): TRGBQuad;
begin Result.rgbRed := ((AColor and $F800) shr 11) * Round(255/31); Result.rgbGreen := ((AColor and $07E0) shr 5) * Round(255/63); Result.rgbBlue := (AColor and $001F) * Round(255/31); end; Pink (255 0 255): 1F 7C IntToBin($1F7C) = 00011 111011 11100 Das kann aber ja nicht stimmen. Dieses Pink müsste ja dann eigentlich so aussehn: 11111 000000 11111 => F8 1F Jetzt bin ich etwas verwirrt :wiejetzt: PS: Ach ja für $F81F liefert meine Funktion Pink, also funktioniert sie. PPS: Wenn man die beiden Bytes umdreht: :arrow: 0111110000011111 :arrow: Ok alles klar.. Antworten könnt ihr euch sparen :mrgreen: Gruß Neutral General |
Re: High Color --> TrueColor
also wenn du schon mit reellen Zahlen arbeiten willst, dann wäre es wohl idealer das Round besser zu platzieren,
denn sonst hast du Probleme mit den oberen Farbbereichen. :arrow: schau dir mal an, was deine Funktion bei WEIß zurückliefert z.B.:
Delphi-Quellcode:
(wobei es ganz ohne reelle Zahlen bestimmt noch optimaler wäre)
function HighColorToTrueColor(AColor: Word): TRGBQuad;
begi Result.rgbRed := Round(((AColor and $F800) shr 11) * 255 / 31); Result.rgbGreen := Round(((AColor and $07E0) shr 5) * 255 / 63); Result.rgbBlue := Round( (AColor and $001F) * 255 / 31); end; |
Re: High Color --> TrueColor
Imho hat eine 16-Bit-Farbe einen Alphakanal (wie 32-Bit ja auch), somit gäbe es also 4 Kanäle à 4 Bit.
//Edit: 16/4 ist 4 und nicht 8 :roll: |
Re: High Color --> TrueColor
Zitat:
15 Bit hat eine gleich grosse Farbraumverteilung 3x 5 Bit und 16 Bit hebt den Grünanteil auf 6 Bit an, weil das menschliche Auge in dem Farbspektrum sensitiver ist. Ich habe noch nie, in den ganzen 19 Jahren wo ich programmiere, einen 16 Bit RGBA Wert gesehen. Ich lass mich aber gerne belehren. |
Re: High Color --> TrueColor
Man man einfach mit "and" die relevanten Bits ausschneidet und dann gleich richtig shiftet,
braucht man nicht mehr multiplizieren:
Delphi-Quellcode:
PS: Bitte ausprobieren, ob das so richtig ist und dann in die Code-Library
function HighColorToTrueColor(AColor: Word): TRGBQuad;
begin // RRRRRGGGGGGBBBBB // 00000000RRRRR000 => 8 nach rechts Result.rgbRed := (AColor and $F800) shr 8; // RRRRRGGGGGGBBBBB // 00000000GGGGGG00 => 3 nach rechts Result.rgbGreen := (AColor and $07E0) shr 3; // RRRRRGGGGGGBBBBB // 00000000BBBBB000 => 3 nach links Result.rgbBlue := (AColor and $001F) shl 3; end; |
Re: High Color --> TrueColor
Zitat:
Delphi-Quellcode:
Wenn RRRRR = 11111 dann wäre der Rot-Farbanteil 100%. 31/31
// RRRRRGGGGGGBBBBB
// 00000000RRRRR000 => 8 nach rechts Result.rgbRed := (AColor and $F800) shr 8; RRRRR000 :arrow: 11111000. das wäre 248/255 (97,25%) |
Re: High Color --> TrueColor
Zitat:
Man könnte aber 2 Lookuptabellen mit 64 und mit 32 Byte bereithalten und sich damit die Multiplikation und Division sparen.
Delphi-Quellcode:
function HighColorToTrueColor(AColor: Word): TRGBQuad; const LU_rot_blau:array[0..31] of Byte = (0,8,16,25,33,41,49,58,66,74,82,90,99,107, 115,123,132,140,148,156,165,173,181, 189,197,206,214,222,230,239,247,255); const LU_gruen:array[0..63] of Byte = (0,4,8,12,16,20,24,28,32,36,40,45,49,53,57,61,65,69,73,77,81,85,89,93,97, 101,105,109,113,117,121,125,130,134,138,142,146,150, 154,158,162,166,170,174,178,182,186,190,194,198,202, 206,210,215,219,223,227,231,235,239,243,247,251,255); begin Result.rgbRed := LU_rot_blau[(AColor and $F800) shr 11]; Result.rgbGreen := LU_gruen[(AColor and $07E0) shr 5]; Result.rgbBlue := LU_rot_blau[(AColor and $001F)]; end; |
Re: High Color --> TrueColor
Zitat:
|
Re: High Color --> TrueColor
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz