Identical images have different pixel data when loaded as a QImage in Release









up vote
3
down vote

favorite












Comparing two identical images which are loaded in the format QImage::Format_Indexed8 have different pixel data only when running in Release mode.



The following code shows differences when running in Release, but not when running in Debug:



int main()

QImage _img1("C:\tmp\diff\identicals\file1.png");
QImage _img2("C:\tmp\diff\identicals\file2.png");

std::cout << QString("Format 1: %1").arg(_img1.format()).toStdString().c_str() << std::endl;
std::cout << QString("Format 2: %2").arg(_img2.format()).toStdString().c_str() << std::endl;

const unsigned char * _bits1 = _img1.bits();
const unsigned char * _bits2 = _img2.bits();

std::cout << QString("Byte count 1: %1


Output:



Format 1: 3
Format 2: 3
Byte count 1: 23424 | Byte count 2: 23424
--DIFFERENCE--
i --> 1535
Bit1: 0 | Bit2: 217

--DIFFERENCE--
i --> 1663
Bit1: 0 | Bit2: 35

--DIFFERENCE--
i --> 1791
Bit1: 0 | Bit2: 94

--DIFFERENCE--
i --> 1919
Bit1: 0 | Bit2: 166

--DIFFERENCE--
i --> 2047
Bit1: 0 | Bit2: 143

--DIFFERENCE--
i --> 2175
Bit1: 0 | Bit2: 104

--DIFFERENCE--
i --> 2303
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 2431
Bit1: 0 | Bit2: 190

--DIFFERENCE--
i --> 2559
Bit1: 0 | Bit2: 129

--DIFFERENCE--
i --> 2687
Bit1: 0 | Bit2: 11

--DIFFERENCE--
i --> 2815
Bit1: 0 | Bit2: 30

--DIFFERENCE--
i --> 2943
Bit1: 0 | Bit2: 163

--DIFFERENCE--
i --> 3071
Bit1: 0 | Bit2: 206

--DIFFERENCE--
i --> 3199
Bit1: 0 | Bit2: 232

--DIFFERENCE--
i --> 3327
Bit1: 0 | Bit2: 124

--DIFFERENCE--
i --> 3455
Bit1: 0 | Bit2: 225

--DIFFERENCE--
i --> 12287
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 12415
Bit1: 0 | Bit2: 224

--DIFFERENCE--
i --> 12543
Bit1: 0 | Bit2: 240


A few notes:



  • This is no longer reproducible When changing the format of the images to, for example QImage::Format_ARGB32, using convertToFormat

  • This is no longer reproducible when using pixelIndex to compare each pixel

  • It is always the same indices that fail

  • The indices that fail change when running on a different machine.

My current guess would be that Qt does some optimization when loading images in this format. I can't explain why this doesn't result in the same data for two identical images however.



If you care to reproduce the issue, here is my input image:



Sample image










share|improve this question





















  • The printing for format 2 needs to use %1, btw
    – kmdreko
    Nov 8 at 8:39














up vote
3
down vote

favorite












Comparing two identical images which are loaded in the format QImage::Format_Indexed8 have different pixel data only when running in Release mode.



The following code shows differences when running in Release, but not when running in Debug:



int main()

QImage _img1("C:\tmp\diff\identicals\file1.png");
QImage _img2("C:\tmp\diff\identicals\file2.png");

std::cout << QString("Format 1: %1").arg(_img1.format()).toStdString().c_str() << std::endl;
std::cout << QString("Format 2: %2").arg(_img2.format()).toStdString().c_str() << std::endl;

const unsigned char * _bits1 = _img1.bits();
const unsigned char * _bits2 = _img2.bits();

std::cout << QString("Byte count 1: %1


Output:



Format 1: 3
Format 2: 3
Byte count 1: 23424 | Byte count 2: 23424
--DIFFERENCE--
i --> 1535
Bit1: 0 | Bit2: 217

--DIFFERENCE--
i --> 1663
Bit1: 0 | Bit2: 35

--DIFFERENCE--
i --> 1791
Bit1: 0 | Bit2: 94

--DIFFERENCE--
i --> 1919
Bit1: 0 | Bit2: 166

--DIFFERENCE--
i --> 2047
Bit1: 0 | Bit2: 143

--DIFFERENCE--
i --> 2175
Bit1: 0 | Bit2: 104

--DIFFERENCE--
i --> 2303
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 2431
Bit1: 0 | Bit2: 190

--DIFFERENCE--
i --> 2559
Bit1: 0 | Bit2: 129

--DIFFERENCE--
i --> 2687
Bit1: 0 | Bit2: 11

--DIFFERENCE--
i --> 2815
Bit1: 0 | Bit2: 30

--DIFFERENCE--
i --> 2943
Bit1: 0 | Bit2: 163

--DIFFERENCE--
i --> 3071
Bit1: 0 | Bit2: 206

--DIFFERENCE--
i --> 3199
Bit1: 0 | Bit2: 232

--DIFFERENCE--
i --> 3327
Bit1: 0 | Bit2: 124

--DIFFERENCE--
i --> 3455
Bit1: 0 | Bit2: 225

--DIFFERENCE--
i --> 12287
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 12415
Bit1: 0 | Bit2: 224

--DIFFERENCE--
i --> 12543
Bit1: 0 | Bit2: 240


A few notes:



  • This is no longer reproducible When changing the format of the images to, for example QImage::Format_ARGB32, using convertToFormat

  • This is no longer reproducible when using pixelIndex to compare each pixel

  • It is always the same indices that fail

  • The indices that fail change when running on a different machine.

My current guess would be that Qt does some optimization when loading images in this format. I can't explain why this doesn't result in the same data for two identical images however.



If you care to reproduce the issue, here is my input image:



Sample image










share|improve this question





















  • The printing for format 2 needs to use %1, btw
    – kmdreko
    Nov 8 at 8:39












up vote
3
down vote

favorite









up vote
3
down vote

favorite











Comparing two identical images which are loaded in the format QImage::Format_Indexed8 have different pixel data only when running in Release mode.



The following code shows differences when running in Release, but not when running in Debug:



int main()

QImage _img1("C:\tmp\diff\identicals\file1.png");
QImage _img2("C:\tmp\diff\identicals\file2.png");

std::cout << QString("Format 1: %1").arg(_img1.format()).toStdString().c_str() << std::endl;
std::cout << QString("Format 2: %2").arg(_img2.format()).toStdString().c_str() << std::endl;

const unsigned char * _bits1 = _img1.bits();
const unsigned char * _bits2 = _img2.bits();

std::cout << QString("Byte count 1: %1


Output:



Format 1: 3
Format 2: 3
Byte count 1: 23424 | Byte count 2: 23424
--DIFFERENCE--
i --> 1535
Bit1: 0 | Bit2: 217

--DIFFERENCE--
i --> 1663
Bit1: 0 | Bit2: 35

--DIFFERENCE--
i --> 1791
Bit1: 0 | Bit2: 94

--DIFFERENCE--
i --> 1919
Bit1: 0 | Bit2: 166

--DIFFERENCE--
i --> 2047
Bit1: 0 | Bit2: 143

--DIFFERENCE--
i --> 2175
Bit1: 0 | Bit2: 104

--DIFFERENCE--
i --> 2303
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 2431
Bit1: 0 | Bit2: 190

--DIFFERENCE--
i --> 2559
Bit1: 0 | Bit2: 129

--DIFFERENCE--
i --> 2687
Bit1: 0 | Bit2: 11

--DIFFERENCE--
i --> 2815
Bit1: 0 | Bit2: 30

--DIFFERENCE--
i --> 2943
Bit1: 0 | Bit2: 163

--DIFFERENCE--
i --> 3071
Bit1: 0 | Bit2: 206

--DIFFERENCE--
i --> 3199
Bit1: 0 | Bit2: 232

--DIFFERENCE--
i --> 3327
Bit1: 0 | Bit2: 124

--DIFFERENCE--
i --> 3455
Bit1: 0 | Bit2: 225

--DIFFERENCE--
i --> 12287
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 12415
Bit1: 0 | Bit2: 224

--DIFFERENCE--
i --> 12543
Bit1: 0 | Bit2: 240


A few notes:



  • This is no longer reproducible When changing the format of the images to, for example QImage::Format_ARGB32, using convertToFormat

  • This is no longer reproducible when using pixelIndex to compare each pixel

  • It is always the same indices that fail

  • The indices that fail change when running on a different machine.

My current guess would be that Qt does some optimization when loading images in this format. I can't explain why this doesn't result in the same data for two identical images however.



If you care to reproduce the issue, here is my input image:



Sample image










share|improve this question













Comparing two identical images which are loaded in the format QImage::Format_Indexed8 have different pixel data only when running in Release mode.



The following code shows differences when running in Release, but not when running in Debug:



int main()

QImage _img1("C:\tmp\diff\identicals\file1.png");
QImage _img2("C:\tmp\diff\identicals\file2.png");

std::cout << QString("Format 1: %1").arg(_img1.format()).toStdString().c_str() << std::endl;
std::cout << QString("Format 2: %2").arg(_img2.format()).toStdString().c_str() << std::endl;

const unsigned char * _bits1 = _img1.bits();
const unsigned char * _bits2 = _img2.bits();

std::cout << QString("Byte count 1: %1


Output:



Format 1: 3
Format 2: 3
Byte count 1: 23424 | Byte count 2: 23424
--DIFFERENCE--
i --> 1535
Bit1: 0 | Bit2: 217

--DIFFERENCE--
i --> 1663
Bit1: 0 | Bit2: 35

--DIFFERENCE--
i --> 1791
Bit1: 0 | Bit2: 94

--DIFFERENCE--
i --> 1919
Bit1: 0 | Bit2: 166

--DIFFERENCE--
i --> 2047
Bit1: 0 | Bit2: 143

--DIFFERENCE--
i --> 2175
Bit1: 0 | Bit2: 104

--DIFFERENCE--
i --> 2303
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 2431
Bit1: 0 | Bit2: 190

--DIFFERENCE--
i --> 2559
Bit1: 0 | Bit2: 129

--DIFFERENCE--
i --> 2687
Bit1: 0 | Bit2: 11

--DIFFERENCE--
i --> 2815
Bit1: 0 | Bit2: 30

--DIFFERENCE--
i --> 2943
Bit1: 0 | Bit2: 163

--DIFFERENCE--
i --> 3071
Bit1: 0 | Bit2: 206

--DIFFERENCE--
i --> 3199
Bit1: 0 | Bit2: 232

--DIFFERENCE--
i --> 3327
Bit1: 0 | Bit2: 124

--DIFFERENCE--
i --> 3455
Bit1: 0 | Bit2: 225

--DIFFERENCE--
i --> 12287
Bit1: 0 | Bit2: 240

--DIFFERENCE--
i --> 12415
Bit1: 0 | Bit2: 224

--DIFFERENCE--
i --> 12543
Bit1: 0 | Bit2: 240


A few notes:



  • This is no longer reproducible When changing the format of the images to, for example QImage::Format_ARGB32, using convertToFormat

  • This is no longer reproducible when using pixelIndex to compare each pixel

  • It is always the same indices that fail

  • The indices that fail change when running on a different machine.

My current guess would be that Qt does some optimization when loading images in this format. I can't explain why this doesn't result in the same data for two identical images however.



If you care to reproduce the issue, here is my input image:



Sample image







c++ qt qimage






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 8 at 8:05









Harry

907616




907616











  • The printing for format 2 needs to use %1, btw
    – kmdreko
    Nov 8 at 8:39
















  • The printing for format 2 needs to use %1, btw
    – kmdreko
    Nov 8 at 8:39















The printing for format 2 needs to use %1, btw
– kmdreko
Nov 8 at 8:39




The printing for format 2 needs to use %1, btw
– kmdreko
Nov 8 at 8:39












2 Answers
2






active

oldest

votes

















up vote
4
down vote













I think I can see what's going on here.



Your image is 8-bit grayscale with a width of 127 pixels. All those indices where the differences occur are multiples of 128 (minus 1, i.e the last column in a 128-byte row). Since you have obtained the raw image bits, it's most likely that row data in the image is aligned (commonly 2 or 4 bytes).



Qt is probably not writing anything into those padding bytes, since they're not considered part of the image. So you're really seeing undefined behavior, as your program cannot guarantee repeatable results (loading data from an uninitialized memory location).



To properly compare your image data, you will need to skip over any padding bytes. That means you'll need to know the padding amount. Given the richness of the Qt library, I'm sure that there will be some way to access or infer that information.



[Edit] I quickly looked up the reference for QImage, and indeed I can see that scanlines are 32-bit aligned. The simplest way to achieve to compare is to call QImage::bytesPerLine() to determine how many bytes to compare for each scanline, and then get each scanline individually via QImage::scanLine(int)






share|improve this answer






















  • Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
    – Harry
    Nov 8 at 14:27


















up vote
1
down vote













Your implementation of image comparison is incorrect. Why didn't you use QImage::operator==? You can also refer to its source code for an idea of how it should be done, but that's sort of pointless since Qt already provides this code for you - unless you real question was how to correctly iterate over all pixels in an image, because that's specifically where the mistake is. Your code has undefined behavior, since it can read locations that were likely never written to, per QImage and C++ semantics.






share|improve this answer






















  • This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
    – Harry
    Nov 12 at 7:23










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53203579%2fidentical-images-have-different-pixel-data-when-loaded-as-a-qimage-in-release%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
4
down vote













I think I can see what's going on here.



Your image is 8-bit grayscale with a width of 127 pixels. All those indices where the differences occur are multiples of 128 (minus 1, i.e the last column in a 128-byte row). Since you have obtained the raw image bits, it's most likely that row data in the image is aligned (commonly 2 or 4 bytes).



Qt is probably not writing anything into those padding bytes, since they're not considered part of the image. So you're really seeing undefined behavior, as your program cannot guarantee repeatable results (loading data from an uninitialized memory location).



To properly compare your image data, you will need to skip over any padding bytes. That means you'll need to know the padding amount. Given the richness of the Qt library, I'm sure that there will be some way to access or infer that information.



[Edit] I quickly looked up the reference for QImage, and indeed I can see that scanlines are 32-bit aligned. The simplest way to achieve to compare is to call QImage::bytesPerLine() to determine how many bytes to compare for each scanline, and then get each scanline individually via QImage::scanLine(int)






share|improve this answer






















  • Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
    – Harry
    Nov 8 at 14:27















up vote
4
down vote













I think I can see what's going on here.



Your image is 8-bit grayscale with a width of 127 pixels. All those indices where the differences occur are multiples of 128 (minus 1, i.e the last column in a 128-byte row). Since you have obtained the raw image bits, it's most likely that row data in the image is aligned (commonly 2 or 4 bytes).



Qt is probably not writing anything into those padding bytes, since they're not considered part of the image. So you're really seeing undefined behavior, as your program cannot guarantee repeatable results (loading data from an uninitialized memory location).



To properly compare your image data, you will need to skip over any padding bytes. That means you'll need to know the padding amount. Given the richness of the Qt library, I'm sure that there will be some way to access or infer that information.



[Edit] I quickly looked up the reference for QImage, and indeed I can see that scanlines are 32-bit aligned. The simplest way to achieve to compare is to call QImage::bytesPerLine() to determine how many bytes to compare for each scanline, and then get each scanline individually via QImage::scanLine(int)






share|improve this answer






















  • Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
    – Harry
    Nov 8 at 14:27













up vote
4
down vote










up vote
4
down vote









I think I can see what's going on here.



Your image is 8-bit grayscale with a width of 127 pixels. All those indices where the differences occur are multiples of 128 (minus 1, i.e the last column in a 128-byte row). Since you have obtained the raw image bits, it's most likely that row data in the image is aligned (commonly 2 or 4 bytes).



Qt is probably not writing anything into those padding bytes, since they're not considered part of the image. So you're really seeing undefined behavior, as your program cannot guarantee repeatable results (loading data from an uninitialized memory location).



To properly compare your image data, you will need to skip over any padding bytes. That means you'll need to know the padding amount. Given the richness of the Qt library, I'm sure that there will be some way to access or infer that information.



[Edit] I quickly looked up the reference for QImage, and indeed I can see that scanlines are 32-bit aligned. The simplest way to achieve to compare is to call QImage::bytesPerLine() to determine how many bytes to compare for each scanline, and then get each scanline individually via QImage::scanLine(int)






share|improve this answer














I think I can see what's going on here.



Your image is 8-bit grayscale with a width of 127 pixels. All those indices where the differences occur are multiples of 128 (minus 1, i.e the last column in a 128-byte row). Since you have obtained the raw image bits, it's most likely that row data in the image is aligned (commonly 2 or 4 bytes).



Qt is probably not writing anything into those padding bytes, since they're not considered part of the image. So you're really seeing undefined behavior, as your program cannot guarantee repeatable results (loading data from an uninitialized memory location).



To properly compare your image data, you will need to skip over any padding bytes. That means you'll need to know the padding amount. Given the richness of the Qt library, I'm sure that there will be some way to access or infer that information.



[Edit] I quickly looked up the reference for QImage, and indeed I can see that scanlines are 32-bit aligned. The simplest way to achieve to compare is to call QImage::bytesPerLine() to determine how many bytes to compare for each scanline, and then get each scanline individually via QImage::scanLine(int)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 8 at 8:46

























answered Nov 8 at 8:38









paddy

41.7k52976




41.7k52976











  • Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
    – Harry
    Nov 8 at 14:27

















  • Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
    – Harry
    Nov 8 at 14:27
















Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
– Harry
Nov 8 at 14:27





Unfortunately, bytesPerLine doesn't seem to cater for the padding and returns 8 which means comparing each scanLine also fails. I am pretty sure you are correct, however, as the size of the pixel data (in bytes) is exactly image height more than that of image width x image height. It seems there is one byte of padding per line. It is still strange that the comparison always fails on the same index, however. I would expect it to be a bit more random if it was caused by uninitialized memory...
– Harry
Nov 8 at 14:27













up vote
1
down vote













Your implementation of image comparison is incorrect. Why didn't you use QImage::operator==? You can also refer to its source code for an idea of how it should be done, but that's sort of pointless since Qt already provides this code for you - unless you real question was how to correctly iterate over all pixels in an image, because that's specifically where the mistake is. Your code has undefined behavior, since it can read locations that were likely never written to, per QImage and C++ semantics.






share|improve this answer






















  • This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
    – Harry
    Nov 12 at 7:23














up vote
1
down vote













Your implementation of image comparison is incorrect. Why didn't you use QImage::operator==? You can also refer to its source code for an idea of how it should be done, but that's sort of pointless since Qt already provides this code for you - unless you real question was how to correctly iterate over all pixels in an image, because that's specifically where the mistake is. Your code has undefined behavior, since it can read locations that were likely never written to, per QImage and C++ semantics.






share|improve this answer






















  • This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
    – Harry
    Nov 12 at 7:23












up vote
1
down vote










up vote
1
down vote









Your implementation of image comparison is incorrect. Why didn't you use QImage::operator==? You can also refer to its source code for an idea of how it should be done, but that's sort of pointless since Qt already provides this code for you - unless you real question was how to correctly iterate over all pixels in an image, because that's specifically where the mistake is. Your code has undefined behavior, since it can read locations that were likely never written to, per QImage and C++ semantics.






share|improve this answer














Your implementation of image comparison is incorrect. Why didn't you use QImage::operator==? You can also refer to its source code for an idea of how it should be done, but that's sort of pointless since Qt already provides this code for you - unless you real question was how to correctly iterate over all pixels in an image, because that's specifically where the mistake is. Your code has undefined behavior, since it can read locations that were likely never written to, per QImage and C++ semantics.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 9 at 18:50

























answered Nov 9 at 18:25









Kuba Ober

68.5k980179




68.5k980179











  • This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
    – Harry
    Nov 12 at 7:23
















  • This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
    – Harry
    Nov 12 at 7:23















This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
– Harry
Nov 12 at 7:23




This code is used in our E2E testing framework to calculate the peak signal-to-noise ratio when comparing two images. Because no two images will be exactly identical in our architecture, we permit a PSNR threshold. One of the solutions to my problem is to use the pixelIndex, which is what I did. The purpose of my question is to get a better understanding of what Qt is doing here. @paddy helped a lot with this, but I still cannot understand why it is always the same indices that differ (e.g not each 128th bit of the image but a subset thereof).
– Harry
Nov 12 at 7:23

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53203579%2fidentical-images-have-different-pixel-data-when-loaded-as-a-qimage-in-release%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to how show current date and time by default on contact form 7 in WordPress without taking input from user in datetimepicker

Syphilis

Darth Vader #20