Pillow-SIMD: improving the performance of image processing (github.com)

Both of the implementations you mentioned are not best known for its speed, rather, its their versatility (or bloatedness, some may argue).

PIL is dead. No updates at all since 2009.

I don't the whole backstory, but I was a PIL user before Pillow was a thing. PIL was old and crusty and had barely been updated since about the Python 2.1 days. While I don't know the details, I've always assumed that PIL was abandonware and the Pillow guys decided to reinvigorate it.

It didn't install cleanly with plone, so Alex Clark forked it to clean that up and make it work with pip and the other setuptools. Python 3 compatibility was added for pillow 2, and since then it's been a steady stream of additions and bug fixes.

(I'm one of the maintainers of pillow, but I hadn't seen the smid fork before.)

> What's the backstory here?

No backstory, the development of PIL gradually slowed down and ultimately stopped in 2011 (the last official release having been cut in 2009), I've never seen any info as to why that happened, it just did. Possibly the difficulty of implementing P3 compatibility while remaining pre-2.7 compatible.

PIL was always an idiosyncratic package with a completely custom setup script, a difficult install (including setuptools-incompatibility) and weird-ass modules (probably owing in part to 1.5~2.7 compatibility), as well as a fairly slow release schedule (bi-yearly at the best of times).

And so in 2013 it was forked (not entirely unlike LibreSSL from OpenSSL) and a dedicated group started on maintaining and cleaning the stuff, progressively phasing out pre-2.6 compatibility and adding Python 3 support, etc...

  wget http://effbot.org/downloads/Imaging-1.1.7.tar.gz
  tar xvf Imaging-1.1.7.tar.gz
  cd Imaging-1.1.7/
  python2.7 setup.py build
  sudo python2.7 setup.py install

Then fork it and make a command line tool that links to the C code.

Then you can use Bash or another strange scripting language from the late-1980s, presuming you're okay with it writing files, too.

https://github.com/imazen/imageflow works for that and still gives you speed. :P

You can even use the GCC ifunc attribute and get the dynamic linker to handle selecting the right function.

In practice, it's very hard to make Python's distutils do this. I tried to figure it out years ago, see http://stackoverflow.com/questions/15527611/how-do-i-specify... . I also asked on the distutils list. No one had a clean solution.

The best solution I have is to interpose my own "CC", which looks at what is being compile and adds the correct compiler options for the right files before calling the real compiler. This is hacky and inflexible.

It's possible to do automatically this by using a SIMD library such as libsimdpp (https://github.com/p12tic/libsimdpp). Everything is mostly abstracted away and you just write the SIMDified code once and add a CMake rule that builds the same file for several architectures, sets up dynamic dispatch and links everything together.

Many sites have a simple requirement of "allow user to upload a jpeg, resize it to create user profile pic for the user". No need to support anything but the most common formats for this, but you need security and you need speed of resizing.

There are a lot of formats, some of them are better exercised than others. It's not as complete as imagemagick, but we're getting one or two formats per release lately.

You could make a hybrid solution where Pillow supported formation (which should be the vast majority of your input) go through its filters while other formats are run through ImageMagick to be converted into something Pillow understands so they can be stuffed into the front end.

If you support JPEG, PNG, and GIF you will have 99% of the user data supported. Very few people upload RLE TARGA to webpages these days.

ImageMagick has also better default handling. For example, in a previous project, we were automatically resizing jpeg images. Surprisingly, some resulting images were blurry. After some investigation, we found that these images had been photoshopped and Photoshop was using a different sampling factor (one of the variables used in jpeg compression). ImageMagick automatically detected this sampling factor and reused the same, but Pillow was using a default sampling factor and was blurring the image.

Fuzzing is slow. I've tried afl against a small subset of images and I was getting about 10 tries per sec per core.

There have been some bugs that look like people have been successfully fuzzing, but there's nothing organized.

The goal is certainly to be safe against user input, I would say we're there, but we're better off than we were 6months ago.

I just discovered today that our resize example is actually absurdly slow. Working on a better one. So far it's about 8x faster. The other apps are much better tuned.

(I'm one of the main Halide devs)

Opencv doesn't provide convolution-based resampling. Only supersampling with INTER_AREA flag, which is comparable to BICUBIC for high-ratio downscaling. So, such statements don't make sense without exact code :-)