Ello. I’ve written a patch for SDL_Image that adds PNG saving support
(for my own use), I’m wondering if it would be useful to add to SDL_Image?
Or should I release it as a new SDL addon, SDL_SaveImage or some such?
-Philip D. Bober
Honestly, probably best as its own lib.
(I also did PNG save code myself, for Tux Paint; didn’t think to make a lib
out of it!)
-bill!On Fri, Apr 23, 2004 at 01:29:31AM -0400, Philip D. Bober wrote:
Ello. I’ve written a patch for SDL_Image that adds PNG saving support
(for my own use), I’m wondering if it would be useful to add to SDL_Image?
Or should I release it as a new SDL addon, SDL_SaveImage or some such?
Ello, Philip 
i would like to use it along with SDL_image.
Olle
Walter> Ello. I’ve written a patch for SDL_Image that adds PNG saving support
(for my own use), I’m wondering if it would be useful to add to SDL_Image?
Or should I release it as a new SDL addon, SDL_SaveImage or some such?-Philip D. Bober
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Ello. I’ve written a patch for SDL_Image that adds PNG saving
support (for my own use), I’m wondering if it would be useful to
add to SDL_Image? Or should I release it as a new SDL addon,
SDL_SaveImage or some such?Honestly, probably best as its own lib.
Right; most people don’t need saving (or have their own solutions
already), so it’s probably better to avoid bloating SDL_image. (Not
much bloat if PNG would be the only saving format supported though,
that would be a bit weird…)
(I also did PNG save code myself, for Tux Paint; didn’t think to
make a lib out of it!)
It would be rather nice to have an SDL image saving lib around. Using
uncompressed BMP for screenshots wastes a lot of disk space - and I’d
rather like to be able to include alpha channels, so I can abuse SDL
for custom image processing tools. hehe
But what about the API? For formats with destructive compression (such
as JPG) one would need some form of “quality” interface… And
there’s the compression level for PNG as well, which affects
processing time a great deal with large images.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 23 April 2004 08.40, Bill Kendrick wrote:
On Fri, Apr 23, 2004 at 01:29:31AM -0400, Philip D. Bober wrote:
IMHO it’s probably best if SDL_image deals both
with loading and saving…
After all, the lib is called SDL_image and not SDL_LoadImage 
Everything that has an IMG_Load* interface should
have the equivalent IMG_Save*
I can see the API problem tho, for things like JPEGS
that allow for quality options…
The simple way out, would be to offer a quality
factor as one of the args of IMG_SaveJPG(…)
(a bit like graphics packages do (e.g. Photoshop))
So you’d have something like:
returnCode IMG_SaveJPG(const SDL_Surface * const sourceImage, const char*
targetFilename, const int qualityFactor);
You’d be surprised how many people would find the saving
options useful… You can, for example, capture various jpegs of your game
to put on your website as screen shots… Not very nice to do it all in
BMPs
and then have to Photoshop or GIMP them to jpegs
cheers,
k.> ----- Original Message -----
From: David Olofson [mailto:david@olofson.net]
Sent: 23 April 2004 08:32
To: sdl at libsdl.org
Subject: Re: [SDL] SDL_Image + PNG saving?On Friday 23 April 2004 08.40, Bill Kendrick wrote:
On Fri, Apr 23, 2004 at 01:29:31AM -0400, Philip D. Bober wrote:
Ello. I’ve written a patch for SDL_Image that adds PNG saving
support (for my own use), I’m wondering if it would be useful to
add to SDL_Image? Or should I release it as a new SDL addon,
SDL_SaveImage or some such?Honestly, probably best as its own lib.
Right; most people don’t need saving (or have their own solutions
already), so it’s probably better to avoid bloating SDL_image. (Not
much bloat if PNG would be the only saving format supported though,
that would be a bit weird…)(I also did PNG save code myself, for Tux Paint; didn’t think to
make a lib out of it!)It would be rather nice to have an SDL image saving lib around. Using
uncompressed BMP for screenshots wastes a lot of disk space - and I’d
rather like to be able to include alpha channels, so I can abuse SDL
for custom image processing tools. heheBut what about the API? For formats with destructive compression (such
as JPG) one would need some form of “quality” interface… And
there’s the compression level for PNG as well, which affects
processing time a great deal with large images.//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
David Olofson wrote:
Ello. I’ve written a patch for SDL_Image that adds PNG saving
support (for my own use), I’m wondering if it would be useful to
add to SDL_Image? Or should I release it as a new SDL addon,
SDL_SaveImage or some such?Honestly, probably best as its own lib.
Agreed.
Right; most people don’t need saving (or have their own solutions
already), so it’s probably better to avoid bloating SDL_image. (Not
much bloat if PNG would be the only saving format supported though,
that would be a bit weird…)
Agreed.
It would be rather nice to have an SDL image saving lib around.
And name it: SDL_image_write, for example.
But what about the API? For formats with destructive compression (such
as JPG) one would need some form of “quality” interface… And
there’s the compression level for PNG as well, which affects
processing time a great deal with large images.
Formats that have quality can have many parameters for functions that
use them. I.e. I think there sould be different functions to save in
different formats:
SaveBMP();
SaveGIF(bool OptimizePalette);
SaveJPG(int CompressionLevel, whatever);
SavePNG(bool SaveAlpha, …);
Well, just my $0.02–
Milan Babuskov
http://fbexport.sourceforge.net
IMHO it’s probably best if SDL_image deals both
with loading and saving…After all, the lib is called SDL_image and not SDL_LoadImage
Everything that has an IMG_Load* interface should
have the equivalent IMG_Save*
Well, that’s a point.
Ok, I wouldn’t mind having SDL_image doing both. I’m just worried
about the code size of the lib.
Then again, if you’re extremely worried about size, you should
probably configure and compile your own libs anyway…
I can see the API problem tho, for things like JPEGS
that allow for quality options…
The simple way out, would be to offer a quality
factor as one of the args of IMG_SaveJPG(…)
(a bit like graphics packages do (e.g. Photoshop))
So you’d have something like:returnCode IMG_SaveJPG(const SDL_Surface * const sourceImage, const
char* targetFilename, const int qualityFactor);
Could work, though I’d kind of like it if all the functions had the
same prototype. OTOH, it’s easy enough to wrap them, I think.
You’d be surprised how many people would find the saving
options useful…
No, not really surprised at all, actually.
More seriously, though; when messing with game code using SDL for
blitting, it sometimes kinda’ makes sense to use SDL for custom tools
as well, rather than using some different API for that - especially
if you have special FX code in the game that you want to use in the
tools as well.
You can, for example, capture various jpegs of
your game to put on your website as screen shots…
And with about 6 lines of code, at that, including a counter to
generate different file names.
Not very nice
to do it all in BMPs
and then have to Photoshop or GIMP them to jpegs
Right… Been there, done that. hehe
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 23 April 2004 11.11, Kostas Kostiadis wrote:
[…]
But what about the API? For formats with destructive compression
(such as JPG) one would need some form of “quality” interface…
And there’s the compression level for PNG as well, which affects
processing time a great deal with large images.Formats that have quality can have many parameters for functions
that use them. I.e. I think there sould be different functions to
save in different formats:SaveBMP();
SaveGIF(bool OptimizePalette);
SaveJPG(int CompressionLevel, whatever);
SavePNG(bool SaveAlpha, …);
Yeah… If you want an IMGW_Save() function, it’s pretty easy to
implement anyway - with whatever compression parameters you like. All
that function can do anyway is look at the extension. (Unlike
IMG_Load() which looks at the data instead, whenever possible.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 23 April 2004 12.01, Milan Babuskov wrote:
Ok, I wouldn’t mind having SDL_image doing both. I’m just worried
about the code size of the lib.
Then again, if you’re extremely worried about size, you should
probably configure and compile your own libs anyway…
EXACTLY!!! If you’re worried about size, you’d probably be happy
working with 1 format, rather than using SDL_image and have support
for bmp, jpg, png, tiff, etc. It makes sense (to me anyway)
for your image lib to handle serialisation both ways (rather than
just loading images).
More seriously, though; when messing with game code using SDL for
blitting, it sometimes kinda’ makes sense to use SDL for custom tools
as well, rather than using some different API for that - especially
if you have special FX code in the game that you want to use in the
tools as well.
Couldn’t agree more… Trying to configure particle effects for
your world via your game editor comes to mind
It’s not very nice when you tweak and polish stuff, only to find
that they look different in-game
You can, for example, capture various jpegs of
your game to put on your website as screen shots…
And with about 6 lines of code, at that, including a counter to
generate different file names.
lol…I know exactly what you mean
cheers,
k.
David Olofson wrote:
Ok, I wouldn’t mind having SDL_image doing both. I’m just worried
about the code size of the lib.
I put the code in a #define (like PNG loading is in LOAD_PNG, PNG saving
is in… SAVE_PNG ),so it’d be simple to have it be a configure option
to not compile PNG.
I included it with the SDL_Image code since it is already linked against
libpng, and it’s really not a lot of extra code. (Plus I’m not really
sure I know enough to design a dynamic-lib for linux :))
I did consider the quality option, so I used this API:
/* Compression constants for IMG_SavePNG */
#define IMG_COMPRESSION_NONE -1
#define IMG_COMPRESSION_DEFAULT 0
#define IMG_COMPRESSION_MAX 1
/* Saving functions */
extern DECLSPEC int SDLCALL IMG_SavePNG(const char *file, SDL_Surface
*surf ,int compression);
extern DECLSPEC int SDLCALL IMG_SavePNG_RW(SDL_RWops *src, SDL_Surface
*surf, int compression);
No compression creates a uncompressed PNG, default is the ZLIB default
(6, I think) and max is ZLIB level 9. So you’ve got 0 compression for
fast saving, max for smallest size, and default for a nice mix.
#define IMG_COMPRESSION_NONE -1
#define IMG_COMPRESSION_DEFAULT 0
#define IMG_COMPRESSION_MAX 1
No compression creates a uncompressed PNG, default is the ZLIB default
(6, I think) and max is ZLIB level 9. So you’ve got 0 compression for
fast saving, max for smallest size, and default for a nice mix.
I think it could be more useful if one could set the exact png
compression s/he wants.
There would be no point in using those defines with JPEG pictures, for
example… So why make generic compression defines that restrict the
user’s choices?On 23/04/2004, Philip D. Bober, you wrote:
–
Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.