Just theoretically, b/c I’ve just read that we should expect that almost all mobile devices are configured to use little endian byte order:
That utility function is just to make 100% sure our code is indeed running on a little endian device (which statistically should always be so):
The datatype of pixels[] is Uint8ClampedArray: reference | p5.js
And there are 11 Typed Array versions:
As long as we’re using 1 of the 3 8-bit versions of Typed Arrays we can fully ignore endianness.
But as you can see within Blurry::resetImageColor() method there’s a Uint32Array viewer of the p5.Image::pixels[] there:
const pix32 = new Uint32Array(img.pixels.buffer),
It means that instead of needing 4 indices from p5.Image::pixels[] in order to get a pixel’s RGBa color, 1 index now represents the whole 4-byte (32-bit) color value.
The problem about using a multibyte viewer on a little endian device is that its byte order is inverted.
That is, when we read an RGBa pixel we get aBGR mirror of it instead.
And when we write a pixel, we gotta arrange its values in aBGR order, so it’s correctly stored as RGBa:
c[3] << 0o30 | c[2] << 0o20 | c[1] << 0o10 | c[0] : // aBGR
Above the c[] array’s 4 indices represent RGBa, but they’re ordered as aBGR for the sake of the Uint32Array viewer.
But again, all this complex explanation can be skipped if you don’t use a viewer for pixels[]. 