Sharp: Take advantage of forthcoming libvips 8.3.1 features

[lovell]

Requires libvips v8.3.1.

Input formats

• [X] Improve WebP performance by using its new shrink-on-load API, bundle libwebp v0.5.0 on Windows
• [x] Improve SVG performance with new svgload, bundle librsvg
• [x] Improve GIF performance with new gifload, bundle giflib v5.1.4+ - see https://github.com/jcupitt/libvips/issues/407
• [x] Expose ability to use libvips compiled with pdfload, but this is GPL so will not be bundled
• [x] Retain support for libvips compiled with *magick but no longer bundle it (lower support burden, reduced security risk e.g. http://seclists.org/oss-sec/2016/q1/297).

Internal API changes

• [x] Use vips_sharpen new sigma param instead of deprecated radius

[lovell]

Need to investigate "will the improved GIF support add the ability to detect an animated gif via .metadata(...)?" via @papandreou

[jcupitt]

There's a first test tarball of 8.3 up here:

http://www.vips.ecs.soton.ac.uk/development/8.3/

I've done a test win64 build too. It seems to work, including the new pdf, svg and gif loaders, but I've only done some simple checks.

I think you'll probably want to make a cut-down win64 binary with fewer load modules built in. The build-win64 repository has an 8.3 directory which would make a good starting point.

[lovell]

@jcupitt Thanks John, I'll submit a PR for an additional, more web-focused win64 build, perhaps later this week.

[dhotson]

Hello :)

One small thing that has been fixed and should work in 8.3 is saving lossless webp.

https://github.com/jcupitt/libvips/blob/master/ChangeLog

- webpsave_buffer no longer ignores @lossless, thanks aaron42net

Sharp's webp saving code currently always uses the lossy mode (with a default quality of 80). libvips has an option for saving lossless webp.

I've started work on a PR to bring this into sharp—does this sounds like something you would be interested in?

Any thoughts on what the API might look like? webp is probably one of the few formats that supports both lossy and lossless compression.

sharp()
  .webp()
  .lossless() // maybe something like this?

[lovell]

@dhotson, sounds great, yes please.

The API is (slowly) moving so that where attributes relate to a specific operation, then the method to invoke that operation accepts those attributes as a Object-based parameter. In the case of lossless I think this would look like webp({ lossless: true }) and toFormat('webp', { lossless: true }).

This would put existing methods like quality out of sync. Perhaps now is the time to also allow the quality attribute to be set via webp({ quality: 90, lossless: true }) and friends?

[lovell]

@dhotson Please use the outfit branch as the destination for any work-in-progress that requires libvips 8.3+.

[dhotson]

Also, do you have any opinions about what the default should be?

I think I'll keep it as-is lossy by default for backwards compatibility—even though I think lossless would perhaps be a better default.

[lovell]

@dhotson Where possible, existing behaviour should remain the default, so yes please on lossy. I'm mulling a possible future enhancement to automagically make the lossy vs lossless decision based on image entropy.

[felixbuenemann]

I'm currently working on adding more options to the webp encoder in vips and specifying them via an option instead of methods is definitely much nicer. There will be at least options for preset, alpha quality, hint and near_lossless.

My changes will also enable high quality rgb2yuv conversion by default, which greatly reduces quality of fine details in lossy mode by getting rid of chroma subsampling artifacts. It's similar to the "fancy upsampling" which libjpeg uses by default. It's quite some work because I have to switch to the advanced libwebp encoding API and adding new enums in Vips is quite verbose.

[lovell]

@felixbuenemann Did you see @dhotson's work-in-progress #408 for lossless WebP?

[jcupitt]

Hi @felixbuenemann, adding an enum to vips should be just a couple of lines of code. The boilerplate is all generated for you on make.

You add the enum to a header (in this case probably foreign.h) with a specially-formatted comment block, like:

https://github.com/jcupitt/libvips/blob/master/libvips/include/vips/foreign.h#L353

Then on make, enumtypes.h and enumtypes.c will be regenerated for you, and (slightly crappy) docs will be written for your enum, like:

http://www.vips.ecs.soton.ac.uk/supported/current/doc/html/libvips/libvips-VipsForeignSave.html#VipsForeignTiffCompression

You can put the enum comment block in your .c file if you prefer.

[felixbuenemann]

Thanks John, that will save me time adding the remaining enums.

[lovell]

The outfit branch now supports libvips' new GIF, SVG and PDF loaders and the Linux/OS X and Windows CI environments are passing.

In my preliminary testing, SVG and GIF processing is almost twice as fast with far lower memory consumption, and output images are of noticeably higher quality.

I've created a provisional pre-compiled bundle that adds giflib and librsvg (and libwebp for Windows) and removes GraphicsMagick. I do not intend to include a pre-built libpoppler (for PDF support) as this library is only available under the terms of the GPL.

[lovell]

This is now in the master branch to be included in v0.15.0.

[lovell]

v0.15.0 with all these lovely features is now available via npm.