The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 wrote:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks

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:

Let me know what you find! :)

On Tue, Mar 8, 2011 at 12:58 PM, Kees Bakker wrote:



--
    -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:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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.

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 3/8/11, Kees Bakker wrote:


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.)


-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

On Wed, Mar 9, 2011 at 4:07 AM, Gregory Smith wrote:

I beg to differ, and i completely agree on Eric's point #2, #4, #7; i
look forward to the commit of #8
bye
Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 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.

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 :)

Gregory

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

yesh :-)


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


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


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 ;)

Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 9 Mar, 2011, at 04:07 , Gregory Smith 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.

-- Kees

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Thu, 10 Mar 2011, Kees Bakker wrote:


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!

Gregory

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 3/10/11, René Dudfield 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.


-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 3/10/11, Gregory Smith wrote:

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.

-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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


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.


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.


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?

Gregory
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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: