Re: Help understanding Arith coding



I think I understand the difference implied between the 16 bit and 32 bit
accuracy. An an adaptive model surely seems the way to go -especially on
smaller files. If one were to be generally using a similar input and getting
files of the same type i.e same characters with similar frequency
distibutions - would it be possible to set up an adaptive model to cater for
a set of know characters and thus maximise the compression of the file?

Thanks

<avtomatkalashnikov@xxxxxxx> wrote in message
news:1132330630.306416.91050@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> to maximize the compression you could:
>
> 1. use an adaptive model or quasi static model. try to google, i think
> something like this shouldn`t be hard to find. note that this in most
> cases doesn`t really mean that you gain compression, but the advantage
> is, that you don`t have to save the model to the stream. imagine you
> use 16 bit counts and don`t got a clever way to store them, they take
> 512 bytes, not that much, but if you use more bits for the counts, eg
> 32, you got 1k. this is quiet messy. if you use higher orders than
> order 0, saving the counts really gets a problem.
>
> 2. try to increase the coder`s precision, use 32 or even 64 bit
> integers for calculation instead of the 16 bit solution, using more
> bits also allows the coder to use more bits for frequency
> representation, which gives a better approximation for the symbol
> distribution. here is a short explanation:
>
> let n be the maximum number of bits available for calculations, r the
> size of an arithmetic register and f the number of bits for frequency
> storage.
>
> range = high - low + 1 will at most result in a binary number
> containing r + 1 bits.
> range * symbol_xxx (xxx is low or high) will at most result in an
> integer containing r + 1 + f bits.
> so the condition
>
> n > r + f + 1 must be fullfilled, to avoid overflows.
>
> typically we have:
> 32 > 16 + 14 + 1 for a 16 bit implementation
> 64 > 32 + 30 + 1 for a 32 bit implementation
>


.



Relevant Pages

  • Re: Reduce numbers to one number
    ... jpg is lossy in that the uncompressed image doesn't equal the original. ... more to compression. ... could jump up to 16 bit "characters" e.g. unicode. ...
    (sci.math)
  • Re: Some questions
    ... Briefly some methods uses 2 or even 4 byte per characters, ... compressible you can achieve compression on most files." ... The very problem is that on a pure etropic file you cast prediction on ... sort (or otherwise give an alternative representation) of such a file ...
    (comp.compression)
  • Re: mp3AIFF
    ... A quick lesson in lossy compression... ... AAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAABBBBBBBBBCCCCCCCAABBBBBBBBBBBBBB ... Now the same information takes up 17 characters, ... That's lossless compression; you still have all the information. ...
    (uk.comp.sys.mac)
  • Re: compression API available in Java & C++?
    ... > "Monique Y. Mudama" wrote... ... >>> compression scheme that asume them. ... >> ASCII characters, and of those only the common ones that show up on ... > schema for mapping each character to 6 bits instead of 8. ...
    (comp.lang.java.programmer)
  • Re: Help understanding Arith coding
    ... An an adaptive model surely seems the way to go ... > Analysis of Arithmetic Coding for Data Compression ... > Paul G. Howard and Jeffrey Scott Vitter ... > My Crypto code ...
    (comp.compression)