作者realmeat (念.力.写.程.式)
看板Soft_Job
标题Re: [闲聊] 合理的是训练 不合理的是磨练??
时间Thu Nov 20 21:11:52 2008
※ 引述《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
1F：推 GALINE:结论，原po应该早点到板上来问的… 11/20 21:25
2F：推 abcdefghi:原po如果还没递辞呈,还来得及,赶快跟r大多请教几招... 11/20 21:57
3F：→ abcdefghi:这阵子很多公司人事紧缩想换工作,最好先找好再换.... 11/20 21:58
4F：推 iincho:这边高手还真不少...:p 11/20 22:05
5F：推 nagual07:不太懂原PO为何要YCbCr转RGB?不是JPEG都吃YUV吗? 11/20 22:55
6F：→ nagual07:我知道YCbCr跟YUV不同 11/20 22:56
7F：推 nagual07:我查了一下资料, 原来是我白痴 11/20 22:59