Well, I'm not sure what's in SDL_image, I'm using the binary from
libsdl.org. You said imageext, which links to just libjpeg and libpng
directly.
-bob
On Jul 12, 2006, at 9:24 PM, René Dudfield wrote:
> SDL_image supports libtiff, at least here on my debian box.
>
> 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
>> >>
>> >>
>>
>>