libsdl-org / sdl_image Goto Github PK
View Code? Open in Web Editor NEWImage decoding for many popular formats for Simple Directmedia Layer.
License: zlib License
Image decoding for many popular formats for Simple Directmedia Layer.
License: zlib License
SDL_image 3.0 The latest version of this library is available from GitHub: https://github.com/libsdl-org/SDL_image/releases This is a simple library to load images of various formats as SDL surfaces. It can load BMP, GIF, JPEG, LBM, PCX, PNG, PNM (PPM/PGM/PBM), QOI, TGA, XCF, XPM, and simple SVG format images. It can also load AVIF, JPEG-XL, TIFF, and WebP images, depending on build options (see the note below for details.) API: #include <SDL3_image/SDL_image.h> SDL_Surface *IMG_Load(const char *file); or SDL_Surface *IMG_Load_IO(SDL_IOStream *src, SDL_bool closeio); or SDL_Surface *IMG_LoadTyped_IO(SDL_IOStream *src, SDL_bool closeio, char *type); where type is a string specifying the format (i.e. "PNG" or "pcx"). Note that IMG_Load_IO cannot load TGA images. To create a surface from an XPM image included in C source, use: SDL_Surface *IMG_ReadXPMFromArray(char **xpm); An example program 'showimage' is included, with source in examples/showimage.c Documentation is also available online at https://wiki.libsdl.org/SDL_image This library is under the zlib License, see the file "LICENSE.txt" for details. Note: Support for AVIF, JPEG-XL, TIFF, and WebP are not included by default because of the size of the decode libraries, but you can get them by running external/download.sh - When building with CMake, you can enable the appropriate SDLIMAGE_* options defined in CMakeLists.txt. SDLIMAGE_VENDORED allows switching between system and vendored libraries. - When building with configure/make, you can build and install them normally and the configure script will detect and use them. - When building with Visual Studio, you will need to build the libraries and then add the appropriate LOAD_* preprocessor define to the Visual Studio project. - When building with Xcode, you can edit the config at the top of the project to enable them, and you will need to include the appropriate framework in your application. - For Android, you can edit the config at the top of Android.mk to enable them.
Reported in version: unspecified
Reported for operating system, platform: FreeBSD, x86
On 2008-04-15 07:22:09 +0000, Chad Whitacre wrote:
Is it possible to include /usr/local/include on the search path for header files by default? That's where libpng installs png.h by default on my system (FreeBSD 6).
On 2009-10-17 12:49:21 +0000, Sam Lantinga wrote:
Can you test with the latest pre-release snapshot?
http://www.libsdl.org/tmp/SDL_image-1.2.8.zipThanks!
On 2011-12-31 09:32:24 +0000, Sam Lantinga wrote:
No response in a few years. :)
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.5 (Intel), x86
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 resultI'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
Reported in version: unspecified
Reported for operating system, platform: Linux, All
On 2007-02-28 04:48:02 +0000, wrote:
Add MNG support to SDL_image. At [http://cryptology.org/research/SDL MNG Library/] there is SDL_mng-0.1.tar.bz2. I have tested it with the following result:
SDL_mng-0.1> ./autogen.sh
Generating aclocal.m4
/usr/share/aclocal/sdlmm.m4:12: warning: underquoted definition of AM_PATH_SDLMM
/usr/share/aclocal/sdlmm.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/sdlmm.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
Generating Makefile.in
configure.ac:6: installing./config.sub' configure.ac:10: installing
./missing'
configure.ac:10: installing./install-sh' configure.ac:6: installing
./config.guess'
Makefile.am: installing./depcomp' configure.ac:14: required file
./ltmain.sh' not found
Generating configure fileI worked around the problem:
SDL_mng-0.1> ln -s /usr/share/libtool/ltmain.sh .
SDL_mng-0.1> ./autogen.sh
Generating aclocal.m4
/usr/share/aclocal/sdlmm.m4:12: warning: underquoted definition of AM_PATH_SDLMM
/usr/share/aclocal/sdlmm.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/sdlmm.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
Generating Makefile.in
Generating configure fileThen configure works. But make ends with:
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -DLOAD_PNG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -o libSDL_mng.la -rpath /usr/local/lib SDL_mng.lo @IMG_LIBS@ -lpng -lz -lSDL -lpthread
gcc -shared .libs/SDL_mng.o /usr/lib/libpng12.so -lz /usr/lib/libSDL.so -L/usr/lib -lpthread @IMG_LIBS@ -Wl,-soname -Wl,libSDL_mng.so.0 -o .libs/libSDL_mng.so.0.0.0
gcc: @IMG_LIBS@: No such file or directory
make: *** [libSDL_mng.la] Fel 1I commented out the line "libSDL_mng_la_LIBADD = @IMG_LIBS@" in Makefile.am and did "./autogen.sh;configure;make" again. Then I could run ./mngtest and see the dancing panda.
On 2007-03-05 19:12:48 +0000, Dennis Payne wrote:
I was just looking at SDL_mng and I'm probably going use it. But I don't think it is a good idea to integrate as is. I'd prefer to see an interface more like SDL_anim (http://tamale.net/SDL_anim/). That interface isn't entirely to my liking either.
On 2007-07-12 20:17:09 +0000, Sam Lantinga wrote:
Yes, SDL_image is really meant for single images, not animation or image sets.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), PowerPC
On 2009-02-03 11:31:50 +0000, Nicolas Simonds wrote:
Created attachment 293
SDL_image.h.patchApple's gcc gives you this bit of syntactic sugar for free; if you include headers in the form:
#include <Some_Framework/some_header_file.h>
...the compiler will look in any relevant frameworks as well as the defined INCLUDE_PATH. If the SDL_image.framework headers are modified to use this style, it requires much less tinkering on the part of developers to get the think to compile/link.
The attached patch throws in some good vibes for us Apple folk, while hopefully staying out of everyone else's way.
On 2009-09-26 01:37:57 +0000, Sam Lantinga wrote:
This is a larger discussion about expected usage of SDL headers.
This will be evaluated with the SDL 1.3 release.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2006-03-22 12:16:57 +0000, Samuel Owens wrote:
After successfully compiling SDL 1.2.9, I tried to compile SDL_image 1.2.4, but after successfully configuring, when I try to run make, I get this error:
IMG_png.c:72:17: error: png.h: No such file or directory
IMG_png.c: In function 'IMG_isPNG':
IMG_png.c:86: error: 'png_size_t' undeclared (first use in this function)
IMG_png.c:86: error: (Each undeclared identifier is reported only once
IMG_png.c:86: error: for each function it appears in.)
IMG_png.c:86: error: syntax error before numeric constant
IMG_png.c: At top level:
IMG_png.c:90: error: syntax error before 'ctx'
IMG_png.c: In function 'png_read_data':
IMG_png.c:94: error: 'ctx' undeclared (first use in this function)
IMG_png.c:95: error: 'area' undeclared (first use in this function)
IMG_png.c:95: error: 'size' undeclared (first use in this function)
IMG_png.c: In function 'IMG_LoadPNG_RW':
IMG_png.c:100: error: 'png_structp' undeclared (first use in this function)
IMG_png.c:100: error: syntax error before 'png_ptr'
IMG_png.c:101: error: 'png_infop' undeclared (first use in this function)
IMG_png.c:102: error: 'png_uint_32' undeclared (first use in this function)
IMG_png.c:109: error: 'png_bytep' undeclared (first use in this function)
IMG_png.c:109: error: syntax error before 'volatile'
IMG_png.c:112: error: 'png_color_16' undeclared (first use in this function)
IMG_png.c:112: error: 'transv' undeclared (first use in this function)
IMG_png.c:120: error: 'png_ptr' undeclared (first use in this function)
IMG_png.c:120: error: 'info_ptr' undeclared (first use in this function)
IMG_png.c:120: error: 'row_pointers' undeclared (first use in this function)
IMG_png.c:123: error: 'PNG_LIBPNG_VER_STRING' undeclared (first use in this function)
IMG_png.c:151: error: 'width' undeclared (first use in this function)
IMG_png.c:151: error: 'height' undeclared (first use in this function)
IMG_png.c:163: error: 'PNG_COLOR_TYPE_GRAY' undeclared (first use in this function)
IMG_png.c:169: error: 'PNG_INFO_tRNS' undeclared (first use in this function)
IMG_png.c:174: error: 'PNG_COLOR_TYPE_PALETTE' undeclared (first use in this function)
IMG_png.c:195: error: 'PNG_COLOR_TYPE_GRAY_ALPHA' undeclared (first use in this function)
IMG_png.c:237: error: syntax error before ')' token
IMG_png.c:246: error: syntax error before 'Uint8'
IMG_png.c:281: error: 'png_infopp' undeclared (first use in this function)
IMG_png.c:281: error: syntax error before numeric constant
make: *** [IMG_png.lo] Error 1I don't know why that file isn't there in the "stable" source code. Especially since I compiled SDL, & SDL_image successfully on my machine at home (I'm on Computer Science lab computer now) last night
On 2006-03-22 12:23:08 +0000, Samuel Owens wrote:
When I tried the CVS build, I get the same error.
On 2006-03-25 04:24:37 +0000, Christian Walther wrote:
Looks like you don't have libpng? Although I'd expect configure to complain in that case...
On 2006-04-12 10:29:09 +0000, Sam Lantinga wrote:
What platform are you running on?
If it's a UNIX platform, what's the output of: sh configure
On 2006-05-01 05:19:14 +0000, Sam Lantinga wrote:
I think this may be fixed in subversion.
You can check out a snapshot here:
http://www.libsdl.org/tmp/SDL_image-1.2.5.tar.gzPlease reopen this bug if it's not fixed, and include the output of config.log
On 2006-05-02 18:29:05 +0000, Samuel Owens wrote:
Created attachment 109
config log for error diagnosticsame problem I'm afraid.
config.log is attached
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2007-12-10 16:47:36 +0000, Mike Frysinger wrote:
it's much easier to manage .pc files for cross-compiling setups than it is for random *-config scripts ... the cross-compiled pkg-config files can all be easily/tightly controlled and separate from the host pkg-config files. the *-config files however are to be found in $PATH and can easily pick the wrong one.
can we get the sdl.m4 macro updated so that it checks for libsdl.pc first via the standard PKG_CHECK_MODULES() m4 macro, and if that fails, fall back to the normal sdl-config voodoo.
along these lines, the png code in configure.in should be updated to use PKG_CHECK_MODULES() rather than parsing the headers/libs directly ... the current code can break easily when libpng requires other libs (like -lz and/or -lm).
On 2007-12-28 08:52:56 +0000, Sam Lantinga wrote:
I'm not very familiar with the pkg-config system. Can you supply a patch?
Thanks!
On 2007-12-29 18:12:10 +0000, Mike Frysinger wrote:
Created attachment 240
sdl-image-find-lib-cross.patchsorry, i didnt see your reply
this patch makes it so find_lib() does not look in /usr/local/lib and /usr/lib when cross-compiling as that can easily cause troubles
On 2007-12-29 19:07:08 +0000, Mike Frysinger wrote:
Created attachment 241
libsdl-sdl-m4-pkg-config.patchhere's the fun one ... this updates libsdl's sdl.m4 so that it uses sdl.pc (and pkg-config) before sdl-config
the order preference is:
- use sdl configure options first from user
- try to use sdl.pc/pkg-config
- try to use sdl-config/SDL_CONFIG
so really all this does is insert pkg-config before the normal default logic
On 2009-10-02 05:32:45 +0000, Sam Lantinga wrote:
I applied your configure.in patch, thanks!
The sdl.m4 patch didn't cleanly apply though, can you update it for the latest SDL snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zipThanks!
On 2009-10-03 00:24:03 +0000, Mike Frysinger wrote:
Created attachment 382
libsdl-sdl-m4-pkg-config.2.patchapplied rev 3493 and rev 3532 manually to get the patch to apply
On 2009-10-03 03:14:33 +0000, Sam Lantinga wrote:
Are you creating the diff against the current SDL_image in subversion?
sam-lantingas-mac-pro:SDL_image hercules$ patch -l -p2 <~/Downloads/libsdl-sdl-m4-pkg-config.2.patch
patching file acinclude/sdl.m4
Hunk # 1 FAILED at 19.
On 2009-10-03 08:06:20 +0000, Mike Frysinger wrote:
this bug started out as "SDL_image should do XXX", but the m4 problems SDL_image isnt specific to it. the problematic code comes from SDL itself, so the patch applies to trunk/SDL/sdl.m4. once the original version gets fixed, it'll propagate to all the other packages.
On 2009-10-03 21:42:33 +0000, Sam Lantinga wrote:
It doesn't quite work here...
./configure: line 20603: syntax error near unexpected tokenSDL,' ./configure: line 20603:
PKG_CHECK_MODULES(SDL, sdl >= $min_sdl_version,'
On 2009-10-03 22:48:43 +0000, Mike Frysinger wrote:
do you not have pkg-config installed on your system ? it provides that m4 macro via its pkg.m4 ...
guess the AM_PATH_SDL should be updated like so:
@@ -10,5 +10,6 @@
dnl
AC_DEFUN([AM_PATH_SDL],
-[dnl
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+dnl
dnl Get the cflags and libraries from the sdl-config script
dnl
On 2009-10-03 22:57:19 +0000, Sam Lantinga wrote:
Okay, I tried that...
configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:1: error: possibly undefined macro: dnl
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:20608: error: possibly undefined macro: AC_MSG_RESULT
On 2009-10-04 09:57:36 +0000, Mike Frysinger wrote:
adding the AC_REQUIRE wont fix your original problem (no pkg.m4 on your system), it'll only make the failure obvious at an earlier point (from a sometimes-syntax error to an autoconf error)
you still need to install the pkgconfig program and the associated pkg.m4:
http://pkgconfig.freedesktop.org/wiki/i dont think it's unreasonable to expect developers who are running autotools to have this installed
On 2009-10-04 11:12:06 +0000, Sam Lantinga wrote:
Okay, I applied your changes to sdl.m4 to SDL 1.3 and the SDL_* libraries I maintain, and added pkg.m4 to the libraries.
I didn't want to make that change to SDL 1.2 because anyone who updates to the release will suddenly have an unexpected pkg.m4 dependency.
Can you provide a patch for the png support? It should fall back to the current system if pkg-config isn't available.
Thanks!
On 2009-10-04 22:28:31 +0000, Mike Frysinger wrote:
Created attachment 395
sdl-image-pkg-config-png.patchi think the current handling of autotool files is broken ... but i guess it doesnt matter since i'm not the SDL maintainer. since you're including pkg.m4 in svn, no one who updates will have a dependency on pkg.m4.
at any rate, this patch should convert SDL_image's png lookup to pkg-config
On 2009-10-05 00:55:09 +0000, Sam Lantinga wrote:
Should there be equivalent changes for libjpeg and libtiff?
Do you have suggestions on improving the autotools support?
Thanks!
On 2009-10-05 09:28:43 +0000, Mike Frysinger wrote:
the jpeg/tiff packages dont provide .pc files, so they wouldnt work
imo, generated autotool files shouldnt be in svn. it does mean that people need more development packages installed in order to use the development svn, but i think that is how it should be. i dont imagine you want to impose these higher requirements on people which is why you copy so much to acinclude/ and such.
On 2009-10-05 21:54:17 +0000, Sam Lantinga wrote:
Yes, that's true. My general philosophy is to try to work on as many different environments as possible. :)
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
On 2012-11-11 13:19:53 +0000, Sylvain wrote:
Created attachment 987
xpm colors mapping table !Here's a file to recognize lots colors for XPM format !
colors were found on internet, but I can't remember where ...
On 2012-11-22 13:11:13 +0000, Sam Lantinga wrote:
Added, thanks!
http://hg.libsdl.org/SDL_image/rev/2e4f9d95a8c8
Reported in version: 1.2.12
Reported for operating system, platform: Mac OS X (All), All
On 2012-11-16 01:13:08 +0000, wrote:
When compiling with the configure and makefile on Mountain Lion, libSDLmain.a and libSDL.a get somehow included in libSDL_image.a. This seems to confuse ld, as I ge tthe following message in the final linking with the application:
ld: warning: ignoring file lib/libSDL_image.a, file was built for archive which is not the architecture being linked (x86_64): lib/libSDL_image.a
otool and lipo still recognize the library as a x86_64 blob. It's only clang that seems to be upset at it.
The same happens with libSDL_mixer.a, but I won't report this bug twice.
I don't know whether this is related to # 1429.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2012-02-27 08:07:38 +0000, pelya wrote:
Created attachment 828
PatchJust few #ifdefs around functions that use SDL_Texture
On 2013-06-03 01:48:41 +0000, Sam Lantinga wrote:
Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/e94321a2e752
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2012-12-10 19:16:47 +0000, SwordBearer wrote:
I used libSDL_image.a in my SDL codes,and call IMG_Load()method,
then Code:Block said this error:/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function
IMG_InitJPG':| (.text+0xff)||undefined reference to
jpeg_calc_output_dimensions'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x109)||undefined reference to
jpeg_CreateDecompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x113)||undefined reference to
jpeg_destroy_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x11d)||undefined reference to
jpeg_finish_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x127)||undefined reference to
jpeg_read_header'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x131)||undefined reference to
jpeg_read_scanlines'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x13b)||undefined reference to
jpeg_resync_to_restart'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x145)||undefined reference to
jpeg_start_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In functionIMG_InitJPG':| (.text+0x14f)||undefined reference to
jpeg_std_error'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x53)||undefined reference to
png_create_info_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x5d)||undefined reference to
png_create_read_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x67)||undefined reference to
png_destroy_read_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x71)||undefined reference to
png_get_IHDR'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x7b)||undefined reference to
png_get_channels'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x85)||undefined reference to
png_get_io_ptr'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x8f)||undefined reference to
png_get_PLTE'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0x99)||undefined reference to
png_get_tRNS'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xa3)||undefined reference to
png_get_valid'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xad)||undefined reference to
png_read_image'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xb7)||undefined reference to
png_read_info'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xc1)||undefined reference to
png_read_update_info'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xcb)||undefined reference to
png_set_expand'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xd5)||undefined reference to
png_set_gray_to_rgb'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xdf)||undefined reference to
png_set_packing'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xe9)||undefined reference to
png_set_read_fn'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xf3)||undefined reference to
png_set_strip_16'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In functionIMG_InitPNG':| (.text+0xfd)||undefined reference to
png_sig_cmp'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In functionIMG_InitTIF':| (.text+0x12f)||undefined reference to
TIFFClientOpen'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In functionIMG_InitTIF':| (.text+0x139)||undefined reference to
TIFFClose'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In functionIMG_InitTIF':| (.text+0x143)||undefined reference to
TIFFGetField'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In functionIMG_InitTIF':| (.text+0x14d)||undefined reference to
TIFFReadRGBAImage'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In functionIMG_InitTIF':| (.text+0x157)||undefined reference to
TIFFSetErrorHandler'|
||=== Build finished: 32 errors, 0 warnings ===|================================================================================================================================================================
so ,I delete the libSDL_image.a lib๏ผand add the libSDL_image.so lib(they are both in the '/usr/lib/i386-linux-gnu' directory ).
it compiled success!
On 2013-05-01 19:46:37 +0000, wrote:
I would say to broaden this as I have dynamic loading of libjpeg and I am also getting failures. The issue is on IMG_jpg.c:66, dlopen fails to find the .so for libjpeg even though I can access it fine. I had a previous version of SDL_image and it worked just fine.
I will try to find out what is causing this later today.
On 2013-06-03 01:51:00 +0000, Sam Lantinga wrote:
Any luck finding the issue with the RC snapshot?
http://www.libsdl.org/tmp/SDL_image/
On 2013-06-03 08:34:55 +0000, wrote:
I just built the latest source and it does find and use the right version of libjpeg and libpng and links nicely. I just tested it and I am seeing images loading just fine, thanks. I did force what libpng and libjpeg were found for my previous builds of SDL_image, so I don't know 100% if the successful build is influenced at all from my previous efforts. Otherwise, I would say it is fixed.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2009-10-04 12:43:58 +0000, Sam Lantinga wrote:
Created attachment 394
PCX test imageAttached file is PCX without RLE compression. PCX files should always be with
RLE compression, but it looks like some programs like XnView can create PCX
files without RLE compression and for example IrfanView seems to support decode
of them.
On 2009-10-04 13:16:54 +0000, Sam Lantinga wrote:
This is implemented for the next release.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2006-05-13 16:06:32 +0000, Maurizio Monge wrote:
The palette of bmp files is loaded from a wrong offset in the bmp file.
I am attaching a test file (it is being loaded correcty by imagemagick, gdk-pixbuf and windows too, but not with current sdl-image).
Here is a very little patch to fix the problem:diff -Nurb SDL_image-1.2.4-old/IMG_bmp.c SDL_image-1.2.4-new/IMG_bmp.c --- SDL_image-1.2.4-old/IMG_bmp.c 2004-12-16 05:41:01.000000000 +0100 +++ SDL_image-1.2.4-new/IMG_bmp.c 2006-05-13 04:51:40.000000000 +0200 @@ -301,6 +301,13 @@ /* Load the palette, if any */ palette = (surface->format)->palette; if ( palette ) { + + if ( SDL_RWseek(src, fp_offset+14+biSize, SEEK_SET) < 0 ) { + SDL_Error(SDL_EFSEEK); + was_error = 1; + goto done; + } + /* | guich: always use 1<<bpp b/c some bitmaps can bring wrong information | for colorsUsed
On 2006-05-13 16:10:24 +0000, Maurizio Monge wrote:
Created attachment 127
A sample file
On 2006-05-14 16:57:21 +0000, Sam Lantinga wrote:
This is fixed in subversion, thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
On 2013-01-09 13:38:25 +0000, David North wrote:
Building SDL_image latest (from Mecurial) with libpng-compat installed under Fedora 17 causes PNG files (that worked perfectly well under SDL 1.2) to return NULL.
I am calling the method IMG_LoadTexture, but I believe the actual problem resides in IMG_Load
The error returned is 'undefined symbol: _png_set_longjmp_fn'
libpng-compat is installed with Google Chrome, and so it took a little bit of tracking down in order to find the offending package.
I've fixed it now by removing libpngt-compat and recompiling SDL_image, but if there is any other information you require, please let me know
On 2013-06-03 01:57:38 +0000, Sam Lantinga wrote:
Can you download the source and send me the output of configure with and without libpng-compat installed?
My guess is that it's finding newer libpng headers, and finding the old png library and using that as the one to load.
On 2013-06-07 13:13:23 +0000, Yaohan Chen wrote:
Created attachment 1182
config.log with both libpng 1.2 and 1.6 installed, default configure options
On 2013-06-07 13:15:34 +0000, Yaohan Chen wrote:
Created attachment 1183
config.log with both libpng 1.2 and 1.6 installed, --disable-png-shared
On 2013-06-07 13:17:44 +0000, Yaohan Chen wrote:
Created attachment 1184
config.log with libpng 1.6 installed, and without libpng 1.2 installed
On 2013-06-07 13:32:20 +0000, Yaohan Chen wrote:
I also have this problem on Arch Linux. I have the following library files owned by the libpng 1.6 and 1.2 packages:
libpng 1.6
/usr/lib/libpng.so
/usr/lib/libpng16.so
/usr/lib/libpng16.so.16
/usr/lib/libpng16.so.16.2.0libpng 1.2
/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.50.0
/usr/lib/libpng12.so
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.50.0With both packages installed, configure will by default generate both -lpng and -lpng.so.3. With both packages installed and --disable-png-shared, configure will generate only -lpng, which produces a working build for me. With libpng 1.2 removed, it also produces a working build.
The problem seems to be due to in lines 218 to 226 of configure.in:
png_lib=[find_lib "libpng.so.[0-9]"
]
if test x$png_lib = x; then
png_lib=[find_lib "libpng.so.[0-9]*"
]
fi
if test x$png_lib = x; then
png_lib=[find_lib "libpng*.so.[0-9]"
]
fi
if test x$png_lib = x; then
png_lib=[find_lib "libpng*.so.[0-9]*"
]
fi
This matches libpng.so.3 but not ligpng.so. Maybe this is not even necessary since another part of configure uses pkg-config to get flags for libpng 1.6 correctly.
On 2013-06-08 00:56:18 +0000, Sam Lantinga wrote:
Okay, this should be fixed.
http://hg.libsdl.org/SDL_image/rev/2608ba5feac1Please let me know if this doesn't work or breaks something else.
Thanks!
Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86
On 2011-10-27 11:08:25 +0000, wrote:
NOTE: This is using the latest version of SDL_image (1.2.11) from Mercurial.
The configure script for SDL_image fails to detect libpng if a โbuild argument is specified for i386.
Repro Steps:
get libpng-1.5.5.tar.gz from http://www.libpng.org/pub/png/libpng.html
compile libpng from i386
open console window and cd to libpng source folder
./configure โbuild=i386-apple-darwin10.8.0
make CFLAGS="-arch i386" LDFLAGS="-arch i386"
make install
lipo โinfo /usr/local/lib/libpng.dylib
Non-fat file: /usr/local/lib/libpng.dylib is architecture: i386then, configure SDL_image
cd _SDL_image_1.2.11
./configure โbuild=i386-apple-darwin10 โdisable-sdltestBUG:
configure: WARNING: *** Unable to find PNG library (http://www.libpng.org/pub/png/libpng.html)
configure: WARNING: PNG image loading disabledHowever, if you compile libpng without the โbuild argument (i.e. building for x86_64) :
./configure
make
make installAnd then invoke SDL_image's configure script without the โbuild argument, then the libpng library is found:
./configure โdisable-sdltest
The work-around is to invoke SDL_image's configure script with the i386 build argument, and then modify the Makefile to add the missing info to the DEFS entry:
-DLOAD_PNG=1
-DLOAD_PNG_DYNAMIC="\libpng.dylib"I hope this helps!
Regards,
Alain
On 2013-06-03 01:35:34 +0000, Sam Lantinga wrote:
This is probably a general problem with all dependency library detection. Please let me know if you find a fix!
Reported in version: unspecified
Reported for operating system, platform: Windows (All), All
On 2009-06-10 06:29:45 +0000, Mason Wheeler wrote:
See http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-April/069705.html for the patch and the rationale for it.
On 2009-06-29 21:05:00 +0000, Mason Wheeler wrote:
After further testing, I've found that the patch needs to be revised a little. The "initialized & CONSTANT_VALUE" checks need to be removed from IMG_Init, as they make it impossible to nest initialization calls from different subsystems of the calling program.
Also, the line "initialized = result;" ought to read "initialized |= result;", again to allow for multiple calls to IMG_Init to work correctly.
On 2009-09-26 02:10:04 +0000, Sam Lantinga wrote:
This is in for the next release, thanks!
These attachments are available in the static archive:
Reported in version: 1.2.6
Reported for operating system, platform: Linux, x86
On 2009-03-26 00:04:24 +0000, peter wrote:
Created attachment 308
a png with alpha channelPossible Memory Leak rendering PNG images,the parts code of a sample is belows:
//============================================================================
/* Initialize the SDL library */
if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
fprintf(stderr, "Couldn't initialize SDL: %s\n",SDL_GetError());
return(255);
}flags = SDL_SWSURFACE;
SDL_Surface* Surf_Temp = NULL;
/* Open the image file */
for(j=0;j<100;j++)
{
image[j] = IMG_Load(argv[1]);} /* Use the deepest native mode, except that we emulate 32bpp for viewing non-indexed images on 8bpp screens */
screen = SDL_SetVideoMode(720, 576, 16, flags);
if ( screen == NULL ) {
fprintf(stderr,"Couldn't set video mode: %s\n",
SDL_GetError());
return -1;
}
#if 0
/* Set the palette, if one exists */
if ( image[20]->format->palette ) {
SDL_SetColors(screen, image[20]->format->palette->colors,
0, image[20]->format->palette->ncolors);
}/* Draw a background pattern if the surface has transparency */ if(image[20]->flags & (SDL_SRCALPHA | SDL_SRCCOLORKEY)) draw_background(screen);
#endif
/* Display the image */
SDL_BlitSurface(image[20], NULL, screen, NULL);
SDL_UpdateRect(screen,0,0,0,0);
sleep(5);
fprintf(stderr,"start free resource...................\n");for(j=0;j<100;j++) { printf("before free:image[%d].refcount is %d\n",j,image[j]->refcount); SDL_FreeSurface(image[j]); printf("after free:image[%d].refcount is %d\n",j,image[j]->refcount); }
SDL_Quit();
...............
On 2009-03-26 00:05:48 +0000, peter wrote:
I don't know if it's a memory leak or something else. How can I fix it.
thanks for your help!
On 2009-09-26 01:39:52 +0000, Sam Lantinga wrote:
It's not legal to check the refcount on a surface after it was freed. :)
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Android (All), ARM
On 2012-04-18 16:58:21 +0000, Dan Hatch wrote:
Created attachment 846
Simple test programI'm using the most recent versions of sdl-1.3 and SDL_image from HG. My build environment is Ubuntu 11.10 x86_64.
I've built a simple test program which loads an image and displays it for 5 seconds. The image fails to load, and the app is just a black screen that remains open.
'adb logcat' displays the following:(loads all .so files just fine)
V/SDL ( 785): pixel format RGB_565
I/SDL ( 785): SDL_Android_Init()
I/SDL ( 785): SDL_Android_Init() finished!
W/SDL/APP ( 785): **Setting up display
I/Process ( 80): Sending signal. PID: 785 SIG: 3
I/dalvikvm( 785): threadid=3: reacting to signal 3
W/SDL/APP ( 785): **Error::Video driver doesn't support changing display mode
V/SDL ( 785): Starting up OpenGL ES 1.1
D/libEGL ( 785): Emulator without GPU support detected. Fallback to software renderer.
D/libEGL ( 785): loaded /system/lib/egl/libGLES_android.so
I/dalvikvm( 785): Wrote stack traces to '/data/anr/traces.txt'
D/gralloc_goldfish( 785): Emulator without GPU emulation detected.
I/SDL ( 785): [STUB] GL_SetSwapInterval
I/SDL ( 785): [STUB] GL_GetSwapInterval
W/SDL/APP ( 785): **Loading Image /sdcard/data/images/test.jpg
W/SDL/APP ( 785): **Error::Image Failed to Load
W/SDL/APP ( 785): **Displaying Image
W/SDL/APP ( 785): **Error::Invalid texture
I/ActivityManager( 80): Displayed org.libsdl.app/.SDLActivity: +2s172ms
W/InputManagerService( 80): Starting input on non-focused client com.android.internal.view.IInputMethodClient$Stub$Proxy@41593c58 (uid=10013 pid=177)
W/NetworkManagementSocketTagger( 80): setKernelCountSet(10013, 0) failed with errno -2The files exists inside the emulator:
$adb shellls /sdcard/data/images/
default.png
grass(old).png
grass.png
items.png
monster.png
objects.png
objectsheet.xcf
pirate.png
pog.png
stoneblock.png
test.jpgI think I am having a similar problem as described in this post:
http://forums.libsdl.org/viewtopic.php?t=8037&sid=6e8774e5eb3b0e7b83be13d7bfe1fcf6
On 2012-04-19 13:25:07 +0000, Dan Hatch wrote:
I'm also getting an 'invalid renderer'
On 2012-04-20 14:28:59 +0000, Dan Hatch wrote:
Tested on 2.1 and 4.0.3 emulators and a 2.3 device. All platforms show same errors.
On 2012-05-11 11:32:25 +0000, Gabriel Jacobo wrote:
You are loading the image from an absolute path outside of the Android package. By default IMG_Load under Android will, iirc, load images using RWops and the paths have to be specified relative to the assets folder (ie, whatever you drop into the assets folder of the Android project you can load it as if it where in a "virtual root").
On 2012-05-16 00:24:46 +0000, Dan Hatch wrote:
(In reply to comment # 3)
You are loading the image from an absolute path outside of the Android package.
By default IMG_Load under Android will, iirc, load images using RWops and the
paths have to be specified relative to the assets folder (ie, whatever you drop
into the assets folder of the Android project you can load it as if it where in
a "virtual root").Ok, cool thanks, I'll give it a try :)
These attachments are available in the static archive:
Reported in version: 1.2.12
Reported for operating system, platform: Mac OS X (All), x86_64
On 2012-02-23 10:48:46 +0000, Gabriel Jacobo wrote:
This happens at least in Lion, with CFLAGS="-arch i386" or CFLAGS="-arch x86_64"
The workaround I'm using is removing showimage from the Makefilei386:
/bin/sh ./libtool --tag=CC --mode=link gcc -I/Users/gabo/ignifuga/dist/osx/include/libpng12 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -o showimage showimage.o libSDL2_image.la -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit
libtool: link: gcc -I/Users/gabo/ignifuga/dist/osx/include/libpng12 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -o showimage showimage.o -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,ForceFeedback -Wl,-framework -Wl,Cocoa -Wl,-framework -Wl,Carbon -Wl,-framework -Wl,IOKit -Wl,-framework -Wl,CoreAudio -Wl,-framework -Wl,AudioToolbox -Wl,-framework -Wl,AudioUnit ./.libs/libSDL2_image.a -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -lobjc
ld: warning: ignoring file ./.libs/libSDL2_image.a, file was built for archive which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
"_IMG_LoadTexture", referenced from:
_main in showimage.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make: *** [showimage] Error 1x86_64:
/bin/sh ./libtool --tag=CC --mode=link gcc -I/opt/local/include/libpng14 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -static-libgcc -o showimage showimage.o libSDL2_image.la -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit
libtool: link: gcc -I/opt/local/include/libpng14 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -static-libgcc -o showimage showimage.o -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,ForceFeedback -Wl,-framework -Wl,Cocoa -Wl,-framework -Wl,Carbon -Wl,-framework -Wl,IOKit -Wl,-framework -Wl,CoreAudio -Wl,-framework -Wl,AudioToolbox -Wl,-framework -Wl,AudioUnit ./.libs/libSDL2_image.a -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -lobjc
ld: warning: ignoring file ./.libs/libSDL2_image.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_IMG_LoadTexture", referenced from:
_main in showimage.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [showimage] Error 1
On 2012-02-23 19:37:16 +0000, Gabriel Jacobo wrote:
I'm seeing this in SDL_image's showimage as well as in my own projects...I think I've managed to reduce the problem to the sdl2-config --libs line, that gives me:
-L/Users/gabo/ignifuga/dist/osx32/lib /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit
Note that instead of -lSDL2 it's giving out the full path without -l, so it will be statically linked!
This in turns makes the static library generation for SDL_ttf (and SDL_image) look something like:
libtool: link: ar cru .libs/libSDL2_ttf.a /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a SDL_ttf.o
So, instead of only archiving SDL_ttf.o it's trying to archive libSDL2.a as well...THIS is the actual problem...removing libSDL2.a by hand from the Makefile solves the issue...
However, if I apply the fix in sdl2-config (changing /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a by -lSDL2), the configure script for SDL_image halts at "checking for SDL - version >= 2.0.0..."
On 2012-02-24 04:26:53 +0000, Gabriel Jacobo wrote:
Created attachment 827
Fix for sdl2-config line for static libs under OSXSorry for the brain fart yesterday, it turns out that sleeping on a problem is always a good idea. Anyway, replacing the whole library path for -lSDL2 actually solves the problem, so this patch should solve the issue. SDL_ttf and SDL_image compile statically without issue now.
On 2012-02-28 18:59:18 +0000, Sam Lantinga wrote:
I don't think we need that hack anymore, thanks!
http://hg.libsdl.org/SDL/rev/6bb657898f55
Reported in version: unspecified
Reported for operating system, platform: Other, All
On 2006-11-16 05:16:57 +0000, Andrew Radford wrote:
Using 1.2.5 stable off the homepage
Compiling on RHEL4 x86 32bit LinuxI am using configure to set up a MIPS cross compile on a x86 box
Because of this, the SDL libs and headers are compiled for mips in a directory other than /usr/local. Configure should execute sdl-config with -prefix=<path/to/mips/sdl/installation> because supplied the correct --with-sdl-prefix parameter to configure. Instead sdl-config is called with no -prefix parameter, causing it to default to /usr/local - which contains either the wrong (x86) libs or none at all.
In configure, changing $SDL_CONFIG to pass $sdl_args instead of $sdlconf_args made this work. It seems $sdlconf_args or $sdl_config_args are empty.
Note I am no expert in configure & autotools, so this may not be a bug if configure can be rebuilt somehow to fix this.
On 2007-07-12 20:59:25 +0000, Sam Lantinga wrote:
This seems like a bug in your SDL installation. If I configure SDL with --prefix=/usr/local/cross-tools/i386-mingw32, and then do make install, an sdl-config will be generated and installed in /usr/local/cross-tools/i386-mingw32/bin, and running that with the --cflags and --libs arguments will yield:
-I/usr/local/cross-tools/i386-mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main
-L/usr/local/cross-tools/i386-mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows
These attachments are available in the static archive:
Reported in version: 1.2.6
Reported for operating system, platform: Windows (All), PowerPC
On 2008-01-13 07:59:42 +0000, Christian Walther wrote:
I'm trying to build a set of static SDL_* libraries in my Mingw cross-compilation setup on Mac OS X. I have only static (no dynamic) versions of libpng and libtiff installed and configure SDL_image using
cross-configure.sh --prefix=/usr/local/cross-tools/i386-mingw32 --disable-shared --disable-jpg-shared --disable-png-shared --disable-tif-shared
In this invocation, the checks for libpng and libtiff fail (even though the libraries are there, and are found) because of missing symbols from zlib. I can fix this using the attached patch. I assume this shouldn't interfere in the case that dynamic png/tiff libraries are around, but I'm reluctant to try it, and I'm not very familiar with autoconf in general. Perhaps someone who is can advise if this is the right thing to do...
On 2008-01-13 08:00:33 +0000, Christian Walther wrote:
Created attachment 245
patch for configure.in
On 2008-12-13 06:51:28 +0000, Patrice Mandin wrote:
I also encountered it on a different platform, where the only option is static linking. It fails to find the -lz dependency for libpng and libtiff the same way, and found the same fix :). Would be nice to have it commited.
On 2009-09-26 01:43:02 +0000, Sam Lantinga wrote:
Thanks, this is committed to subversion.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, PowerPC
On 2010-03-05 19:54:38 +0000, wrote:
I posted this bug against supertux on bugs.debian.org because I wasnt sure if it was in supertux or libsdl.
I believe its in libsdlimage, I dont knoe if this is a compile flag bug or an SDL bug.
I dont know how to further troubleshoot this issue but I cannot run a single SDL app. They all get illegal instruction.
The original report is here
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572420
0000:00:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth AGP [106b:0020]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes
Capabilities:
Kernel driver in use: agpgart-uninorth0000:00:10.0 Display controller [0380]: ATI Technologies Inc Rage 128 RL/VR AGP [1002:524c]
Subsystem: ATI Technologies Inc Rage 128 RL/VR AGP [1002:524c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 255 (2000ns min), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 48
Region 0: Memory at 94000000 (32-bit, prefetchable) [size=64M]
Region 1: I/O ports at 0400 [size=256]
Region 2: Memory at 90000000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 90020000 [size=128K]
Capabilities:
Kernel driver in use: aty128fb0001:10:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth PCI [106b:001f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes0001:10:12.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB12LV23 IEEE-1394 Controller [104c:8019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (500ns min, 1000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 52
Region 0: Memory at 80082000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at 80084000 (32-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: firewire_ohci0001:10:17.0 Class [ff00]: Apple Computer Inc. KeyLargo Mac I/O [106b:0022] (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes
Region 0: Memory at 80000000 (32-bit, non-prefetchable) [size=512K]
Kernel driver in use: macio0001:10:18.0 USB Controller [0c03]: Apple Computer Inc. KeyLargo USB [106b:0019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 27
Region 0: Memory at 80081000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd0001:10:19.0 USB Controller [0c03]: Apple Computer Inc. KeyLargo USB [106b:0019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 28
Region 0: Memory at 80080000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd0002:20:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth Internal PCI [106b:001e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes0002:20:0f.0 Ethernet controller [0200]: Apple Computer Inc. UniNorth GMAC (Sun GEM) [106b:0021]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- <TAbort- SERR- <PERR+ INTx-
Latency: 16 (16000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 41
Region 0: Memory at f5200000 (32-bit, non-prefetchable) [size=2M]
Expansion ROM at f5000000 [disabled] [size=1M]
Kernel driver in use: gem$ cat /proc/cpuinfo
processor : 0
cpu : 740/750
temperature : 48-51 C (uncalibrated)
clock : 400.000000MHz
revision : 131.0 (pvr 0008 8300)
bogomips : 49.93
timebase : 24967850
platform : PowerMac
model : PowerMac2,1
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags : 00000014
L2 cache : 512K unified
pmac-generation : NewWorld
Memory : 256 MB$ dpkg -l | grep sdl
ii libguichan-sdl-0.8.1-1 0.8.2-1 small, efficient C++ GUI library (SDL integration)
ii libsdl-gfx1.2-4 2.0.20-1 drawing and graphical effects extension for SDL
ii libsdl-gfx1.2-dev 2.0.20-1 development files for SDL_gfx
ii libsdl-image1.2 1.2.10-2 image loading library for Simple DirectMedia Layer 1.2
ii libsdl-image1.2-dev 1.2.10-2 development files for SDL 1.2 image loading libray
ii libsdl-mixer1.2 1.2.8-6+b1 mixer library for Simple DirectMedia Layer 1.2
ii libsdl-mixer1.2-dev 1.2.8-6+b1 development files for SDL1.2 mixer library
ii libsdl-net1.2 1.2.7-2 network library for Simple DirectMedia Layer
ii libsdl-net1.2-dev 1.2.7-2 Development files for SDL network library
ii libsdl-pango-dev 0.1.2-4 text rendering with Pango in SDL applications (developm
ii libsdl-pango1 0.1.2-4 text rendering with Pango in SDL applications (shared l
ii libsdl-sound1.2 1.0.3-3+b1 Decoder of several sound file formats for SDL
ii libsdl-ttf2.0-0 2.0.9-1 ttf library for Simple DirectMedia Layer with FreeType
ii libsdl1.2-dev 1.2.14-4 Simple DirectMedia Layer development files
ii libsdl1.2debian 1.2.14-4 Simple DirectMedia Layer
rc libsdl1.2debian-alsa 1.2.13-5 Simple DirectMedia Layer (with X11 and ALSA options)
ii libsdl1.2debian-oss 1.2.14-4 Simple DirectMedia Layer (with X11 and OSS options)
On 2010-03-05 19:56:51 +0000, wrote:
Created attachment 496
strace on pingus
On 2010-03-05 19:58:15 +0000, wrote:
Created attachment 497
strace on supertux
On 2010-03-10 06:39:28 +0000, Sam Lantinga wrote:
Can you run them in the debugger and see where they are crashing?
Thanks!
On 2011-12-31 09:33:06 +0000, Sam Lantinga wrote:
No response in a few years. :)
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86_64
On 2011-04-07 07:24:58 +0000, wrote:
Created attachment 599
Diff for libjpeg 8libjpeg 8 has a different naming scheme for booleans:
boolean -> JPEG_boolean
FALSE -> JPEG_FALSE
TRUE -> JPEG_TRUEI'm building SDL_image with MinGW, attached is a small change I've made to IMG_jpg.c to be able to compile it.
On 2011-04-07 08:01:37 +0000, Sam Lantinga wrote:
This is in, thanks!
http://hg.libsdl.org/SDL_image/rev/b1c1ec3a8d49
On 2011-09-25 17:09:34 +0000, Yury G. Kudryashov wrote:
Created attachment 708
Fix compilation on LinuxTRUE was renamed to JPEG_TRUE by mingw port maintainers, not by upstream developers.
So instead of testing for version number one should test whether JPEG_TRUE is defined.
The attached patch is against the latest hg version.
On 2011-12-31 09:36:49 +0000, Sam Lantinga wrote:
I like this patch, it's in, thanks!
http://hg.libsdl.org/SDL_image/rev/e0527402f476
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2009-11-15 23:17:46 +0000, wrote:
The webpage at [http://www.libsdl.org/projects/SDL_image/] should use headings like
and
so that it is possible to link to [http://www.libsdl.org/projects/SDL_image/#changes] and [http://www.libsdl.org/projects/SDL_image/# 1.2.10].
And of course the page should be syntactically correct: http://validator.w3.org/
(this bugtracker does not seem to have a version 1.2.10 of SDL_image)
On 2009-12-14 13:23:32 +0000, Sam Lantinga wrote:
I added anchors so you can have links of that form. I also added the missing SDL_image version to the bug tracker. Thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2012-04-10 13:25:09 +0000, Mikhail wrote:
Created attachment 843
bad looking imageI see only part of loaded image. It's happening when I compiling with -std=c++0x option.
CODE:
#include "SDL/SDL.h"
#include "SDL/SDL_image.h"int main(int argc, char* args[])
{SDL_Surface* hello = NULL;
SDL_Surface* screen = NULL;SDL_Init(SDL_INIT_EVERYTHING);
screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
hello = IMG_Load("alien.png");
SDL_BlitSurface(hello, NULL, screen, NULL);
SDL_Flip(screen);
SDL_Delay(2000);
SDL_FreeSurface(hello);
SDL_Quit();return 0;
}COMPILER:
mike@mike-laptop:~/work/invdrs$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.SDL:
Source: libsdl1.2
Version: 1.2.14-6.1ubuntu4
On 2012-04-10 13:29:36 +0000, Mikhail wrote:
Sorry, it's a bug in my code, I set 24 bit depth in SDL_SetVideoMode and now it's all right.
Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86
On 2006-09-21 15:27:48 +0000, Donald Straney wrote:
I'm writing a program that's linked to SDL 1.2.9 and SDL_image 1.2.5 in Windows XP, and when I use IMG_Load to try to load PNG images, it returns NULL, and IMG_GetError returns "Unsupported image format". SDL.dll, SDL_image.dll, and libpng12.dll are all in the same directory as the program, and it works fine when loading BMPs (or when it's run in Windows ME, for some reason). If it matters, I'm using Dev-C++, which uses MinGW as a backend.
On 2006-09-25 13:33:00 +0000, Dmitry Yakimov wrote:
Hi,
Please try SDL_Image from SVN, I have fixed similar error in 2004 (http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL_image/IMG_png.c?view=log)
-- Dmitry Yakimov
On 2006-09-28 16:44:52 +0000, Donald Straney wrote:
Thanks, but when I try to compile in Dev-C++ I get these errors:
[Linker error] undefined reference to
SDL_RWFromFile' [Linker error] undefined reference to
SDL_SetError'I've got the SDL 1.2.9 development libraries installed, and the extra commands passed to the compiler are "-lmingw32 -lSDLmain -lSDL". (I tried searching to see if there was something I was doing wrong, but couldn't find anything)
On 2007-09-19 19:43:00 +0000, Ryan McCann wrote:
With Dev-C++ you have to create a .a lib file for any dll's you want to call directly(Dev will occasionally let you get away without them, but the functionality involved is incredibly buggy). Anything using sdl_image needs a -lsdl_image flag.
To get a .a file from a dll DL the mingw_utils_0.3 package, use bin/pexports.exe to change the get a .def and bin/dlltool.exe to get a .a from the .def
This is a compiler issue and not a SDL_Image issue. The current version of image(and at least two previous releases) work with PNG files on winXP.
On 2009-01-01 12:26:48 +0000, BJ wrote:
Same problem under linux. When trying to load a png file i get a segmentation fault.
using netbeans 6.5, ubuntu 8.10, gcc, sdl 1.2.13
On 2009-10-17 12:47:41 +0000, Sam Lantinga wrote:
Can you test with the latest pre-release snapshot?
http://www.libsdl.org/tmp/SDL_image-1.2.8.zipThanks!
On 2011-12-31 09:32:03 +0000, Sam Lantinga wrote:
No response in a few years. :)
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2006-07-19 08:30:52 +0000, Pierre Sarrazin wrote:
My code calls IMG_ReadXPMFromArray(char **xpm) to create an SDL_Surface from an XPM array in memory. That function calls load_xpm(xpm, NULL). That NULL is the 'src' argument, of type SDL_RWops. The first thing that load_xpm() does with 'src' is to call SDL_RWtell(src). SDL/SDL_rwops.h defines SDL_RWtell(ctx) as (ctx)->seek(ctx, 0, RW_SEEK_CUR). Since 'ctx' is null, the process crashes. This all happens in IMG_xpm.c.
This happens with SDL_image 1.2.5. Version 1.2.4 had a different implementation for load_xpm(): it called get_next_line(xpmlines, src, 0) instead of SDL_RWtell(src). get_next_line() did not use 'src' if 'xpmlines' was non-null.
On 2006-07-22 00:37:49 +0000, Michael Koch wrote:
Created attachment 150
Patch fixing several segfaultsI have got a patch for the same problem in Debian. Applications that worked with SDL_Image 1.2.4 segfaulted a lot with SDL_Image 1.2.5. The attached patch fixes this. I already use this patch in Debian and it looks okay.
On 2007-02-13 05:08:38 +0000, Ryan C. Gordon wrote:
This patch is now in Subversion (revision # 2970).
Thanks!
--ryan.
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86
On 2011-08-16 13:08:21 +0000, Vern Jensen wrote:
Application Loader rejects any apps that include SDL_Image.framework, complaining that "SDL_Image is an invalid bundle identifier."
The solution is simple: rebuild the framework with "SDLImage" as the bundle identifier.
Apparently it doesn't like underscores.
On 2011-11-30 15:37:35 +0000, C.W. Betts wrote:
Created attachment 735
Changes the Xcode variable FRAMEWORK_VERSION from 1.3 to B
On 2011-11-30 15:43:04 +0000, C.W. Betts wrote:
(In reply to comment # 1)
Created attachment 735 [details]
Changes the Xcode variable FRAMEWORK_VERSION from 1.3 to BSorry, not used to this bugzilla: this patch is for a different issue.
As for renaming supporting SDL frameworks without an underscore, this could break linking with older apps. I think a static file link (e.g. ln -s SDLImage SDL_Image) might take care of it. If not, there's probably a linker flag that can be passed to make the framework be recognized as both SDL_Image and SDLImage, but default to SDLImage when built and linked to it.
On 2011-11-30 16:53:39 +0000, C.W. Betts wrote:
Created attachment 737
Removes the underscore from SDL_image's product name
On 2011-12-31 10:36:03 +0000, Sam Lantinga wrote:
Both of these fixes are in for all the SDL_* libraries I maintain.
Thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2006-01-24 01:19:19 +0000, Sam Lantinga wrote:
Date: Tue, 1 Apr 2003 11:43:04 +0200
From: David Raulo [email protected](by way of David Raulo [email protected])
Subject: [SDL] SDL_Image patch for ILBM Amiga imagesHi all,
Here's a patch for SDL_Image, adding support for classic Amiga ILBM formats:
- fixes a small bug with stencil (images with a transparent color but no
stencil/mask plane could not be read)- fixes colormap for EHB ("Extra Half Brite") mode (these images have 6
bitplanes, but the colormap only contains 32 colors. The second half of the
colormap has to be a copy of the first one, with brightness divided by 2)- adds support for HAM ("Hold And Modify") and HAM8 modes. These are
converted to 24bits images.Detailed information about these formats can be found on
http://netghost.narod.ru/gff/graphics/summary/iff.htmThe attached patch is a unidiff against SDL_Image version 1.2.3.
On 2006-01-24 01:20:38 +0000, Sam Lantinga wrote:
Created attachment 31
sdlimage-ilbm-amiga-modes.2.diffThis diff doesn't apply cleanly anymore.
On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:
Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.
--ryan.
On 2006-05-01 04:03:06 +0000, Sam Lantinga wrote:
It looks like this functionality is already in SDL_image in subversion.
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86_64
On 2011-11-20 09:29:10 +0000, Martin Gerhardy wrote:
I'm not sure whether it's a problem in SDL_image or SDL. But loading an image with SDL_image 1.2.10 on an intel mac 64 bit results in a segfault (bt full is attached)
The SDL version that was used was SDL 1.3 from Nov. 15th
------------------snip----------------------------------
SDL_Surface *surf = IMG_Load(file.getName());
SDL_PixelFormat format;
memset(&format, 0, sizeof(format));
format.BitsPerPixel = 32;
format.BytesPerPixel = 4;
#if SDL_BYTEORDER == SDL_BIG_ENDIAN
format.Rmask = 0xff000000;
format.Gmask = 0x00ff0000;
format.Bmask = 0x0000ff00;
format.Amask = 0x000000ff;
#else
format.Rmask = 0x000000ff;
format.Gmask = 0x0000ff00;
format.Bmask = 0x00ff0000;
format.Amask = 0xff000000;
#endif
format.Rshift = 24;
format.Gshift = 16;
format.Bshift = 8;
format.Ashift = 0;// here comes the segfault
SDL_Surface * converted = SDL_ConvertSurface(surf, &format, 0);------------------snap----------------------------------
On 2011-11-20 09:29:50 +0000, Martin Gerhardy wrote:
Created attachment 730
the backtracethe backtrace
On 2012-11-06 11:44:49 +0000, Martin Gerhardy wrote:
this can be closed - it works with the latest sdl version.
On 2012-11-06 20:19:50 +0000, Sam Lantinga wrote:
Great, thanks!
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: All, All
On 2011-02-16 16:09:28 +0000, Mikael Eriksson wrote:
Trying to build SDL_image with libpng 1.5 fails with:
/bin/sh ./libtool --tag=CC --mode=compile i486-mingw32-gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.10" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff-3.dll" -DLOAD_PNG_DYNAMIC="libpng15-15.dll" -I. -I/usr/i486-mingw32/include/libpng15 -g -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/usr/i486-mingw32/include/SDL -MT IMG_png.lo -MD -MP -MF .deps/IMG_png.Tpo -c -o IMG_png.lo IMG_png.c
libtool: compile: i486-mingw32-gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.10" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff-3.dll" -DLOAD_PNG_DYNAMIC="libpng15-15.dll" -I. -I/usr/i486-mingw32/include/libpng15 -g -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/usr/i486-mingw32/include/SDL -MT IMG_png.lo -MD -MP -MF .deps/IMG_png.Tpo -c IMG_png.c -DDLL_EXPORT -DPIC -o .libs/IMG_png.o
IMG_png.c: In function 'IMG_LoadPNG_RW':
IMG_png.c:350:7: error: dereferencing pointer to incomplete type
IMG_png.c:419:21: error: dereferencing pointer to incomplete type
IMG_png.c:421:28: error: dereferencing pointer to incomplete type
IMG_png.c:429:22: error: dereferencing pointer to incomplete type
IMG_png.c:477:25: error: dereferencing pointer to incomplete type
IMG_png.c:478:30: error: dereferencing pointer to incomplete type
IMG_png.c:479:23: error: dereferencing pointer to incomplete type
IMG_png.c:480:38: error: dereferencing pointer to incomplete type
IMG_png.c:481:38: error: dereferencing pointer to incomplete type
IMG_png.c:482:38: error: dereferencing pointer to incomplete type
make: *** [IMG_png.lo] Error 1
On 2011-02-16 16:11:05 +0000, Mikael Eriksson wrote:
Created attachment 575
libpng 1.5 supportThe attached patch makes it build with libpng 1.5. I have also verified that it still works with libpng 1.4.
On 2011-02-16 16:26:09 +0000, Sam Lantinga wrote:
Have you tried SDL_image from Mercurial?
hg clone http://hg.libsdl.org/SDL_image
On 2011-02-16 16:46:26 +0000, Mikael Eriksson wrote:
The hg tip compiles fine. Guess I should have checked that before writing the patch.
On 2011-02-16 17:18:40 +0000, Sam Lantinga wrote:
Okay, thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2009-07-07 03:35:39 +0000, Luca Bigliardi wrote:
Created attachment 338
patch to add pkg-config for SDL_imageHi,
I'm attaching two patches to add pkg-config support to SDL_image.pkg-config is used to retrieve information about installed libraries and
it's well integrated with build configurators (for instance
PKG_CHECK_MODULES autoconf macro).Thank you,
Luca
On 2009-08-07 03:08:22 +0000, Sam Lantinga wrote:
Committed to subversion with revision 4670
Thanks!
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: Android (All), ARM
On 2012-01-03 07:25:10 +0000, pelya wrote:
Created attachment 760
A patch to fix thatWhen compiled with SDL 1.3, the SDL_Image library cannot load monochrome .PNG images.
An example of such image: http://imagebin.org/191575
On 2012-01-03 18:38:51 +0000, Sam Lantinga wrote:
Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/b51a5e14a456
These attachments are available in the static archive:
Reported in version: 1.2.6
Reported for operating system, platform: Windows (CE)/PocketPC, x86
On 2009-05-05 11:59:42 +0000, mosfet wrote:
Pocket PC Visual Project
On 2009-05-05 12:01:59 +0000, mosfet wrote:
Created attachment 325
Pocket PC Project
On 2009-10-02 05:36:45 +0000, Sam Lantinga wrote:
This has been added for the next release, thanks!
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: Windows 7, x86
On 2010-10-25 07:43:30 +0000, Cannon wrote:
Created attachment 543
this conatins the complied binary and the source codewe have this program set up where every left click adds a ball and loads an image to the screen, they bounce around etc.
a right click deletes all the balls, however the memory footprint stays the same
have attached my project, the file classexamp.exe under Debug\bin should run and the behavior above should existwe tried many things including explicitly calling the deconstructor and memory still wont fall
the functions that are called to create/destroy are in ball.h/ball.cpp (the Ball class )
anything further need please ask
On 2011-02-17 13:13:58 +0000, Sam Lantinga wrote:
That is a pretty cool demo!
How are you detecting the memory usage? It's possible that the OS is committing memory pages on behalf of your application and then not releasing them even though the memory has actually been freed.
I ran the test here, creating 200 balls and then deleting them, and the allocation counts seem correct:
First start:
Process 22374: 12314 nodes malloced for 9425 KBAfter 200 balls created:
Process 22374: 13133 nodes malloced for 10986 KBAfter the balls are deleted:
Process 22374: 12303 nodes malloced for 9438 KBI ran this test on Mac OS X and used the "leaks" tool to detect memory leaks.
Cheers!
On 2011-12-31 09:33:48 +0000, Sam Lantinga wrote:
No response in over a year.
Reported in version: unspecified
Reported for operating system, platform: Other, Other
On 2009-06-14 22:05:14 +0000, Satya Surya Kiran Kumar wrote:
Hi
I am trying to load bmp images using SDL. I am trying to load png & jpg images for symbian O.S. Can any body please help me out how to configure "SDL_Image" for s60 symbian (using carbide c++).
Thanks in advance.
On 2009-09-26 02:13:04 +0000, Sam Lantinga wrote:
This is a good question for the SDL forums:
http://forums.libsdl.org/
Reported in version: unspecified
Reported for operating system, platform: Haiku, x86
On 2012-01-03 16:12:04 +0000, Scott McCreary wrote:
/boot/develop/haikuports/media-libs/sdl-image/work/sdl-image-1.2-hg> make
source='IMG_ImageIO.m' object='IMG_ImageIO.lo' libtool=yes
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp
/bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.11" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff.so.3" -DLOAD_PNG_DYNAMIC="libpng.so.1.4" -I. -I/boot/common/include/libpng15 -g -O2 -I/boot/common/include/SDL -D_GNU_SOURCE=1 -c -o IMG_ImageIO.lo IMG_ImageIO.m
libtool: compile: gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.11" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff.so.3" -DLOAD_PNG_DYNAMIC="libpng.so.1.4" -I. -I/boot/common/include/libpng15 -g -O2 -I/boot/common/include/SDL -D_GNU_SOURCE=1 -c IMG_ImageIO.m -Wp,-MD,.deps/IMG_ImageIO.TPlo -DPIC -o .libs/IMG_ImageIO.o
gcc: IMG_ImageIO.m: Objective-C compiler not installed on this system
make: *** [IMG_ImageIO.lo] Error 1
On 2012-01-03 19:15:01 +0000, Sam Lantinga wrote:
Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/66fc2d8ddfbc
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2007-05-11 15:14:18 +0000, Patrice Mandin wrote:
SDL_image' configure.in script assumes that zlib library is in the default compiler path. It may not be the case if zlib has been compiled by the user and/or installed to a different location.
The autoconf macro archive contains the CHECK_ZLIB macro to allow the user to specify the path to zlib (--with-zlib=, --without-zlib).
http://autoconf-archive.cryp.to/autoconf-archive-2007-05-10.tar.bz2
On 2007-07-12 20:52:35 +0000, Sam Lantinga wrote:
This has been added to SDL_image in revision 3243. Thanks!
On 2007-07-19 21:34:57 +0000, Sam Lantinga wrote:
The CHECK_ZLIB wasn't able to detect cross-compiled libz.
From the new SDL_image README:
If you have these libraries installed in non-standard places, you can
try adding those paths to the configure script, e.g.
sh ./configure CPPFLAGS="-I/somewhere/include" LDFLAGS="-L/somewhere/lib"
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2012-01-20 11:03:07 +0000, wrote:
After upgrade to the recent sdl_image 1.2.11, pygame.image reports error on img.get_palette():
import pygame
img = pygame.image.load('/usr/share/solarwolf/data/fire.png')
pal = img.get_palette()
Traceback (most recent call last):
File "", line 1, in
error: Surface has no palette to getAs a result the game solarwolf is no longer playable.
On 2012-01-20 17:05:09 +0000, Sam Lantinga wrote:
This is fixed in 1.2.12 which is being released shortly.
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: All, All
On 2011-08-07 00:19:51 +0000, Joshua Beck wrote:
Created attachment 669
Patch that fixes the memory leaks against current hgcppcheck found these errors in SDL_image:
[IMG_xpm.c:262]: (error) Common realloc mistake: 'linebuf' nulled but not freed upon failure
[IMG_xpm.c:280]: (error) Common realloc mistake: 'linebuf' nulled but not freed upon failure
[IMG_xpm.c:127]: (error) Memory leak: hash.tableThe included patch fixes all of them.
On 2011-08-09 16:28:01 +0000, Joshua Beck wrote:
Created attachment 672
Patch that fixes the memory leaks against current hg, and compiles
On 2011-08-24 23:25:14 +0000, Ryan C. Gordon wrote:
This patch is now hg changeset bb611e7cb1e5, thanks!
--ryan.
These attachments are available in the static archive:
Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86_64
On 2011-06-24 00:41:23 +0000, Mike wrote:
Created attachment 633
Test programCGDataProviderRef must be cleaned after usage.
Here is a proposed patch:
{{{
diff -r b1c1ec3a8d49 IMG_ImageIO.c
--- a/IMG_ImageIO.c Thu Apr 07 07:50:52 2011 -0700
+++ b/IMG_ImageIO.c Fri Jun 24 13:45:18 2011 +0700
@@ -103,6 +103,7 @@
// Get the CGImageSourceRef.
// The dictionary can be NULL or contain hints to help ImageIO figure out the image type.
source_ref = CGImageSourceCreateWithDataProvider(data_provider, hints_and_options);
- CGDataProviderRelease(data_provider);
return source_ref;
}}}}
Attached are test program and valgrind's logfiles
On 2011-06-24 00:44:42 +0000, Mike wrote:
Created attachment 634
valgrind logfile - on current (1.2.10) version
On 2011-06-24 00:45:23 +0000, Mike wrote:
Created attachment 635
valgrind logfile for patched libSDL_image
On 2011-12-31 09:39:09 +0000, Sam Lantinga wrote:
Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/ec183abd5996
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
On 2008-06-06 11:48:45 +0000, Matt Turner wrote:
Quite a few functions in SDL_image can be marked as static, AFAICS. Such functions are IMG_Init* and IMG_Quit* functions.
On 2008-06-06 11:49:16 +0000, Matt Turner wrote:
Created attachment 255
patch to mark said functions static
On 2008-08-01 19:06:11 +0000, Matt Turner wrote:
Uhh, any reason this hasn't been applied yet? It's a simple patch.
On 2009-09-26 01:54:32 +0000, Sam Lantinga wrote:
Nope, this has been applied for the next release.
Thanks!
Reported in version: unspecified
Reported for operating system, platform: Windows (All), All
On 2009-06-10 06:26:21 +0000, Mason Wheeler wrote:
This patch will allow PNG files to be saved.
Index: IMG_png.c
--- IMG_png.c (revision 4475)
+++ IMG_png.c (working copy)
@@ -76,17 +76,26 @@
png_infop (*png_create_info_struct) (png_structp png_ptr);
png_structp (*png_create_read_struct) (png_const_charp user_png_ver, png_voidp error_ptr, png_error_ptr error_fn, png_error_ptr warn_fn);
void (*png_destroy_read_struct) (png_structpp png_ptr_ptr, png_infopp info_ptr_ptr, png_infopp end_info_ptr_ptr);
- png_structp (*png_create_write_struct) (png_const_charp user_png_ver, png_voidp error_ptr, png_error_ptr error_fn, png_error_ptr warn_fn);
- void (*png_destroy_write_struct) (png_structpp png_ptr_ptr, png_infopp info_ptr_ptr);
png_uint_32 (*png_get_IHDR) (png_structp png_ptr, png_infop info_ptr, png_uint_32 *width, png_uint_32 *height, int *bit_depth, int *color_type, int *interlace_method, int *compression_method, int *filter_method);- void (*png_set_IHDR) (png_structp png_ptr, png_infop info_ptr, png_uint_32 width, png_uint_32 height, int bit_depth, int color_type, int interlace_method, int compression_method, int filter_method);
png_voidp (*png_get_io_ptr) (png_structp png_ptr);
png_uint_32 (*png_get_tRNS) (png_structp png_ptr, png_infop info_ptr, png_bytep *trans, int *num_trans, png_color_16p *trans_values);
png_uint_32 (*png_get_valid) (png_structp png_ptr, png_infop info_ptr, png_uint_32 flag);
void (*png_read_image) (png_structp png_ptr, png_bytepp image);- void (*png_write_image) (png_structp png_ptr, png_bytepp image);
void (*png_read_info) (png_structp png_ptr, png_infop info_ptr);- void (*png_write_info) (png_structp png_ptr, png_infop info_ptr);
- void (*png_set_PLTE) (png_structp png_ptr, png_infop info_ptr, png_colorp palette, int num_palette);
- void (*png_write_end) (png_structp png_ptr, png_infop info_ptr);
void (*png_read_update_info) (png_structp png_ptr, png_infop info_ptr);
void (*png_set_expand) (png_structp png_ptr);
void (*png_set_gray_to_rgb) (png_structp png_ptr);- void (*png_set_bgr) (png_structp png_ptr);
void (*png_set_packing) (png_structp png_ptr);
void (*png_set_read_fn) (png_structp png_ptr, png_voidp io_ptr, png_rw_ptr read_data_fn);- void (*png_set_write_fn) (png_structp png_ptr, png_voidp io_ptr, png_rw_ptr read_data_fn);
void (*png_set_strip_16) (png_structp png_ptr);
int (*png_sig_cmp) (png_bytep sig, png_size_t start, png_size_t num_to_check);
} lib;
@@ -120,6 +129,20 @@
SDL_UnloadObject(lib.handle);
return -1;
}lib.png_create_write_struct =
(png_structp (*) (png_const_charp, png_voidp, png_error_ptr, png_error_ptr))
SDL_LoadFunction(lib.handle, "png_create_write_struct");
if ( lib.png_create_write_struct == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_destroy_write_struct =
(void (*) (png_structpp, png_infopp))
SDL_LoadFunction(lib.handle, "png_destroy_write_struct");
if ( lib.png_destroy_write_struct == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_get_IHDR = (png_uint_32 (*) (png_structp, png_infop, png_uint_32 *, png_uint_32 *, int *, int *, int *, int *, int *)) SDL_LoadFunction(lib.handle, "png_get_IHDR");
@@ -127,6 +150,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_set_IHDR =
(void (*) (png_structp, png_infop, png_uint_32, png_uint_32, int, int, int, int, int))
SDL_LoadFunction(lib.handle, "png_set_IHDR");
if ( lib.png_set_IHDR == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_get_io_ptr = (png_voidp (*) (png_structp)) SDL_LoadFunction(lib.handle, "png_get_io_ptr");
@@ -155,6 +185,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_write_image =
(void (*) (png_structp, png_bytepp))
SDL_LoadFunction(lib.handle, "png_write_image");
if ( lib.png_write_image == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_read_info = (void (*) (png_structp, png_infop)) SDL_LoadFunction(lib.handle, "png_read_info");
@@ -162,6 +199,27 @@
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_write_info =
(void (*) (png_structp, png_infop))
SDL_LoadFunction(lib.handle, "png_write_info");
if ( lib.png_write_info == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_set_PLTE =
(void (*) (png_structp, png_infop, png_colorp, int))
SDL_LoadFunction(lib.handle, "png_set_PLTE");
if ( lib.png_set_PLTE == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_write_end =
(void (*) (png_structp, png_infop))
SDL_LoadFunction(lib.handle, "png_write_end");
if ( lib.png_write_end == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_read_update_info = (void (*) (png_structp, png_infop)) SDL_LoadFunction(lib.handle, "png_read_update_info");
@@ -183,6 +241,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_set_bgr =
(void (*) (png_structp))
SDL_LoadFunction(lib.handle, "png_set_bgr");
if ( lib.png_set_bgr == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_set_packing = (void (*) (png_structp)) SDL_LoadFunction(lib.handle, "png_set_packing");
@@ -197,6 +262,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}
lib.png_set_write_fn =
(void (*) (png_structp, png_voidp, png_rw_ptr))
SDL_LoadFunction(lib.handle, "png_set_write_fn");
if ( lib.png_set_write_fn == NULL ) {
SDL_UnloadObject(lib.handle);
return -1;
} lib.png_set_strip_16 = (void (*) (png_structp)) SDL_LoadFunction(lib.handle, "png_set_strip_16");
@@ -505,6 +577,171 @@
return(surface);
}+static void png_write_data(png_structp ctx, png_bytep area, png_size_t size)
+{
- SDL_RWops *src;
- src = (SDL_RWops *)lib.png_get_io_ptr(ctx);
- SDL_RWwrite(src, area, size, 1);
+}
+/* write a png file */
+int IMG_SavePNG_RW(SDL_Surface *surface, SDL_RWops *src)
+{- png_structp png_ptr;
- png_infop info_ptr;
- png_colorp palette = NULL;
- int start;
- int colorType;
- int i;
- const char *error = NULL;
- SDL_Palette *sdlPalette;
- png_uint_32 height = surface->h;
- png_uint_32 width = surface->w;
- png_bytep *volatile row_pointers;
- int row;
- if ( !src ) {
/* The error message has been set in SDL_RWFromFile */
return -1;
- }
- start = SDL_RWtell(src);
- if ( IMG_InitPNG() < 0 ) {
return -1;
- }
- /* Create and initialize the png_struct with the desired error handler
- functions. If you want to use the default stderr and longjump method,
- you can supply NULL for the last three parameters. We also check that
- the library version is compatible with the one used at compile time,
- in case we are using dynamically linked libraries. REQUIRED.
- */
- png_ptr = NULL; info_ptr = NULL;
- /* Create the PNG loading context structure */
- png_ptr = lib.png_create_read_struct(PNG_LIBPNG_VER_STRING,
NULL,NULL,NULL);
- if (png_ptr == NULL){
error = "Couldn't allocate memory for PNG file or incompatible PNG dll";
goto done;
- }
- /* Allocate/initialize the memory for image information. REQUIRED. */
- info_ptr = lib.png_create_info_struct(png_ptr);
- if (info_ptr == NULL) {
error = "Couldn't create image information for PNG file";
goto done;
- }
- /* Set error handling if you are using setjmp/longjmp method (this is
- the normal method of doing things with libpng). REQUIRED unless you
- set up your own error handlers in png_create_read_struct() earlier.
- */
- if ( setjmp(png_ptr->jmpbuf) ) {
error = "Error reading the PNG file.";
goto done;
- }
- /* Set up the output control */
- lib.png_set_write_fn(png_ptr, src, png_write_data);
- /* Set the image information here. Width and height are up to 2^31,
* bit_depth is one of 1, 2, 4, 8, or 16, but valid values also depend on
* the color_type selected. color_type is one of PNG_COLOR_TYPE_GRAY,
* PNG_COLOR_TYPE_GRAY_ALPHA, PNG_COLOR_TYPE_PALETTE, PNG_COLOR_TYPE_RGB,
* or PNG_COLOR_TYPE_RGB_ALPHA. interlace is either PNG_INTERLACE_NONE or
* PNG_INTERLACE_ADAM7, and the compression_type and filter_type MUST
* currently be PNG_COMPRESSION_TYPE_BASE and PNG_FILTER_TYPE_BASE. REQUIRED
*/
- sdlPalette = surface->format->palette;
- if (sdlPalette)
- {
colorType = PNG_COLOR_TYPE_PALETTE;
- } else if (surface->format->Amask)
- {
colorType = PNG_COLOR_TYPE_RGB_ALPHA;
- } else
- {
colorType = PNG_COLOR_TYPE_RGB;
- }
- lib.png_set_IHDR(png_ptr, info_ptr, surface->w, surface->h, surface->format->BitsPerPixel, colorType,
PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
- /* set the palette if there is one. REQUIRED for indexed-color images */
- if (colorType == PNG_COLOR_TYPE_PALETTE)
- {
palette = (png_colorp) malloc(sdlPalette->ncolors * sizeof(png_color));
for( i=0; i < sdlPalette->ncolors; ++i ) {
palette[i].blue = sdlPalette->colors[i].b;
palette[i].green = sdlPalette->colors[i].g;
palette[i].red = sdlPalette->colors[i].r;
}
lib.png_set_PLTE(png_ptr, info_ptr, palette, sdlPalette->ncolors);
- }
- else
- { //not sure how to handle this
+// sig_bit.red = true_red_bit_depth;
+// sig_bit.green = true_green_bit_depth;
+// sig_bit.blue = true_blue_bit_depth;/* if the image has an alpha channel then */
+// sig_bit.alpha = true_alpha_bit_depth;
+// png_set_sBIT(png_ptr, info_ptr, sig_bit);
- }
- lib.png_set_bgr(png_ptr);
- /* Write the file header information. REQUIRED */
- lib.png_write_info(png_ptr, info_ptr);
- /* The easiest way to write the image (you may have a different memory
* layout, however, so choose what fits your needs best). You need to
* use the first method if you aren't handling interlacing yourself.
*/
- row_pointers = (png_bytep*) malloc(sizeof(png_bytep)*height);
- if ( (row_pointers == NULL) ) {
error = "Out of memory";
goto done;
- }
- for (row = 0; row < (int)height; row++) {
row_pointers[row] = (png_bytep)
(Uint8 *)surface->pixels + row*surface->pitch;
- }
- if (height > PNG_UINT_32_MAX/sizeof(png_bytep))
- {
error = "Image is too tall to process in memory";
goto done;
- }
- /* Read the entire image in one go */
- lib.png_write_image(png_ptr, row_pointers);
- /* It is REQUIRED to call this to finish writing the rest of the file */
- lib.png_write_end(png_ptr, info_ptr);
+done: /* Clean up and return */
- if ( png_ptr ) {
lib.png_destroy_write_struct(&png_ptr, &info_ptr);
- }
- if ( row_pointers ) {
free(row_pointers);
- }
- if (palette)
- {
free(palette);
- }
- if ( error ) {
IMG_QuitPNG();
IMG_SetError(error);
return(-1);
- } else {
IMG_QuitPNG();
- }
- return(0);
+}#else
/* See if an image is contained in a data source */
Index: SDL_image.h--- SDL_image.h (revision 4475)
+++ SDL_image.h (working copy)
@@ -107,6 +107,8 @@extern DECLSPEC SDL_Surface * SDLCALL IMG_ReadXPMFromArray(char **xpm);
+extern DECLSPEC int SDLCALL IMG_SavePNG_RW(SDL_Surface *surface, SDL_RWops src);
+
/ We'll use SDL for reporting errors */
#define IMG_SetError SDL_SetError
#define IMG_GetError SDL_GetError
On 2012-02-01 11:57:57 +0000, Rodrigo Cardoso wrote:
Will this patch be added?
Since plain SDL have Save BMP I think this patch for SDL_image makes much sense.
On 2013-06-03 01:32:23 +0000, Sam Lantinga wrote:
I added a separate implementation based on miniz.c by Rich Geldreich, which doesn't require libpng, so it's always available.
http://hg.libsdl.org/SDL_image/rev/cf211e9ff224Cheers!
Reported in version: 1.2.12
Reported for operating system, platform: Windows 7, x86
On 2012-04-27 14:18:14 +0000, Pere wrote:
Hi, at Tux Paint there is this bug report [1], a quick test with fopen(fname, "r")) goes right, so the images are accesible at the path described by fname.
An additional test is -with the file manager inside W7- to drag a image over showimage.exe, the results are that the image only displays if the chars of the path to the image are all ASCII.
[1] http://sourceforge.net/tracker/?func=detail&aid=3473049&group_id=66938&atid=516295
On 2012-05-24 13:54:03 +0000, Pere wrote:
Well, I followed the trace of the filaname passed to IMG_Load() up to the win32_file_open() function in the SDL-1.2.15/src/file/SDL_rwops.c file, it is unchanged untill arriving there, then it is recoded in this function, thus changing the path and avoiding to load the file.
If in win32_file_open() I force the use of filename as it is passed to the function ( h = CreateFile(filename, (w_right|r_right).....) instead of the recoded filenameW (h = CreateFileW(filenameW, (w_right|r_right), .....), then it loads right the images with non ascii chars on their path.
I don't provide a patch as I don't know enouth the code to understand what side effects this change can have.
Hope this helps
Pere
Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86_64
On 2013-01-01 04:24:01 +0000, wrote:
The configure script for my mingw setup failed due to the issue that "sdl-config" is missing.
SDL 2 only sets the SDL2-config. Although its probably only temporary ( is it? ), it will be helpful to provide an SDL2 compatible makefile.
On 2013-06-03 01:51:40 +0000, Sam Lantinga wrote:
This is fixed with the SDL_image 2.0 release candidate:
http://www.libsdl.org/tmp/SDL_image/
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
On 2011-06-12 10:17:31 +0000, Dimitris Zenios wrote:
When building SDL_Image with mingw libjpeg-8 header files define SDL_TRUE,SDL_FALSE and SDL_boolean.The problem though occurs when building with gcc in linux where this flags are not defined in jpeglib
On 2011-06-12 10:18:12 +0000, Dimitris Zenios wrote:
Created attachment 622
fixes the bug
On 2011-08-10 11:30:15 +0000, Scott McCreary wrote:
Attached patch by Dimitris fixes this isssue on Haiku as well.
+1
On 2011-10-04 21:48:48 +0000, Ryan C. Gordon wrote:
This is now hg changeset a5d4daece235, thanks!
--ryan.
Reported in version: 1.2.9
Reported for operating system, platform: Linux, x86_64
On 2009-11-14 09:36:36 +0000, federico wrote:
I'm working on Gentoo Linux.
With version 1.2.9 (and only with it) IMG_Load() works correctly for the first two/three images and then starts to return NULL pointers.
Even the bundled showimage program has this problem if you give it multiple files as input.
I cannot confirm the bug on other systems.
On 2009-11-14 11:52:32 +0000, Sam Lantinga wrote:
This is fixed in subversion and I'm working on a 1.2.10 release.
Thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), All
On 2009-10-29 08:06:06 +0000, Vittorio Giovara wrote:
starting from 1.2.14 with the new ImageIO backend, some images (we use pngs) have problems in setting the alpha channel correctly. The surface is loaded and converted correctly, as the colors match the ones in the other OSes, but when blending an alpha area, the alpha color is completely ignored.
here is the correct behaviour (1.2.13) -> http://dl.getdropbox.com/u/24468/screen-capture1.png
here is the (weird) behaviour (1.2.14 and 1.3) -> http://dl.getdropbox.com/u/24468/screen-capture2.png
here is a (normal) behaviour with red as alpha color -> http://dl.getdropbox.com/u/24468/screen-capture3.png
we have a strong suspect that one area might be doing ABGR, and the other area expecting the alpha to be the last byte and reading the R as an A.
On 2009-10-29 08:06:58 +0000, Vittorio Giovara wrote:
Created attachment 435
correct behaviour (1.2.13)
On 2009-10-29 08:09:16 +0000, Vittorio Giovara wrote:
Created attachment 436
wrong behaviour (1.2.14 + 1,3)
On 2009-10-29 08:10:41 +0000, Vittorio Giovara wrote:
Created attachment 437
correct behaviour with background red channel as alpha
On 2009-10-29 08:33:45 +0000, Vittorio Giovara wrote:
Created attachment 438
another (more evident) screenshot of the wrong behaviour
On 2009-10-29 09:13:05 +0000, Sam Lantinga wrote:
Are you able to reproduce this with showimage, or is this a problem in your application?
There were a few color issues in some games that turned out to be the game assuming the order of the RGB channels, but once they started checking the masks in the screen->format, everything was fine.
On 2009-10-29 10:30:50 +0000, Vittorio Giovara wrote:
(In reply to comment # 5)
Are you able to reproduce this with showimage, or is this a problem in your
application?There were a few color issues in some games that turned out to be the game
assuming the order of the RGB channels, but once they started checking the
masks in the screen->format, everything was fine.We're quite sure that the order of the channels are correct because the other images are displayed correctly -- the problem only arise when images with alpha are blended.
a similar issue was found here http://forums.libsdl.org/viewtopic.php?p=19729 where opacity is applied in two different ways on OSX and win.
btw our application is located at http://www.hedgewars.org/ and you can read the source here http://fireforge.net/scm/viewvc.php/trunk/hedgewars/?root=hedgewars (the IMG_Load is in uStore.pas)
On 2009-10-29 13:13:06 +0000, Vittorio Giovara wrote:
hm we noticed that by stripping color profiles from the png helped with the background image.
perhaps our theory was wrong, but does sdlimage handles color profiles correcly in the new backend?
On 2009-10-29 13:47:03 +0000, Vittorio Giovara wrote:
Ok, dumping the first column of a buggy SDL surface, we noticed an interesting pattern:
A B G R
SDL on OSX
206 | 177 | 131 | 125GIMP
206 | 220 | 163 | 155SDL on OSX
14 | 8 | 5 | 4GIMP
14 | 157 | 92 | 84Pattern seems to be that if you take:
177 * (255/206) ~ 219and
8 * (255/14) ~ 146Now, that 2nd one is not so accurate. But.
157 / (255 / 14) = 8.58 which if truncated is 8.220 / (255 / 206) = 177.72 = 177
So we could be dealing with some curious modification proportional to alpha and a floor operation to boot.
Fortunately the fix for that is fairly trivial, until SDL is fixed, we can ifdef DARWIN to reverse the damage.
The truncation means some accuracy is lost, but hopefully not too much.
On 2009-10-29 21:03:12 +0000, Sam Lantinga wrote:
From nemo:
Hey. Turns out the problem was a bit weirder than someone simply messing up RGBA vs ABGR.
http://forums.libsdl.org/viewtopic.php?p=20011# 20011
On 2009-10-29 21:55:37 +0000, Sam Lantinga wrote:
Eric, can you look into this?
On 2009-11-09 19:45:09 +0000, Vittorio Giovara wrote:
is there any update on this?
in the meantime i have updated the workaround code{$IFDEF DARWIN}
tmpP := tmpsurf^.pixels;
for i:= 0 to (tmpsurf^.pitch shr 2) * tmpsurf^.h - 1 do
begin
{$IFDEF ENDIAN_LITTLE}
tmpA:= tmpP^[i] shr 24 and $FF;
tmpR:= tmpP^[i] shr 16 and $FF;
tmpG:= tmpP^[i] shr 8 and $FF;
tmpB:= tmpP^[i] and $FF;
{$ELSE}
tmpA:= tmpP^[i] and $FF;
tmpR:= tmpP^[i] shr 8 and $FF;
tmpG:= tmpP^[i] shr 16 and $FF;
tmpB:= tmpP^[i] shr 24 and $FF;
{$ENDIF}
if tmpA <> 0 then
begin
tmpR:= round(tmpR * 255/tmpA);
tmpG:= round(tmpG * 255/tmpA);
tmpB:= round(tmpB * 255/tmpA);
end;if tmpR > 255 then tmpR:= 255; if tmpG > 255 then tmpG:= 255; if tmpB > 255 then tmpB:= 255;
{$IFDEF ENDIAN_LITTLE}
tmpP^[i]:= (tmpA shl 24) or (tmpR shl 16) or (tmpG shl 8) or tmpB;
{$ELSE}
tmpP^[i]:= (tmpA) or (tmpR shl 8) or (tmpG shl 16) or (tmpB shl 24);
{$ENDIF}
end;
{$ENDIF}
On 2009-11-09 20:38:05 +0000, Sam Lantinga wrote:
Oh, it looks like Mac OS X is just pre-multiplying the alpha. Thanks for the great workaround code!
On 2009-11-09 20:40:13 +0000, Sam Lantinga wrote:
And of course looking at the code, I see we're explicitly asking for that with kCGImageAlphaPremultipliedFirst.
On 2009-11-09 22:02:11 +0000, Sam Lantinga wrote:
It turns out that ImageIO only supports pre-multiplied alpha output. Ugh.
http://lists.apple.com/archives/mac-opengl/2007/may/msg00056.html
On 2009-11-09 23:33:52 +0000, Sam Lantinga wrote:
Out of curiosity, what does your workaround do to this image?
http://www.w3.org/Graphics/PNG/alphatest.png
On 2009-11-10 00:45:42 +0000, Sam Lantinga wrote:
Nevermind, this is fixed now, thanks!
http://www.libsdl.org/tmp/SDL_image/SDL_image-1.2.9.tar.gz
On 2009-11-10 10:24:36 +0000, Vittorio Giovara wrote:
ok now it works fine, thanks!
there is just one thing that worries me is that by looking at the code
Uint8 *p = (Uint8 *)surface->pixels;
Uint8 A = p[3];
so we are using 8 bits for Alpha, 8 for Red, 8 for Green and 8 for Blue; then we make a division and save it on an eight bit variableif the result of the operation is something like 99.99 then the result stored would be 99, truncating the .99, making the color a little darker -- not noticable -- but different from an alpha-free surface; every computation on color value would be likely to fail with this code.
What do you think of this possibility?
On 2009-11-10 13:11:28 +0000, Vittorio Giovara wrote:
PowerPC loading is broken
normal pngs work fine but pngs with alpha segfault
showimage's output isshowimage(52993) malloc: *** error for object 0x837200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug(attached BlueWater.png)
On 2009-11-10 13:12:27 +0000, Vittorio Giovara wrote:
Created attachment 448
test image used in showimage to test ppc code
On 2009-11-10 23:09:44 +0000, Sam Lantinga wrote:
The crash is fixed, thanks!
As for the inaccuracy in the multiplication, we might be able to solve it by using 256 instead of 255, although that might break things the other direction.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
On 2012-01-17 22:46:56 +0000, wrote:
see https://bugs.mageia.org/show_bug.cgi?id=4175
i fear this may have been the problematic change: (unsure)
http://hg.libsdl.org/SDL_image/rev/ea460af4ceff
On 2012-01-18 04:53:50 +0000, Sam Lantinga wrote:
Created attachment 781
Sample imageAL13N
i think this is the one
On 2012-01-18 14:21:26 +0000, wrote:
Created attachment 785
SDL_image-1.2.11-png_channels.patchwhen looking a the differences between a patch we carried in the 1.2.10 and the 1.2.11; i noted a difference in it, and after fixing that, it seemed to work.
since this is about a 256c png image it should be 1byte, not 3, thus this solves it for me.
thanks alot of the assistance. since i'm a mageia packager, i'm adding the patch to our SDL_image build.
On 2012-01-19 20:20:17 +0000, Sam Lantinga wrote:
Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/7036dd36a22f
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2007-03-04 13:15:42 +0000, Dennis Payne wrote:
I found some images used in a Bard's Tale Construction Set game that don't load properly. When the LBM is a packed bitmap the number of planes are set to one. This causes the number of colors in the palette to be set to 2. Here is a patch to fix the problem. I think it is correct but I don't have a lot of LBM files to test with. Some broken LBMs can be found in Bard's Lore I found at http://bardstale.brotherhood.de/talefiles/cs/files/index.html
--- IMG_lbm.c.orig 2007-03-04 15:56:51.000000000 -0500
+++ IMG_lbm.c 2007-03-04 15:58:45.000000000 -0500
@@ -297,7 +297,8 @@
Image->format->palette->colors[i].g = Image->format->palette->colors[i%nbcolors].g;
Image->format->palette->colors[i].b = Image->format->palette->colors[i%nbcolors].b;
}
Image->format->palette->ncolors = nbrcolorsfinal;
if ( !pbm )
Image->format->palette->ncolors = nbrcolorsfinal;
}
/* Get the bitmap */
On 2007-07-12 20:21:52 +0000, Sam Lantinga wrote:
Can you attach a sample image?
On 2007-07-14 10:51:44 +0000, Sam Lantinga wrote:
Created attachment 226
sample image contributed by dulsi
On 2007-07-19 21:38:44 +0000, Sam Lantinga wrote:
I tried contacting the author of the previous patch that introduced this bug, but got no response.
Unless someone comes up with a problem with this, I'm checking this in as subversion revision 3341
Thanks!
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: All, All
On 2012-05-23 08:57:54 +0000, pelya wrote:
Created attachment 860
2-color grayscale PNGBranch default, rev. 330:1230766039be
SDL_image will fail when trying to load the PNG file I've attached, it's in 2-color grayscale format.I remember opening a very similar bug a while ago.
On 2012-05-25 11:04:24 +0000, Adam Olsen wrote:
Created attachment 861
8-bit greyscaleHere's an 8-bit greyscale that SDL_image also fails to load (reports "Out of memory").
SDL1.3 trunk of a few weeks ago, SDL_image trunk of today.
On 2012-05-25 11:47:57 +0000, Adam Olsen wrote:
I poked around and SDL_MasksToPixelFormatEnum only supports INDEX8 and RGB332, which isn't what IMG_LoadPNG_RW is asking for.
I'm not sure what the solution is here. I don't see any greyscale formats listed in SDL_PIXELFORMAT_*. Maybe the easiest is to pretend it's 8-bit indexed but with a no-op palette that can be ignored?
On 2013-03-06 10:05:16 +0000, q66 wrote:
Created attachment 1058
bug 1503 fixHello, just attaching a fix here (by Lee "eihrul" Salzman) to make it noticed :)
DK
On 2013-03-10 14:26:05 +0000, q66 wrote:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.