Juicy.Pixels 3.1 is here, with a “Squeezed juice” release. Performance updates were there since a long time but not released officially, and now thanks to GHC in the latest Haskell Platform, performances are even better on many cases :
|ImageMagick||Optimisation pass 1||Optimisation pass 2||3.1 with GHC 7.3|
|Png -> Jpg||379,99ms||1091,23ms||859,12ms||968.33ms|
|Jpg -> Png||3945,51ms||16409,36ms||8157,63ms||7417.51ms|
|Gif -> Png||2518,37ms||3348,69ms||762.50ms|
|Png -> Bmp||286,3ms||423,77ms||330.83ms|
I don’t explain the regression for the PNG to Jpg conversion, nor the curious performance bump in Gif decoding. I’ll try to fix the Png -> Jpg conversion in a next minor release.
The next version of the library should include the following (in no particular order):
- Progressive JPEG loading
- Tiff writing
- More concentrated juice
Other than the performance improvement, the addition of Tiff reading, 16 bits pixels support and some helper function are in this release.
Big thanks to Alp Mestanogullari and Jason Dagit who helped making this release possible.
Here is some new timing from the Juicy.Pixels trunk, Optimisation pass 1 refer to the previous pass, the new numbers are in the Optimisation pass 2. Some new categories where added to check performances
|ImageMagick||Optimisation pass 1||Optimisation pass 2|
|Png -> Jpg||379,99ms||1091,23ms||859,12ms|
|Jpg -> Png||3945,51ms||16409,36ms||8157,63ms|
|Gif -> Png||2518,37ms||3348,69ms|
|Png -> Bmp||286,3ms||423,77ms|
And a small graph :
The good news is : we’re now at roughly twice the speed of C for all image formats instead of 4 times (yay!). The open question is now : can we go even further?
Here is some performance measurement of the trunk version of Juicy.Pixels.
This is a simple benchmark considering two operations :
- Reading a 1360×1312 PNG image and saving it as a JPG.
- Reading a 4928×3264 JPG image and saving it as a PNG.
Both images are the “huge” test images present in the JuicyPixel repository.
- Test machine : Core i5 M520@2.40Ghz
- OS : Windows7 x64
- GHC : 7.4.2
- The energy mode is set as “best performances”.
The imagemagick performance as been measured with the command “convert” repeated 20 times with the time result are below :
PNG -> JPG Avg: 306.3059ms Min: 290.6701ms Max: 327.0791ms JPG -> PNG Avg: 3668.5218ms Min: 3637.5323ms Max: 3741.9981ms
The Benchmarking of Juicy.Pixels is done using the Criterion library. In 20 runs, the code is the following :
jpegToPng :: IO () jpegToPng = do img <- readImage "tests/jpeg/huge.jpg" case img of Left err -> putStrLn err Right i -> savePngImage "huge.png" i pngToJpeg :: IO () pngToJpeg = do img <- readImage "tests/pngsuite/huge.png" case img of Left err -> putStrLn err Right i -> saveJpgImage 50 "huge.jpg" i
And the results :
benchmarking trad/JPG -> PNG collecting 12 samples, 1 iterations each, in estimated 158.6611 s mean: 16.40936 s, lb 15.57981 s, ub 17.18032 s, ci 0.950 std dev: 1.477429 s, lb 1.199743 s, ub 1.949199 s, ci 0.950 variance introduced by outliers: 31.549% variance is moderately inflated by outliers benchmarking trad/PNG -> JPG collecting 12 samples, 1 iterations each, in estimated 20.88119 s mean: 1.091229 s, lb 1.083062 s, ub 1.097646 s, ci 0.950 std dev: 13.40252 ms, lb 9.745841 ms, ub 17.60697 ms, ci 0.950 variance introduced by outliers: 7.639% variance is slightly inflated by outliers
We can see that we are roughly at 4x the speed of imagemagick C implementation. Thats reasonable, but I’m curious what the improvement of the new code generator of GHC 7.6 would bring on the performance side.
Today just the small release of a spotlight plugin [CtagSpotlight](https://github.com/Twinside/CTagSpotlight) which allow spotlight, the search module of Mac OS X, to index many of your source code and search specific element in it.
I almost forgot, A software I made with Fabien Donius, AutoSummary, a PowerPoint 2010 Plug-in.
The idea is to give some function of LaTeX’s beamer module to powerpoint, it’s a shareware with a fair price (7€). Give it a shot