Last modified: 2014-07-29 11:40:57 UTC
Dispenser mentioned to me that our image scaling is working on non-linear sRGB colour space, which causes some less than ideal results on dark images Background on issue: * http://www.4p8.com/eric.brasseur/gamma.html [Specifically mentions Wikipedia as doing it wrong] * http://www.imagemagick.org/Usage/resize/#resize_colorspace For image magick, it looks like this can be addressed by just adding some command line flags (which flags unfortunately vary by version). [Except possibly not jpeg as that's shrunk by libjpeg] Its unclear if something similar can be done in vips well still using the very efficient sequential read and not creating a giant temporary file. There is a -a option to vipsthumbnail that could maybe be used. (If it can only be on image magick and then not for jpeg, we possibly wouldn't want to do it at all to keep things consistent. Requires more investigation anyhow)
> Its unclear if something similar can be done in vips well still using the > very efficient sequential read and not creating a giant temporary file. > There is a -a option to vipsthumbnail that could maybe be used. In my test, the -a option slowed things down quite a bit, and increased memory usage to beyond 400mb. :(
Some benchmarks: $ time vipsthumbnail -a wtc.jpg --vips-leak memory: high-water mark 65.98 MB real 0m4.039s user 0m4.003s sys 0m0.038s $ time vipsthumbnail wtc.jpg --vips-leak memory: high-water mark 6.22 MB real 0m0.307s user 0m0.289s sys 0m0.020s wtc.jpg is a 10,000 x 10,000 pixel RGB image. The main source of the slowdown is that you can't use libjpeg's very fast shrink-on-load feature, since that's calculated in Y, which is not linear. Instead, you have to decode the entire image, convert to a linear space (vipsthumbnail uses XYZ), and then shrink that. -a is much more competitive if you use a format that doesn't support shrink-on-load, such as vanilla tif: $ time vipsthumbnail wtc.tif --vips-leak memory: high-water mark 44.31 MB real 0m2.662s user 0m0.513s sys 0m0.119s $ time vipsthumbnail -a wtc.tif --vips-leak memory: high-water mark 66.62 MB real 0m3.623s user 0m3.547s sys 0m0.078s memuse should not be huge, the whole process can still be streamed.
