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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> >> >> >> >> >>