主題: 8bit driver ic
瀏覽單個文章
oskwu
Regular Member
 

加入日期: Apr 2002
您的住址: Taiwan
文章: 94
引用:
Originally posted by SeaWalker
<<前恕刪>>
至於該面板的10bit模擬是直接用Drive IC上來進行
抑或是再經由外部電路(IC)的方式來處理
小弟倒是不清楚
猜測是如果要做一顆這種8bit差補模擬10bit的Drive IC
不如直接開發10Bit
但是成本可能不低吧
...<<恕刪>>
小弟一直以為8bitor 10bit的事情
主要是在色階(灰階)的表現上
表現度越高則是漸進顏色的連續性越佳
因此可以降低色塊的產生
同時經由R/G/B混色後的表現也越接近真實
至於GAMMA修正
是不是用在改正顯示器與真實顏色間的誤差
也就是在顯示器因為不同特質
基本上就有顏色表現的的差異
GAMMA修正則是用在還原顯示器表現出真實R/G/B
<<下恕刪>>

Sorry for deleting so many sentences.
就6bit模擬8bit而言,此種dithering並非是作在driver IC上的,而是在訊號進driver IC前就已經模擬,driver IC仍然為6bit。假如8bit模擬10bit也是這個原理的話,IC仍然是8bit。只是訊號進入前有個look up table去mapping。這是我個人的猜想。
這邊附上我之前寫在其他討論串裡的6bit如何模擬8bit顏色的方法。(若有錯誤,請告知。)
--------
FRC(or dithering)方法其實是利用人眼對於顏色的混色來將顏色再細分出來。
舉6bit模擬8bit為例。
以每個60Hz來說,將8bit-6bit的後面2bit以4個frame來補償。所以每個循環是4/60s,其演算方如下方。利用4個6bit的frame來混8bit的顏色。
6 bit---------------------------------------> 8bit
1st/60s, 2nd/60s, 3rd/60s, 4th/60s -> 4/60s
000000+000000+000000+000000 -> 00000000
000000+000001+000000+000000 -> 00000001
000000+000001+000000+000001 -> 00000010
000000+000001+000001+000001 -> 00000011
000001+000001+000001+000001 -> 00000100
000001+000010+000001+000001 -> 00000101
000001+000010+000001+000010 -> 00000110
000001+000010+000010+000010 -> 00000111
.
.
.
111110+111111+111111+111111 -> 11111011
111111+111111+111111+111111 -> 11111100
=> 共 253 個灰階
所以253x253x253 約16.19M色。
基本上若是用FRC方法模擬出來的顏色是16.19百萬色,
而以純8bit driver IC所表現的顏色256x256x256約16.77百萬色。
至於為何要去模擬?當然是cost的關係了,6bit IC與8bit IC是有價差的,目前17"也有這樣的趨勢。反正模擬這個動作在Scaler算是基本功能而已。
--------
其次是,要用螢幕表現出色彩的「真實性」,這個問題老實講非常複雜,也是目前很多軟、硬體廠商所要追求的目標,如錄像、資料coding、顯示卡、A/D sampling、螢幕...的配合問題。
我認為,並非色彩越多、顏色越鮮豔,螢幕表現會越有真實性,還必須其他條件配合。我只能說,色彩越多、顏色越鮮豔,螢幕的表現「比較有可能」優於色彩較少、顏色較不鮮豔的螢幕。(希望網友能指正或補充我的解釋。)
舊 2003-02-14, 08:54 PM #20
回應時引用此文章
oskwu離線中