Re: [閒聊] 合理的是訓練 不合理的是磨練??

[realmeat (念.力.寫.程.式)]

※ 引述《peacecorner (說謊的沒海鷗)》之銘言：
: ※ 引述《gaber (老。人渣爵士)》之銘言：
: : (前文恕刪)
: : 1. YCrCb to RGB 有快速演算
:         YCrCb to RGB的快速演算法我也在網路上查了
:         基本上就是把浮點運算改成整數運算
:         再加上查表法  一張640*480的圖在平台上要花>50ms
差不多, 24bit RGB許多運算只有255*255
建一個暴力乘法表, 取代掉乘法

: : 2. 當你想用 CxImage 去處理的時候，你已經輸了
: :    方便是方便，效率不能看
: :    把你要的部分抓出來用 C 重寫一次後再最佳化吧
:         我再CodeProject上抓了兩隻程式參考
:         一隻CxImage 另一隻TonyJpegDecoder
:         CxImage是效率比較好的
:         但是我看不懂他的Code
:         所以只有做效率測試參考
JPEG流程拆出來處理
首先要知道他大致上的運作
RGB-> YUV -> DCT -> 量化 -> Zigzig scan -> run length-> huffman
瞭解之後你就會知道有更多偷吃步的地方

檔案結構
http://delphi.ktop.com.tw/board.php?cid=168&fid=923&tid=81120

X和Y的密度單位, 看到這個
就知道支援可以偷很大
不過畫質一整個犧牲掉

: : 3. 每秒十張應該是還好而已
: :    不要太依賴微軟給的元件比較有機會
:         我當初給主管的建議是專心把YCrCb to RGB最佳化
:         就算要用組合語言寫也可以
:         然後再把RGB轉成JPEG(利用微軟的CImage只要7ms)
:         這樣比較有機會做出來
:         另外主要難度在於DCT
:         我估算了一下   用AAN快速演算也達不到需求的效率
:         何況實際上平台還有隻驅動程式不斷的透過鏡頭抓圖呢
AAN查一下, 還有許多地方可以做最佳化
例如把一些乘法用查表幹掉(前面已經建立了一個就繼續用)

還有,有些平台硬體是有支援DCT運算
你也可以稍微去問一下

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 218.166.10.215
推 GALINE:結論，原po應該早點到板上來問的…
推 abcdefghi:原po如果還沒遞辭呈,還來得及,趕快跟r大多請教幾招...
→ abcdefghi:這陣子很多公司人事緊縮想換工作,最好先找好再換....
推 iincho:這邊高手還真不少...:p
推 nagual07:不太懂原PO為何要YCbCr轉RGB?不是JPEG都吃YUV嗎?
→ nagual07:我知道YCbCr跟YUV不同
推 nagual07:我查了一下資料, 原來是我白痴