识别/反向工程师lz压缩

我正在为Prototype（日本公司）发行的游戏的PSP版本进行翻译项目，但是我在处理某些GIM文件（图像文件）时遇到了麻烦。
现在实际的问题不是gim格式，而是gim文件上的压缩，但在此之前我先澄清一些事情。
GIM的某些工作，但是有时GIM文件似乎puyotools或GimConv（将gim转换为png的软件）都无法处理。无法使用的GIM在外观上有所不同。
我知道它的GIM文件是因为它以MIG.00.1PSP开头，尽管准确的说，它还是有些不同，写成这样： />
[integer equals 16, signature?] [integer equals 131792] [MIG.00.1PSP, but where a 00 HEX is placed between each hex byte]

像这样：

10 00 00 00 D0 02 02 00 4D 00 49 00 47 00 2E 00 30 00 30 00 2E 00 31 00 50 00 53 00 50 00 00 00

每个压缩的GIM文件都以这两个整数值开头（但是我具有较小分辨率的图像具有不同的第二个整数）。我已经准备好删除这两个整数并且还尝试替换M（00）I（00）G（00）。（00）0（00）0（00）。（00）1（00）P（00）S（ 00）P（00），仅带有MIG.00.1PSP，但最终使GIMConv说：错误的块数据。某种形式，但signersrch找不到任何东西，而TrID只找到：“ 100 .0％（。）LTAC压缩音频（v1.61）（1001/2）” .gim（黑色图像）
这是一个随机CG：未压缩的版本应该看起来像。请注意，第二行的前4个字节表示文件大小减去16。
另一件事是MIG.001.PSP之后的int，我从不同来源发现它是版本号。因此，所有压缩文件也应该都可以在该位置到达该int。

更新：我相信这是某种lz压缩，但是我还没有弄清楚哪一个。尝试过lz01，lz00，lz10，lz11，CXLZ，lzss。在我看来，它始于10个字节（如lz），它使MIG.001.PSP分隔为00，这是由于压缩依赖于值，密钥对，我相信密钥0意味着应该直接发送值到输出。 <-如果您确信它是我尝试过的压缩方式之一，请也说一遍，因为它很可能只是我用来尝试这些错误方式的工具。 GZIP和deflate已在C＃中使用.NET的System.IO.Compression进行了尝试，而其他版本已使用称为Puyo工具的其他项进行了尝试。等于零输出值到解压缩的数据。如果key大于零，则获得[Value，key-1]的短值。短加8乘以2得到的字节必须写两次以解压缩数据。换句话说，00 00 08 01将输出00 0000。唯一的问题是在第3行的black.gim示例中为0f01。这将指向15，即位置（15 + 8）* 2等于字节46，应在第二行中为02 00。但是，这是不正确的！因为我希望它在此处放置零，而不输出02 02 ..

简而言之，在black.gim示例中，我发现：
0C 01应该输出00 00 0D 01应该输出00 00 00
0F 01应该输出00 00

有什么建议吗？

如果有人可以给我一些输入或者铅:)