Re: PIL Consuming All System Resources
Edward Cannon <[email protected]>
| Newsgroups | gmane.comp.python.image |
|---|---|
| Message-ID | <[email protected]> |
Another method used by many websites is to put a limit on uploaded file size. This has the double benifit of saving on bandwidth as well. Facebook uses 5MB if I recall correctly, and that seems to work really well in practice, large enough to handle most camera files, but small enough to exclude giant images that cause server problems. In some instances you can even preform the file size check pre upload and save your user frustration and headache. Edward Unicorn School On May 30, 2010, at 7:26 AM, Fredrik Lundh <[email protected]> wrote: > I spent about a decade working on libraries with paging, tiling, and > streaming processing architectures. PIL's simple storage model is > pretty much a reaction against that. It has worked reasonably well > this far :-) > > However, note that for resizing and some color conversions, the draft > & thumbnail operations can do a bunch of tricks to avoid decoding > everything; e.g. im.thumbnail((200, 150), Image.ANTIALIAS) only uses > 40 MB peak on my machine for that image, and you can use draft to > specify a maximum size you're interested in dealing with: > >>>> im = Image.open("1291762-img016.jpg") >>>> im.draft("RGB", (1000, 1000)) > <JpegImagePlugin.JpegImageFile image mode=RGB size=2550x3510 at > 0xE18580> >>>> im > <JpegImagePlugin.JpegImageFile image mode=RGB size=2550x3510 at > 0xE18580> > > (note that this modifies the image in place, and can only be used > directly after open. also note that it doesn't necessarily give you > exactly the mode or size you're asking for, and it also doesn't work > for all formats) > > </F> > > 2010/5/30 Yury V. Zaytsev <[email protected]>: >> Hi! >> >> On Sun, 2010-05-30 at 14:59 +0200, Fredrik Lundh wrote: >>> The file has mode=RGB size=20400x28079, so you'd need about 2291246400 >>> bytes to load it all into memory at once, and twice that to do e.g. >>> color conversion (which creates a second image memory), so it's a >>> bit >>> on the big side, at least for a 32-bit environment. >> >> I was just about to complain how suboptimal PIL is at loading images, >> but first tried to load this in eog (which actually did render the >> image >> after consuming an insane amount of 1.8 Gb memory) and then in Gimp >> that >> was no better :-) >> >> I am wondering whether there's a way of performing image >> transformations without temporarily decoding the whole image in >> memory... >> >> -- >> Sincerely yours, >> Yury V. Zaytsev >> >> > _______________________________________________ > Image-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/image-sig _______________________________________________ Image-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/image-sig