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 = (0xe000) 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 (0xb7c8) 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 (0x8000) 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
Re: [pygame] pygame.scrap bitmap stuff
Well, you can't use symbols from indirectly referenced libraries in a system with two-level namespaces (like OS X), so it really doesn't matter what SDL_image is linked to. Especially because the libpng/ libjpeg/etc. are compiled statically into SDL_image and aren't exported anyway. The saving functions aren't terribly useful for this purpose right now because they need to write to files, they won't use a file-like object. -bob On Jul 12, 2006, at 11:17 PM, René Dudfield wrote: 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 [EMAIL PROTECTED] 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 [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
Re: [pygame] pygame.scrap bitmap stuff
On Jul 12, 2006, at 8:34 PM, andrew baker wrote: What's a scrap? http://www.pygame.org/docs/ref/scrap.html -bob
Re: [pygame] pygame.scrap bitmap stuff
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
Re: [pygame] pygame.scrap bitmap stuff
Oh, a clipboard, lovely.Thanks!On 7/12/06, René Dudfield [EMAIL PROTECTED] wrote: Sounds good!Nice one.Is libtiff linked to imageext on macosx?If so, I think there is asave 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 -- Andrew Ulysses Bakerfailrate
Re: [pygame] pygame.scrap bitmap stuff
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
