Hi,
Are there any plans to enhance SDL_Image to save images to disk?
It would be really useful if it could save PNG (and possibly JPEG and BMP, but
mostly PNG) from a surface or specified memory location or something like that.
Any chance this would ever be implemented?
Sincerely
Hi,
Are there any plans to enhance SDL_Image to save images to disk?
Probably not in SDL_Image, because it would add a bloat
(small amount, at least), that most people wouldn’t take advantage of.
It would be really useful if it could save PNG (and possibly JPEG
and BMP, but mostly PNG) from a surface or specified memory location
or something like that.
I wrote a function in Tux Paint to export to PNG, using the libPNG functions.
It wasn’t very hard, I just followed the libPNG instructions. 
-bill!
bill at newbreedsoftware.com April shower bring Kompressor power!
http://newbreedsoftware.com/On Tue, Jan 18, 2005 at 02:04:39AM +0000, Damian wrote:
Damian wrote:
Hi,
Are there any plans to enhance SDL_Image to save images to disk?
I’ve asked the same thing, and never gotten an answer.
I’ve even written the code (http://burningsmell.dyndns.org/xtopng/) to
add PNG saving to SDL_Image, but never heard if it could be included in
the main package.
-Philip D. Bober
Are there any plans to enhance SDL_Image to save images to disk?
I’ve asked the same thing, and never gotten an answer.
I’ve even written the code (http://burningsmell.dyndns.org/xtopng/) to
add PNG saving to SDL_Image, but never heard if it could be included in
the main package.
It needs work. In your “src” directory, I get nothing from this:
egrep -i ‘srgb|gamma|linear’ *.cOn Tue, 2005-01-18 at 10:12, Philip D. Bober wrote:
Albert Cahalan wrote:
It needs work. In your “src” directory, I get nothing from this:
egrep -i ‘srgb|gamma|linear’ *.c
SDL doesn’t store per-surface gamma info, so I thought no metadata is
better than wrong metadata.
-Philip D. Bober
Yes, no metadata is better than wrong metadata.
While SDL is wrong to not handle per-surface gamma,
you can work around this by adding a flag argument.
You only need two values: sRGB and linear. You can
make that be 5 if you include all 4 sRGB rendering
intents.
For normal sRGB, do this:
png_set_sRGB_gAMA_and_cHRM(png_ptr, info_ptr, PNG_sRGB_INTENT_PERCEPTUAL);
(do NOT set gamma==2.2; this is wrong)
For linear, supply a gamma==1.0 value.
BTW, it appears that SDL is really clueless about gamma.
Data goes directly to screen, implying that sRGB is used.
Data is linearly alpha-blended, implying that linear RGB
is used. Well, data can’t be both sRGB and linear RGB.
I see this as ugly dark outlines around alpha-blended
objects. Try a fuzzy line in Tux Paint, using yellow and
blue. (yellow on blue, or blue on yellow) I’d naturally
go for sRGB 0…255 with 8-bit unsigned channels, and for
linear RGB 0…1 with 32-bit float channels. Tux Paint has
some fast conversion tables if you need them, with 12-bit
accuracy going from linear RGB to sRGB.On Tue, 2005-01-18 at 12:12, Philip D. Bober wrote:
Albert Cahalan wrote:
It needs work. In your “src” directory, I get nothing from this:
egrep -i ‘srgb|gamma|linear’ *.c
SDL doesn’t store per-surface gamma info, so I thought no metadata is
better than wrong metadata.
Bill Kendrick <nbs sonic.net> writes:
Are there any plans to enhance SDL_Image to save images to disk?
Probably not in SDL_Image, because it would add a bloat
(small amount, at least), that most people wouldn’t take advantage of.
I don’t see why not. The neccessary libraries (libjpeg/libpng) are already used
by SDL_Image to load those formats, and the actual saving routine (using
libpng) is fairly short.
Besides, there’s plenty of stuff in all the SDL libraries that i don’t use, but
you take it all if you want a part.
It would be really useful if it could save PNG (and possibly JPEG
and BMP, but mostly PNG) from a surface or specified memory location
or something like that.I wrote a function in Tux Paint to export to PNG, using the libPNG functions.
It wasn’t very hard, I just followed the libPNG instructions.
Same here. It wasn’t that hard, although i haven’t fully got it working yet - i
think the problem is the format i’m reading the SDL_Surface information in.
Its just that it would be clear, more portable and undoubtably more efficient
if it were a part of the library rather than a hack by the user.
(Please Sam, make my day! Add png writing. You know you want to! )
Regards
Damian <damian_rajkowski technologyonecorp.com> writes:
Oops. Sorry Bill. I just read another post from Colin Vella (SDL Digest Vol 9,
Issue 18) where he points out SDL_SaveBMP.
What i meant to ask, before i worded it badly, is whether SDL could include
saving to PNG/JPG, whether its in SDL_Image or SDL itself (the library doesn’t
really matter).
As i said in that post, there’s times when you need to save the alpha layer
with your image (in constructing font textures for example), hence png.
While i’m on the subject, it would be great (and probably asking too much) if
there were ways to save a specified rectangular area of the surface to
png/jpg/bmp, as well as the whole surface. Kind of a ‘partial’ screenshot.
Useful for saving a particular viewport.
Yes, i know this could all be implemented by the user (and that’s what i’m
doing for now). But it would be much nicer as part of the framework itself. 
Ciao
BMP is an obscure format with many variations. It’s bloated
and limited, yet still complex. I have to wonder why it gets
supported at all. The useful and modern formats are:
PNG, obviously
JPEG
PNM, optionally with gzip compression
PostScript (level 2 or 3, binary or ASCII83, deflate or uncompressed)
That’s about it for modern stuff, unless you count JNG and MNG.
I think there are patent problems with Jpeg2000.
GIF, TIFF, TARGA, PCX, PICT, BMP… all are obsolete.On Tue, 2005-01-18 at 17:36, Damian wrote:
Damian <damian_rajkowski technologyonecorp.com> writes:
Oops. Sorry Bill. I just read another post from Colin Vella (SDL Digest Vol 9,
Issue 18) where he points out SDL_SaveBMP.What i meant to ask, before i worded it badly, is whether SDL could include
saving to PNG/JPG, whether its in SDL_Image or SDL itself (the library doesn’t
really matter).
Bill Kendrick <nbs sonic.net> writes:
Are there any plans to enhance SDL_Image to save images to disk?
Probably not in SDL_Image, because it would add a bloat
(small amount, at least), that most people wouldn’t take advantage of.I don’t see why not. The neccessary libraries (libjpeg/libpng) are already used
by SDL_Image to load those formats, and the actual saving routine (using
libpng) is fairly short.
Besides, there’s plenty of stuff in all the SDL libraries that i don’t use, but
you take it all if you want a part.It would be really useful if it could save PNG (and possibly JPEG
and BMP, but mostly PNG) from a surface or specified memory location
or something like that.I wrote a function in Tux Paint to export to PNG, using the libPNG functions.
It wasn’t very hard, I just followed the libPNG instructions.Same here. It wasn’t that hard, although i haven’t fully got it working yet - i
think the problem is the format i’m reading the SDL_Surface information in.
Its just that it would be clear, more portable and undoubtably more efficient
if it were a part of the library rather than a hack by the user.(Please Sam, make my day! Add png writing. You know you want to!
Why not add it yourself and submit a patch to Sam?
Bob PendletonOn Tue, 2005-01-18 at 22:25 +0000, Damian wrote:
Regards
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
What i meant to ask, before i worded it badly, is whether SDL could include
saving to PNG/JPG, whether its in SDL_Image or SDL itself (the library doesn’t
really matter).
SDL_image might be extended to save images, just submit a patch for it.
There are already snippets to save SDL surfaces in various formats, that
have been posted to the mailing list in the past. Try google to find them.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment