TL;DR：如果我有足够的数据量，是否有机会解码自定义图片格式？请参阅最后的示例。

我有一个旧的 DOS diskmag（90 年代后期）的二进制文件。在使用 010 Editor、Kaitai Struct 和 Python 玩了几周后，我设法从这些文件中以某种方式获取了结构化数据。最终很容易，文件被内部索引并包含所有部分 - 就像 Doom WAD 一样，那几年没有什么出乎意料的。

所以现在我可以提取文本（存储为纯文本）、声音（主要存储为 PCM）、音乐（MOD、XM）、字体（位图）和图片。有些图片存储为简单的位图（不是带有标题的 BMP 等，只是原始像素数据），有些图片是用类似 PCX 的 RLE 算法压缩的，这对我来说不是问题。

但还有一些我不认识的其他压缩。假设对于我拥有的每张未知图片：

• 以像素为单位的尺寸（主要是 640x480）
• 颜色深度（始终为高颜色）
• 第一个二进制 blob（小，通常 1-2 kB，确切大小不同）
• 第二个二进制 blob（大，50-250 kB，确切大小不同）
• 在 DOSbox 中运行的 diskmag 图片的屏幕转储（是的！）

在我看来，斑点的大小取决于图片的复杂性和独特的使用颜色。另外我猜第一个 blob 是某种字典（或者可能是霍夫曼树？），而第二个 blob 包含压缩的图片内容本身。

在此之上，我怀疑有一些奇怪的自制有损压缩，因为边缘周围很容易识别伪影，甚至梯度填充区域中的 8x8 量化块。请参阅下面的示例，我有数千个。

所以我的问题是：有没有机会解码这些图片？我有足够的数据，还是我遗漏了什么？我认为我需要的一切就是识别压缩算法。有人可以帮我吗？我相信我可以像往常一样用 Python 完成其余的工作。

（抱歉没有直接链接二进制 blob，我在这里没有足够的声誉......）

编辑 1：添加示例 06-04002-0004 - 我发现的最小图片（212x160 像素）。

编辑2：我意识到diskmag EXE 里面有调试符号！一些有趣的函数名称是：

• RLEDecomp（这个是针对RLE打包的图片，我已经解决了）
• LZSS_解压
• InitHuffDecomp_
• 吼吼解压_
• BuildHuffTree_
• BuildHuffTreeImg_

我不能说它是否更有可能解码视频（是的，diskmag 引擎也有自己的视频格式，我还没有那么远），但也许它会有所帮助？

编辑 3：用于下载的 Diskmag EXE：https://filebin.ca/3kL3kgNAqlJI

示例 06-04002-0004

• 尺寸：212x160
• 高色
• 第一个二进制 blob： https://filebin.ca/3kJWIHFLZJ9X
• 第二个二进制 blob： https://filebin.ca/3kJWL5SqHlAK
• 屏幕转储：

示例 06-05000-0004

• 尺寸：640x480
• 高色
• 第一个二进制 blob： https://filebin.ca/3kF4G2r0DnXT
• 第二个二进制 blob： https://filebin.ca/3kF4wopld9QG
• 屏幕转储：

示例 06-05050-0004

• 尺寸：640x480
• 高色
• 第一个二进制 blob： https://filebin.ca/3kF7hbOexD7D
• 第二个二进制 blob： https://filebin.ca/3kF7lLgeaAQ7
• 屏幕转储：

示例 06-05483-0004

• 尺寸：312x480
• 高色
• 第一个二进制 blob： https://filebin.ca/3kFAGWNEnNdM
• 第二个二进制 blob： https://filebin.ca/3kFAJdwtohzB
• 屏幕转储：

示例 06-07011-0004

• 尺寸：640x480
• 高色
• 第一个二进制 blob： https://filebin.ca/3kFGUQGcMZqD
• 第二个二进制 blob： https://filebin.ca/3kFGRc37e2pm
• 屏幕转储：