Support canvas.getBuffer('raw')

[adamhooper]

This should help interface with custom image libraries like LodePNG or
WebP.

refs #306. Also, I think users could handle #562 themselves, using https://github.com/lovell/sharp plus some bit-shifts. (I haven't seen a Node library that does bulk bit-shifts on Buffer data, but it'd be straightforward to write one.)

[adamhooper]

Along with https://github.com/huffpostdata/node-lightnpng, I've achieved a 50% speedup in PNG compression.

Before: canvas.toBuffer(undefined, 3, canvas.PNG_FILTER_SUB)

After: lightnpng.native_argb32_to_png(canvas.toBuffer('raw'), canvas.width, canvas.height, canvas.stride)

[adamhooper]

Also, it works a treat with node-jpeg-turbo:

const buf = canvas.toBuffer('raw')
return jpeg.compressSync(buf, {
  format: os.endianness() == 'LE' ? jpeg.FORMAT_BGRA : jpeg.FORMAT_ARGB,
  width: canvas.width,
  height: canvas.height,
  quality: 85
})

That's faster than node-canvas's JPEG encoding, and it's actually synchronous.

[LinusU]

This is great!! I'm hoping to review this very soon.

If you're interested, I also maintain some lodepng bindings here: https://github.com/LinusU/node-lodepng

[LinusU]

A few small nits, but this looks great! I agree that toBuffer never should return PNG data, but as said that will be for the next major version.

I actually want to move all non-standard APIs away from the Canvas and Context and keep them as close to the spec as possible

[LinusU]

This can be replaced with os.endianness()

[adamhooper]

os.endianness() was introduced in Node v0.9.4, but Travis runs the tests on Node v0.8.

[LinusU]

Good catch

[LinusU]

How about something like this?

var postfix = os.endianness()
var px = buf['readUInt32' + postfix](y * stride + x * 4)

[LinusU]

How about info.Length() >= 1 to support .toBuffer('raw', undefined, undefined)? (might be used if someone wraps .toBuffer)

[adamhooper]

Good advice! Tweaked.

[LinusU]

Thank you for this!

[paramaggarwal]

I am curious to understand how is this different from ctx.getImageData() which also returns the raw pixel data?

EDIT: Found the answer here: #306 (comment)

[adamhooper]

* it's synchronous * It returns a Buffer, not an ImageData * It does not accept arguments * It does not do any color conversion (like argb->rgba) In other words: if you use node-canvas to emulate HTML, choose getImageData. If you use node-canvas as a Cairo+Pango wrapper, code getBuffer('raw'). I suspect lots of node-canvas users choose it for the same reason I did: it's the only viable drawing API on Node. HTML compatibility is a burden for that use case.

On Wed, Dec 20, 2017, 3:37 AM Param Aggarwal, ***@***.***> wrote: @adamhooper <https://github.com/adamhooper> - I am curious to understand how is this different from ctx.getImageData() which also returns the raw pixel data? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#819 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAqPLu4RQg-ZrvQDV9bNd8mukNtdvCBks5tCMc4gaJpZM4KQl-Y> .

-- Adam Hooper http://adamhooper.com +1-929-332-3503