For Programmers: Free Programming Magazines  


Home > Archive > Compression > January 2006 > Re: DEFLATE, ZLIB dynamic Huffman compressed stream









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: DEFLATE, ZLIB dynamic Huffman compressed stream
George Wilson

2006-01-20, 3:55 am

Thanks for your replies.

I wanted to decode a DEFLATE compressed stream in
Dynamic mode (using
the optimized code lengths available within it) and
regenerate the same
DEFLATE compressed stream.

I tried to generate the same compressed data,
generated data has few
errors. I used the puff implementation (located inside
contrib folder
'ZLIB source code') to decode a ZLIB stream in Dynamic
mode.

Q:I have implemented DEFLATE implementation using the
module "local
void compress_block(s, ltree, dtree)" located in
"trees.c", zlib 1.2.3.
Should I subtract MIN_MATCH (defined as 3) value from
the decoded
length using puff before encoding ?

Any relevant information will be appreciated

George Wilson

Carsten Neubauer wrote:
> George Wilson wrote:
>
> possible, but pretty unlikely.
>
> starting from the uncompressed data, you would have to choose
> the same window-size and apply exactly the same LZ77-compression.
> only then it would make sense to reuse huffman-codes from another
> implementation.
>
>
> as matt stated, there can be several occurances of a string,
> while there's no rule, defining which one to refer to.
>
> string-matches can also overlap and block each other,
> for example theres 'abc...bcde...abcde'
> when approaching 'abcde' you can either replace 'abc' by
> a (length,dist)-pair and 'd' and 'e' by literals or alternatively
> encode 'a' as literal and 'bcde' with (length,dist).
>
> depending on memory- and speed-requirements, stringsearch and
> replacement do not have to be optimal.
> usually one tries to store previous occurances by using hash-tables.
> for a superfast low-memory-implementation, one would use a smaller
> table, possibly only store the first three bytes to compare with
> and 'forget' about previous similar matches. not checking blocking
> matches also speeds up compressing.
>
>
> to reproduce the output of an unknown LZ77-encoder you would have
> to analyze its behaviour in detail.
>
> perhaps you can write your own encoder, debug and compare with the
> stream generated by another compressor.
>
>
> hope it helps,
> carsten neubauer
> http://www.c14sw.de/


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com