32 Bit pro Farbkomponente? - amiga-news.de Forum

amiga-news

DEUTSCHE VERSION

|

|

|

|

|

|

amiga-news.de Forum > Programmierung > 32 Bit pro Farbkomponente?

[ - Search - New posts - Register - Login - ]

-1-

[ - Post reply - ]

2004-07-18, 02:12 h

Mad_Dog
Posts: 1944
User

In meinem C-Kurs habe ich gerade eine Lektion zum Thema "Farben" geschrieben.

Allerdings bin ich noch nicht dahinter gestiegen, warum man bei einigen AmigaOS API-Funktionen für jede Farbkomponente 32 Bit angeben muß. Sicher: Die Funktionen sind eben so definiert - aber ergibt sich daraus irgendein technischer Vorteil?

Hier ein Beispielcodeschnipsel:

code:

cyan_pen = ObtainBestPen(Fenster->WScreen->ViewPort.ColorMap,
                           0x00000000,0xFFFFFFFF,0xFFFFFFFF,
                           PRECISION_EXACT, TAG_DONE);

Das sind je 32 Bit für Rot, Grün und Blau... das ermöglicht natürlich mehr Farbabstufungen, aber eine Grafikkarte mit 96 Bit Farbtiefe ist mir bis jetzt noch nicht untergekommen...

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-18, 08:02 h

thomas
Posts: 7718
User

Zukunfts-Kompatibiliät. Man hat das beim Umstieg von OCS auf AGA gelernt: Alle Programme, die mit IFF-Paletten arbeiteten haben nur die oberen 4 Bits gefüllt. Dadurch sehen die Bilder auf AGA-Rechnern viel zu dunkel aus. Jetzt hat man definiert, daß alle 32 Bits gefüllt werden müssen, dadurch kann das nicht mehr passieren, man ist bis in alle Ewigkeit sicher, selbst wenn irgendwann die 48bit-Grafikkarte erfunden wird.

Wichtig ist natürlich, daß die Regeln auch angewendet werden. Also nicht nur (farbe << 24), sondern ((farbe << 24) | (farbe << 16) | (farbe <<

| farbe).

Ich benutze dafür üblicherweise eine Funktion wie diese:

ULONG expand (UBYTE c)
{
return ((c << 24) | (c << 16) | (c <<

| c);
}

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]

2004-07-18, 13:24 h

Mad_Dog
Posts: 1944
User

Zitat:
Original von thomas:

Zukunfts-Kompatibiliät.

Sowas habe ich mir schon gedacht. Aber wirklich benutzt werden wahrscheinlich nur 24 Bit (je 8 Bit pro Farbkomponente)?

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-18, 13:34 h

DariusBrewka
Posts: 899
[Banned user]

Ich denke mal benutzt werden soviele wie es das untergebene System erlaubt, d.h. AGA -> 24 Bit, ECS -> 12 Bit.

Man hat seitens Commodore damals aber wirklich weit in die Zukunft gedacht, denn auf eine Auflösung von 65536*65536 können wir noch eine weile warten. Denke 16 Bit pro Kanal hätten genügt, 8 Bit sind eigentlich zu wenig, wenn ich manchmal einige DVD's schaue sieht man in Horizont öfters harte Übergänge.

[ - Answer - Quote - Direct link - ]

2004-07-18, 13:43 h

Mad_Dog
Posts: 1944
User

Zitat:
Original von DariusBrewka:

Man hat seitens Commodore damals aber wirklich weit in die Zukunft gedacht, denn auf eine Auflösung von 65536*65536 können wir noch eine weile warten. Denke 16 Bit pro Kanal hätten genügt, 8 Bit sind eigentlich zu wenig, wenn ich manchmal einige DVD's schaue sieht man in Horizont öfters harte Übergänge.

Mit Auflösung hat das nichts zu tun (es ging um Farbtiefe).
2^96 Farbabstufungen - das wäre schon häftig - und auch ziemlich sinnlos, da das menschliche Auge garnicht soviele Farben unterscheiden kann...
Bei den DVD's wird das Problem vermutlich an der Kompression liegen...

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-19, 13:28 h

Mad_Dog
Posts: 1944
User

Habe nochmal auf der Developer CD herumgestöbert. Da stand auch was über Zukunftskompatiblität. Allerdings habe ich nirgends etwas darüber gefunden, welche Bits jetzt tatsächlich verwendet werden.

Ich nehme mal an, daß alle verwendet werden und diese dann irgendwie verrechnet werden.

Denn ein Rotwert von z.B. 1203ACFF ist ja was anderes, wie ein Rotwert FFFFFFFF.

Gibt's irgendwo genauere Dokumentation zu dem Thema?

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-19, 13:58 h

thomas
Posts: 7718
User

Es sollte (darf) dich nicht interessieren, wieviele Bits benutzt werden. Geh davon aus, daß alle benutzt werden.

Praktisch werden nur die oberen 8 Bits benutzt. Mehr als 256 Möglichkeiten bekommt man mit einem Byte nicht dargestellt, wie willst du da noch etwas verrechnen ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]

2004-07-19, 14:06 h

Solar
Posts: 3680
User

Zitat:
Original von Mad_Dog:

2^96 Farbabstufungen - das wäre schon häftig - und auch ziemlich sinnlos, da das menschliche Auge garnicht soviele Farben unterscheiden kann...

64Bit RGBA (16Bit pro Kanal auf Rot - Grün - Blau - AlphaChannel) sind heute state-of-the-art. Das sind schon mal doppelt so viele Farbabstufungen, wie man für "unterscheidbar" hält (24bit RGB).

Eine SGI Octane leistete schon 1997 48Bit RGBA...

...und auf einmal sieht die so überkandidelt wirkende Commo-API gar nicht mehr so "übermäßig", da kein AlphaChannel...

[ - Answer - Quote - Direct link - ]

2004-07-19, 14:16 h

Mad_Dog
Posts: 1944
User

@Thomas:

Ist in Deiner Aussage nicht ein Widerspruch?

Was ich mit Verrechnen meine: Wenn man bei verschiedenen AmigaOS API-Funktionen je 32 Bit pro Farbwert angibt, hat man ja insgesamt 96 Bit für die Farbe. Vermutlich werden die 32 Bit je Farbkomponente dann intern irgendwie auf jeweils 1 Byte pro Farbkomponente heruntergerechnet, so daß man am Ende je 1 Byte für Rot, Grün und Blau hat, also insgesamt 24 bit.

Wenn man von einer Farbkomponente (siehe mein letztes Posting) nur 1 Byte von vorne oder hinten nehmen würde, wäre das ein ziemlicher Murks.

Das Problem hatte ich übrigens auch, als ich mein Beispielprogramm "Intui Spektrum" gemacht habe. Dort habe ich mittels der Gauss Funktion die RGB-Werte zu bestimmten Wellenlängen berechnet. Somit hatte ich quasi "fließende Werte" für die einzelnen Farbkomponenten von 0x00000000 bis 0xFFFFFFFF. Ich muß gestehen, daß ich dann etwas rumgepfuscht habe, bis ich einigermaßen passende Farbkomponenten erhalten habe. Das ursprüngliche Programm war ein OpenGL Programm. Dort werden die Farbkomponenten als Float-Werte angegeben...

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-19, 14:41 h

thomas
Posts: 7718
User

Nein, kein Widerspruch und kein Murks.

Stell dir die Zahlen als Nachkommastellen vor.

Damit hast du Zahlen zwischen 0,00000000 (also 0) und 0,ffffffff (also fast 1). Jetzt kann deine Grafikkarte aber nur zwei Nachkommastellen verarbeiten. Welche nimmst du ? Natürlich die höchstwertigen, also von 0,12345678 die 0,12. Das einzige, was du machen kannst, ist runden, also von 0,128 auf 0,13. Damit würdest du bei 0,ff aber auf 1,00 kommen, was wieder nicht so gut hinhaut. Also lieber doch abschneiden.

Wenn jetzt aber eine Grafikkarte kommt, die vier Nachkommastellen verarbeiten kann, bist du mit 0,ffff immer noch am nächsten an der eins, anstatt mit 0,ff00, was wieder nur grau aussieht, statt weiß.

Nochmal das Beispiel mit den IFF-Dateien: unter OCS wurden nur vier Bits berarbeitet. Man hat also Zahlen zwischen 0,0 und 0,f. Jetzt wurden in den IFF-Dateien aber zwei Stellen gespeichert. Also theoretisch 0,00 bis 0,ff. Man hat aber einfach die eine Stelle genommen und mit 0 aufgefüllt, also 0,f0. Sieht auf AGA grau aus, weil 0,ff ja weiß ist.

Du kannst das auch mathematisch berechnen:

Wenn du ffffffff durch ff teilst, kommt 1010101 raus. Du mußt also alle zweistelligen Farbwerte mit 1010101 multiplizieren, um den komplette Farbraum auszufüllen: 45 mal 1010101 ist 45454545. Um jetzt von der 32bit-Zahl auf 8bit zu kommen, mußt du durch 1010101 teilen. Du kannst aber auch einfach durch 1000000 teilen, bei ganzahligem Ergebnis macht das keinen Unterschied.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]

2004-07-19, 14:41 h

Solar
Posts: 3680
User

Zitat:
Original von Mad_Dog:

Wenn man von einer Farbkomponente (siehe mein letztes Posting) nur 1 Byte von vorne oder hinten nehmen würde, wäre das ein ziemlicher Murks.

Öh... wenn Du statt 2^32 nur 2^8 Ausprägungen hast, und die verfügbaren Ausprägungen gleichmäßig über die 2^32 möglichen Werte legen willst, hast Du genau das - die Verwendung der most significant 8 bit.

Was willst Du da noch dran drehen?

[ - Answer - Quote - Direct link - ]

2004-07-19, 15:03 h

Mad_Dog
Posts: 1944
User

@thomas und Solar:

Sorry, ich stand gerade etwas auf dem Schlauch (denken bei dieser Hitze...

)

Die Kernaussage ist also:

Ein RGB-Tuppel, wie z.B. 0xFF000000, 0x00000000, 0x00000000 wird intern (sofern man 24 Bit Farbtiefe hat) den selben Farbwert (maximales Rot) ergeben wie 0xFFFFFFFF, 0x00000000, 0x00000000.
Man nimmt also jeweils die ersten 8 Bit pro Farbkomponenete und schneidet die restlichen Stellen einfach ab.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

2004-07-20, 08:00 h

Solar
Posts: 3680
User

Yep.

[ - Answer - Quote - Direct link - ]

2004-07-21, 00:50 h

Holger
Posts: 8116
User

Zitat:
Original von thomas:
Wenn du ffffffff durch ff teilst, kommt 1010101 raus. Du mußt also alle zweistelligen Farbwerte mit 1010101 multiplizieren, um den komplette Farbraum auszufüllen: 45 mal 1010101 ist 45454545. Um jetzt von der 32bit-Zahl auf 8bit zu kommen, mußt du durch 1010101 teilen. Du kannst aber auch einfach durch 1000000 teilen, bei ganzahligem Ergebnis macht das keinen Unterschied.

Das stimmt nur für Zahlen, die ursprünglich aus 8Bit-Farbkanälen berechnet wurden, für Werte höherer Auflösung kommen sehr wohl ein Unterschied heraus.
0xff000000 / 0x01010101 ergibt 0xfe
0xff000000 / 0x01000000 ergibt 0xff
während es bei 24Bit-Displays nur tendenziell zu helle Werte ergibt, kommen bei Modis mit unterschiedlichen Auslösungen pro Farbkanal, wie zB. 16Bit deutlich sichtbare Farbverfälschungen heraus, wenn man diese Vereinfachung anwendet, aber DAS Thema will ich nicht nochmal haben.
Es ist nur sehr ironisch, daß bei dieser Vereinfachung gerade die Werte, die in höherer Auflösung vorliegen, falsch berechnet werden. Soviel zum Thema zukunftssichere APIs.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2004-07-21, 08:49 h

Solar
Posts: 3680
User

*hausichvordiestirn*

Nehme das "Yep" wieder zurück. Dumpfdödel, ich...

[ - Answer - Quote - Direct link - ]

-1-

[ - Post reply - ]

amiga-news.de Forum > Programmierung > 32 Bit pro Farbkomponente?

[ - Search - New posts - Register - Login - ]

Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.