Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

array.array is fine, I guess, but using a list of array.array objects is inelegant and inflexible. It’s much better to put all your image data in one big array, keep track of the various stride lengths to go down rows or across pixels, and then implement proper multi-dimensional indexing.

I suppose it doesn’t really matter. This library is also missing all the other flexibility you’d want in a general imaging toolkit – e.g. the assumption of 8 bit/channel RGB is baked into everything, with no notion of color space or gamma encoding (and the JPEG decoder doesn’t seem to have any mention of color spaces, meaning that many JPEG images will be wrongly interpreted). It’s not usable for any but the most basic image processing tasks.

The JPEG decoder might make an okay benchmark for pypy performance, though it’s a straight port from C++, so it’s probably not the style of python code that pypy is designed to be fast on.



I believe Jonas is approaching it from his position as a web developer and Django author who's spent a LOT of time dealing with requests from people who've had trouble with PIL and generally only use 8-bit RGB.

I'd be reluctant to condemn a project which is a few days old. Having spent time wrestling with optimizing the horror which is the PIL code, I'd definitely suggest that having a pure Python implementation will make it much easier for people to experiment with API and performance improvements.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: