This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test source/script, input image file and my result (sdlimagetest.tar.gz, application/x-gzip, 2012-02-07 18:17:06 +0000, 329878 bytes)
• Screenshot of SDLInvaders showing image corruption towards bottom of sprites. (SDLInvaders.png, image/png, 2012-12-31 06:20:13 +0000, 23144 bytes)
• Fix that can apply to changeset 292 and later. (IMG_ImageIO.m.srgbmapping.diff, text/plain, 2012-12-31 14:54:27 +0000, 639 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.5 (Intel), x86

Comments on the original bug report:

On 2012-02-06 19:38:31 +0000, wrote:

I was writing a simple image viewer with SDL. Everything was fine, until I switched to SDL_Image for image loading. The surface I was getting was of correct size, but all pixels were simply black (0,0,0,255).

I tried to compile from source, still no joy. showimage utility wasn't working either.

I started to debug with gdb. When I stepped into SDL_Image routines, I found it uses whatever ImageIO gives back: with that black SDL_Surface.

Since ImageIO routines were suspicious, I just configured with '--enable-imageio=no' to use default SDL backend.
Finally it works. I'm not sure which one is faulty, though. I'm filing this because someone might encounter this as well, unless it's something wrong only on my mac.

On 2012-02-06 19:39:39 +0000, wrote:

ADDED: SDL_image version is 1.2.12.

On 2012-02-06 19:40:23 +0000, wrote:

(In reply to comment # 1)
Sorry for confusion. The version is actually 1.2.15.

On 2012-02-07 16:06:32 +0000, Sam Lantinga wrote:

I built SDL_image with ImageIO and tested it on all the images I have here and didn't have any problems.
Can you post a link to an image that doesn't work?

Thanks!

On 2012-02-07 18:17:06 +0000, wrote:

Created attachment 817
Test source/script, input image file and my result

I'm attaching a test program and script with input image file.
I have MacPorts version (with ImageIO) in /opt/local/lib, and source-compiled version without ImageIO in /usr/local/lib.
wo_imageio.txt is the result when linked against the library in /usr/local/lib, and w_imageio.txt is the result when linked against the library in /opt/local/lib. The result was the same for the source compiled version before I manually disabled ImageIO through configure.

This is weird, if this is happening only to me. What would be a possible cause?

On 2012-02-27 08:24:48 +0000, Gabriel Jacobo wrote:

I tested image loading with ImageIO last week with the latest SDL_image and OS X 10.7, it worked fine for PNG files at least.

On 2012-12-31 06:19:11 +0000, Mark Scott wrote:

I can confirm this bug exists - MacOSX 10.5.8; XCode 3.1.4;

All SDL based games I've tried are impacted (widelands, SDLInvaders). I've seen both black images and image corruption. For example, the splash screen of SDLInvaders is black, and in-game it has corrupt graphics (see attachment)

I have traced the problem to be starting when changeset 292 was applied to the SDL_image library (changeset 289 works; 290 & 291 are not code updates) - so this is first seen with SDL_image 1.2.11. SDL_image 1.2.12 is also affected.

http://hg.libsdl.org/SDL_image/rev/5953114c0d27

I have a MacPorts issue open for downstream visibility: https://trac.macports.org/ticket/37453

Workaround: compile SDL_image with --disable-imageio.

Let me know if there's anything I can help check, though ImageIO is not an area I'm familiar with.

On 2012-12-31 06:20:13 +0000, Mark Scott wrote:

Created attachment 1003
Screenshot of SDLInvaders showing image corruption towards bottom of sprites.

On 2012-12-31 14:54:27 +0000, Mark Scott wrote:

Created attachment 1005
Fix that can apply to changeset 292 and later.

The attached diff fixes the library so ImageIO can be used and images are displayed again without corruption and black screens.

(Based on http://pastebin.com/T3s15UXF and http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html)

I suspect the matrix passed to CGColorSpaceCreateCalibratedRGB() as implemented in r292 is invalid and the CoreGraphics framework on 10.5 doesn't reject it, but later ones do. Unfortunately all the documentation I can find doesn't actually specify what the valid range of values of the arguments is.

On 2013-01-01 11:41:33 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/3999783ed889

On 2013-01-01 11:41:37 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/3999783ed889