Deflate

[f.hump]

Написал кодер Deflate. При построении кодов Хаффмана, если наибольшая длина кодов меньше или равна максимально допустимой для Deflate, все хорошо. В противном случае мне было лень вращать дерево, поэтому все символы с длиной кода большей максимально разрешенной просто добавил к символам максимально разрешенной длины, в общем сделал такое

колво_кодов_максимальной_длины += колво_кодов_длиной_больше_максималь ной;

фор (и=1;;и++) {
колво_кодов_максимальной_длины += колво_кодов_длиной_(максимальная_дл ина - и);
колво_кодов_длиной_(максимальная_дл ина - и) = 0;

если емкость_кодов_максимальной_длины >= колво_кодов_максимальной_длины брейк;
}

и проблема тут в том, при таком раскладе, чужие декодеры меня не понимают. Может кто знает, что не так? Что я тут упустил? Какие требования выносятся к кодам Хаффмана в данном случае?

[f.hump]

повращал дерево честно и дело пошло на лад. вопрос закрыт.

[f.hump]

спрашивается зачем в PNG используется ZLIB? из-за двух байт заголовка? как это ни странно, ADLER32 в PNG не используется.

[Пепел Феникса]

Сообщение от f.hump

спрашивается зачем в PNG используется ZLIB? из-за двух байт заголовка? как это ни странно, ADLER32 в PNG не используется.

а зачем им реализовывать еще одну реализацию сжатия если есть готовая?

[f.hump]

сори, это я просто о наболевшем писал.
сделал кодер PNG, согласно вот этому http://www.ietf.org/rfc/rfc1950.txt правильный zlib стрим должен заканчиваться чек-суммой ADLER32, но софтина (Corel, XnView) по всей видимости использующая опен-сорс декодеры, отказывалась принимать мои PNG пока я не выкинул ADLER32 из zlib стрима, что на мой взгляд лишено смысла. в итоге от zlib отсталось только два байта заголовка, и поскольку единственный метод сжатия, который на данный момент поддерживается zlib это Deflate, я не понимаю зачем тогда вообще использовать zlib заголовок.