找回密码
 注册
搜索
查看: 3173|回复: 19

[讨论] JPEG图像有些手机打不开,求救!

[复制链接]
发表于 2006-4-12 23:59:00 | 显示全部楼层 |阅读模式
各位大虾,最近我在做一个手机彩信方面的项目,发现采集的图像,通过JPEG压缩算法(Baseline)压缩,发送到手机上,有些手机能够打开,有些手机打不开,在微机上所有的开图工具都能打开。请教各位高手,手机里的JPEG格式是不是有什么特殊要求?希望各位高手不吝赐教,谢谢!我的email:fanyuanqin@tom.com,希望做各位高手交流、指教。
 楼主| 发表于 2006-4-14 15:13:00 | 显示全部楼层
<P>怎么没人恢复啊?各位高手,不吝赐教!</P>
点评回复

使用道具 举报

发表于 2006-4-14 15:58:00 | 显示全部楼层
<P>这个要看看你用的压缩算法编码后的文件,重点检查文件头,方法如下:</P><P>用UltraEditor打开该文件,看看第三四字节是不是0xff0xe0或是0xff0xe1,前者是JFIF格式,后者是Exif格式,数码相机一般是采用后一种格式,如果是前一种格式可能有的解码软件不支持。</P><P>再就是元素分割编码模式,即YHxYV,CbHxCbV,CrHxCrV:有四种模式:</P><P> 2x2,1x1,1x1;  1x2,1x1,1x1; 2x1,1x1,1x1;and 1x1,1x1,1x1</P><P>一般采用2x2,1x1,1x1还有些是2x1,1x1,1x1,如果是另外两种,可能有些软件就不支持了。</P><P>说道这里,我就要说说baseline模式下,应该以上所说的都应该支持,但考虑到内存和解码时间,有些手机软件就对一些不常用模式不支持了,这不足为怪。建议你将原始图片用ACDSee或PS再转一遍JPEG格式,就得到了标准常用的模式了,再下到手机看看,再不行的话我就没辙了。</P>[br]<p align=right><font color=red>+5 RD币</font></p>
点评回复

使用道具 举报

 楼主| 发表于 2006-4-18 21:25:00 | 显示全部楼层
谢谢snaper,再次请教snaper,我实现的jpeg 编码器,元素分割用的是2x2,1x1,1x1,这个应该不是主要原因。我是在DSP上实现的,考虑DSP结构和内存特点,每个扫描只有一个图像分量,即输出数据是非交织的。是不是部分手机不支持非交织数据的解码。
点评回复

使用道具 举报

发表于 2006-4-18 23:44:00 | 显示全部楼层
<P>可能问题就出在这里。</P><P>我做的JPEG解码程序确实是图像分量元素交织解码的,即:如果用2x2,1x1,1x1模式,则在解码的时候先做Y分量的4次解码(包括HUFFMAN解码和IDCT),再做一次Cb分量的解码,最后做一次Cr分量的解码。这样就一次解得了4个8×8象素的图像块。</P><P>解码和编码应该是配对使用的,做编码的时候尽量要按照T.81或JFIF的文件格式要求来做。</P>[br]<p align=right><font color=red>+3 RD币</font></p>
点评回复

使用道具 举报

 楼主| 发表于 2006-4-19 17:20:00 | 显示全部楼层
谢谢snaper,我正在把编码器改成交织的。T.81上jpeg baseline是可以按交织或非交织进行编码。
点评回复

使用道具 举报

 楼主| 发表于 2006-4-27 15:15:00 | 显示全部楼层
<P>把扫描方式改成交织的,绝大部分手机都能够打开了。希望我们做研发的多多交流!共同进步!</P>
点评回复

使用道具 举报

发表于 2006-5-17 13:29:00 | 显示全部楼层
请问在一幅JPEG文件里的哪个地方可以看出扫描方式是交织的还是非交织的?谢谢[em01]
点评回复

使用道具 举报

发表于 2006-5-17 14:59:00 | 显示全部楼层
<P>用UltraEditor打开一幅JPEG图片,找到“0xFFC0”字段,按照T.81的baseline的说明查看其元素分割编码模式:
点评回复

使用道具 举报

发表于 2006-5-17 16:30:00 | 显示全部楼层
怎么上传图片?我想对照着说一下[em01]
点评回复

使用道具 举报

发表于 2006-5-18 10:23:00 | 显示全部楼层
我发现直接上传图片不行,会被解码并打上52RD的水印,然后重新编码过,失去我本来上传图片进行说明的意义了。
我把.,jpg的扩展名改成.txt再上传:


【文件名】:06518@52RD_Origin.txt
【格 式】:txt
【大 小】:16K
【简 介】:原始的jpg图片,在Moto的手机上无法显示
【目 录】:



我看了FF C0段,是一样的,看jpg图片到底是不是交织编码应该看FF DA(SOS)段吧

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?注册

×
点评回复

使用道具 举报

发表于 2006-5-18 13:41:00 | 显示全部楼层
我发现在Moto手机上不能显示的图片中间有restart,是不是手机的解码程序不支持这种格式啊?[em13]
点评回复

使用道具 举报

发表于 2006-5-19 10:09:00 | 显示全部楼层
<P>to liangdan:</P><P>我看了你的两附图,原图用的扩展符是0xFFE2,而不是我们常用的“JFIF”或“EXIF”格式,再看它的量化表0xFFDB有问题,两个量化表的全部大小应该是0x80,而它的大小显然不是“0xFFDB0x0084”,刚好是把第二个量化表又弄了一个出来。如果你是做解码软件的,你该怎么办?软件很肯能会读文件出错!!!</P><P>时下手机的硬件解码一般只支持baseline模式,所以其他的超出这个范围的很可能就打不开了,相反,PC机的专用看图软件就强大的多,经过像ACDSee这样的软件转换后的图一般也是baseline模式的,这样在手机上能看也不奇怪了。</P><P>注:0xFFDD  DRI(restart)表示的是huffman表重置,软件设计应该是考虑进去的,没有影响的。</P>
点评回复

使用道具 举报

发表于 2006-5-19 11:46:00 | 显示全部楼层
<P>to snaper:</P><P>我在PC上编程,把一个bmp文件压缩成jpg,使用量化表的定义方式就是FF DB 00 84……,然后把这幅jpg传到Moto手机上,可以打开。因为这种量化表定义的方式就是把2个量化表放在一个段里,具体参见T.81的43页:B.2.4.1 Quantization table-specification syntax的说明,和2个FF DB 00 43的效果应该是完全一样的,对手机上的解码应该不会有影响。</P><P>huffman表的定义也一样,可以把4个码表放在一个段里(FF C4……),也可以分别放在4个段里,不影响解码。</P><P>至于FF E2这种扩展格式,是可以在很多品牌的手机上打开的,解码软件完全可以跳开这里继续下去。我编程把FF E2这一段替换成了FF E0……,即JFIF格式,Moto手机还是打不开。</P><P>基于以上的试验,我认为Moto手机打不开原图的原因是它不支持restart。</P>
点评回复

使用道具 举报

发表于 2006-5-19 21:44:00 | 显示全部楼层
<P>to liangdan:</P>
<P>我前面说的你可能没听明白,我还是认为你那张图的量化表有问题。</P>
<P>你看看“0xFFDB0x0084”这一段到下一段“0xFFDD”之间,数一数有几个字节?不是132个,而是196个,你的软件是如何能够处理?读文件的指针会不会出错?程序会不会异常而退出?如果是硬件解码的话,更是难以预料。</P>
再看看你转换后的图,量化表是分两段的,问题不在这里。对比两图的量化表,发现原图的量化表在QT_C(色量化表)后又多出来一段数据“0x0A0x0B。。。”像是复制了QT_C的一段,而本该在这段数据之前就结束,这正好符合“0x84”的长度。


<P>PC机的专用看图软件(如ACDSee)是怎么能看原图的,具体我不知道,看可以肯定它的处理能力及容错能力要强大的多。至于我说到“JFIF”和“EXIF”格式之外的格式,其本身倒不是问题,问题是格式和生成图像的软件(或者说是JPEGcoding算法)是紧密联系的,如经过ACDSee转换后的图一般是“JFIF”格式,而“EXIF”这一般是数码相机支持的格式。这个问题远不是将0xE2修改0xE0那么简单。</P>
<P>你认为打不开图片的原因是0xFFDD(restart)有何根据?如果你有怀疑,你完全可以把它删除掉,量化表接着就是0xFF0xC0(SOF),你再看有什么影响。
其实一个可靠的JPEG解码程序,在SOS开始后读取压缩数据解码前,无论有没有restart,都会重值HUFFMAN表的。</P>
[此贴子已经被作者于2006-5-19 22:16:39编辑过]
点评回复

使用道具 举报

发表于 2006-5-22 09:08:00 | 显示全部楼层
<P>to snaper:</P><P>搞定了,谢谢你!</P><P>我把量化表里多出来的那个表去掉了,可以在moto上显示了。原来出错是因为我是通过USB把jpg数据传过来,usb的程序没做好,多传了,但是由于PC上的图像工具容错能力比较强,可以显示出来,我没有发现这个错误。</P>
点评回复

使用道具 举报

发表于 2006-5-22 15:10:00 | 显示全部楼层
<P>我在看JPEG里的huffman编解码过程,参考网上流传甚广的JPEG简易文档,看得晕晕的,看T.81里的huffman表也不知道什么意思,例如DC系数的huffman表中第一列category代表什么,以及AC系数的huffman表中第一列run/size代表什么,请大侠指教</P>[em01]
点评回复

使用道具 举报

发表于 2006-5-22 18:43:00 | 显示全部楼层
<P>关于JPEG的huffman表的问题,不是几句话就能说清楚的,强烈建议看--东南大学吴乐南编著的《数据压缩》!!!</P><P>它上面有一章就是专门讲JPEG的,对huffman表有很详细的解说。</P><P>那个JPEG简易文档是云风多年前的作品,基本原理倒是说清楚了,有一定参考价值。不过它是针对PC机的,而且也有很多遗漏的地方。前段时间在52RD驱动版看到有人问道多帧JPEG的解码问题(就是有多个SOI在一个文件里),以前我也遇到这个问题以为是图片的问题当时就搁置起来了,现在有人问起来确实也要解决,苦于一直没有时间做试验,待我这段时间有所喘息再说。</P><P>对JPEG解码有任何疑问的,可以发信和我交流:<a href="mailthglinfei@163.com" target="_blank" >hglinfei@163.com</A></P>
点评回复

使用道具 举报

发表于 2006-6-6 22:22:00 | 显示全部楼层
<P>补记:</P><P>多帧JPEG经初步判断,不是baseline模式,而是传说中的渐进模式,可能会遇到算术编码,比baseline要复杂的多,所以公开研究的资料不多。</P>
点评回复

使用道具 举报

发表于 2006-6-8 10:17:00 | 显示全部楼层
<P>For the progressive DCT-based mode, 8 × 8 blocks are also typically encoded in the same order, but in multiple scans through the image. This is accomplished by adding an image-sized coefficient memory buffer (not shown in Figure 4) between the quantizer and the entropy encoder. As each block is transformed by the forward DCT and quantized, its coefficients are stored in the buffer. The DCT coefficients in the buffer are then partially encoded in each of multiple scans.</P><P>渐进模式的墒编码有两种:huffman和算术编码。不过算术编码由于专利问题,没有被使用!</P>
点评回复

使用道具 举报

高级模式
B Color Image Link Quote Code Smilies

本版积分规则

Archiver|手机版|小黑屋|52RD我爱研发网 ( 沪ICP备2022007804号-2 )

GMT+8, 2024-11-23 07:28 , Processed in 0.082352 second(s), 17 queries , Gzip On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表