You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: 2.0.0 Reported for operating system, platform: Mac OS X 10.8, x86_64
Comments on the original bug report:
On 2014-11-20 00:10:37 +0000, Jeffrey Carpenter wrote:
Created attachment 1935
proposed colorspace fix for ImageIO backend
I believe I may have found the origin of a serious bug in the ImageIO implementation of SDL_image, where it inaccurately returns pixel color values that are off by one -- i.e.: R(110), G(143), B(189) instead of R(110), G(144), B(190). I've been using a custom built SDL_image with libpng & friends for the backend to work around this issue.
On 2014-11-20 00:11:53 +0000, Jeffrey Carpenter wrote:
Created attachment 1936
reference test case data (diag_main.txt before patch)
On 2014-11-20 00:12:23 +0000, Jeffrey Carpenter wrote:
Created attachment 1937
comparison test case data (diag_main.txt after patch)
On 2014-11-20 00:12:45 +0000, Jeffrey Carpenter wrote:
Created attachment 1938
RGB8888 (24-bit, BMP) test case image
On 2014-11-20 00:13:01 +0000, Jeffrey Carpenter wrote:
Created attachment 1939
ARGB8888 (32-bit, PNG) test case image
On 2014-11-20 00:14:09 +0000, Jeffrey Carpenter wrote:
Created attachment 1940
test case (for use with test.bmp, test.png to produce diag_main.txt output)
On 2014-11-20 00:18:52 +0000, Jeffrey Carpenter wrote:
Sorry .. I probably should have zipped all that before hand -_- Anyhow ...
Test case resources (should be able to be replaced with your own as long as the pixel format and file encoding matches):
test.bmp RGB8888 (24-bit, BMP)
test.png ARGB8888 (32-bit, PNG)
This patch reverts revision 292 back to the original author's implementation (Eric Wing). The comments made in this revision seem to contradict what is intended; see CGColorSpaceCreateCalibratedRGB [1] and CGColorSpaceCreateDeviceRGB [2] for Apple's API notes. Also note that the revision comments by "Albert" use a test case that is for use with SDL1 -- how this may change things is unknown to me.
NOTE: ff6e8fbd = R(110) G(143) B(189)
The actual pixel value is 110, 144, 190. SDL_LoadBMP gets it right in both
cases, whereas IMG_Load (ImageIO backend) gets it wrong on both counts.
Rebuild test case, ensuring that we compile and run with the proper runtime
search paths for our patched SDL2_image library (I built mine using Xcode project files):
# man dyld (1)
DYLD_FRAMEWORK_PATH=<my_local_prefix_lib_path> ./sdl2_image-colorspace-fix
Comparison output of reference data with patched library:
(output in diag_main.txt, using test.bmp and test.png)
I'm not sure what the problem was with the original device RGB colorspace. I tested this with the default calibration and a tweaked monitor calibration and albert's original test case worked fine here.
Thanks!
On 2014-11-30 00:20:50 +0000, Jeffrey Carpenter wrote:
Yay! You the man! :D
Your comments make me curious ... I'll see if I can get different results by playing around with my display's calibration -- I've got three of them to test on. I'll report back if I find anything.
When was it that you tested? I'm guessing during round about time of Albert's patch?
On 2014-11-30 06:29:29 +0000, Sam Lantinga wrote:
Albert's original sample test is still live, if you want to grab it. I played with calibration and it didn't affect the test here.
On 2014-12-06 12:35:11 +0000, Jeffrey Carpenter wrote:
Using Albert's sdlimagetest.cpp [1] and the official distributed binaries of SDL_image (AKA Albert's patch), I get the following output:
FF0000FF is RGBA(255, 0, 0, 255). Note that this is what Albert's test expected, too, with his patch.
Choosing different color calibrated color profiles at random made no difference whatsoever for me in any of these tests.
I think Albert's test case was built with SDL1 in mind, whereas my tests are with SDL2. My tests also use a newer version of SDL_image than at the revision where Albert's changes were introduced. I don't know how this might change any of the results.
In summary, I don't know either! The conflicting test results leave me ever more... confused, with more questions than answers. Such is often the case :-)
In any case, the fact that my proposed patch doesn't appear to introduce problems for either one of us is hopefully a good sign of things. I haven't yet found anybody else to help test this with, but it's only a matter of time! In conclusion, until more information comes to light, I feel OK about my proposed patch.
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: 2.0.0
Reported for operating system, platform: Mac OS X 10.8, x86_64
Comments on the original bug report:
On 2014-11-20 00:10:37 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:11:53 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:12:23 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:12:45 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:13:01 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:14:09 +0000, Jeffrey Carpenter wrote:
On 2014-11-20 00:18:52 +0000, Jeffrey Carpenter wrote:
On 2014-11-29 20:09:25 +0000, Sam Lantinga wrote:
On 2014-11-30 00:20:50 +0000, Jeffrey Carpenter wrote:
On 2014-11-30 06:29:29 +0000, Sam Lantinga wrote:
On 2014-12-06 12:35:11 +0000, Jeffrey Carpenter wrote:
The text was updated successfully, but these errors were encountered: