Re: [請益] webcam的速度?
※ 引述《wahaha99 (此方不可長)》之銘言:
: → kuninaka:640*480*8*3 這樣呢 05/23 00:38
: → kuninaka:一個像素應該至少存255,255,255 05/23 00:39
: → kuninaka:所以是三個8bit 請webcam專業人士出來回答吧XD 05/23 00:41
: → kuninaka:那三組是RGB 05/23 00:41
: → kuninaka:有請圖學專家XD 05/23 00:41
: → kuninaka:所以才說請專業人士回答XDD 沒碰過這塊XD 05/23 01:00
通常不會是RGB格式....一般影像會用YUV或者是YCbCr儲存,
其中Y是亮度,後兩個是彩度....組成彩色影像.
會這樣做的主要原因是符合大多數過去的影片或者是電視系統等,
而過去用YUV也有包袱問題,也就是從黑白電視電影時代,系統只傳送
亮度.為了跟這些相容,彩色電視電影影片等也就以YUV為主.黑白電視
系統接受到Y以外的訊號會無視.
不過,現在在電腦上數位化後,即使電腦大量採用RGB為基礎的LCD/CCD
來顯示/儲存影像.影片壓縮格式仍然會以YUV/YCbCr為主.不會回到RGB.
這有一個明顯的好處.人眼對亮度比較敏感,對彩度比較不敏感,所以影像
格式可以只把資料空間留給Y值,將剩下兩個彩度值縮減,對影像的品質
影響還不大.
自從MPEG出來後,應該沒有多少電腦上的影像格式還保留在RGB的..
(古早dos的抓圖軟體自定格式,以及Win 3.1的MS"原始AVI"是RGB格式.....)
不過,640x480全彩,即使用YUV 各8bit/4bit/4bit儲存,再用字典壓縮法
也頂多只能把一個畫面900KB壓縮成300KB而已,這仍然不夠.
所以.....進階的影像壓縮是怎麼做的呢 ??
只要從JPEG/MJPEG/MPEG開始介紹起,再介紹到MPEG4/H.264就差不多了,
技術概念上要理解的部分不算很多啦.....
為什麼我們看的見顏色 ??顏色的物理性質是 ??
R,G,B在物理上是三種不同頻率的光,不過為什麼是這三種顏色是
基本色
主要是生理性質而非物理性質.人眼中負責感光的細胞有四種.
一種是只會感應光的亮度的桿狀細胞,三種是感應特定波長的光的
錐狀細胞,這三種當然最會產生反應的對象範圍在是R,G,B三個
波長附近....
紅外 ||紅 橙 黃 綠 藍 紫 || 紫外
弱弱弱強強弱弱無無無無 錐1
無無弱弱弱強強弱弱無無 錐2
無無無無無無弱弱強弱弱 錐3
視覺的黃色,可能是完全反射了570nm,純的黃色光.
(但是除非用雷射直接打眼睛,否則應該沒機會:: )
讓錐狀1跟錐狀2兩種細胞各產生強弱的反應,在腦部神經中
組合成"看見黃色"的感覺.
也可以是看到一定比例的紅光(僅錐狀1有反應),一定比例的
綠光(錐狀2有反應,其他無).這兩種到了腦部認知中會完全等價.
所以說,用RGB三種光的強弱也可以調配出各種顏色.不是因為
紅光加上綠光兩個頻率會互相中和變成黃光(物理上不可能)
色彩學有點離題.反正只要先知道YUV或者是YCbCr,一個是亮度,
後面兩個代表的彩度..可以組成跟RGB系統幾乎等價的座標軸就好.
接著前面已經說過了,彩度的儲存資料量可以減少,人眼比較不敏感.
這個過程可以以4:4:4(不縮減彩度),4:2:2(彩度精確度是亮度的一半),以及
更進階的4:2:0....這個要稍微解釋一下,不是只留下一種彩度,而是彩度輪流
儲存,沒存的跟隔壁掃描線補.所以正確的4:2:0應該說是4:2:0和4:0:2交錯
掃描線N 4:2:0 ----------->
N+1 4:0:2 ----------->
N+2 4:2:0 ----------->
當然,要做比較簡單的4:1:1也可以.
不過只這樣,相對RGB好像只減少了1/3~1/2的資料量吧 ??
接下來就是失真影像壓縮最重要的觀念,量化表(Quantilation Table)
基本觀念就是....任何連續的資料stream如影像,聲音等.
把它資料化以後,也和富立葉轉換一樣.可以以無限個不同頻率/振幅的波表示.
只是影像部分是2D的波,聲音以及其他是1D的波
那......如果我覺得我只要嘗試用少量的波型去趨近原來的資料分布,
少部分失真沒關係,但是省去大量的資料量,這樣可行嗎?
可行的,如果省略的是分析出的波裡面的高頻部分,只留下低頻部分.
那麼實際上跟原本的資料分部只會有少部分誤差...也就是
2D資料 --> 頻率資料(也是NxN) -->量化
N 低
* * * * 低* * * *高 * * * *
N * * * * * * * * * * *
* * * * * * * * * * 留下這些就好了,其他當0,不用存
* * * * * * * * *
高
這樣又可以省去大量的資料量,而得到略為失真的結果.
接下來.把這些資料以無失真壓縮法儲存起來,才會是最後的結果.
這個過程中,總共的壓縮率達到5~10倍以上.
補充一下,jpeg是用變相的4:2:0儲存彩度問題,接著在量化時候以DCT
而非富立葉轉換處理,最後的非失真壓縮則以huffman encoding處理.
使用DCT/FFT的壓縮會有甚麼問題呢?由於他們用的都是SIN/COS波.
在數位資料上.瞬間變化很大的部分只能以高頻率表示.比如我們以黑底
(RGB=0,0,0)紅字(RGB=255,0,0)當例子
----黑紅紅黑--->
255 |-----|
| |
| |
| |
| |
0----| |-----
這個不管以SIN/COS波來模擬,都需要以頻率近乎無限大的
波.如果只使用低頻率的波那麼就.............
----淺淺紅淺淺--->
255 ---
/ \
/ \
/ \
/ \
0--| |--
中間會留下一大段範圍是淺紅色.這個自行拿jpeg壓縮一個X底紅字
然後放大看就知道了.相當於本來明確的邊緣,會被破壞的很模糊...
所以說JPEG/MPEG,只適合自然拍攝的影像.不適合人工產生的如動畫,CG
等等.當然如果壓縮率設太高,也就是中高頻資料砍的差不多,只剩下最低頻
的來還原原本資料....那不管本來是甚麼都會很模糊.
上面介紹完了JPEG,用同樣的方法,把靜態影像每張都存起來,變成動態.
就成為Motion-JPEG了,但是到真正的MPEG,技術上還缺了一個稱為動作補償
的東西.
OK,這動作補償又是甚麼 ??
由於是動態影像,所以每張圖取的都是相差一點點時間的動作,那麼一般而言,
這些圖應該是大同小異的變化.比如說拍電影,取景的背景不變,只有人物在前面演戲.
那麼就這一串影像而言,只有前景的人物是有改變的.背景幾乎都和之前相同.....
有沒有甚麼辦法節省這些畫面上不動的部分,告訴他們"其實取上一個畫面
來補充"就好了 ??
相對於完整的frame(稱為I),MPEG設計了P(向前一個畫面參考),以及B(向前面以及
"後面"的frame參考資料).如果MPEG中不使用P/B兩種frame,就相當於Motion JPEG,
使用到的話..在B/P frame裡面保存的資料只有有變化的區塊,所以實際資料量比較少.
但是B/P使用太多的話,那麼要跳著存取就不方便了,因要這樣就得跨很大量的資料
幫你重新組合出完整的資料.所以一個考量過的平衡的標準是IBBPBBP的循環.
MPEG1/MPEG2的動作補償只以區塊為單位,會造成的缺陷是,如果是整個畫面都有變化
(攝影機的視角變化,轉動就造成如此現象).這時候對整個影像會有相當大的影響.
比如說視角一轉動就滿螢幕馬賽克現象.
上面大概介紹完了MPEG-1,那麼...MPEG-2相對於MPEG-1的技術有改進嗎?
其實只以技術來看,技術上兩者差不多,資料量上以及門檻兩者就有差了.
MPEG-2是希望能對應當時的完整的SDTV/5.1聲道,以
及可接受至少超過LD的影像品質.
而MPEG-1卻要適應當時的CD容量以製作VCD,也要適應當時硬體處理的能力.
所以MPEG-1比較像是過渡規格.這也是很多高收入地方不曾流行過VCD,直接
轉到DVD的原因.
MPEG 1/2後的後繼者.MPEG 3/4/7等.其中3原本希望對應HDTV,但是後來
發現並不需要特別訂出MPEG-3,因為MPEG-2提高資料量後,也可以很好的對應
HDTV的傳送.因此MPEG-3並沒有推展.另外MPEG-7個人理解為一種資料庫檢索影像
的方式.跟影像規格沒有直接關係.....所以MPEG2最重要的後繼者就是
MPEG-4
MPEG-4當然包含了前面在MPEG-1/MPEG-2中介紹的做法.同時也定義了
從簡單到完整的多個層次的實作以給不同的廠商遵循,不過若只要談技術
上最大改進的話....
相比之前,最大的改進還是更好的動作補償.前面說過MPEG 1/2的動作補償.
主要以區塊為主,然後跟前一個/後一個frame比較.但是MPEG-4把分別的標準
設定為前景物件們跟背景.當一個物件移動的時候,MPEG 1/2的所有被影響到的
範圍內的區塊都會有變化,但是MPEG-4卻會把這個當成"物件的影像變化"+"物件的
移動方向"來處理.所以在低流量的時候,可以做到更好更低流量的動作補償.
不過,要是輸入的影像是拍攝的,如何偵測分離出前景物件來儲存呢?
這就是在mpeg-4技術規格中的shape coding以及texture coding了.
(略...webcam應該沒有即時壓縮mpeg-4的)
至於其他很多大家會聽到的規格啦,不過很多都是MJPEG-->MPEG4這一條線
為基礎衍生出來的.比如說Quicktime衍生自MJPEG,WCDMA手機的3GP影像衍生自MPEG4等.
基本上.......
H.261 H.262 -->H.263 \
/\ /\ \
|| || \
Motion JPEG --> MPEG -->MPEG 2 -->MPEG 4 --> H.264/AVC
|| || | || ||
\/ \/ | \/ \/
QuickTime VC-1 | 3GP FLV
最早最早的 |
V
WMV,ASF
技術上比較獨立無關的:
Intel Indeo Video(低流量為主),同時也被VfW跟Quicktime支援
RealMedia RealVideo(一開始低流量為主,而且被評為品質比MPEG-1還慘,
直到做出rmvb後才有改善)
webcam有些採用現成的codec,有些採用自家的codec...不過大多數自家的
codec,也大量採用了現成的技術.所以說從MJPEG-->MPEG-->MPEG4開始理解起的話,
就可以對大部分的影像壓縮技術有個七八成的理解了.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.114.78.62
※ 編輯: jk21234 來自: 140.114.78.62 (05/26 05:37)
→
05/26 05:38, , 1F
05/26 05:38, 1F
→
05/26 05:39, , 2F
05/26 05:39, 2F
→
05/26 05:41, , 3F
05/26 05:41, 3F
→
05/26 05:42, , 4F
05/26 05:42, 4F
推
05/26 05:45, , 5F
05/26 05:45, 5F
推
05/26 06:52, , 6F
05/26 06:52, 6F
→
05/26 06:53, , 7F
05/26 06:53, 7F
→
05/26 06:54, , 8F
05/26 06:54, 8F
→
05/26 06:54, , 9F
05/26 06:54, 9F
推
05/26 07:46, , 10F
05/26 07:46, 10F
推
05/26 08:14, , 11F
05/26 08:14, 11F
推
05/26 08:45, , 12F
05/26 08:45, 12F
推
05/26 08:48, , 13F
05/26 08:48, 13F
推
05/26 09:10, , 14F
05/26 09:10, 14F
推
05/26 09:15, , 15F
05/26 09:15, 15F
推
05/26 09:17, , 16F
05/26 09:17, 16F
推
05/26 09:23, , 17F
05/26 09:23, 17F
推
05/26 10:40, , 18F
05/26 10:40, 18F
推
05/26 10:54, , 19F
05/26 10:54, 19F
推
05/26 10:56, , 20F
05/26 10:56, 20F
→
05/26 10:56, , 21F
05/26 10:56, 21F
推
05/26 12:15, , 22F
05/26 12:15, 22F
推
05/26 12:23, , 23F
05/26 12:23, 23F
推
05/26 13:10, , 24F
05/26 13:10, 24F
推
05/26 13:13, , 25F
05/26 13:13, 25F
推
05/26 13:25, , 26F
05/26 13:25, 26F
推
05/26 14:13, , 27F
05/26 14:13, 27F
推
05/26 14:54, , 28F
05/26 14:54, 28F
推
05/26 15:07, , 29F
05/26 15:07, 29F
推
05/26 15:35, , 30F
05/26 15:35, 30F
→
05/26 15:35, , 31F
05/26 15:35, 31F
推
05/26 15:54, , 32F
05/26 15:54, 32F
推
05/26 15:58, , 33F
05/26 15:58, 33F
推
05/26 18:26, , 34F
05/26 18:26, 34F
推
05/26 21:37, , 35F
05/26 21:37, 35F
推
05/26 22:30, , 36F
05/26 22:30, 36F
推
05/27 02:37, , 37F
05/27 02:37, 37F
推
05/27 02:53, , 38F
05/27 02:53, 38F
推
06/01 02:43, , 39F
06/01 02:43, 39F
推
06/12 20:46, , 40F
06/12 20:46, 40F
推
08/09 21:04, , 41F
08/09 21:04, 41F
推
12/23 01:31, , 42F
12/23 01:31, 42F