Add support for different bit depths with raw input and output

[mart-jansink]

Fixes #1454 and fixes #1289. I've mostly added just the logic to support input or output raw data in different bit depths for now. If you like it, I'll also adjust the documentation accordingly and ensure test coverage of course.

---

Raw input example

const input = new Uint16Array( 48 );
for ( let i = 1; i < 48; i += 3 ) {
  input[ i ] = 0xffff;
}
sharp( input, {
  raw: {
    width: 4,
    height: 4,
    channels: 3,
  },
} ).toFile( "16bpc.png" );

This generates a green 4x4 .png file with 16 bits per pixel per color.

---

Raw output example

sharp( "16bpc.png" )
  .toColourspace( "rgb16" )
  .raw( {
    depth: "ushort",
  } )
  .toBuffer( ( error, data, {
    width,
    height,
    channels,
    size,
  } ) => {
    console.log( size / width / height / channels * 8 );
    console.log( new Uint16Array( data.buffer ) );
  } );

This takes the above .png file and reads the raw pixels from it as an Uint16Array. Note that the raw output still defaults to 8-bit results, so you have to explicitly use { depth: "ushort" }. Also, .toColourspace( "rgb16" ) is needed to prevent downsampling earlier on in the pipeline with

sharp/src/pipeline.cc

Line 711 in 61640fb

image = image.colourspace(baton->colourspace, VImage::option()->set("source_space", image.interpretation()));

Maybe you have a suggestion on how to do this automatically?

---

Please let me know your thoughts on this PR, I'd happy to work some more on it to get it merged.

[lovell]

Hello Mart, thank you for your PR, this will be a welcome addition.

If you hadn't seen it, I'm planning to review #2704 very soon, and I think it's worth getting that merged first as it should then help improve what's in this proposed change.

[mart-jansink]

Perfect! The main reason that I need this modifications is to prevent unnecessary banding while processing 16-bit images, so #2704 will definitely help.

[lovell]

This looks great, thank you. Please can you go ahead and add tests for all this useful new logic.

(You might also want to rebase against the circle branch to pick up #2704 as it has now been merged there.)

[mart-jansink]

Apologies for the delay, but I've now rebased and added some unit tests for this functionality. I'm not getting 100% coverage on output.js, but that's already not the case with the circle branch itself.

[coveralls]

Coverage remained the same at 100.0% when pulling a559e4f on mart-jansink:raw-pixel-depth into 21d1a7c on lovell:circle.

[lovell]

Bedankt Mart!