OpenCV vs Matlab : Different Values on pixels with imread

Question

I have encountered a problem with the function imread() in Matlab (2014) and OpenCV (3.0) on Windows 7 with jpg files.

I don't have the same values by reading the same file jpg and the same pixel.

Here are my 2 codes : (OpenCV code followed by the Matlab code) and the values I have (mode debug to see in OpenCV, keyboard in Matlab)

#include <opencv2\opencv.hpp>
#include <cstdio>

using namespace cv;
using namespace std;

int main()
{
     Mat img = imread("test.jpg");

     uchar pb = img.at<Vec3b>(0, 0).val[0];
     uchar pg = img.at<Vec3b>(0, 0).val[1];
     uchar pr = img.at<Vec3b>(0, 0).val[2];

     int d = img.depth();

     int t = img.type();
}

Values :

     pixel [0,0] = (147,174,204); // = index(1,1) in the image.
     d = 0;
     t = 16;

Code Matlab :

img = imread('test.jpg');

img(1,1,:)

whos img

Values :

ans(:,:,1) =
148

ans(:,:,2) =
174

ans(:,:,3) =
201

Name         Size                   Bytes  Class    Attributes
img       1920x2560x3            14745600  uint8     

Have you any idea why values are different?

I have seen on another post a problem like this but the person did not have the same depth by reading a tiff. Here as you can see I have the same depth !

Thank you in advance and sorry for any English mistake.

PS: I have test with other pixels too, same results : closed results but not exactly equals.

Marsha

Can you provide the JPEG file in question for further investigation? – Morten

also post the whole openCV code, where you save the image. – Breastwork

are matlab code and c++ application in the same directory? are you sure that both files are identical? e.g. you didn't open+save the image at the other location (maybe introducing additional jpeg compression effects)? – Saltsman

Hello ! Thanks for your answers and sorry for the time delay for my answer ! @Morten I've lost my first example but I've found an other , you can test the code i wrote above with this picture link , try with the pixel (86,86) in Matlab (and so (85,85) in openCV. I find (92,104,118) in openCV, (91,105,118) in Matlab. – Marsha

@AnderBiguri I don't save the image. Here you are the whole code for my test. I check openCV values with "debug" in Visual Studio 2013, but if I add cout to see values in console it's the same. – Marsha

@Saltsman I've tested to put the .m matlab in the same directory, with the same file but same results. – Marsha

There is something weird happening. If you realise, the image types read are different. What data type does img.type()==16 corresponds to? – Breastwork

@Marsha I get [90 ,106 ,122] in Matlab for pixel (86,86). Maybe its not openCV's problem. – Breastwork

@AnderBiguri I fixed the problem. It comes from the version 8 of libjpeg, used from the version 2.4.11 of openCV. By compiling openCV 3.0 with libjpeg 6b, I have good results (same versus Matlab 2014 by the way). – Marsha

Brilliant. Edit that information somewhere. I read a bit after this. The differences are totally normal. There is no standard for encoding in jpg, thus different encoding gives different values, and all of them are OK. basically, if you don't want changes in pixel values, save it in a lossless format, such as png. – Breastwork

Answer 1

For people who would read this topic this is the final explanation:

It comes from the version of libjpeg. The version 6b (OpenCV used this one before 2.4.11) works in the same way as Matlab 2014b. From version 8 of libjpeg, I had the other results I mentioned above.

To solve my problem (I used some difference of image and background to create a mask and my problem was that I had some snow in the image with OpenCV (without libjeg version 6b), I compiled OpenCV 3.0 with libjpeg 6b. (I also had to import 2 runtime libraries and put it in my project, found freely on the web).

I did not report bug on OpenCV. To be honest, I did not manage, I did not understand how to do in their website even I tried...

Marsha

I have the same exact issue, but your explanation is kinda not understandable. For example, do I need to create mask, if yes, how? Could you please explain a bit more detailed? – Comedienne

No, I spoke about a mask because it was in my application. There is no relation with the problem. With openCV 2.4.11 and 3.0, you will not have same results with matlab because of the library which openCV use. If you want to have same results (by reading a jpeg image) than Matlab, you can use openCV 2.4.10 and before, or try to compile openCV 2.4.11 (or 3.0) with libjpeg 6b instead of 8 which is used by default. I don't know which version is the good one, but I think it is the 6b because my results with my application were better. – Marsha

Answer 2

This code gives the correct values for your example image test2.jpg:

#include <opencv2/highgui/highgui.hpp>
#include <iostream>

int main()
{
    auto img = cv::imread("test2.jpg");
    auto pixel = img.at<cv::Vec3b>(85, 85);
    std::cout << (int)pixel[0] << "\t" << (int)pixel[1]
              << "\t" << (int)pixel[2] << std::endl;
}

Output:

118     105     91

The OpenCV version here is 2.4.10. I get the same result when using your code. I suppose there is a bug somewhere that is beyond your influence.

Morten

Thanks a lot ! I've copied your code and indeed i've not the same results ... I've just downloading openCV 2.4.10 and I get the good values. So we can say that the problem comes from the 3.0 version. – Marsha

On OpenCV 2.4.11, I get [118, 104, 92] at (85,85). Can you also share what platform you're using? I'm on Mac OS X Yosemite - 10.10.4. I suspect it isn't simply just the version... it may also be platform dependent. – Therrien

@rayryend I tried with openCV 2.4.10 (and I have the same value : 118, 105, 91) but not with 2.4.11 ! On Visual Studio 2013, and MSI GP70 (windows 7)! – Marsha

You should file a bug report with the OpenCV project. – Morten

Hmm the statut is cancelled, but the answer of the man who changed the statut does not give an answer to the fact that it works well on the 2.4.10 version and not on the laters .. – Marsha

Yes and also JPEG decoding is a deterministic process. The reasoning for closing the bug is bullshit. – Morten