Yeah. However pygame uses the writing functions in libpng, libjpg to
save images. libtiff also has some tif saving code in it, so we can
use that. Since SDL_image is often compiled with libjpg, libpng, and
libtiff support compiled in we can use those libraries for write
support.
I've notified the SDL people about the saving functions in pygame, but
I didn't get any response to that email. So I'm not sure if anyone
wants to put them into SDL_image.
Cheers.
On 7/13/06, Alex Holkner <aholkner@xxxxxxxxxxxxxx> wrote:
René Dudfield wrote:
> SDL_image supports libtiff, at least here on my debian box.
SDL_image doesn't have any support for saving images.
Alex.
>
> On 7/13/06, Bob Ippolito <bob@xxxxxxxxxx> wrote:
>
>> Just libpng and libjpg like everywhere else.. there's no code in
>> imageext that knows how to do TIFF, so I don't see why it
should link
>> to libtiff.
>>
>> That said, it *could* link to libtiff if we added that
functionality.
>> I don't have any problem adding that dependency.
>>
>> -bob
>>
>> On Jul 12, 2006, at 8:51 PM, René Dudfield wrote:
>>
>> > Sounds good! Nice one.
>> >
>> > Is libtiff linked to imageext on macosx? If so, I think
there is a
>> > save as tiff function in there which I could add.
>> >
>> > I think I could make it save to bmp in memory fairly easily.
I'll
>> > need to change the save signature to take a name hint(like
load does).
>> >
>> > eg.
>> > f = someStringIOclass()
>> > surf.save(f, "bla.bmp")
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 7/13/06, Bob Ippolito <bob@xxxxxxxxxx> wrote:
>> >> I went ahead and implemented (read: prototyped) scrap bitmap
support
>> >> for Mac OS X, but the implementation is terribly
inefficient. Pygame
>> >> surfaces aren't terribly accessible from Python outside of
surfarray
>> >> (which I didn't want to depend on).
>> >>
>> >> Going from a Surface to the pasteboard is particularly
painful in
>> >> this implementation:
>> >>
>> >> 1. Surface to PNG (on disk!)
>> >> 2. NSImage from on-disk PNG
>> >> 3. NSImage to TIFF
>> >> 4. TIFF to pasteboard
>> >>
>> >> The absolute fastest route (which doesn't exist in pygame)
would be:
>> >>
>> >> 1. Surface to TIFF (in memory)
>> >> 2. TIFF to pasteboard
>> >>
>> >> pygame doesn't have any TIFF writing capability at all, a
compromise
>> >> here would to at least avoid hitting the disk and zlib:
>> >>
>> >> 1. Surface to BMP (in memory)
>> >> 2. BMP to NSImage
>> >> 3. NSImage to TIFF
>> >> 4. TIFF to pasteboard
>> >>
>> >> Unfortunately this also isn't currently possible because pygame
>> >> doesn't support BMP writing anymore (or so it seems from a
quick look
>> >> at the code) and it definitely won't do it to memory instead
of disk.
>> >> Cocoa does not support TGA.
>> >>
>> >> Going the other way is also gnarly, but mostly because I
didn't want
>> >> to think more than I had to:
>> >>
>> >> 1. pasteboard to NSImage
>> >> 2. NSImage to TIFF
>> >> 3. TIFF to NSBitmapImageRep
>> >> 4. NSBitmapImageRep to BMP (in memory)
>> >> 5. Surface from BMP
>> >>
>> >> Getting a NSBitmapImageRep directly from the NSImage (steps 2+3
>> >> combined) is definitely possible without going between TIFF,
but I
>> >> was too lazy to think about what that would do for vector
graphics
>> >> (e.g. PDF on the pasteboard) and screen representations.
It's not
>> >> necessarily true that NSImage will have a NSBitmapImageRep
cached
>> >> already.
>> >>
>> >> Going from NSBitmapImageRep to a Surface without hitting BMP is
>> >> possible, but there's a bunch of formats the
NSBitmapImageRep could
>> >> be in and I didn't want to think about that either :)
>> >>
>> >> In any case, pygame.scrap is 100% implemented on Mac OS X,
and it's
>> >> kinda fun to play with. An easy way to test is to take a
partial
>> >> screen cap to the pasteboard (shift-ctrl-cmd-4) and blit it
in your
>> >> pygame app. You should be able to bring in anything from the
>> >> pasteboard that NSImage can load: icons, jpeg, png, pdf (!),
tiff,
>> >> etc.
>> >>
>> >> -bob
>> >>
>> >>
>>
>>
>
>