[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zlib-devel
Subject:    [Zlib-devel] compressBound
From:       tringi () mx-3 ! cz (=?iso-8859-2?Q?Jan_Ringo=B9?=)
Date:       2005-03-03 1:52:08
Message-ID: 005001c51fa3$aff841a0$62219453 () merovingian
[Download RAW message or body]

Oh, I almost forgot to thank you for those good ideas.
As the file format isn't out of dev yet, I'll use the first approach and will 
consult use of the negative windowBits value. I am not sure if I can afford to 
loose the checksum value ...but adding one myself into the new header would do 
the trick :-)

---
Jan Ringo?, Tringi at Mx-3.cz
http://Tringi.Mx-3.cz


----- Original Message ----- 
From: "Gilles Vollant" <info at winimage.com>
To: <zlib-devel at zlib.net>
Cc: <tringi at mx-3.cz>
Sent: Tuesday, March 01, 2005 6:40 AM
Subject: RE: [Zlib-devel] compressBound


I can suggest two ideas:
- if you can change the format specification, you can add one byte at the
beginning to say if this is raw or deflate.
So in a 65472 bytes long clusters, you are sure you'll be able to store at
least 65471 bytes
other tips : use deflateInit2 with negative windowBits (and same value on
inflateInit2) to remove zLib header. This can save between 6 and 10 bytes (I
don't remember)

- if you can't change the specification, try compress with Z_NO_COMPRESSION
(0) compression level. This must be stable (X bytes lenght data to compress
will always give the same Y length data "deflated").

You will discover that Z_NO_COMPRESSION can store always X bytes in 65472
bytes. So if the standard compress return more than 65472 bytes, you will
just recompress with Z_NOCOMPRESSION and be absolutely sure you'll get less
than 65471 bytes

-----Original Message-----
From: Jan Ringo? [mailto:tringi at mx-3.cz]
Sent: Tuesday, March 01, 2005 1:26 AM
To: zlib-devel at zlib.net
Subject: [Zlib-devel] compressBound

Hi,

I would like to ask, how exact the compressBound function is?
I see the function is pretty simple, so I am afraid that the actual maximum
compress' output size may be smaller.

Well my problem is to get as many compressed data as possible into up to
65472 bytes long clusters. For simplicity I use compress/uncompress function
to compress 65443 bytes of data (compressBound (65472)).

I would like to know, if it is possible and absolutely safe to write more.
My current testing says that I may compress 65446 bytes and even with random
data I still get exactly into 65472 bytes boundary. But I would like to be
sure, not to get crashing in some rare situation.

I know, it is only 3 bytes, but it may save me from allocating 4096 bytes
long sector ;-)

---





[prev in list] [next in list] [prev in thread] [next in thread]