关于jpeg的8x8矩阵的提取

ys82 · 发表于 2009-2-18 15:33:43

按照ITU的说法：图像扫描方式从左到右，从上到下的顺序来处理。。如果用硬件实现jpeg压缩的话会很费资源。。。因为摄像头过来的数据是按行过来的。。。这样至少要保存八行才能拼凑出一个八x八的矩阵。。。为什么ITU要规定这样一个顺序。。。
如果我按照行来提出8x8矩阵，只要收齐64个数据就进行jpeg压缩可以不，这样做还能用ITU推荐的那些表格吗？？？？？

china_clear · 发表于 2009-2-20 10:38:26

你算算,这两种情况下,第一个点与最后一个点的距离是多少?
哪一种关联性大?[br]+1 RD币

ys82 · 发表于 2009-2-20 16:05:13

相关性不大会怎样？？

frag3170 · 发表于 2009-2-23 10:27:14

照楼主的做法,后面解码也得跟着变啊,

ys82 · 发表于 2009-2-25 09:41:12

是的。。。变没关系。。。关键是这样压缩可行不？

frag3170 · 发表于 2009-2-25 11:24:13

呵呵,这样做当然可以啦,只要是编码,解码都自己设计的话(后续的解码必须相应变化,所以像acdsee之类的软件肯定是看不了你压缩的图的),不过因为相关性不高,压缩率也会比较差.

当然这就不叫JPEG啦.

iiiooo · 发表于 2009-2-25 13:03:43

自己设计压缩算法？

so520hf · 发表于 2009-8-17 10:27:14

不是很理解

chris_meng · 发表于 2009-8-20 21:49:53

当前宏块的DCT变换基本上是这个块的，

但是请看看直流分量的编码方式，DPCM再huffman编码。
标准规定了要求的是从上到下，从左到右。
若DC分量不按照此顺序，解码端肯定要变化了。

另外，这样的顺序，也是为了让DC分量的编码量小一些，
原因是DC分量的横向相关性（当然不否认其他方向的相关性），可以被压缩得更充分。[br]+3 RD币

blackaj · 发表于 2009-8-24 11:49:37

回一樓

DCT base JPEG 壓縮原理最關鍵的部份就是利用DCT取出image的各種頻域係數.
再利用量化去降低影像的資料量.

一般用硬體實現大都要掛 8-line以上的buffer, 以800x600來說, 8條800*rgb =18.75KB
要內建不是不可能不過蠻吃資源的.

所以如要使用2D DCT,就不能將row[0:63]當成 8x8 block處理
另外8x8 block在JPEG內應該稱為 data unit , 多個data unit 可以組成一個 minimum coded block(MCU)

當然若是要自行開發row-base JPEG-like 的壓縮方法也是可以使用1D DCT的, 這方面有很多patent可以看.
大體上都是使用JPEG format + 1D DCT/IDCT + 1D Q/IQ + RLD/DPCM +Huffman.

[br]+3 RD币

kakayi · 发表于 2009-8-25 10:33:37

以上说的有道理,路过学习一下

centerxy · 发表于 2009-9-19 10:53:43

学习学习~

lengsen · 发表于 2010-7-26 22:37:45

学习一下喽~

ldj000 · 发表于 2010-8-11 14:37:43

学习。。。。

ldj000 · 发表于 2010-8-21 17:54:23

学习。。。。

lengsen · 发表于 2010-11-27 22:50:05

理解一下高深的思想~

		自动登录	找回密码
密码			注册

[讨论] 关于jpeg的8x8矩阵的提取