长话短说
版本区间[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