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:
c++ qt qimage
add a comment |
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:
c++ qt qimage
The printing for format 2 needs to use%1
, btw
– kmdreko
Nov 8 at 8:39
add a comment |
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:
c++ qt qimage
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:
c++ qt qimage
c++ qt qimage
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
add a comment |
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
add a comment |
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)
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 exactlyimage height
more than that ofimage 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
add a comment |
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.
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 thepixelIndex
, 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
add a comment |
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)
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 exactlyimage height
more than that ofimage 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
add a comment |
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)
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 exactlyimage height
more than that ofimage 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
add a comment |
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)
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)
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 exactlyimage height
more than that ofimage 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
add a comment |
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 exactlyimage height
more than that ofimage 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
add a comment |
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.
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 thepixelIndex
, 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
add a comment |
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.
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 thepixelIndex
, 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
add a comment |
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.
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.
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 thepixelIndex
, 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
add a comment |
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 thepixelIndex
, 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
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
The printing for format 2 needs to use
%1
, btw– kmdreko
Nov 8 at 8:39