Slo-Tech - Senitel zna, to vemo vsi, ki vsaj malo spremljamo forum ter njegove utemeljene odgovore na vse, kar se tiče grafičnih tehnologij. Na Infosu me je obiskal ter začel govoriti, da 32 bitov barvne globine kmalu ne bo več zadosti. Čudno sem ga pogledal, a vse mi je bilo jasno po petnajstih minutah intenzivnega razlaganja tipa "sedaj pa še enkrat, počasneje". Na to temo je bil ukazan spisati tudi članek - ukaz je tudi izpolnil. Uživajte!
Ne da bi hotu pljuvat po delu drugih, sam tuki (vsaj meni) ni vse jasno.
Stvar utemeljuje povečanje barvne globine s potrebami po natančnosti v internih izračunih mašine.
Pri tem domneva, da program jemlje vzorce slike iz videobufferja, kar sploh ni nujno res.
Zakaj bi nekdo delal s bitno širino končnega piksla ? Pač delaš s širino, ki jo rabiš in nato rezultat odrežeš na zeljeno sirino, ko ga vpisujes v sliko...
Ce bi recimo presaltu z 32bp na 128 bp pri 1600x1200, bi slika, ki ti je prej vzela cca 8Mb, zdej vzela kar 32 MB. Pa to ni tisto glavno, glavno je to, da bi ble VSE rastrske operacije zdej 4x pocasnejse...
Tud ni mi jasno, kaj bi melo uporabnikovo oko od dodatnih bitov. Ni ga D/A pretvornika na tem svetu, ki bi dal od sebe postenih 16 bitov pri recimo 300 Mvzorcih /s in tudi ne monitorja, ki bi to znal prikazat...
mocno se strinjam z Brane2 njegovim zadnjim odstavkom.... problem je v tem da oko tega ne opazi.... ko bo 32bpp premalo, to sigurno nebo zaradi tega ker bi moje očkice to opazle... zgolj marketinška poteza, zaradi katere bodo nekateri spet leteli v trgovine po nove grafične....
seveda sem pri tem govoril o barvah ki pridejo na zaslon.... za tisto kar si pa ti napisal pa bo verjetno res kot si napisal... vseeno je vse skupaj malo cudno... lp caqka
Sem šu še enkrat brat tisti clanek in tam je govora o stvareh, kot so zapisane v sliki, torej videobufferju in ne o internih stvareh v grafičnem čiperaju.
Poleg tega so navedeni primeri 5 bitnega računanja, ki se po moje nikjer ne uporablja. Senitel očitno v primeru uporablja 16 bp s po 5 timi biti na barvo. O.K. mogoče bi kdo v grafičnem čiperaju res uporabu 5-bitne prenosne poti, sam to je mal tko-za lase privlečeno.
O.K. pri 5-tih bitih si lahko natančen na 1/32ko in tam se ti pač napake naberejo...
To bi pasalo bolj v problematiko hardvera izpred 10-12 let.
Mater, še prve kartice z videoprocesorjem, mislim da je bil to Motorolin 68343, ki so dale od sebe "sapo jemajočih in neverjetnih 1Mpix/s" so mele vsaj 8-bitno matematko!
-tip govori o najvec 10 bitih po kanalu. Sanja celo nekaj o 12-tih, kar kao imajo skenerji (grejo pa danes tud več, moj EPSON ma 14, tanov model pa 16), pozablja pa, da hitrost zajema podatkov v skenerju ni 1/100 tistega, kar pride ven iz kartice.
Torej, 10 bitni DACi so ze nekaj casa zunaj in zdej je za videt, kdo bo naredu preskok na 12-bitne v normalnem cenovnem razredu pri recimo 300 Ms/s.
Vsekakor pa tip ne govori o 64 ali 128 Bitnem pikslu in recimo 32 ali 40 bitnem kanalu.
32bitni video DAC ? To moram se videt.Nato ga še skadim tropu slonov in lahko rečem, da sem v življenju izkusu več ali manj vse.
Aja, kar se sirine tice, jaz sem dojel, da si v primeru navedu 16bitni pixel s tremi 5 bitnimi kanali. A sem falou ?
Aja, se ena cvetka v clanku je bla ta, da se interno vsa izracunavanja dogajajo v desetiskem formatu ?!?
Ce sem se zmotu, se opravicujem, sam mislem, da si tle falu ortodoksno.
Vsa interna izračunavanja se v masinah dogajajo binarno (za kar je kup razlogov) in to, da so vsa stevila v obsegu 0..1 ne pomeni dosti. Tko zgleda vsaka cifra v FPU enoti tvojga Pentiuma, ce ji odrezes eksponent.
Se to, Carmack navaja kot glavni razlog za vec bitov po kanalu "banding". Pravi torej, da je 8 premalo, da je sedanji standard 10 in da novi standardi za HDTV narekujejo 12. O.K. Ampak to je se vedno dalec od 128 bitov oziroma 32 ali celo 42 po kanalu.
Tam pride v igro tisti plavi prelivcek v tvojem clanku. Ce delas torej prelive in nimas na voljo zadosti barv, da bi imel vsak piksel preliva svojo barvo, se ti lahko zgodijo lise v prelivu.
Pa kaj ? To se dogaja samo zato, ker folk in njihov hardver nima časa za dithering.
Zdej naj bi ves folk presaltu na totalno nov, bistveno dražji in neizmerljivo malo boljši harver zaradi Carmackovih videorutin ? LOL
>Ni nujno, važno je, da je back buffer na 64bpp, front buffer pa lahko ostane >na 32bpp.
O.K. Ima smisel. Ampak potem organizacija bitov posameznih pikslov v videobufferju, od koder shifter pobira sliko nima veliko z geometrijsko definicijo stvari, mislim poligoni, normalami itd. Tisto se pac racuna v katerikoli natancnosti in sirini in na koncu se rezultat obreze na zahtevano sirino.
>>Aja, kar se sirine tice, jaz sem dojel, da si v primeru navedu 16bitni pixel s >>tremi 5 bitnimi kanali. A sem falou ?
>>Ja 16bitni pixli z tremi 5bitnimi kanali in 32bitni pixli z štirimi 8 birnimi kanali. >>Kaj je s tem narobe?
Nič, samo karikira problem. Danes so 16 bitne ALU in FPU enote že stvar preteklosti, torej ne vidim v čem je taka frka pri prehodu s "starih" na "nove"... Že res, da jih grafični čiperaj verjetno rabi na kilo, pa vseeno...
>>Aja, se ena cvetka v clanku je bla ta, da se interno vsa izracunavanja >>dogajajo v desetiskem formatu ?!?
>Kje sem to reku??? Tisti izračun levo je lepo izračunan, in spodaj tudi piše "lep >izračun" in je samo realen rezultat in nič drugega.
Evo:
Kot smo spoznali že v zgornjih dveh poglavjih, imamo opravka z dvema vrstama števil. Decimalna števila so zelo pripravna za računanje in grafični čipi dejansko delajo z pravimi decimalnimi števili v območju 0.0 do 1.0 za vsako barvno komponento posebej.
Šele po tvoji reakciji sem dojel, da si mislu na racionalna števila med 0 in 1, ne pa obdelave v desetiskem (decimalnem) številskem sistemu. BCD (Binary Coded Decimal) ukazi v mašincu se sicer (so se) uporabljajo, vendar v druge namene, ne pa zaradi večje hitrosti.
.
. 