Re: huffman encoder
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 24 Dec 2005 08:38:25 +1000
<aarklon@xxxxxxxxx> wrote in message
news:1135306561.078291.197850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi all,
>
> this is the program which I saw in my colleagues book. the program was
> run on turbo C++ 3.0 compiler
>
<snip>
this was imo very inefficient code...
>
> now my questions are
>
> 1) how can the function freetree be implemented properly.
>
as written, it should work, but I have (personally) had some bad experiences
with malloc/free's behavior in the past.
imo, a better alternative is that of not using malloc/free on each node,
instead allocating an array of nodes (for 256 leaves, only 255 extra nodes
are needed, this pattern holds with larger numbers, eg, n-1 extra are
needed). on can, however, use a full 256 to make things more even.
when building a new tree, one starts at the start of the array and uses up
the nodes in the array.
(some implementations may not even build a tree of nodes, as I imagine is
possibly the case with deflate).
> 2) can anybody explain refreshbuffer funcion
> i mean refresh buffer function writes the encoded bit pattern
> using
> fputc function.
>
> the function of fputc function is as follows
>
> int fputc(int ch, FILE *stream);
>
> Writes a character (an unsigned char) specified by the argument ch
> to the specified stream and advances the position indicator for the
> stream.On success the character is returned. If an error occurs,
> the error indicator for the stream is set and EOF is returned.
>
> now my question is how compression is achieved,if we are writing ints
>
errm...
the total number of fputc's is a smaller that the total number of fgetc's...
not like you can read or write bits to the file directly...
the whole damn int does not go to the file, only the byte value of the int.
ints free one from having to worry about signed/unsigned issues in these
cases, and also allow things like fgetc to return -1 on error.
> 3) what exactly is the purpose served by these two statements in this
> program???
>
> fputc(getoddchar(),fq);
> fputc(bc,fq);
>
flushing the (incomplete last bits), eg, so the last char is not truncated.
next one, maybe a sanity check, or a means of indicating eof, but I am
unsure (it is unclear how the decoder will know exactly when the eof is).
guess:
it reads in the input size, gets the last char;
it decodes characters so long as there are more input bits related.
or:
it reads values into the decode buffer, also reading in the next byte;
on eof it knows it has reached the end of the stream, maybe only decoding
chars so long as bits are left.
or something like that...
.
- Follow-Ups:
- Re: huffman encoder
- From: aarklon
- Re: huffman encoder
- References:
- huffman encoder
- From: aarklon
- huffman encoder
- Prev by Date: Re: JPEG compression in a TIFF file, pointless?
- Next by Date: Re: huffman encoder
- Previous by thread: huffman encoder
- Next by thread: Re: huffman encoder
- Index(es):
Relevant Pages
|