[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] pygame.scrap bitmap stuff



Hi,

I'm not sure how... but imageext here is linked with libtiff.  Maybe
because it is linked with SDL_image it gets it's dependencies linked
in?

This is the link line:
gcc -pthread -shared build/temp.linux-i686-2.4/src/imageext.o -lSDL
-lpthread -lSDL_image -o build/lib.linux-i686-2.4/pygame/imageext.so

This is the list of things it's linked against.
ldd build/lib.linux-i686-2.4/pygame/imageext.so
	linux-gate.so.1 =>  (0xffffe000)
	libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7eb2000)
	libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e9f000)
	libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0xb7e84000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d4b000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c80000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7c72000)
	libasound.so.2 => /usr/lib/libasound.so.2 (0xb7bbf000)
	libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7b99000)
	libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b95000)
	/lib/ld-linux.so.2 (0x80000000)
	libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb7b42000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7b24000)
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7aff000)
	libz.so.1 => /usr/lib/libz.so.1 (0xb7aeb000)


On 7/13/06, Bob Ippolito <bob@xxxxxxxxxx> wrote:
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
>> >>
>> >>
>>
>>