< prev index next >

src/java.desktop/share/native/libjavajpeg/jchuff.c

Print this page




 788         ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
 789 
 790       bits[codesize[i]]++;
 791     }
 792   }
 793 
 794   /* JPEG doesn't allow symbols with code lengths over 16 bits, so if the pure
 795    * Huffman procedure assigned any such lengths, we must adjust the coding.
 796    * Here is what the JPEG spec says about how this next bit works:
 797    * Since symbols are paired for the longest Huffman code, the symbols are
 798    * removed from this length category two at a time.  The prefix for the pair
 799    * (which is one bit shorter) is allocated to one of the pair; then,
 800    * skipping the BITS entry for that prefix length, a code word from the next
 801    * shortest nonzero BITS entry is converted into a prefix for two code words
 802    * one bit longer.
 803    */
 804 
 805   for (i = MAX_CLEN; i > 16; i--) {
 806     while (bits[i] > 0) {
 807       j = i - 2;                /* find length of new prefix to be used */
 808       while (bits[j] == 0)


 809         j--;

 810 
 811       bits[i] -= 2;             /* remove two symbols */
 812       bits[i-1]++;              /* one goes in this length */
 813       bits[j+1] += 2;           /* two new symbols in this length */
 814       bits[j]--;                /* symbol of this length is now a prefix */
 815     }
 816   }
 817 
 818   /* Remove the count for the pseudo-symbol 256 from the largest codelength */
 819   while (bits[i] == 0)          /* find largest codelength still in use */
 820     i--;
 821   bits[i]--;
 822 
 823   /* Return final symbol counts (only for lengths 0..16) */
 824   MEMCOPY(htbl->bits, bits, SIZEOF(htbl->bits));
 825 
 826   /* Return a list of the symbols sorted by code length */
 827   /* It's not real clear to me why we don't need to consider the codelength
 828    * changes made above, but the JPEG spec seems to think this works.
 829    */




 788         ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
 789 
 790       bits[codesize[i]]++;
 791     }
 792   }
 793 
 794   /* JPEG doesn't allow symbols with code lengths over 16 bits, so if the pure
 795    * Huffman procedure assigned any such lengths, we must adjust the coding.
 796    * Here is what the JPEG spec says about how this next bit works:
 797    * Since symbols are paired for the longest Huffman code, the symbols are
 798    * removed from this length category two at a time.  The prefix for the pair
 799    * (which is one bit shorter) is allocated to one of the pair; then,
 800    * skipping the BITS entry for that prefix length, a code word from the next
 801    * shortest nonzero BITS entry is converted into a prefix for two code words
 802    * one bit longer.
 803    */
 804 
 805   for (i = MAX_CLEN; i > 16; i--) {
 806     while (bits[i] > 0) {
 807       j = i - 2;                /* find length of new prefix to be used */
 808       while (bits[j] == 0) { 
 809         if (j == 0) 
 810           ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); 
 811         j--; 
 812       } 
 813 
 814       bits[i] -= 2;             /* remove two symbols */
 815       bits[i-1]++;              /* one goes in this length */
 816       bits[j+1] += 2;           /* two new symbols in this length */
 817       bits[j]--;                /* symbol of this length is now a prefix */
 818     }
 819   }
 820 
 821   /* Remove the count for the pseudo-symbol 256 from the largest codelength */
 822   while (bits[i] == 0)          /* find largest codelength still in use */
 823     i--;
 824   bits[i]--;
 825 
 826   /* Return final symbol counts (only for lengths 0..16) */
 827   MEMCOPY(htbl->bits, bits, SIZEOF(htbl->bits));
 828 
 829   /* Return a list of the symbols sorted by code length */
 830   /* It's not real clear to me why we don't need to consider the codelength
 831    * changes made above, but the JPEG spec seems to think this works.
 832    */


< prev index next >