DeflateStream & GZipStream
-
I've been using the DeflateStream and the GZipStream for a while and recently I found out that both streams produced an excessive amount of data when compressing data. Here is my question: Is there a bug in the compression algorythm?
-
I've been using the DeflateStream and the GZipStream for a while and recently I found out that both streams produced an excessive amount of data when compressing data. Here is my question: Is there a bug in the compression algorythm?
ant-damage wrote:
produced an excessive amount of data when compressing data
What are you compressing? The LZ77 algorithm can actually create MORE data depending on what your compressing.
ant-damage wrote:
Is there a bug in the compression algorythm?
No. Best Wishes, -David Delaune
-
ant-damage wrote:
produced an excessive amount of data when compressing data
What are you compressing? The LZ77 algorithm can actually create MORE data depending on what your compressing.
ant-damage wrote:
Is there a bug in the compression algorythm?
No. Best Wishes, -David Delaune
I'm compressing a binary file. it is a 678KB file, and after compressing all bytes of it with DeflateStream I've got 1MB of data. I used the zlib compression library on the same file and I'v got a smaller file with 671KB. I searched around the web and I found out that it's possible that the DeflateStream algorythm has a bug, and generates too much data compared with the original file data.
-
I'm compressing a binary file. it is a 678KB file, and after compressing all bytes of it with DeflateStream I've got 1MB of data. I used the zlib compression library on the same file and I'v got a smaller file with 671KB. I searched around the web and I found out that it's possible that the DeflateStream algorythm has a bug, and generates too much data compared with the original file data.
ant-damage wrote:
after compressing all bytes of it with DeflateStream I've got 1MB of data.
Did you mean compressing with GZipStream? Because... DeflateStream does not do compression.
ant-damage wrote:
I searched around the web and I found out that it's possible that the DeflateStream algorythm has a bug, and generates too much data compared with the original file data.
The GZipStream class does not check for incompressible data. Yes it is possible to create more data.. this is the nature of the algorithm. I guess it would be better if the GZipStream class detected that it would be unable to compress the data. Classifying it as a bug is debatable. I agree with you that the GZipStream class should be smart and detect this situation. Best Wishes, -David Delaune
-
ant-damage wrote:
after compressing all bytes of it with DeflateStream I've got 1MB of data.
Did you mean compressing with GZipStream? Because... DeflateStream does not do compression.
ant-damage wrote:
I searched around the web and I found out that it's possible that the DeflateStream algorythm has a bug, and generates too much data compared with the original file data.
The GZipStream class does not check for incompressible data. Yes it is possible to create more data.. this is the nature of the algorithm. I guess it would be better if the GZipStream class detected that it would be unable to compress the data. Classifying it as a bug is debatable. I agree with you that the GZipStream class should be smart and detect this situation. Best Wishes, -David Delaune
-
I'm compressing a binary file. it is a 678KB file, and after compressing all bytes of it with DeflateStream I've got 1MB of data. I used the zlib compression library on the same file and I'v got a smaller file with 671KB. I searched around the web and I found out that it's possible that the DeflateStream algorythm has a bug, and generates too much data compared with the original file data.
I have found that the results are better when you use the biggest possible Write (so buffer first, then write it all out at once). It's slower of course, but for some reason this implementation gives really poor results on small writes. Such a big expansion seems excessive though. It can only happen due to crappy implementation, since the Deflate spec contains an escape mechanism to store uncompressed data with only tiny overhead, but then this implementation is not known for being good in any way.