Algorithm 为什么GIF规范要求初始LZW代码大小至少为2位？

我一直在试图弄明白为什么GIF89a规范要求初始LZW代码大小至少为2位，即使在编码1位图像（B&W）时也是如此。规范附录F中规定如下：

确定代码大小

压缩数据流的第一字节是一个值，指示表示实际像素值集所需的最小位数。通常这将与颜色位的数量相同。但是，由于一些算法限制，具有一个颜色位的黑白图像必须表示为代码大小为2

---

我很好奇这些算法约束是什么。什么可能阻止GIF中使用的LZW变体使用1的代码大小？这只是早期编码器或解码器的局限性吗？或者是否存在一些奇怪的边缘情况，可以通过正确的位组合来表现自己？或者这里发生了完全不同的事情吗？

除了

0

和

1

的代码外，还有

清除的
代码和
信息结束的代码

引述自：

输出代码长度可变，从每分钟+1位开始
代码，每个代码最多12位。这定义了最大代码值4095
（0xFFF）。每当LZW代码值超过当前代码长度时
代码长度增加1

如果开始时代码大小为1，则需要根据此规则立即增加代码大小。
此限制在实现中消除了一个
If
（当codesize==1时，第一个词汇短语code的宽度==codesize+2，在所有其他情况下，宽度==codesize+1）。

缺点是双色图片的压缩比下降很小。
我对该规范不太熟悉，但是否也需要某种EOF符号（除了0和1）？@500 InternalServerError是的，CC和stop保留了两个额外的代码。但是，当您写出初始代码大小时，您不包括这些，因为它们总是在那里。但是
清除
代码总是需要n+1位的定义，我看不出1位的情况会有什么不同。@MarkRansom-抱歉，修复了。@EgorSkriptunoff我想您这里可能有些东西。对于1位颜色表，第一个添加的条目将自动扩展宽度，抵消使用较小宽度所节省的任何费用。事实上，这意味着您最多只能保存1位，因为只有第一个像素会以较小的代码大小进行编码。有了这个规则，解码器的实现可能会稍微容易一些，特别是在1987年GIF第一次被实现的机器上。是的，但不管颜色深度如何，这都是事实。但是1位和2位颜色都应该具有相同的初始代码大小，这意味着在1位颜色深度的情况下，每个代码将浪费一位。@DennisMunsie代码总是从n+1位开始。对于n=1，表格从一开始就完全开始，取下所有4个可能的值：
0
，
1
，
清除
，
EOI
。对于
n
的任何其他值，表格一开始并不完整-对于n=2，使用8中的6，对于n=3，使用16中的10，等等。我认为在你和@EgorSkriptunoff的答案之间，我有足够的理由说这已经得到了回答。因为我只能将一个答案标记为“正确”，所以我要将这个答案标记为正确，因为它看起来像是你首先回答的。谢谢你们两位！