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
> >> >>
> >> >>
> >>
> >>
>
>