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
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/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
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/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
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/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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.
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.
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
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/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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
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:
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:
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!
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/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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
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:
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:
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
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
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:
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
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org