; Please find attached screen shots of this Emacs 24.3 vs. Emacs 25.1 bug:
(progn (insert-image (create-image "/* Example at
https://en.Wikipedia.org/wiki/X_BitMap */
#define test_width 16
#define test_height 7
static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
				   (quote xbm) t))
       (insert emacs-version))
; MacOS 10.11.6 Emacs 24.3 displays a proper [Blarg] glyph.
; MacOS 10.11.6 Emacs 25.1 displays a scrambled [alBgra] glyph with the
"a" split in two, i.e., [Blarg] glyph with each octet LSB-MSB reversed.

It seems in XBM image bool-vector data

    (A) octets are sometimes little-endian and sometimes big-endian
    (B) rows are sometimes padded to octet boundaries and sometimes not

It would be helpful to standardize -- or at least document -- such
per-version per-platform differences
as XBM is the only programmatically accessible graphical element natively
supported in vanilla Emacs!

		Peace
			--Devon

P.S. Here's an example of the opposite problem:
bash$ curl -L -O http://csail.mit.edu/~devon/emacs/bitmap.el    # this
workaround works in 25.1 but is scrambled in 24.3
bash$ Emacs -Q -eval '(setq debug-on-error t)' -l cl -l bitmap.el -f blarg
-eval '(insert emacs-version)'    # 24.3
bash$ /Applications/Emacs.app/Contents/MacOS/Emacs -Q -eval '(setq
debug-on-error t)' -l cl -l bitmap.el -f blarg -eval '(insert
emacs-version)'    # 25.1

P.P.S. If you're looking at the XBM image code, the XBM parser should hack
c++ comments.
(insert-image (create-image "// Example at
https://en.Wikipedia.org/wiki/X_BitMap
#define test_width 16
#define test_height 7
static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
			    (quote xbm) t))
; Emacs 24.3 and 25.1 both display a blank space with the expected display
property but no bitmap.
; Perhaps more annoying feature than bug.