Interleaved data

[Yay295]

Pillow currently supports "band interleaved by pixel" and "band interleaved by line" image data (to an extent). Should it also support "band sequential"? Supporting only one layout would be the easiest, but if someone wants to use their image data with some other library they might want it to be in a specific layout.

https://desktop.arcgis.com/en/arcmap/latest/manage-data/raster-and-images/bil-bip-and-bsq-raster-files.htm

[radarhere]

I think Pillow already does. Here is a snippet from SgiImagePlugin, where one channel is loaded after another into the final image.

Pillow/src/PIL/SgiImagePlugin.py

Lines 114 to 118 in c924fd8

	for layer in self.mode:
	self.tile.append(
	("raw", (0, 0) + self.size, offset, (layer, 0, orientation))
	)
	offset += pagesize

[Yay295]

That's before the data gets decoded.

Pillow/src/PIL/SgiImagePlugin.py

Lines 200 to 216 in c924fd8

	class SGI16Decoder(ImageFile.PyDecoder):
	_pulls_fd = True
	def decode(self, buffer):
	rawmode, stride, orientation = self.args
	pagesize = self.state.xsize * self.state.ysize
	zsize = len(self.mode)
	self.fd.seek(512)
	for band in range(zsize):
	channel = Image.new("L", (self.state.xsize, self.state.ysize))
	channel.frombytes(
	self.fd.read(2 * pagesize), "raw", "L;16B", stride, orientation
	)
	self.im.putband(channel.im, band)
	return -1, 0

On line 214 is self.im.putband(channel.im, band). putband is C code that can be traced back to here:

Pillow/src/libImaging/Bands.c

Lines 169 to 208 in d72779a

	Imaging
	ImagingPutBand(Imaging imOut, Imaging imIn, int band) {
	int x, y;
	/* Check arguments */
	if (!imIn || imIn->bands != 1 || !imOut) {
	return (Imaging)ImagingError_ModeError();
	}
	if (band < 0 || band >= imOut->bands) {
	return (Imaging)ImagingError_ValueError("band index out of range");
	}
	if (imIn->type != imOut->type || imIn->xsize != imOut->xsize ||
	imIn->ysize != imOut->ysize) {
	return (Imaging)ImagingError_Mismatch();
	}
	/* Shortcuts */
	if (imOut->bands == 1) {
	return ImagingCopy2(imOut, imIn);
	}
	/* Special case for LXXA etc */
	if (imOut->bands == 2 && band == 1) {
	band = 3;
	}
	/* Insert band into image */
	for (y = 0; y < imIn->ysize; y++) {
	UINT8 *in = imIn->image8[y];
	UINT8 *out = (UINT8 *)imOut->image[y] + band;
	for (x = 0; x < imIn->xsize; x++) {
	*out = in[x];
	out += 4;
	}
	}
	return imOut;
	}

So it is loading the raw data one channel/layer/band at a time, but when the data is decoded it is being stored as "rgbrgbrgb", not "rrrgggbbb".

[radarhere]

What would be the advantage to storing the data as rrrgggbbb? If it is so that another library can use Pillow's C code directly, then my response is that Pillow is a Python library that happens to have C code inside it, not a C library.

[Yay295]

Yep, that makes sense. Check my other comment; I was mistaken about Pillow already using multiple data layouts.

[Yay295]

The interleaved data I had remembered seeing is actually in the unpacking code:

Pillow/src/libImaging/Unpack.c

Lines 415 to 435 in d72779a

	static void
	unpackLA(UINT8 *_out, const UINT8 *in, int pixels) {
	int i;
	/* LA, pixel interleaved */
	for (i = 0; i < pixels; i++) {
	UINT32 iv = MAKE_UINT32(in[0], in[0], in[0], in[1]);
	memcpy(_out, &iv, sizeof(iv));
	in += 2;
	_out += 4;
	}
	}
	static void
	unpackLAL(UINT8 *_out, const UINT8 *in, int pixels) {
	int i;
	/* LA, line interleaved */
	for (i = 0; i < pixels; i++, _out += 4) {
	UINT32 iv = MAKE_UINT32(in[i], in[i], in[i], in[i + pixels]);
	memcpy(_out, &iv, sizeof(iv));
	}
	}

So after the data is unpacked, it is being stored as "band interleaved by pixel", not "band interleaved by line". So this isn't an issue; all image data is being stored the same after decoding/unpacking.