Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot load images with ImageIO enabled on Mac OS X #39

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Cannot load images with ImageIO enabled on Mac OS X #39

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

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?


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.

I have a MacPorts issue open for downstream visibility:

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 and

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!

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

Fixed, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant