我已經試圖找出爲什麼的GIF89a規範要求，初始LZW代碼大小爲至少2比特，編碼1位圖像（B & W）時也是如此。在規範中的附錄F，它說以下內容：爲什麼GIF規格要求初始LZW編碼大小至少2位？
ESTABLISH代碼大小
所述壓縮數據流的第一個字節是表示以表示所述一組實際的像素所需的最小比特數的值值。通常這與顏色位的數量相同。然而，因爲一些算法的限制，其中有一個顏色位黑色&白色圖像必須標明爲具有2
我很好奇，什麼這些算法的限制是一個代碼大小。什麼可能會阻止GIF中使用的LZW變體使用1的代碼大小？這僅僅是早期編碼器或解碼器的限制嗎？還是有一些奇怪的邊緣情況可以用恰當的位組合來表現自己？還是在這裏有完全不同的東西？
除了代碼0和1，您還有一個clear代碼和一個end of information代碼。
從the spec引用：
輸出代碼是可變長的，開始於每 碼+1位，最多每碼12個比特。這定義的4095 （0xFFF的）的最大碼值。每當LZW代碼值將超過當前的代碼長度，則 代碼長度被增加一。
如果您從代碼大小1開始，則需要通過此規則立即增加代碼大小。
是的，但無論顏色深度如何，這都是事實。但1位和2位的顏色都應該有相同的初始代碼大小，這意味着會有浪費於在1位顏色深度情況下，每個碼的一個比特。 –
@DennisMunsie代碼總是以n + 1位開始。對於n = 1，表從一開始就開始全部右移，並且所有4個可能的值都被採用：'0'，'1'，'clear'，'EOI'。對於任何其他的n值，表格不會全部開始 - 對於n = 2，你使用8中的6，對於n = 3，你使用16中的10等等。 –
我想你和@ EgorSkriptunoff的答案，我已經足夠說這已被回答。由於我只能將一個答案標記爲「正確」，所以我會將其標記爲正確的，因爲它看起來像是你先回答的。感謝你們兩位！ –
這個限制在實現中擺脫了一個if（代碼大小== 1，第一個詞彙表短語代碼的寬度== codesize + 2，其他所有情況下的寬度== codesize + 1）。
缺點是非常小的壓縮比降低爲2色圖像。
但是'clear'代碼總是需要n + 1個比特，我沒有看到1比特情況會有什麼不同。 –
@MarkRansom - 抱歉，已修復。 –
@EgorSkriptunoff我想你可能在這裏有一些東西。使用1位色表時，第一個添加的條目將自動擴展寬度，從而減少使用較小寬度所節省的空間。實際上，這意味着您可以節省的最多隻有1位，因爲只有第一個像素會使用較小的代碼尺寸進行編碼。有了這個規則，可能會使解碼器的實現稍微容易一些，特別是在GIF首次實施時的1987年的機器上。 –
我對這個規範並不熟悉，但也不需要某種EOF符號（除了0和1）？ –
@ 500-InternalServerError是的，有兩個額外的代碼保留給CC並停止。但是當你寫出初始代碼大小時，你不會包含這些內容，因爲它們總是在那裏。 –