Warum Fließkommawerte bei Pixelfarben ?

Gegenfrage schrieb:

Warum nicht?

24 Bit bilder haben 3 Byte pro Pixel. Eine Pixelangabe mit Fließkommawert hat mindestens 3*4 = 12 Byte pro Pixel( float ), bzw. 3*8 = 24 Byte pro Pixel( double), usw.
Das ist Speicherplatz- Geschwindigkeitsverlust.

Hallo,

genau diese Frage habe ich vor Ewigkeiten hier auch gestellt, allerdings im Spieleforum. Wenn ich mich recht entsinne, war die plausible Antwort, dass die Hardware intern sehr wohl mit floats rechne, was dann natürlich Geschwindigkeitsgewinn mit sich brächte. Kannst ja mal nach suchen, wenn du mir nicht glaubst oder z.B. die Radeon-Register-Spezi anschauen, wie es heute bei einer aktuellen 3D-Karte aussieht.

Computergrafik n00b schrieb:

Moin !
Warum werden Pixelfarben in Fließkommawerten angegeben ?
Z.B. bei einem 24-Bit Pixel: (0.75, 0.5, 0.2)

rgb-farben werden nicht generell im floating point-format angegeben, sondern mindestens genauso häufig als integer mit n bits pro kanal, wobei n in den meisten fällen 8 sein dürfte. gdi erwartet farbdaten in dieser form und viele andere apis auch.

grafikkarten arbeiten intern mit fließkomma-zahlen, weil sie auf vektorenberechnung ausgelegt sind und mit integerdaten nicht so effizient rechnen können. außerdem ist ein rgb[a]-wert ein vektor und kann entsprechend transformiert werden (stichwort normalmaps).

rüdiger

Grafik IT Profffesssional schrieb:

Gegenfrage schrieb:

Warum nicht?

24 Bit bilder haben 3 Byte pro Pixel. Eine Pixelangabe mit Fließkommawert hat mindestens 3*4 = 12 Byte pro Pixel( float ), bzw. 3*8 = 24 Byte pro Pixel( double), usw.
Das ist Speicherplatz- Geschwindigkeitsverlust.

Arbeiten neuere Grafikkarten nicht mit "High Dynamic Range"-Farben (HDR)? Also 16 oder 32 Bit _pro_ Farbkanal?

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Spiele-/Grafikprogrammierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Artchi

Na, wird doch vielleicht was mit Prozentverhalten zu tun haben?

R = 0.75f sind 75% Rotanteil.

zwutz

so wie es Artchi sagt, wird es wohl sein. Nicht immer gehen Farben von 0-255

außerdem lässt es sich mit solchen Werten besser rechnen bzw.leichter auf Gültigkeit geprüft werden

rapso

Computergrafik n00b schrieb:

Moin !
Warum werden Pixelfarben in Fließkommawerten angegeben ?
Z.B. bei einem 24-Bit Pixel: (0.75, 0.5, 0.2)

Du widersprichst dir irgendwie. ein 24bit pixel wird in 24bit angegeben, ich kenne bisher kein float format das R,G,B in 24bit speichern wuerde.

die antworten der anderen scheinen mir blankes raten zu sein was du fragen wolltest. also?

this-*gt*that

Wie schon gesagt wird nicht generell in Floats gerechnet und es gibt eine Vielzahl an Formaten. Floats haben einfach ein paar Vorteile, z.B. die schnelle Handhabung auf der GPU, dass zwischen 0.01 und und 0.02 noch ziemlich viele Werte liegen und die leichte Einbettung in mathematische Operationen (exp, log etc).

HDRR hat übrigens nichts mit der Bittiefe zu tun.

rapso

this->that schrieb:

HDRR hat übrigens nichts mit der Bittiefe zu tun.

uebrigens, hat es doch
laut definition
int8 range = LDR
float16/int16 = MDR
float32 HDR

pro channel versteht sich.

this-*gt*that

rapso schrieb:

this->that schrieb:

HDRR hat übrigens nichts mit der Bittiefe zu tun.

uebrigens, hat es doch
laut definition
int8 range = LDR
float16/int16 = MDR
float32 HDR

pro channel versteht sich.

Da kenne ich aber andere Definitionen. HDRR ist einfach das Rendern in einem größeren, möglicherweise dynamischen Bereich. Meistens wird es noch genauer ausgedrückt als Rendern in einem Bereich außerhalb [0,1]. Ob ich diesen Bereich nun mit 16 oder 32 oder 128 Bit darstelle hat eigentlich mit HDRR nichts zu tun.

rapso

this->that schrieb:

rapso schrieb:

this->that schrieb:

HDRR hat übrigens nichts mit der Bittiefe zu tun.

uebrigens, hat es doch
laut definition
int8 range = LDR
float16/int16 = MDR
float32 HDR

pro channel versteht sich.

Da kenne ich aber andere Definitionen. HDRR ist einfach das Rendern in einem größeren, möglicherweise dynamischen Bereich. Meistens wird es noch genauer ausgedrückt als Rendern in einem Bereich außerhalb [0,1]. Ob ich diesen Bereich nun mit 16 oder 32 oder 128 Bit darstelle hat eigentlich mit HDRR nichts zu tun.

ja, ein irglaube der mit absicht in die welt gesetzt wurde. LDR MDR und HDR waren klare begriffe, lange vor den graphikkarten die das konnten. besonders bei photographen.
als dann die graphikkarten float konnte, musste das marketing von den herstellern leider "Higher Dynamic Range" in die welt setzen. noch zu sehen auf NVidias todgeburt openEXR homepage.

Higher dynamic range and color precision than existing 8- and 10-bit image file formats.

es gab frueher auch erst streit ob float16/24 HDR oder MDR sein soll. Fuer die die das gebraucht haben war aber nur float32 das richtige format fuer HDR. weil die anderen formate nicht nur nicht genug range anboten, sondern desweden auch fehler darstellten (was auch ein wenig softwareabhaengig ist).

aber wenn man zu graphikprogrammieren hdr sagt, dann ist selbst r10g10b10a2 noch enthalten, somit will ich mich da nicht weiter streiten;).

hellihjb

Auch wenn Grafikkarten heute mit float32 rechnen koennen, muessen die Quelldaten dafuer ja auch erstmal irgendwo herkommen.
Wenn ich dann also mit einer professionelleren Digitalkamera HDR-Texturen knipse, werden die aus mehreren (>=3) Belichtungen des gleichen Bildes erzeugt. Jede Stufe hat dann so 10..12 Bit Farbtiefe, insgesamt kommt man damit also trotz aller Inter- und Extrapoliererei nicht wirklich weit ueber 16Bit Farbtiefe pro Kanal.
Das ist fuer die meisten Anwendungen die man heute "HDR" nennt aber auch vollkommen ausreichend.
Davon abgesehen war es eh schon schwierig genug, dem Grafiker zu erklaeren warum man jetzt mehr Farbtiefe braucht als der Bildschirm darstellen kann...