Pillow-SIMD: improving the performance of image processing

re: <a href="https:&#x2F;&#x2F;github.com&#x2F;uploadcare&#x2F;pillow-simd#why-do-not-contribute-simd-to-the-original-pillow" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uploadcare&#x2F;pillow-simd#why-do-not-contrib...</a><p>They can create three versions of each affected function (fallback, SSE4 and AVX2), place them in separate files (one file for each set of compiler flags), compile each version with its own compiler flags, then link them all together, and in the main module (which is compiled for generic cpu) run cpuid and set global function pointers to the right function implementation.<p>Then always use the global function pointer to call the right implementation of the function, and only expose calling the global function pointer if the function is exported from a shared library.<p>They do need to make sure that function pre and post conditions are preserved in all versions and that memory alignment&#x2F;layout required by optimized functions is created by the generic code.<p>I think x264 does this.

It&#x27;d be interesting to see this compared to Halide [0], which conveniently already has a resize example [1]. Parallelization and data locality for example can make big differences.<p>[0]: <a href="http:&#x2F;&#x2F;halide-lang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;halide-lang.org&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;halide&#x2F;Halide&#x2F;blob&#x2F;e9ece5ee8ee9cb62295d5e7e5409e54390bb01b4&#x2F;apps&#x2F;resize&#x2F;resize.cpp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;halide&#x2F;Halide&#x2F;blob&#x2F;e9ece5ee8ee9cb62295d5e...</a>

I don&#x27;t really want to defend ImageMagick, but does Pillow come anywhere close to it in terms of format support? A magnitude better performance is great, but sometimes you just need to operate on and convert strange files (X bitmaps, ASCII braille come to mind).

This is a bit OT, but if you only care about downscaling, cropping and&#x2F;or rotating JPEG images by multiples of 90 degrees, you might also want to take a look at jpegtran-cffi (<a href="https:&#x2F;&#x2F;github.com&#x2F;jbaiter&#x2F;jpegtran-cffi" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jbaiter&#x2F;jpegtran-cffi</a>).<p>It does all of the above operations without decoding the image, giving a significant speed boost.<p>I just benchmarked it against pillow-smd on my laptop (SSE4 only) and it&#x27;s 1.3-1.8x faster, depending on the operation.

I wonder why this isn&#x27;t benched against graphics magick (which I have found to be ~2x faster than imagemagick)

With Python, is there an alternative for pexif.py to parse the orientation data for reorientating images? I used Thumbor in production for a while (which relies on Pexif) and found so many bugs in it that I had to make a hurried switch back to PHP.

Just slipped this into an image resize-bound Python script I&#x27;m using. Immediate 3x speedup. Glorious!<p>(But yeah, would love to see this merged upstream. Lots of Python libraries have sorted out harder CPU&#x2F;GPU dependencies.)

Does Pillow have good security tests like fuzzing? Is it safe to pass arbitrary user input (file upload) to Pillow and Pillow-SIMD?

Why did Pillow fork from PIL in the first place?<p>&gt; If you have ever worried or wondered about the future of PIL, please stop. We&#x27;re here to save the day<p>What&#x27;s the backstory here?

What about compared to opencv&#x27;s image handling functions? I&#x27;ve seen Opencv run about 4x faster than pillow for certain operations.

Is there any chance the ImageMagick developers would consider adding such optimizations?

Which operations you do the most? I&#x27;ll try speed up them too.

How about versus imagemagick with openCL?

What if you don&#x27;t care about speed, but you do care about not embedding strange scripting languages from the mid-1990s that can write files and make network requests?