长话短说
版本区间[OpenCV3.0.0, OpenCV3.4.1]内的OpenCV,(至少在windows下,使用官方提供的预编译版本),imread读取jpg图片后的像素值,和版本区间[OpenCV2.4.9, OpenCV2.4.13.6]结果不一样,虽然imshow看到的结果差不多。
从编码解码角度考虑并没有谁对谁错,但是要注意到,imread结果的不同对于CNN框架前向计算结果的影响。(妈的,因为这个difference,周末被迫加班,对OpenCV多了一份不信任)
关键是,这个不同,在opencv官方changelog中找不到!
啰嗦版本
OpenCV的imread并没有自己去实现编码解码,而是根据图像类型(jpg, png等)去调用相应的编码解码器(libjpeg,libpng等)。
因为不是研究传统DIP的图像编码解码的,以前没有注意到opencv的不同版本中jpg图像解码器的不同。
但是最近项目中我负责维护的CNN前向计算框架计算结果不太对,表现为SSD网络输出的loc信息,小数点后面几位对不上。明明一样的图,CNN前向代码我仅仅是拆分layer到文件,没有修改逻辑。为何结果不对??
尝试逐层打印结果,第一步应该确认网络输入,结果发现imread后再去查看图像像素值,同一张图结果不一样。imshow则看不出来区别。
一开始因为CMake用了最新版,但是CMakeLists.txt里配置出了点问题,发现读取结果不对的情况,是使用了配置的Windows下Caffe的依赖包里的OpenCV,也就是opencv3.1.0。
于是手动从官方下载了opencv3.1.0的windows预编译版本,发现确实,结果仍然和opencv249不对。我这里以opencv249结果算作正确,尝试了一个下午,发现opencv3.0.0到opencv3.4.1(包含)这系列版本的imread都不对。无语了:
问题的原因,通过打印每个opencv版本的图片解码信息cv::getBuildInformation()
来查看:
#include <stdio.h>
#include <iostream>
#include <string>
#include <opencv2/opencv.hpp>
using namespace std;
using namespace cv;
int main() {
std::string im_pth = "F:/xx/work/20190315/1.jpg";
cv::Mat src_image = cv::imread(im_pth);
IplImage* shadow_image = cvLoadImage(im_pth.c_str(), CV_LOAD_IMAGE_COLOR);
std::cout << cv::getBuildInformation() << std::endl << std::endl << std::endl;
for (int i = 0; i < shadow_image->height * shadow_image->width * 3; i++){
fprintf(flog, "%f\n", (float)(unsigned char)(shadow_image->imageData[i]));
if (i == 0) {
// 158 is correct
// 192 is wrong
printf("%u\n", (unsigned int)(unsigned char)(shadow_image->imageData[i]));
}
}
fclose(flog);
printf("-------------------end-------------------\n");
return 0;
}
我这里的情况,打印上面这张jpg图片的第一个像素值,opencv249打印出来是158(认为是正确,因为板子上跑的版本就是这个结果,是正确的标准,DSP优化库要以这个为标准的),而opencv310打印出来是192。
各个opencv版本的Media IO信息:
//-------------------
opencv 3.0.0 (wrong)
Media I/O:
ZLib: build (ver 1.2.8)
JPEG: build (ver 90)
WEBP: build (ver 0.3.1)
PNG: build (ver 1.5.12)
TIFF: build (ver 42 - 4.0.2)
JPEG 2000: build (ver 1.900.1)
OpenEXR: build (ver 1.7.1)
GDAL: NO
//------------------
opencv 3.4.1 (wrong)
Media I/O:
ZLib: build (ver 1.2.11)
JPEG: build (ver 90)
WEBP: build (ver encoder: 0x020e)
PNG: build (ver 1.6.34)
TIFF: build (ver 42 - 4.0.9)
JPEG 2000: build (ver 1.900.1)
OpenEXR: build (ver 1.7.1)
//------------------
opencv 3.4.2 (correct)
Media I/O:
ZLib: build (ver 1.2.11)
JPEG: build-libjpeg-turbo (ver 1.5.3-62)
WEBP: build (ver encoder: 0x020e)
PNG: build (ver 1.6.34)
TIFF: build (ver 42 - 4.0.9)
JPEG 2000: build (ver 1.900.1)
OpenEXR: build (ver 1.7.1)
HDR: YES
SUNRASTER: YES
PXM: YES
//------------------
opencv 2.4.9 (correct)
Media I/O:
ZLib: build (ver 1.2.7)
JPEG: build (ver 62)
PNG: build (ver 1.5.12)
TIFF: build (ver 42 - 4.0.2)
JPEG 2000: build (ver 1.900.1)
OpenEXR: build (ver 1.7.1)
//------------------
opencv 2.4.13.6 (correct)
Media I/O:
ZLib: build (ver 1.2.7)
JPEG: build (ver 62)
PNG: build (ver 1.5.27)
TIFF: build (ver 42 - 4.0.2)
JPEG 2000: build (ver 1.900.1)
OpenEXR: build (ver 1.7.1)
可以看出:opencv2.4.x系列,JPEG都是使用ver62,这个应该是libjpeg库版本信息;opencv3.4.2开始,用libjpeg-turbo,这个结果和2.4.x系列一致;只有坑爹的opencv3.0.0到opencv3.4.1系列用的ver90鬼东西结果不对。
references
Opencv3.0.0‘s bug of imread function
Problem caused by the change from libjpeg to libjpeg-turbo
Loading jpg files gives different results in 3.4.0 and 3.4.2