yeah, that was a bit strange. By choosing Little Endian, the author would achieve the ability to mmap an uncompressed image file to memory and then use it directly like an array in all contemporary hardware architectures. Not that it's a big deal, but I fail to see why would anyone choose Big Endian in 2016.

Hey krasin,

how come people assume there are only Little Endian machines. This mmap-technique wouldn't work on Big Endian like this, this is inaccetable!

However, you can still mmap and properly call ntohs() on each color channel value (if you access it). These functions won't hurt performance too much anyway, if at all. If you show me a measurable difference between using LE and BE, I owe you a beer, okay? :)

People are making the (valid) assumption that LE is far more common than BE.

On x86 swapping endianness is one instruction (BSWAP), but AFAIK it can't be SIMD'd easily. Given that SIMD is one of the things that can greatly speed up image processing, I don't think it "won't hurt performance too much"...

For SIMD you can use _mm<width>_shuffle_epi8 to swap endianness in a single cycle.

(Just FYI, this only works with SSSE3+, which to be fair is essentially all x86 machines. It's also >1 cycle on mobile x86 chips, which is very frustrating.)

One of the few legit criticisms in this thread.

Keep in mind not all machines are Little Endian. This assumption is wrong.

You are right, only 99.999% of machines are little endian now (iOS, Android and x86).

All machines are ALSO not 64 bit and you have a trivially exploitable buffer overflow on 32 bit machines.

Choosing big endian is bad enough, but they dont even mention that in the four line specification :o

It is specified (BE = Big Endian)