jpg毁损检测思路

基于libjpeg保存jpg图像或者读取图像时,特别是再存储大尺寸图像时,一个问题特别突出。即图像存储明明毁损了,但是调用存储的函数直接再控制台输出警告信息,但是没有返回值或者异常可供捕获。造成毁损的原因不明。只能推测是libjpeg多线程存储问题。其中图像存在 JWRN_JPEG_EOF 问题时特别致命。因为图像从某一个节点之后信息全部无效。以下是最终算法能够捕获的毁损。

JMESSAGE(JWRN_JPEG_EOF, "Premature end of JPEG file")

JMESSAGE(JWRN_HUFF_BAD_CODE, "Corrupt JPEG data: bad Huffman code")

JMESSAGE(JWRN_TOO_MUCH_DATA, "Application transferred too many scanlines")

JWRN_JPEG_EOF是核心要解决的问题。 后俩者是最后优化代码时剩余部分比较复杂,时间有限,保留代码顺带检测。

动手解决之前思路:基于libjpeg库,屏蔽掉无关代码,将警告改为异常抛出。捕获并产生相应记录信息。因为是提前终止,因此期待直接从文件头获取文件长度和实际文件长度比较,直接得到判定。

实际解决思路:

1.借鉴opencv的库进行libjpeg重新改写。

2.将libjpeg里面一些C代码更改为C++代码,并消除一些与检测无关代码,提高检测效率。

3.跟踪JWRN_JPEG_EOF 出现位置,梳理前后代码。发现动手前的思路存在缺失。并不能直接获取文件长度进行比较。实际jpg判断该问题是基于段,每次循环前判定当前读取字节数 < 该段字节总数。是的话一次读取固定长度(jpg代码有具体数值)。当读取到字节数目<固定长度,就会进行判定 抛出俩种异常其中一种 就是“JWRN_JPEG_EOF”。 原始libjpg代码如下:

 1 METHODDEF(boolean)
 2     fill_input_buffer (j_decompress_ptr cinfo)
 3 {
 4     my_src_ptr src = (my_src_ptr) cinfo->src;
 5     size_t nbytes;
 6 
 7     nbytes = JFREAD(src->infile, src->buffer, INPUT_BUF_SIZE);
 8 
 9     if (nbytes <= 0) {
10         if (src->start_of_file)    /* Treat empty input file as fatal error */
11             ERREXIT(cinfo, JERR_INPUT_EMPTY);
12         WARNMS(cinfo, JWRN_JPEG_EOF);
13         /* Insert a fake EOI marker */
14         src->buffer[0] = (JOCTET) 0xFF;
15         src->buffer[1] = (JOCTET) JPEG_EOI;
16         nbytes = 2;
17     }
18 
19     src->pub.next_input_byte = src->buffer;
20     src->pub.bytes_in_buffer = nbytes;
21     src->start_of_file = FALSE;
22 
23     return TRUE;
24 }
 1 METHODDEF(boolean)
 2     fill_mem_input_buffer (j_decompress_ptr cinfo)
 3 {
 4   static const JOCTET mybuffer[4] = {
 5     (JOCTET) 0xFF, (JOCTET) JPEG_EOI, 0, 0
 6   };
 7 
 8   /* The whole JPEG data is expected to reside in the supplied memory
 9    * buffer, so any request for more data beyond the given buffer size
10    * is treated as an error.
11    */
12   WARNMS(cinfo, JWRN_JPEG_EOF);
13 
14   /* Insert a fake EOI marker */
15 
16   cinfo->src->next_input_byte = mybuffer;
17   cinfo->src->bytes_in_buffer = 2;
18 
19   return TRUE;
20 }

4.找到查错代码后更改自定义代码。我理解不够没有重新书写代码,而是通过剥离出来的opencv的jpeg库调用。然后跟踪执行路径,把执行路径中的函数标记出来,重新写成自己的函数,然后调用。

5.最终效果:使用opencv读取图片会报 JWRN_JPEG_EOF,我这边也会报。执行时间:16000*8192彩色图像,用imread执行时间3~5s,用我更改后的libjpeg库只需要0.2~0.3s(这边耗时主要霍夫编解码上面。因为指针遍历有部分再霍夫编解码上,赶时间没有细究。如果消除的话就是 10ms以内级别操作)。

 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2019-05-10这样直接改某些情况下会触发野指针。暂不清楚引起得原因。因为此时有问题的图片能打开,能看。不确定是真的文件存在问题,还是写的算法有问题。所以最好加异常捕获代码。

posted @ 2018-06-06 15:49  飘零_未知的坚持  阅读(1430)  评论(0编辑  收藏  举报