# PNG with 8bit colormap loaded as full 32 bits per pixel

**URL:** <https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028>\
**Category:** SDL Development\
**Created:** [March 8, 2011, 1:39pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028 "2011-03-08T13:39:03Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kees\_Bakker](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/kees_bakker/32/2346_2.png) [@Kees\_Bakker](https://discourse.libsdl.org/u/Kees_Bakker)\
**Post date:** [March 8, 2011, 1:39pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/1 "2011-03-08T13:39:03Z")

</div>

Hi,

Since PNG recently was mentioned on the list, I want ask  
a question too, about loading PNGs.  
When I load a PNG with 8-bit colormap using IMG\_load I  
get a surface with full 32 bits for each pixel.  
I was expecting to get a SDL\_surface with a palette  
and 1 byte colorindex per pixel.

We’re a bit tight on memory so we need to use the smallest  
possible image memory.

What am I missing?–  
Kees

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [March 8, 2011, 7:22pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/2 "2011-03-08T19:22:23Z")

</div>

It looks like it should create an 8-bit surface. You can trace through the  
code in IMG\_png.c and see what’s going on.

See ya!On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:

> Hi,
> 
> Since PNG recently was mentioned on the list, I want ask  
> a question too, about loading PNGs.  
> When I load a PNG with 8-bit colormap using IMG\_load I  
> get a surface with full 32 bits for each pixel.  
> I was expecting to get a SDL\_surface with a palette  
> and 1 byte colorindex per pixel.
> 
> We’re a bit tight on memory so we need to use the smallest  
> possible image memory.
> 
> ## What am I missing?
> 
> Kees
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

–  
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

---

<div class="post-metadata">

**Author:** ![Kees\_Bakker](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/kees_bakker/32/2346_2.png) [@Kees\_Bakker](https://discourse.libsdl.org/u/Kees_Bakker)\
**Post date:** [March 8, 2011, 8:58pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/3 "2011-03-08T20:58:38Z")

</div>

Not the answer I wanted to hear 🙂  
But I’ll give it a shot.

– KeesOn 8 Mar, 2011, at 20:22 , Sam Lantinga wrote:

> It looks like it should create an 8-bit surface. You can trace through the code in IMG\_png.c and see what’s going on.
> 
> See ya!
> 
> On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<@Kees\_Bakker\> wrote:  
> Hi,
> 
> Since PNG recently was mentioned on the list, I want ask  
> a question too, about loading PNGs.  
> When I load a PNG with 8-bit colormap using IMG\_load I  
> get a surface with full 32 bits for each pixel.  
> I was expecting to get a SDL\_surface with a palette  
> and 1 byte colorindex per pixel.
> 
> We’re a bit tight on memory so we need to use the smallest  
> possible image memory.
> 
> ## What am I missing?
> 
> Kees
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> 
> –  
> -Sam Lantinga, Founder and CEO, Galaxy Gameworks
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [March 9, 2011, 12:49am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/4 "2011-03-09T00:49:22Z")

</div>

Let me know what you find! :)On Tue, Mar 8, 2011 at 12:58 PM, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:

> Not the answer I wanted to hear 🙂  
> But I’ll give it a shot.
> 
> – Kees
> 
> On 8 Mar, 2011, at 20:22 , Sam Lantinga wrote:
> 
> It looks like it should create an 8-bit surface. You can trace through the  
> code in IMG\_png.c and see what’s going on.
> 
> See ya!
> 
> On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:
> 
> > Hi,
> > 
> > Since PNG recently was mentioned on the list, I want ask  
> > a question too, about loading PNGs.  
> > When I load a PNG with 8-bit colormap using IMG\_load I  
> > get a surface with full 32 bits for each pixel.  
> > I was expecting to get a SDL\_surface with a palette  
> > and 1 byte colorindex per pixel.
> > 
> > We’re a bit tight on memory so we need to use the smallest  
> > possible image memory.
> > 
> > ## What am I missing?
> > 
> > Kees
> > 
> > * * *
> > 
> > SDL mailing list  
> > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> 
> –  
> -Sam Lantinga, Founder and CEO, Galaxy Gameworks
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

–  
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

---

<div class="post-metadata">

**Author:** ![Nicholas\_Vining](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/f04885/32.png) [@Nicholas\_Vining](https://discourse.libsdl.org/u/Nicholas_Vining)\
**Post date:** [March 9, 2011, 12:53am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/5 "2011-03-09T00:53:12Z")

</div>

What platform are you on? There are some very interesting issues with  
SDL\_Image and 8 bit PNGs on OS X - by default, SDL\_Image uses OS X’s built  
in graphics loading facilities to load PNGs instead of libpng, and OS X’s  
support for 8-bit PNGs does not always do what libpng does.

I ended up ditching SDL\_Image and going with a hacked version of Sean  
Barrett’s STB\_Image for this very reason.

N.On Tue, 8 Mar 2011, Kees Bakker wrote:

> Not the answer I wanted to hear 🙂  
> But I’ll give it a shot.
> 
> – Kees
> 
> On 8 Mar, 2011, at 20:22 , Sam Lantinga wrote:
> 
> > It looks like it should create an 8-bit surface. You can trace through the code in IMG\_png.c and see what’s going on.
> > 
> > See ya!
> > 
> > On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:  
> > Hi,
> > 
> > Since PNG recently was mentioned on the list, I want ask  
> > a question too, about loading PNGs.  
> > When I load a PNG with 8-bit colormap using IMG\_load I  
> > get a surface with full 32 bits for each pixel.  
> > I was expecting to get a SDL\_surface with a palette  
> > and 1 byte colorindex per pixel.
> > 
> > We’re a bit tight on memory so we need to use the smallest  
> > possible image memory.
> > 
> > ## What am I missing?
> > 
> > Kees
> > 
> > * * *
> > 
> > SDL mailing list  
> > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> > 
> > –  
> > -Sam Lantinga, Founder and CEO, Galaxy Gameworks
> > 
> > * * *
> > 
> > SDL mailing list  
> > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![Gregory\_Smith](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/50afbb/32.png) [@Gregory\_Smith](https://discourse.libsdl.org/u/Gregory_Smith)\
**Post date:** [March 9, 2011, 3:07am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/6 "2011-03-09T03:07:06Z")

</div>

There’s a define you can set to tell SDL\_Image not to use CoreImage,  
which is essential to the library being in any way usable.

> **[Aleph One: Marathon Open Source](https://sourceforge.net/projects/marathon/)**
>
> Download Aleph One: Marathon Open Source for free. Aleph One is the open source continuation of Bungie's Marathon 2 FPS game engine. Aleph One plays Marathon, Marathon 2, Marathon Infinity, and 3rd-party content on a wide array of platforms, with...

Look for SDL\_Image, there are instructions how to fix it. If you want  
a pre-built Universal Binary version, you can download Aleph One and  
pull it out of Contents/Frameworks. The dependencies are in there as  
frameworks as well.

IMO, this is the way SDL\_Image should be distributed for the Mac.

GregoryOn Tue, Mar 8, 2011 at 7:53 PM, Nicholas Vining wrote:

> What platform are you on? There are some very interesting issues with  
> SDL\_Image and 8 bit PNGs on OS X - by default, SDL\_Image uses OS X’s built  
> in graphics loading facilities to load PNGs instead of libpng, and OS X’s  
> support for 8-bit PNGs does not always do what libpng does.
> 
> I ended up ditching SDL\_Image and going with a hacked version of Sean  
> Barrett’s STB\_Image for this very reason.

---

<div class="post-metadata">

**Author:** ![Eric\_Wing](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@Eric\_Wing](https://discourse.libsdl.org/u/Eric_Wing)\
**Post date:** [March 9, 2011, 8:04am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/7 "2011-03-09T08:04:15Z")

</div>

So, I disagree with this, though I can sympathize with the argument up  
to a point.

First, I don’t know how to get ImageIO (it’s not CoreImage) to handle  
8-bit color palette images. If there is a way, I would love to see a  
patch.

Second, I think ImageIO is the right thing to use on Mac and iOS. We  
abandoned libpng, libjpeg, libtiff, etc. for many reasons. The binary  
sizes were 10x larger, we never kept up with security issues, and the  
build systems sucked on Mac.

Third, my interpretation of SDL\_image is that it is a simple, opaque  
image loader to get things into an SDL\_Surface. As such, it is going  
to be limited to what is common to most image formats and is not  
necessarily required to handle all the weird cases. For example, I  
don’t think SDL\_image handles the multiple layer/dimension features of  
TIFF.

Forth, since we go to so much work to make our SDL Mac frameworks  
embeddable anybody can recompile it themselves with libpng and embed  
it in their app. They don’t have to worry about dll hell and  
conflicting with the official framework.

Fifth, this is 2011, not 1990. SDL 1.3 is embracing OpenGL more  
heavily and that rendering model is the future. Color palettes need to  
die. OpenGL already dropped their color index features years ago. And  
shaders are the future. (But I sympathize with those who are trying to  
maintain legacy games.)

Sixth, libpng is actually kind of available on Mac in Leopard and Snow  
Leopard if they want to use it directly. However, I think it might be  
an “optional” component like the X11 stuff, so we will have to contend  
with the Mac App Store issues if we use it.

Seventh, ImageIO is kind of like SDL\_image. It already unifies all the  
different image loaders into one consistent API. Behind the scenes,  
ImageIO is using libpng, libjpeg, libtiff, etc. It is redundant to  
re-embed these.

Eighth, ImageIO is the same on Mac and iOS. There is a nice advantage  
to having these implementations consistent. (That is one of the items  
I still need to push to mainline.)

-EricOn 3/8/11, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:

> Hi,
> 
> Since PNG recently was mentioned on the list, I want ask  
> a question too, about loading PNGs.  
> When I load a PNG with 8-bit colormap using IMG\_load I  
> get a surface with full 32 bits for each pixel.  
> I was expecting to get a SDL\_surface with a palette  
> and 1 byte colorindex per pixel.
> 
> We’re a bit tight on memory so we need to use the smallest  
> possible image memory.
> 
> ## What am I missing?
> 
> Kees

–  
Beginning iPhone Games Development

> **[Learn how to program games for iOS](https://playcontrol.net/iphonegamebook/)**
>
> Beginning iPhone Games Development Book published by Apress for PlayControl Software, Eric Wing. The best iPhone Game Programming Book.

---

<div class="post-metadata">

**Author:** ![Rene\_Dudfield](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rene_dudfield/32/3235_2.png) [@Rene\_Dudfield](https://discourse.libsdl.org/u/Rene_Dudfield)\
**Post date:** [March 9, 2011, 10:49am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/8 "2011-03-09T10:49:38Z")

</div>

oh, I noticed this bug on the latest OSX SDL\_image too. The old version  
works, and it works ok on other platforms.On Wed, Mar 9, 2011 at 12:53 AM, Nicholas Vining wrote:

> What platform are you on? There are some very interesting issues with  
> SDL\_Image and 8 bit PNGs on OS X - by default, SDL\_Image uses OS X’s built  
> in graphics loading facilities to load PNGs instead of libpng, and OS X’s  
> support for 8-bit PNGs does not always do what libpng does.
> 
> I ended up ditching SDL\_Image and going with a hacked version of Sean  
> Barrett’s STB\_Image for this very reason.
> 
> N.
> 
> On Tue, 8 Mar 2011, Kees Bakker wrote:
> 
> Not the answer I wanted to hear 🙂
> 
> > But I’ll give it a shot.
> > 
> > – Kees
> > 
> > On 8 Mar, 2011, at 20:22 , Sam Lantinga wrote:
> > 
> > It looks like it should create an 8-bit surface. You can trace through
> > 
> > > the code in IMG\_png.c and see what’s going on.
> > > 
> > > See ya!
> > > 
> > > On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<kees.bakker at xs4all.nl\> wrote:  
> > > Hi,
> > > 
> > > Since PNG recently was mentioned on the list, I want ask  
> > > a question too, about loading PNGs.  
> > > When I load a PNG with 8-bit colormap using IMG\_load I  
> > > get a surface with full 32 bits for each pixel.  
> > > I was expecting to get a SDL\_surface with a palette  
> > > and 1 byte colorindex per pixel.
> > > 
> > > We’re a bit tight on memory so we need to use the smallest  
> > > possible image memory.
> > > 
> > > ## What am I missing?
> > > 
> > > Kees
> > > 
> > > * * *
> > > 
> > > SDL mailing list  
> > > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> > > 
> > > –  
> > > -Sam Lantinga, Founder and CEO, Galaxy Gameworks
> > > 
> > > * * *
> > > 
> > > SDL mailing list  
> > > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> > 
> > * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [March 9, 2011, 5:57pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/9 "2011-03-09T17:57:19Z")

</div>

I beg to differ, and i completely agree on Eric’s point #2, #4, #7; i  
look forward to the commit of #8 🙂  
bye  
VittorioOn Wed, Mar 9, 2011 at 4:07 AM, Gregory Smith wrote:

> IMO, this is the way SDL\_Image should be distributed for the Mac.
> 
> Gregory

---

<div class="post-metadata">

**Author:** ![Gregory\_Smith](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/50afbb/32.png) [@Gregory\_Smith](https://discourse.libsdl.org/u/Gregory_Smith)\
**Post date:** [March 9, 2011, 6:39pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/10 "2011-03-09T18:39:42Z")

</div>

> I beg to differ, and i completely agree on Eric’s point #2, #4, #7; i  
> look forward to the commit of #8 🙂

This is why open source is great–SDL\_Image just doesn’t work for us (and  
at least one other poster) stock, but we can modify it.

We account for #2 and #4 by building frameworks for dependencies, which  
can be upgraded just by dropping in a new framework.

For #7 and #8, sacrifices have to be made to use an inflexible proprietary  
image library like ImageIO, and those sacrifices narrow SDL\_Image’s  
potential audience. In exchange, the binary (but not the code base!) gets  
a little smaller, and you get to ship on another inflexible proprietary OS  
(iOS) which you probably couldn’t do had you not made that sacrifice at  
all.

I still maintain shipping a more functional library using open source  
dependencies on the Mac side (the iOS side there’s no choice) is more in  
the spirit of an open source project, but I admit that disagreement on  
whether that trade-off is worth it is understandable 🙂

GregoryOn Wed, 9 Mar 2011, Vittorio G. wrote:

---

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [March 10, 2011, 9:11am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/11 "2011-03-10T09:11:41Z")

</div>

> This is why open source is great–SDL\_Image just doesn’t work for us (and at  
> least one other poster) stock, but we can modify it.

yesh 🙂

> We account for #2 and #4 by building frameworks for dependencies, which can  
> be upgraded just by dropping in a new framework.

why the hassle if it can be done on the fly?  
developing and distributing doesn’t have to suck by definition…

> For #7 and #8, sacrifices have to be made to use an inflexible proprietary  
> image library like ImageIO, and those sacrifices narrow SDL\_Image’s  
> potential audience. In exchange, the binary (but not the code base!) gets a  
> little smaller, and you get to ship on another inflexible proprietary OS  
> (iOS) which you probably couldn’t do had you not made that sacrifice at all.

with the exception that the sdl\_image codebase is slimmer, is much  
better integrated with OS and your application has less security flaws

> I still maintain shipping a more functional library using open source  
> dependencies on the Mac side (the iOS side there’s no choice) is more in the  
> spirit of an open source project, but I admit that disagreement on whether  
> that trade-off is worth it is understandable 🙂

you can use libpng instead of uiimage, if you add the the static  
library to your project  
but is it really worth it? all that free time should be dedicated to  
girls and alcohol 😉

VittorioOn Wed, Mar 9, 2011 at 7:39 PM, Gregory Smith wrote:

> On Wed, 9 Mar 2011, Vittorio G. wrote:

---

<div class="post-metadata">

**Author:** ![Rene\_Dudfield](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rene_dudfield/32/3235_2.png) [@Rene\_Dudfield](https://discourse.libsdl.org/u/Rene_Dudfield)\
**Post date:** [March 10, 2011, 9:52am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/12 "2011-03-10T09:52:49Z")

</div>

Hi,

my 2p…

For the official SDL\_image binary downloads I think there should not be  
regressions.

It really is nice to have a smaller download with the new OSX SDL\_image  
though. Just thought I’d mention how awesome that change was and greatful I  
and others are for that upgrade - before I argue for a change back.

Not supporting previous common image formats breaks hundreds if not  
thousands of applications on OSX. We’ve had to stick with the old version  
of SDL\_image for pygame on OSX because of this. It’s good to know that we  
can compile it ourselves with libpng, I’ll be doing that unless official  
binary is fixed.

SDL\_image should give the same behavior on all platforms. Without that,  
it’s not a multi platform library. This is why I think the official binary  
should include libpng for png image loads until the problems with the other  
code can be fixed.

I think we should consider the needs of all the existing programs that rely  
on SDL\_image being able to load fairly common png images used in SDL  
programs.

cya!

---

<div class="post-metadata">

**Author:** ![Kees\_Bakker](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/kees_bakker/32/2346_2.png) [@Kees\_Bakker](https://discourse.libsdl.org/u/Kees_Bakker)\
**Post date:** [March 10, 2011, 9:44pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/13 "2011-03-10T21:44:05Z")

</div>

On iOS, basically just iPad, because iPhone is out of reach for us now.  
Maybe we can try iPhone again when (if) we can solve the colormap/palette  
problem.On 9 Mar, 2011, at 01:53 , Nicholas Vining wrote:

> What platform are you on? There are some very interesting issues with SDL\_Image and 8 bit PNGs on OS X - by default, SDL\_Image uses OS X’s built in graphics loading facilities to load PNGs instead of libpng, and OS X’s support for 8-bit PNGs does not always do what libpng does.
> 
> I ended up ditching SDL\_Image and going with a hacked version of Sean Barrett’s STB\_Image for this very reason.
> 
> N.
> 
> On Tue, 8 Mar 2011, Kees Bakker wrote:
> 
> > Not the answer I wanted to hear 🙂  
> > But I’ll give it a shot.
> > 
> > – Kees
> > 
> > On 8 Mar, 2011, at 20:22 , Sam Lantinga wrote:
> > 
> > > It looks like it should create an 8-bit surface. You can trace through the code in IMG\_png.c and see what’s going on.
> > > 
> > > See ya!
> > > 
> > > On Tue, Mar 8, 2011 at 5:39 AM, Kees Bakker \<@Kees\_Bakker\> wrote:  
> > > Hi,
> > > 
> > > Since PNG recently was mentioned on the list, I want ask  
> > > a question too, about loading PNGs.  
> > > When I load a PNG with 8-bit colormap using IMG\_load I  
> > > get a surface with full 32 bits for each pixel.  
> > > I was expecting to get a SDL\_surface with a palette  
> > > and 1 byte colorindex per pixel.
> > > 
> > > We’re a bit tight on memory so we need to use the smallest  
> > > possible image memory.
> > > 
> > > ## What am I missing?
> > > 
> > > Kees
> > > 
> > > * * *
> > > 
> > > SDL mailing list  
> > > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> > > 
> > > –  
> > > -Sam Lantinga, Founder and CEO, Galaxy Gameworks
> > > 
> > > * * *
> > > 
> > > SDL mailing list  
> > > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![Kees\_Bakker](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/kees_bakker/32/2346_2.png) [@Kees\_Bakker](https://discourse.libsdl.org/u/Kees_Bakker)\
**Post date:** [March 10, 2011, 10:00pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/14 "2011-03-10T22:00:16Z")

</div>

> > What platform are you on? There are some very interesting issues with  
> > SDL\_Image and 8 bit PNGs on OS X - by default, SDL\_Image uses OS X’s built  
> > in graphics loading facilities to load PNGs instead of libpng, and OS X’s  
> > support for 8-bit PNGs does not always do what libpng does.
> > 
> > I ended up ditching SDL\_Image and going with a hacked version of Sean  
> > Barrett’s STB\_Image for this very reason.
> 
> There’s a define you can set to tell SDL\_Image not to use CoreImage,  
> which is essential to the library being in any way usable.
> 
> [Aleph One: Marathon Open Source download | SourceForge.net](http://marathon.svn.sourceforge.net/viewvc/marathon/frameworks/trunk/README?revision=4076)
> 
> Look for SDL\_Image, there are instructions how to fix it. If you want  
> a pre-built Universal Binary version, you can download Aleph One and  
> pull it out of Contents/Frameworks. The dependencies are in there as  
> frameworks as well.
> 
> IMO, this is the way SDL\_Image should be distributed for the Mac.
> 
> Gregory

I looked at this README, but isn’t that about SDL 1.2 and some older  
version of SDL\_image? Revision 5322 of SVN trunk, which hg changeset is  
that?

The latest hg SDL\_image has an iPhone Xcode project with  
“Deployment\_UIImage” configuration.

– KeesOn 9 Mar, 2011, at 04:07 , Gregory Smith wrote:

> On Tue, Mar 8, 2011 at 7:53 PM, Nicholas Vining wrote:

---

<div class="post-metadata">

**Author:** ![Gregory\_Smith](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/50afbb/32.png) [@Gregory\_Smith](https://discourse.libsdl.org/u/Gregory_Smith)\
**Post date:** [March 10, 2011, 10:07pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/15 "2011-03-10T22:07:09Z")

</div>

> I looked at this README, but isn’t that about SDL 1.2 and some older  
> version of SDL\_image? Revision 5322 of SVN trunk, which hg changeset is  
> that?
> 
> The latest hg SDL\_image has an iPhone Xcode project with  
> “Deployment\_UIImage” configuration.

Yeah, sorry, on iOS you might be out of luck. Or you might not be, those  
instructions might work with 1.3 and iOS too, but I haven’t tried it and  
can’t help you. Good luck!

GregoryOn Thu, 10 Mar 2011, Kees Bakker wrote:

---

<div class="post-metadata">

**Author:** ![Eric\_Wing](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@Eric\_Wing](https://discourse.libsdl.org/u/Eric_Wing)\
**Post date:** [March 10, 2011, 10:58pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/16 "2011-03-10T22:58:58Z")

</div>

While Sam has the ultimate say in these matters, I am not inclined to  
move back. We moved away from libpng, et al for good reasons and those  
reasons are still valid today.

I would also argue that SDL\_image with the ImageIO backend _does_ load  
most of the commonly used png image files. The 8-bit color palette  
stuff is pretty niche stuff in today’s modern world.

OS X is always a moving target. A lot of things are not static on this  
platform and often we have to change things hopefully for the benefit  
of the majority of users. We suffered a lot of pain during the i386  
introduction/transition and we had a very hard time maintaining all  
the dependencies. Snow Leopard and x86\_64 really broke the camel’s  
back. (I recall Ryan doing an 11th hour save for MIDI support in  
SDL\_mixer by implementing a new native backend.) As an extreme  
example, we could continue to only ship a 32-bit PowerPC binary  
exactly how we used to, but probably over 90% of the Mac market would  
be annoyed by that. (The percentages of OS X people running 64-bit  
Snow Leopard are actually pretty high too so 32-bit i386 OS X is  
already going the way of the dinosaur.)

SDL\_image supports both 1.2 and 1.3 so that also makes SDL\_image a  
moving target.

We also gave advance warning of these changes. I think I submitted the  
first patch well over 2 years ago. And we actually made the release a  
year and a half ago. It seems a little strange to be having this  
conversation now so far after the fact.

Again, if somebody can contribute a patch to the ImageIO backend for  
this, that would be ideal.

-EricOn 3/10/11, Ren? Dudfield wrote:

> Hi,
> 
> my 2p…
> 
> For the official SDL\_image binary downloads I think there should not be  
> regressions.
> 
> It really is nice to have a smaller download with the new OSX SDL\_image  
> though. Just thought I’d mention how awesome that change was and greatful I  
> and others are for that upgrade - before I argue for a change back.
> 
> Not supporting previous common image formats breaks hundreds if not  
> thousands of applications on OSX. We’ve had to stick with the old version  
> of SDL\_image for pygame on OSX because of this. It’s good to know that we  
> can compile it ourselves with libpng, I’ll be doing that unless official  
> binary is fixed.
> 
> SDL\_image should give the same behavior on all platforms. Without that,  
> it’s not a multi platform library. This is why I think the official binary  
> should include libpng for png image loads until the problems with the other  
> code can be fixed.
> 
> I think we should consider the needs of all the existing programs that rely  
> on SDL\_image being able to load fairly common png images used in SDL  
> programs.

–  
Beginning iPhone Games Development

> **[Learn how to program games for iOS](https://playcontrol.net/iphonegamebook/)**
>
> Beginning iPhone Games Development Book published by Apress for PlayControl Software, Eric Wing. The best iPhone Game Programming Book.

---

<div class="post-metadata">

**Author:** ![Eric\_Wing](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@Eric\_Wing](https://discourse.libsdl.org/u/Eric_Wing)\
**Post date:** [March 10, 2011, 11:01pm UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/17 "2011-03-10T23:01:27Z")

</div>

I have a private branch which contains an ImageIO change for iOS. I’ve  
been meaning to push up. (Sorry for the delay Sam.) If you guys hated  
ImageIO, you’ll hate UIImage even more which is why I am changing it  
to ImageIO.

-EricOn 3/10/11, Gregory Smith wrote:

> On Thu, 10 Mar 2011, Kees Bakker wrote:
> 
> > I looked at this README, but isn’t that about SDL 1.2 and some older  
> > version of SDL\_image? Revision 5322 of SVN trunk, which hg changeset is  
> > that?
> > 
> > The latest hg SDL\_image has an iPhone Xcode project with  
> > “Deployment\_UIImage” configuration.

–  
Beginning iPhone Games Development

> **[Learn how to program games for iOS](https://playcontrol.net/iphonegamebook/)**
>
> Beginning iPhone Games Development Book published by Apress for PlayControl Software, Eric Wing. The best iPhone Game Programming Book.

---

<div class="post-metadata">

**Author:** ![Gregory\_Smith](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/50afbb/32.png) [@Gregory\_Smith](https://discourse.libsdl.org/u/Gregory_Smith)\
**Post date:** [March 11, 2011, 1:20am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/18 "2011-03-11T01:20:21Z")

</div>

> We also gave advance warning of these changes. I think I submitted the  
> first patch well over 2 years ago. And we actually made the release a  
> year and a half ago. It seems a little strange to be having this  
> conversation now so far after the fact.

Advance warning of the changes, maybe, I wasn’t exactly following  
SVN–but not of the features that would be removed due to them. Not  
that I expect that you could have foreseen them! Things take a while  
to make it into builds to get tested, and there are many Aleph One  
scenarios where the bug wouldn’t show up, so we didn’t notice the  
problem until after the SDL\_Image release.

It didn’t seem worth mentioning until I realized others were having  
problems with it too. I respect that you don’t want to change it, so  
there’s no point continuing that part of the discussion. It’s not a  
problem for us because we can just build it our way ourselves and  
distribute it with the app. It would have been a far bigger deal had  
it affected Linux, where we’re at the mercy of the system library.

> I would also argue that SDL\_image with the ImageIO backend _does_ load  
> most of the commonly used png image files. The 8-bit color palette  
> stuff is pretty niche stuff in today’s modern world.

Aleph One doesn’t use it, but I could see it being pretty common in 2D  
sprite based games, which seem like one of SDL’s target audiences.

> Again, if somebody can contribute a patch to the ImageIO backend for  
> this, that would be ideal.

The showstopper for us is actually the inability to load alpha  
channels correctly, due to the premultiplied alpha in ImageIO. This  
makes it impossible to load combined offset/normal maps. Is a patch  
for this even possible?

GregoryOn Thu, Mar 10, 2011 at 5:58 PM, Eric Wing wrote:

---

<div class="post-metadata">

**Author:** ![Rene\_Dudfield](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rene_dudfield/32/3235_2.png) [@Rene\_Dudfield](https://discourse.libsdl.org/u/Rene_Dudfield)\
**Post date:** [March 11, 2011, 11:35am UTC](https://discourse.libsdl.org/t/png-with-8bit-colormap-loaded-as-full-32-bits-per-pixel/18028/19 "2011-03-11T11:35:20Z")

</div>

No sweat. I’ll just produce our own SDL\_image for OSX.

cu.On Thu, Mar 10, 2011 at 10:58 PM, Eric Wing wrote:

> On 3/10/11, Ren? Dudfield \<@Rene\_Dudfield\> wrote:
> 
> > Hi,
> > 
> > my 2p…
> > 
> > For the official SDL\_image binary downloads I think there should not be  
> > regressions.
> > 
> > It really is nice to have a smaller download with the new OSX SDL\_image  
> > though. Just thought I’d mention how awesome that change was and  
> > greatful I  
> > and others are for that upgrade - before I argue for a change back.
> > 
> > Not supporting previous common image formats breaks hundreds if not  
> > thousands of applications on OSX. We’ve had to stick with the old  
> > version  
> > of SDL\_image for pygame on OSX because of this. It’s good to know that  
> > we  
> > can compile it ourselves with libpng, I’ll be doing that unless official  
> > binary is fixed.
> > 
> > SDL\_image should give the same behavior on all platforms. Without that,  
> > it’s not a multi platform library. This is why I think the official  
> > binary  
> > should include libpng for png image loads until the problems with the  
> > other  
> > code can be fixed.
> > 
> > I think we should consider the needs of all the existing programs that  
> > rely  
> > on SDL\_image being able to load fairly common png images used in SDL  
> > programs.
> 
> While Sam has the ultimate say in these matters, I am not inclined to  
> move back. We moved away from libpng, et al for good reasons and those  
> reasons are still valid today.
> 
> I would also argue that SDL\_image with the ImageIO backend _does_ load  
> most of the commonly used png image files. The 8-bit color palette  
> stuff is pretty niche stuff in today’s modern world.
> 
> OS X is always a moving target. A lot of things are not static on this  
> platform and often we have to change things hopefully for the benefit  
> of the majority of users. We suffered a lot of pain during the i386  
> introduction/transition and we had a very hard time maintaining all  
> the dependencies. Snow Leopard and x86\_64 really broke the camel’s  
> back. (I recall Ryan doing an 11th hour save for MIDI support in  
> SDL\_mixer by implementing a new native backend.) As an extreme  
> example, we could continue to only ship a 32-bit PowerPC binary  
> exactly how we used to, but probably over 90% of the Mac market would  
> be annoyed by that. (The percentages of OS X people running 64-bit  
> Snow Leopard are actually pretty high too so 32-bit i386 OS X is  
> already going the way of the dinosaur.)
> 
> SDL\_image supports both 1.2 and 1.3 so that also makes SDL\_image a  
> moving target.
> 
> We also gave advance warning of these changes. I think I submitted the  
> first patch well over 2 years ago. And we actually made the release a  
> year and a half ago. It seems a little strange to be having this  
> conversation now so far after the fact.
> 
> Again, if somebody can contribute a patch to the ImageIO backend for  
> this, that would be ideal.
> 
> ## -Eric
> 
> Beginning iPhone Games Development  
> [Learn how to program games for iOS](http://playcontrol.net/iphonegamebook/)
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)