Dotaz: 32bit hloubka barev

[dim]

zdravim, da se nejak pod linuxem nastavi 32bit hloubka barev? skousel sem editovat soubor /etc/X11/xorg.conf takto:

SubSection "Display"
                Depth           32
                Modes           "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection

ovsem to mnelo po restartu za nasledek start do nouzoveho grafickeho modu. vizsi hloubku barev se snazim nastavit, protoze pri zobrazeni nekterych fotek, nejsou pozvolne barevne prechody plynule, ale jsou videt hranice mezi odstiny. pod windows pri 32bit barvach se vse zobrazovalo v poradku... normalne by mne to nevadilo (je to videt tak na 5% mych fotek), ale jelikoz planuju pod linuxem upravovat rawy tak potrebuju mit vse spravne zobrazene.

distibuci mam ubuntu 7.10
grafickou kartu radeon 9200
ovladace graf. karty sem nemnenil, tudiz jsou to ty puvodni z distribuce

Odpovědi

[Andrej Herceg]

Nefunguje 24 bitová hĺbka?

[dim]

funguje ale pod ni se to prave spatne zobrazuje

[Andrej Herceg]

Nie je 24 bitový a 32 bitový mód v podstate to isté (teda 8 bitov na červenú, zelenú a modrú farbu a pri 32b je zvyšných 8 bitov nepoužitých)?

Pri 16 bitovom móde nemám plynulé prechody, ale keď to prepnem do 24b módu, tak sú prechody plynulé.

[Michal Kubeček]

Přesně tak. Pooužívalo se to dřív u některých videokaret kvůli rychlejšímu adresování jednotlivých pixelů. Dnes už je to trochu anachronismus a řada driverů to ani nepodporuje.

[Ondrej 'SanTiago' Zajicek]

Pooužívalo se to dřív u některých videokaret kvůli rychlejšímu adresování jednotlivých pixelů. Dnes už je to trochu anachronismus.

Neni to naopak? Ze 24 bpp rezim se pouzival u starych karet kvuli setreni pameti, zatimco dnes uz vsechny pouzivaji 32 bpp (24 bitu barvy a 8 bitu padding)? Nevim jak X drivery, ale fbdev drivery pro intel, ATI radeon i VIA (intelfb, radeonfb, vt8623fb) podporuji jen 32 bpp rezim a 24 bpp nepodporuji.

[Michal Kubeček]

Nevím jak framebuffer, ale driver radeon pro X server naopak podporuje pouze 24-bitovou hloubku, 32-bitovou zcela odmítá.

[Ondrej 'SanTiago' Zajicek]

Mluvime mozna o odlisnych vecech - ja mluvim o fyzicke strukture pameti, ty asi o hodnote parametru depth v konfiguraku X serveru. Ani bych se nedivil, kdyby se do X konfiguraku psalo depth 24 a pritom se pouzivalo 32 bpp (coz je v poradku, kdyz interpretuji depth jako barevnou hloubku - depth je opravdu jen 24, i kdyz je 32 bpp) a pouze u tech driveru, ktere podporuji jak 24 tak 32 bpp, se pouzival rozdil 24/32 v depth pro odliseni.

[Michal Kubeček]

V takovém případě ale moc nerozumím tomu, proč by X server hodnotu 32 striktně odmítal jako chybnou.

[Ctirad Feřtr]

Je to divné, ale opravdu to tak je, viz log z radeon 9250:

(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)

Možná je to v tom ovladači zadrátované z historických důvodů. Staré karty měly organizaci 24bpp z důvodů malé a drahé paměti a podle toho byl napsaný ovladač. U novějších karet s větší pamětí pak už jednoznačně převážila oragnizace po 32bpp, protože se lehce adresují nejen samotné pixely, ale i jednotlivé barevné složky, nicméně ovladač se navenek tváří stále jako 24bpp.

Každopádně kvůli tomu memůžu spustit Phun, protože natvrdo vyžaduje 32bpp což žádný z ovladačů karet na mých strojích neumí :(

[Andrej Herceg]

Phun nepotrebuje 32b mód (ja ho nemám a Phun mi funguje).

[Ctirad Feřtr]

Jo tak stávající verze už mi taky jede. Halelujá :)

[Andrej Herceg]

Na mojej GeForce 6600 môžem použiť iba 24 mód.

[Petr Šobáň]

Přesně ovladače od nvidie na GF 6100 taky pouze 24 a s nVidia Corporation G70 [GeForce 7600 GS] taky pouze 24.

[Ondrej 'SanTiago' Zajicek]

Vizte muj prispevek vyse.

[Mandarinka]

Na windows lze zase jen 32bit (TNT2, Radeony 9200 a x700), 24bitů šlo naposled na RageIIc a tom druhém Rage co jem měl.

Jinak nemusí to být jen padding, těch 8bitů, ale i alfa kanál, což by možná ty přechody mohlo i vysvětlovat. Barev je sice stejně, ale přechody dvou objektů s polotransparentním okrajem by asi vypadaly jinak.

[Andrej Herceg]

Alfa kanál to pravdepodobne nie je (keďže je to pozadie a priehľadné pozadie asi zmysel nemá). O prekrývanie priehľadných objektov sa stará x-server/program a nie grafická karta.

[petris]

Prepsal jste i defaultdepth? Log od Xek jste cetl?

[David Heidelberg]

Depth 24 se v linuxu automaticky rovná 32 pokud se nemýlím...

[Honza "tux" Friesse]

32 bitů je výmysl Windows, ve skutečnosti je neumí použít.

Je třeba 8 bitů na červenou,zelenou a modrou -> 24 bitů. Těch posledních 8 bitů může být použito třeba v OpenGL aplikacích na alpha kanál (nemusí se nutně rovnat průhlednost), a to X server zajistí správně (takže OpenGL aplikace má opravdu plný RGBA -> 32 bitů).

Takže pokud se opravdu fotky v Linuxu při 24 bitech a ve Windows na (teoreticky) 32 bitech zobrazují jinak, je to nejspíše nastavením gamma korekce.

[Mandarinka]

Není to výmysl windows. To se fakt (viz výše) zavedlo někdy koncem devadesátých let, protože s tím grafiky podávaly větší výkon s 16.8 mil. barev, než když se adresovalo 24bitů. Doba boje 3Dfx s nVidií. nVidia tehdy zabodovala s Rivou TNT(2?) protože právě uměla hodně rychle 32bitovou hloubku. Tuším, že to byla první karta, která měla truecolor použitelný.

Podobná situace je s 15bit, vs. 16bit hloubkou. Dobové FAQy tvrdí, že 15bitů je o dost pomalejší.

[Mandarinka]

Z wikipedie:

"In a framebuffer, an alpha channel is meaningless, but 32-bit truecolor is often used because it makes pixel addressing easier. Addressing an array of 24-bit pixels requires multiplication by three, which is more computationally expensive than multiplication by four, which can be computed by bit shifting."

[Ondrej 'SanTiago' Zajicek]

Ale kdeze. Uz stare S3 Trio/Virge pouzivali 32 bpp pro truecolor. AFAIK 24 bpp rezim funguje bez problemu jen na S3 Virge VX, zatimco na ostatnich S3 Trio/Virge funguje bez problemu jen 32 bpp.

[R]

Praveze nie. S3 Trio64 a Virge/DX (velmi rozsirene a tiez velmi zle karty) maju len 24 bpp, lebo pamat tam je taka mala, ze je nemyslitelne nou tak plytvat.

[Ondrej 'SanTiago' Zajicek]

Tak se podivej treba do drivers/video/s3fb.c jake jsou podporovane rezimy pro ktere S3 karty. Pokud bys vedel, jak aktivovat 24 bpp rezim na S3 Trio a Virge/DX, tak rekni, ja jsem na nic funkcniho nenarazil, vzdy jen na 32 bpp.

[R]

Tie karty som nastastie v Linuxe nemusel pouzivat. Ale vo windows pouzivaju urcite 24bpp.

Pozeram tam a fakt je tam napisane, ze 32bpp...

[Honza "tux" Friesse]

To je docela dobře možné, protože 32 bitová architektura. Ale každopádně se ve Windowsech ten alpha kanál (samozřejmě kromě OpenGL a asi i D3D aplikací) ignoruje a počet barev je 2^24.

Co se týče 15x16 bitů. Osobně si neumím příliš představit efektivní 15 bitový přístup (pokud tedy nebudu mít přímo 15-bitové registry).

[Ondrej 'SanTiago' Zajicek]

ono jak pri 15bitovych tak pri 16bitovych barvach bylo 16 bpp. V prvnim pripade byl 1bitovy padding, v druhem pripade mela (obvykle) zelena 6 bitu. Nektere graficke karty umely i ruzne figle jako treba rezim, kdy 16 bitu reprezentovalo bud dva pixely stejne barvy v hi-coloru, nebo dva pixely ruzne barvy zadane paletove (ze 128 barev).

[Ctirad Feřtr]

Jde o to, jak byl udělaný RAMDAC. U 15bpp je každá složka 5 bitů a šestnáctý bit ve slově se ignoruje (viz příspěvek nademnou) a z hlediska návrhu videočipu a zobrazovacích rutin je to jakoby logičtější. 15bpp se hojně používalo na Apple a některých konzolích. 16bpp zase na PC.

[Filip Jirsák]

Alfa kanál u obrazu na monitoru je nesmysl. Co by bylo pod tím (polo)průhledným bodem – viděl byste skrz monitor?

[R]

Obrazovku znutra :)

[Michal Kubeček]

Na LCD to funguje, tam jsou "alfa kanály" hned tři… :-)

[Ondrej 'SanTiago' Zajicek]

Nesmysl to neni. To hned ze dvou duvodu:

1) composite operace pocitaji s alfou zdrojovych i cilovych dat. Pokud tedy delam composite operaci s cilem ve framebufferu, tak se me hodi, kdyz framebuffer tam ma rovnou alfa kanal.

2) alfa kanal muze reprezentovat pruhlednost vzhledem k ostatnim overlayum.

[Filip Jirsák]

V nastavení xorg.conf se ale nastavují vlastnosti grafické karty, ne? Že nad tím vším pak běží nějaký framebuffer nebo OpenGL nebo okenní maanžer něco podobného je už věc vedlejší. Ale zobrazování klidně může fungovat tak, že X aplikace bude malovat v 8 bitech na kanál s průhledností, ale X server to pak převede pro zobrazení na černobílém monitoru.

[Ondrej 'SanTiago' Zajicek]

Že nad tím vším pak běží nějaký framebuffer

Framebufferem myslim oblast pameti graficke karty, ktera se vykresluje.

Ale zobrazování klidně může fungovat tak, že X aplikace bude malovat v 8 bitech na kanál s průhledností, ale X server to pak převede pro zobrazení na černobílém monitoru.

X server by mohl delat ledacos, ale obvykle reseni (pred prichodem composite manageru) je, ze on-screen drawables (okna) se kresli primo do framebufferu na graficke karte a tedy pokud je plocha okna cilem nejake composite operace, tak je vhodne, aby tam byly i ty alfa hodnoty.

[Filip Jirsák]

Jaké je pak rozdělení úloh mezi grafickou kartou a X serverem? Dostane X server od karty přidělený nějaký framebuffer, a k tomu se X server chová jako ke „staré grafické kartě“ (tj. framebuffery apod. si řeší karta ve vlastní režii), nebo na tom X server spolupracuje a může si framebuffery vytvářet dle potřeby, určovat, kde se mají zobrazit atd.?

[Ondrej 'SanTiago' Zajicek]

Obecne karty samy nic neresi. Vsechno resi software. Karty akorat delaji, co se jim rekne. Karta ma nejakou grafickou pamet (ktera je pristupna pro software) a software muze obvykle kartu nastavit tak, aby z nejakeho jejiho useku (obvykle volitelneho) vykreslovala (takovy usek nazyvam framebuffer) a nastavit ji (z nekolika moznosti, co dana karta umi), jak ma intrepretovat data v dane pameti. Obvykle graficke karty mohou mit takovych useku jen par (hlavni, ktery se rozprostira pres celou obrazovku (az na blanking oblasti) a jeden nebo vic overlayu (vyuziva se hlavne na prehravani videa) - proto vetsinou nejde spustit vic prehravacu vyuzivajicich xv metodu prehravani videa.

Software pak zapisuje do graficke pameti bud primo (kdyz se nepouziva akcelerace), pomoci bus-master transferu, nebo tim, ze naprogramuje akceleracni jednotky na graficke karte, aby tam neco udelaly.

Jina vec je jeste rozdeleni tech cinnosti mezi ruzne software (DRI, X server, fbdev drivery, ...).

[Filip Jirsák]

Pak je to stále tak, jak si pamatuju z dob DOSu To ale podle mne znamená, že rozlišení + bitová hloubka u X serveru určuje, jaký zobrazovací mód bude karta používat. A tedy že u takových dat nemá smysl nějak interpretovat alfa kanál – protože už není nic, s čím by se mohl barevný bod „prolnout“. Overlay pro přehrávání videa je speciální případ a jeho rozměr a bitová hloubka nemusí nijak souviset s nastaveným režimem karty. Pro výkon je lepší, pokud bitová hloubka overlay a interpretace jeho jednotlivých bitů bude shodná s režimem grafické karty, ale když může grafická karta s overlayem provádět různá kouzla typu škálování nebo změna barevnosti, mohla by i přepočítávat bitovou hloubku.

Jinými slovy, v xorg.conf se nastavují vlastnosti hlavního framebufferu, který je vždy až „vespod“ a tudíž u něj nemá smysl nějak interpretovat alfa kanál.

[stativ]

Je to nesmysl. Hodi se akorat pri ukladani dat aby se neztratila zadna informace o barve.

[hankey]

Ale vždyť foťáky dávají jen 24 bitů barev. A navíc to je toliko barev, že už se ani jedna od druhé nedají rozeznat. Já bych tady chybu nehledal. Přece na každou barvu je použito 8 bitů.

[andree]

ako ktore... ked fotis do RAW, kludne mozes mat aj 36/48 bitove pixely hmm.. rozmyslam ze v raw je vlastne problem povedat, co je pixel, obcas.. nevermind, len som chcel zamachrovat v kazdom pripade je fakt, ze vzhladom na to ze drviva vacsina domacich LCD stejne zobrazi +/- 6 bits/channel, tak je tych 24bpp tak akurat... :)

[pht]

lidske oko umi rozeznat mnohem vice barev nez "truecolor". 8 bit na kanal je v ruznych situacich docela malo. zkuste si vyfotit neco kontrastniho (slunce, tmavej roh) a pak to porovnejte s tim co vidite.

[Mandarinka]

Ale tam bude chyba v něčem jiném imho - přesnost snímače, světelnost... bych si tipl.

A nezapomeňte, že váš mozek provádí "postprocessing" v zatracenš hojné míře.

[Michal Kubeček]

Hlavní problém je v tom, že lidské smysly typicky nevnímají lineárně ale logaritmicky, a to se týká i vnímání intenzity světla. Kdyby naše datové formáty tuto skutečnost respektovaly, 8 bitů na kanál by bylo až až. Se zvukem je to podobné, jen s tím rozdílem, ža tam tak některé formáty fungují.

[Ondroid]

Kdysi kdesi - myslím že v Photolife jsem četl, že člověčí zrak je schopen rozlišit mnohem víc barev než popíše RGB barevný prostor s 8 bity na kanál. Mám pocit že tam psali o něco kolem 100 miliónů barevných odstínů podprahově a o něco méně v rozlišení dvou odstínů navzájem.

[hankey]

Tak to jsem netušil, že až tak dobrý máme zrak, ale co se týká té dynamiky, tak je jasné, že máme trochu jiný senzor, protože takový rozsah, co dokážeme vnímat, žádný fotoaparát nedá. Navíc nevnímáme lineárně a máme to oko přece jen trochu složitější, přece disponujeme dvěma typy senzorů, tyčinkami a čípky. Nicméně jsem chtěl říct, že na monitoru dvě barvy jen o bit rozdílné se poznat nedají. Kamarád má profi eizo, zítra to ještě zkusím u něj, jestli něco uvidím...