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

看板Soft_Job作者realmeat (念.力.寫.程.式)時間15年前 (2008/11/20 21:11)推噓5(5推 0噓 2→)

留言7則, 4人參與討論串8/14 (看更多)

※ 引述《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

11/20 21:25, , 1^F

11/20 21:25, 1^F

推

abcdefghi

11/20 21:57, , 2^F

11/20 21:57, 2^F

→

abcdefghi

11/20 21:58, , 3^F

11/20 21:58, 3^F