John Carmack: 32 bit per pixel is niet genoeg

NeoCarnifex schrijft dat John Carmack vindt dat we wel 64 bitjes per pixel kunnen gebruiken, de 32 bit per pixel die nu net een beetje standaard begint te worden is volgens hem niet genoeg. Voordat je denkt dat hij de monitor meer kleuren wil laten produceren dan je oog kan waarnemen: hij wil meer bits voor de waarde van de transparantie, de 8 bit die je krijgt voor een alpha kanaal niet genoeg volgens hem:

Eight bits of precision isn't enough even for full range static image display. Images with a wide range usually come out fine, but restricted range images can easily show banding on a 24-bit display. Digital television specifies 10 bits of precision, and many printing operations are performed with 12 bits of precision.

The situation becomes much worse when you consider the losses after multiple operations. As a trivial case, consider having multiple lights on a wall, with their contribution to a pixel determined by a texture lookup. A single light will fall off towards 0 some distance away, and if it covers a large area, it will have visible bands as the light adds one unit, two units, etc. Each additional light from the same relative distance stacks its contribution on top of the earlier ones, which magnifies the amount of the step between bands: instead of going 0,1,2, it goes 0,2,4, etc. Pile a few lights up like this and look towards the dimmer area of the falloff, and you can believe you are back in 256-color land.

[...] Yes, it will be slower. That's ok. This is an important point: we can't continue to usefully use vastly greater fill rate without an increase in precision. You can always crank the resolution and multisample anti-alaising up higher, but that starts to have diminishing returns well before you use of the couple gigatexels of fill rate we are expected to have next year. The cool and interesting things to do with all that fill rate involves many passes composited into less pixels, making precision important.[break]Voor het geval dat er daarwerkelijk kaartjes komen met 64 bit heeft hij nog een gratis tip voor 3dfx :[/break]64 bit pixels. It is The Right Thing to do. Hardware vendors: don't you be the company that is the last to make the transition.

Voor meer redenen en uitleg waarom 32 bit niet genoeg is kan je hier zijn .plan bestandje lezen .

Reacties (32)

[Verwijderd]

Beetje overdreven allemaal 32 bits is 2^32=4,3 miljard kleuren. Beetje veel misschien? De kleuren worden gewoon fout gebruikt, als 16-bits kleuren goed worden gebruikt zie je het verschil tussen 2 opvolgende kleuren echt niet.

[Hielko]

Lees dit eerst voordat je iets zegt ,

Als je 32 bit kleuren gebruikt zijn daarvan 24 bit voor de kleuren gereserveerd en 8 voor transparatie, hij wil dus met 64 bit kleuren gewoon veel meer bits voor de transparantie omdat 8 te weinig is als je lichten hebt die over een grote afstand schijnen of nog erger: als er meerdere op 1 plek schijnen

[JumpStart]

Erhh, sinterklaas:

Het gaat niet om de kleur, maar om transparantie gegevens. Verder dan 24 bit kleur hoef je niet te gaan voor de kleur zelf: 8 bit voor Rood, Groen en Blauw.
Je ogen kunnen inderdaad niet meer dan dat waarnemen. Doe maar eens een test: maak 2 vlakken van een kleur. Het ene vlak veranderje 1 waarde in een van de kleuren. RGB 128-128-127 en RGB 128-128-128. Op voorwaarde dat je contrast van je monitor goed ingesteld staat zie je dit verschil net niet of net wel. Kleinere verschillen kan een menselijk oog in ieder geval niet zien.

En dan heb je nog 8 bit over voor Alpha Channel ( = Transparantie.)

Wanneer je 64 bit per pixel zou gaan gebruiken dan kan je dus per kleur kanaal 8 of zelfs 10 bit transparantie informatie toevoegen, in plaats van 8 bit transparantie waarde voor de hele pixel. 16.777.216 mogelijke transparantie waarden is toch wel beter dan maar 256. En dat zal je merken bij het betere render resultaat van je 64-bit 3D kaart

(kloten, Kinslayer was me voor... )

[NeoCarnifex]

Kinslayer heeft gelijk, het gaat inderdaad niet alleen om de uiteindelijke kleuren die je op je monitor ziet. Het gaat ook niet alleen om het alphachannel. De maximale uiteindelijke kleurdiepte is maximaal 24 bits ofwel ongeveer 16 miljoen kleuren. Maar tijdens de bewerkingen is er een grotere kleurdiepte nodig. Denk aan het volgende: Stel je wilt met waarden tot de 10 werken, en voor sommige effecten heb je 4 van deze waarden nodig, moet je intern dus kunnen werken met waarden tot 4x10=40 omdat je anders allerlei afrondingsfouten krijgt. Daarom is die huidige 32bit alleen nodig bij multitexturing omdat je interne waarden van de bewerkingen anders eerst moet afronden. De verschillen tussen 16 en 32 bits zijn ook het beste te zien op de plekken waar verschillende textures doorelkaar gemixed moeten worden, denk aan lucht, vuur, water e.d.

[P5ycho]

WipKip:

Je hebt veel aan deze man te danken, ik zou op z'n minst een klein beetje respect voor em hebben. tenslotte was het quake dat de HW acceleratie op gang heeft gebracht. (of andersom) er IS helemaal geen verschil tussen 24 en 32bits, niet wat je kunt zien in ieder geval. het alpha kanaal is het kanaal wat meer data kan bevatten. intern wordt er dan dus beter lichten en doorzichtigheid enzo verwerkt, waardoor het eindresultaat beter is.

het is goed dat hij hierover begint, dan hebben we over een jaar 64bits rendering, en over 2 jaar een engine van hemzelf waarschijnlijk die 64bits rendert, en dan best wel strakke plaatjes zal opleveren. Hij begint er natuurlijk nu over, omdat hij de HW support nodig heeft voor z'n volgende engine...

[EfBe]

[UPDATE: ik heb dit even getest en ik krijg inderdaad vrolijke bands in mn gouraudshaded alphapoly... (TNT, win2000, 32bpp, opengl)]

(Hier stond een l*lverhaal wat niet waar bleek)

Binnenkort wil je met shademaps wilt werken en dus met alphabytes in kleuren de per pixel alpha wilt kunnen aangeven, en dan is banding OP DIT moment niet te vermijden ivm de 8 bits alpha in de kleur.

Dus Carmack heeft gelijk in dit verhaal, echter ik zou pleiten voor een floating point waarde voor R, G, B en A (zoals sommige kaarten ook gewoon gebruiken, alleen de destination fragments zijn soms RGBA bytes). Je bent dan meteen van het bitgeneuzel af voor 16/32/64? ...

[Verwijderd]

Ha theoretisch heb je niet eens een 24-bit videokaart nodig. Het is alleen handig om een betere mogelijkheid te geven in het verschil van de kleuren, want het mensen oog kan maar +- 65000 kleuren tegelijk zien.

Door de mogelijkheid van 24-bit kleur is het dus mogelijk om meerdere kleuren rood te kiezen waardoor het vloeiender overloopt, maar als je alle 16 miljoen kleuren op je beeldscherm gaat toveren zien je ogen het verschil niet tussen rood 1 en rood 2. Alleen tussen bv rood 1 en rood 10

Ok maar John Carmack wil volgens mij niet al die 40-bit gaan gebruiken voor alleen tranparantie.

[Femme]

Zie in dit verband (verhaaltje van Kinslayer) ook deze nieuwsposting van 28 mei vorig jaar, waarin Brian Hook (toen nog werkzaam bij id Software, nu voor Verant Interactive) een vraag beantwoordt over het nut van 48-bit kleurdiepte:

www.tweakers.net/nieuws.dsp?ID=2814

Het gaat er dus basicly om dat er kleurdiepte 'verloren' gaat wanneer pixels met meerdere passes bewerkt worden:

</div><div class=b4>Sure, we now are using maybe 3-4 passes in games, but as fill rate increases there is no reason to think that we will not want to use effects that will take maybe 7 or more passes. And when we do, even 24 bit will be pushed to the limit, and we will need those 48 bits to keep the quality decent.</div><div class=b1>

[Verwijderd]

Ik weet niet wat voor ogen sommigen hier hebben, maar het verschil 16-32 bit zie je wel. De enigste manier waarop dit kan verborgen worden is d.m.v. dithering.

Een goed proggy hiervoor is Paint Shop Pro. Zet je schermpje op 32-bit. Neem een image, en maak een mooie gradient tussen 2 (liefst veel verschillende) kleuren. In 32-bit (of 24) zie je een hele mooie gradient. Dan zet je je scherm op 16-bit en de bands verschijnen al. Maar PSP heeft een handige function om te reducen naar 16-bit kleuren. Als je deze functie gebruikt met "Closest Match" dan krijg je ook bands, maar als je "Error Diffusion" neemt dan krijg je een gradient die er 99% hetzelfde uitziet dan die 32-bit. M.a.w. 16-bit *kan* er heel goed uitzien...

Trouwens over het verschil tussen 24-bit/32-bit, het is visueel hetzelfde, omdat er maar 24-bit kleur wordt gebruikt in de 32-bit. Maar het is geloof ik wel sneller omdat er bij 32-bit een even aantal bytes is en er zo geen rekening moet gehouden worden met word-alignment en dergelijke.

[TD-er]

Wat ik me al een tijdje zit af te vragen:
Zou 't niet sneller zijn, om niet alle pixels tig keer te bewerken (met alle afrond-fouten vandien)maar een tabel aan te maken waarin per pixel wordt bijgehouden wat voor operatie d'r op moet worden uitgevoerd.
Als dat tabelletje klaar is, dan kunnen de operaties vereenvoudigd worden (bijv 7x lichter maken door 7 licht-bundels te vereenvoudigen door 1 operatie), dat scheelt een hoop afrond-fouten en er hoeven een hoop minder operaties te worden uitgevoerd.
't kost wel een hoop extra geheugen, maar als je de bus-breedte opvoerd, is dat ook geen probleem meer.
Verder heb je dan niet meer de noodzaak om over te stappen naar een grotere woord-breedte, om de afrond-fouten tegen te gaan en kunnen de processoren voor de bewerkingen nog iets goedkoper worden/blijven.
Verder is het voordeel dan ook nog eens dat de processoren meer operaties tegelijk kunnen doen, omdat de woord-breedte niet 64 bits, maar bijv 32 bits blijft.
Verder ben ik 't met JC. wel eens, dat er wel degelijk verschil zal zijn, met de huidige manier van 3D-verwerking, wanneer er meer bits gebruikt gaan worden.
Ik volg nu 't vak Inleidng Numeriek en daar wordt je pas echt duidelijk hoe onnauwkeurig computers van nu eigenlijk zijn met "maar" 64 bit reals.
* TD-er TD-er