Why is "no code allowed to be all ones" in libjpeg's Huffman decoding? -


i'm trying satisfy myself meteosat images i'm getting ftp server valid images. doubt arises because tools i've used far complain "bogus huffman table definition" - yet when comment out error message, image appears quite plausible (a greyscale segment of earth's disc).

from https://github.com/libjpeg-turbo/libjpeg-turbo/blob/jpeg-8d/jdhuff.c#l379:

while (huffsize[p]) {   while (((int) huffsize[p]) == si) {     huffcode[p++] = code;     code++;   }   /* code 1 more last code used codelength si;    * must still fit in si bits, since no code allowed ones.    */   if (((int32) code) >= (((int32) 1) << si))     errexit(cinfo, jerr_bad_huff_table);   code <<= 1;   si++; } 

if comment out check, or add check huffsize[p] nonzero (as in containing loop's controlling expression), djpeg manages convert image bmp can view few problems.

why comment claim all-ones codes not allowed?

it claims because not allowed. doesn't mean there can't images out there don't comply standard.

the reason not allowed (from standard):

making entropy-coded segments integer number of bytes performed follows: huffman coding, 1-bits used, if necessary, pad end of compressed data complete final byte of segment.

if 1's code allowed, end ambiguity in last byte of compressed data padded 1's coded symbol.


Comments

Popular posts from this blog

resizing Telegram inline keyboard -

command line - How can a Python program background itself? -

php - "cURL error 28: Resolving timed out" on Wordpress on Azure App Service on Linux -