[GELÖST] Bestandteile einer Farbe wieder in HEX?

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

	CO2 ehemals "SirMO" Betreff: [GELÖST] Bestandteile einer Farbe wieder in HEX?	Mo, Apr 14, 2014 21:27 Antworten mit Zitat
Hallo, ich bin mir ziemlich sicher, dass dieses Thema schonmal beantwortet wurde, finde den Thread allerdings nicht (weiß auch nicht, ob das hier war oder im englischen Forum )... Naja, wie auch immer, folgendes Problem: Möchte man eine HEX-Farbe alá #FF00FF00 umwandeln, so benutzt man ja folgenden "Algorithmus": BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local a:Byte = (hexcolor & $FF000000) / $1000000 Local r:Byte = (hexcolor & $FF0000) / $10000 Local g:Byte = (hexcolor & $FF00) / $100 Local b:Byte = (hexcolor & $FF) Meine simple Frage: Wie kehre ich das um - also wie komme ich von den vier Einzelwerten wieder auf den Hex-Wert der Farbe? EDIT: Das Problem hat sich gerade teilweise geklärt, folgender Code erzeugt schonmal das richtige bitmuster (glaube ich) BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local res:Int = (a Shl 24) + (r Shl 16) + (g Shl 8) + b Allerdings ist res bei #FFFFFFFF -1... Hat das Auswirkungen?
mfG, CO² Sprachen: BlitzMax, C, C++, C#, Java Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

CO2

ehemals "SirMO"

Betreff: [GELÖST] Bestandteile einer Farbe wieder in HEX?

Mo, Apr 14, 2014 21:27
Antworten mit Zitat

Hallo,
ich bin mir ziemlich sicher, dass dieses Thema schonmal beantwortet wurde, finde den Thread allerdings nicht (weiß auch nicht, ob das hier war oder im englischen Forum Embarassed

)... Naja, wie auch immer, folgendes Problem: Möchte man eine HEX-Farbe alá #FF00FF00 umwandeln, so benutzt man ja folgenden "Algorithmus": BlitzMax: [AUSKLAPPEN]

Local a:Byte = (hexcolor & $FF000000) / $1000000
Local r:Byte = (hexcolor & $FF0000) / $10000
Local g:Byte = (hexcolor & $FF00) / $100
Local b:Byte = (hexcolor & $FF)

Meine simple Frage: Wie kehre ich das um - also wie komme ich von den vier Einzelwerten wieder auf den Hex-Wert der Farbe?

EDIT: Das Problem hat sich gerade teilweise geklärt, folgender Code erzeugt schonmal das richtige bitmuster (glaube ich) BlitzMax: [AUSKLAPPEN]

Local res:Int = (a Shl 24) + (r Shl 16) + (g Shl 8) + b

Allerdings ist res bei #FFFFFFFF -1... Hat das Auswirkungen?

mfG, CO²

Sprachen: BlitzMax, C, C++, C#, Java
Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

Zuletzt bearbeitet von CO2 am Di, Apr 15, 2014 0:01, insgesamt einmal bearbeitet

	Holzchopf Meisterpacker	Mo, Apr 14, 2014 23:13 Antworten mit Zitat
Nein, das hat keine Auswirkungen. Int und Long in BlitzMax sind immer signed, das heisst, das höchstwertige Bit gibt das Vorzeichen an. Bei $FFFFFFFF hast du 8x 1111b, also alle Bits auf 1. Somit auch das Vorzeichenbit. Das mit dem -1...-was-auch-immer liegt also lediglich daran, wie der Computer die ganzen Einsen interpretiert. MfG Holzchopf
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

Mo, Apr 14, 2014 23:13
Antworten mit Zitat

Nein, das hat keine Auswirkungen. Int und Long in BlitzMax sind immer signed, das heisst, das höchstwertige Bit gibt das Vorzeichen an. Bei $FFFFFFFF hast du 8x 1111b, also alle Bits auf 1. Somit auch das Vorzeichenbit. Das mit dem -1...-was-auch-immer liegt also lediglich daran, wie der Computer die ganzen Einsen interpretiert.

MfG
Holzchopf

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	PhillipK	Mo, Apr 14, 2014 23:32 Antworten mit Zitat
Wenn du Windows7 hast, kannst du das ganze auch wunderbar im internen taschenrechner nachspielen Stell dies auf programmierer ein und klick die bit-positionen an (vorher auf 32bit umstellen) Wie auch immer, #FFFFFFFF entspricht 4 bytes a 255 (#FF), als signed integer als -1 dargestellt, das passt so. Alternativ meine ich das es auch einen "Hex" befehl unter blitzmax gab. BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Print Hex(-1) Siehe: https://www.blitzforum.de/help/Hex Damit kriegst du den Hex-string, wie du ihn auch in der IDE eingeben kannst ($ff wird automatisch als 255 interpretiert als beispiel) zum printen. Damit kannst du das ganze dann selbst nochmal prüfen [quote=CO2]BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local a:Byte = (hexcolor & $FF000000) / $1000000 Local r:Byte = (hexcolor & $FF0000) / $10000 Local g:Byte = (hexcolor & $FF00) / $100 Local b:Byte = (hexcolor & $FF) [/quote] Das kannst auch anders schreiben. Mir persönlich ist das etwas zu kryptisch. Zum "zusammenbauen" verwendest du ja schon bitshifts, das kannst auch zum auseinandernehmen verwenden: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local a:Byte = (hexcolor & $FF000000) Shr 24 Local r:Byte = (hexcolor & $00FF0000) Shr 16 Local g:Byte = (hexcolor & $0000FF00) Shr 8 Local b:Byte = (hexcolor & $000000FF) Die zusätzlichen nullen habe ich der übersichtlichkeit hinzugefügt, eine auswirkung haben sie nicht. Wichtig ist nur das wissen um "shr" - bedeutet Shift-Right (bits um X stellen nach rechts verschieben) Mal eine kleine ausführung: Binär: 00 00 00 10 entspricht der Zahl 2. Wendest du hierrauf ein Shr 1 an, wird daraus Binär: 00 00 00 01 entspricht der Zahl 1. Links werden die "leeren" stellen mit 0er bits aufgefüllt, rechts werden die überschüssigen einfach "entfernt" Ein byte besteht immer aus 2 "Hex stellen", also zb FF. Ein byte hat 8 bit, was die zahlen erklärt. Das Vierte byte wird an die position des ersten geshiftet: Shr 24 ( 3* 8 = 24, es werden 24 stellen Rechts entfernt und 24 0en links angefügt.) Das Dritte byte wird an die position des ersten geshiftet: Shr 16 (2* 8 = 16) undsoweiter. Das selbe wendest du umgekehrt an: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local res:Int = (a Shl 24) + (r Shl 16) + (g Shl 8) + b Hier shiftest du die ersten bytes wieder an die entsprechenden positionen. Beim kombinieren mit "+" musst du aber vorsichtig sein, wobei es in diesem speziellen fall funktionieren wird. Nur als anmerkung

PhillipK

Mo, Apr 14, 2014 23:32
Antworten mit Zitat

Wenn du Windows7 hast, kannst du das ganze auch wunderbar im internen taschenrechner nachspielen Smile

Stell dies auf programmierer ein und klick die bit-positionen an (vorher auf 32bit umstellen)

Wie auch immer, #FFFFFFFF entspricht 4 bytes a 255 (#FF), als signed integer als -1 dargestellt, das passt so.
Alternativ meine ich das es auch einen "Hex" befehl unter blitzmax gab.
BlitzMax: [AUSKLAPPEN]

Print Hex(-1)

Siehe: https://www.blitzforum.de/help/Hex
Damit kriegst du den Hex-string, wie du ihn auch in der IDE eingeben kannst ($ff wird automatisch als 255 interpretiert als beispiel) zum printen. Damit kannst du das ganze dann selbst nochmal prüfen Smile

[quote=CO2]BlitzMax: [AUSKLAPPEN]

Local a:Byte = (hexcolor & $FF000000) / $1000000
Local r:Byte = (hexcolor & $FF0000) / $10000
Local g:Byte = (hexcolor & $FF00) / $100
Local b:Byte = (hexcolor & $FF)

[/quote]

Das kannst auch anders schreiben. Mir persönlich ist das etwas zu kryptisch. Zum "zusammenbauen" verwendest du ja schon bitshifts, das kannst auch zum auseinandernehmen verwenden:

BlitzMax: [AUSKLAPPEN]

Local a:Byte = (hexcolor & $FF000000) Shr 24
Local r:Byte = (hexcolor & $00FF0000) Shr 16
Local g:Byte = (hexcolor & $0000FF00) Shr 8
Local b:Byte = (hexcolor & $000000FF)

Die zusätzlichen nullen habe ich der übersichtlichkeit hinzugefügt, eine auswirkung haben sie nicht.
Wichtig ist nur das wissen um "shr" - bedeutet Shift-Right (bits um X stellen nach rechts verschieben)

Mal eine kleine ausführung:

Binär: 00 00 00 10
entspricht der Zahl 2.
Wendest du hierrauf ein Shr 1 an, wird daraus
Binär: 00 00 00 01
entspricht der Zahl 1.

Links werden die "leeren" stellen mit 0er bits aufgefüllt, rechts werden die überschüssigen einfach "entfernt"
Ein byte besteht immer aus 2 "Hex stellen", also zb FF. Ein byte hat 8 bit, was die zahlen erklärt.

Das Vierte byte wird an die position des ersten geshiftet: Shr 24 ( 3* 8 = 24, es werden 24 stellen Rechts entfernt und 24 0en links angefügt.)
Das Dritte byte wird an die position des ersten geshiftet: Shr 16 (2* 8 = 16) undsoweiter.

Das selbe wendest du umgekehrt an:
BlitzMax: [AUSKLAPPEN]

Local res:Int = (a Shl 24) + (r Shl 16) + (g Shl 8) + b

Hier shiftest du die ersten bytes wieder an die entsprechenden positionen.
Beim kombinieren mit "+" musst du aber vorsichtig sein, wobei es in diesem speziellen fall funktionieren wird. Nur als anmerkung Smile

	CO2 ehemals "SirMO"	Mo, Apr 14, 2014 23:48 Antworten mit Zitat
Vielen Dank für die Antworten, @ Holzchopf: Ich dachte, dass alle Bits auf 1 immer die Hälfte der "Kapazität" negativ wäre, also bspw. 0111 1111 entspricht 127 1111 1111 entspricht -128, deshalb war ich etwas erstaunt, als das Ergebnis -1 war... @ PhillipK: Für den Hex-Befehl benötige ich allerdings die Value, welche ich durch zusammenfügen der Einzelwerte bekomme... Zitat: Das kannst auch anders schreiben. Mir persönlich ist das etwas zu kryptisch. Ehrlich gesagt ist das ein Code, den ich vor Jahren mal aus einem Thread kopiert hatte, und bisher immer ohne groß darüber nachzudenken benutzt habe (brauchte ihn bisher auch nur ein-, zweimal zum testen)... Das Shiften an sich ist mir schon ein Begriff, hatte es allerdings aus dem Hex-To-Einzelwerte-Algorithmus nicht ableiten können (aus o.g. Grund)... Zitat: Beim kombinieren mit "+" musst du aber vorsichtig sein, wobei es in diesem speziellen fall funktionieren wird. Deshalb hier der geupdatete Code mit bitweisem Oder: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Local res:Int = (a Shl 24) \| (r Shl 16) \| (g Shl 8) \| b
mfG, CO² Sprachen: BlitzMax, C, C++, C#, Java Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

CO2

ehemals "SirMO"

Mo, Apr 14, 2014 23:48
Antworten mit Zitat

Vielen Dank für die Antworten,

@ Holzchopf:
Ich dachte, dass alle Bits auf 1 immer die Hälfte der "Kapazität" negativ wäre, also bspw.
0111 1111 entspricht 127
1111 1111 entspricht -128,
deshalb war ich etwas erstaunt, als das Ergebnis -1 war...

@ PhillipK:
Für den Hex-Befehl benötige ich allerdings die Value, welche ich durch zusammenfügen der Einzelwerte bekomme... Wink

Zitat:

Das kannst auch anders schreiben. Mir persönlich ist das etwas zu kryptisch.

Ehrlich gesagt ist das ein Code, den ich vor Jahren mal aus einem Thread kopiert hatte, und bisher immer ohne groß darüber nachzudenken benutzt habe Embarassed

(brauchte ihn bisher auch nur ein-, zweimal zum testen)...
Das Shiften an sich ist mir schon ein Begriff, hatte es allerdings aus dem Hex-To-Einzelwerte-Algorithmus nicht ableiten können (aus o.g. Grund)...

Zitat:

Beim kombinieren mit "+" musst du aber vorsichtig sein, wobei es in diesem speziellen fall funktionieren wird.

Deshalb hier der geupdatete Code mit bitweisem Oder:
BlitzMax: [AUSKLAPPEN]

Local res:Int = (a Shl 24) | (r Shl 16) | (g Shl 8) | b

mfG, CO²

Sprachen: BlitzMax, C, C++, C#, Java
Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

	DAK	Di, Apr 15, 2014 0:10 Antworten mit Zitat
Nennt sich Zweierkomplement, das Phänomen. Die Zählung geht im Zweierkomplement so (8 Bit als Beispiel): Code: [AUSKLAPPEN] [EINKLAPPEN] 0000 0000 = 0 0000 0001 = 1 0000 0010 = 2 ... 0111 1111 = 127 (höchster Wert) 1000 0000 = -128 (höchster Wert+1 = niedrigster Wert) 1000 0001 = -127 1000 0010 = -126 ... 1111 1111 = -1 0000 0000 = 0 Der Sinn dahinter ist, dass Höchste Zahl + 1 = Niedrigste Zahl, und vor allem dass -1 + 1 = 0. Wäre es so wie du schreibst, dann wäre höchste Zahl + 1 = 0 und 0-1 = -128. Mit dem Zweierkomplement kann man die Rechenregeln in Binär direkt ohne Sonderfälle verwenden um die Rechenregeln in Dezimal abzubilden. Was du beschreibst ist ein Zahlensystem mit Vorzeichen und Betrag, also du hast das 1. Bit, was das Vorzeichen darstellt, und alle anderen Bit, die den Wert darstellen (so wie wir es mit dem Dezimalsystem gewohnt sind). Das ist aber leider für Computer schlecht, weil es so viele Sonderfälle hat. So muss man bei dem addieren mit einer positiven Zahl oder einer negativen Zahl jeweils eine andere Rechenart verwenden: Code: [AUSKLAPPEN] [EINKLAPPEN] 4 + (-1) = 4 - 1 4 + (+1) = 1 + 1 Deswegen hat man dann das Einerkomplement erfunden, wo im Gegensatz zum Vorzeichen und Betrag die Zählrichtung bei den negativen Zahlen umgekehrt wird. Sie werden sozusagen direkt als negative Zahl gespeichert, statt als Betrag mit negativem Vorzeichen. Hier geht zwar Code: [AUSKLAPPEN] [EINKLAPPEN] 4 + (-1) = 4 + (-1) 4 + (+1) = 1 + 1 direkt in den eingebauten Rechenregeln (also kein Umschalten im Vorzeichen mehr), aber es gibt die 0 immer noch doppelt (-0 (binär 1111 1111) und +0 (binär 0000 0000)), was heißt, dass -0 + 1 = +0, was man also mittels Sonderfall extra abfangen müsste. Sonderfälle sind böse, deswegen hat man dann den Zweierkomplement erfunden, wo alle negativen Zahlen um 1 verschoben werden, und es somit kein -0 mehr gibt. Das ist dann das, was ich oben detailierter erklärt habe.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Di, Apr 15, 2014 0:10
Antworten mit Zitat

Nennt sich Zweierkomplement, das Phänomen.

Die Zählung geht im Zweierkomplement so (8 Bit als Beispiel):

Code: [AUSKLAPPEN]

0000 0000 = 0
0000 0001 = 1
0000 0010 = 2
...
0111 1111 = 127 (höchster Wert)
1000 0000 = -128 (höchster Wert+1 = niedrigster Wert)
1000 0001 = -127
1000 0010 = -126
...
1111 1111 = -1
0000 0000 = 0

Der Sinn dahinter ist, dass Höchste Zahl + 1 = Niedrigste Zahl, und vor allem dass -1 + 1 = 0.

Wäre es so wie du schreibst, dann wäre höchste Zahl + 1 = 0 und 0-1 = -128.

Mit dem Zweierkomplement kann man die Rechenregeln in Binär direkt ohne Sonderfälle verwenden um die Rechenregeln in Dezimal abzubilden.

Was du beschreibst ist ein Zahlensystem mit Vorzeichen und Betrag, also du hast das 1. Bit, was das Vorzeichen darstellt, und alle anderen Bit, die den Wert darstellen (so wie wir es mit dem Dezimalsystem gewohnt sind).
Das ist aber leider für Computer schlecht, weil es so viele Sonderfälle hat. So muss man bei dem addieren mit einer positiven Zahl oder einer negativen Zahl jeweils eine andere Rechenart verwenden:
Code: [AUSKLAPPEN]

4 + (-1) = 4 - 1
4 + (+1) = 1 + 1

Deswegen hat man dann das Einerkomplement erfunden, wo im Gegensatz zum Vorzeichen und Betrag die Zählrichtung bei den negativen Zahlen umgekehrt wird. Sie werden sozusagen direkt als negative Zahl gespeichert, statt als Betrag mit negativem Vorzeichen.
Hier geht zwar
Code: [AUSKLAPPEN]

4 + (-1) = 4 + (-1)
4 + (+1) = 1 + 1

direkt in den eingebauten Rechenregeln (also kein Umschalten im Vorzeichen mehr), aber es gibt die 0 immer noch doppelt (-0 (binär 1111 1111) und +0 (binär 0000 0000)), was heißt, dass -0 + 1 = +0, was man also mittels Sonderfall extra abfangen müsste.
Sonderfälle sind böse, deswegen hat man dann den Zweierkomplement erfunden, wo alle negativen Zahlen um 1 verschoben werden, und es somit kein -0 mehr gibt. Das ist dann das, was ich oben detailierter erklärt habe.

Gewinner der 6. und der 68. BlitzCodeCompo

Zuletzt bearbeitet von DAK am Di, Apr 15, 2014 10:22, insgesamt einmal bearbeitet

	CO2 ehemals "SirMO"	Di, Apr 15, 2014 10:01 Antworten mit Zitat
Ja, das macht Sinn... Danke, wieder was gelernt.
mfG, CO² Sprachen: BlitzMax, C, C++, C#, Java Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti