Compression Issue? about k4os.compression.lz4 HOT 3 CLOSED

Does original lz4.exe (https://github.com/lz4/lz4/releases/tag/v1.9.4) compress any better?
If so, then we might have a bug here, if not then this is just related to LZ4 as algorithm.

Some notes though:
LZ4 is fast compression algorithm, not high compression algorithm nor general purpose compression algorithm (those terms actually carry meaning). It uses dictionary compression, so its compression depends on repeated data.

Your comment about "not even the strings are compressed" suggest that you expected Huffman coding (which is quite common and relatively slow) but it is not part of LZ4 algorithm.

So, does lz4.exe produce different results?

from k4os.compression.lz4.

Hi thanks for the quick reply.

I am trying to replace a part of this library (https://github.com/Norbyte/lslib) that works with a native lz4 implementation.

The native implementation is here:
https://github.com/Norbyte/lslib/tree/master/LSLibNative/lz4

I have no idea about compression algorithms, at least a method is called that ends with "HC", probably "Huffman Coding" is meant.

Now when I use lz4 directly, the result is almost the same, so it won't be a bug.

lz4.exe -z -12 Globals.lsf

Compressed filename will be : Globals.lsf.lz4
Compressed 20856981 bytes into 18077530 bytes ==> 86.67%

But what I find interesting is that this is decompressed correctly. Only not compressed again.

The compressed file:
Globals.lsf.compressed.zip

Basically, I just want to decompress the data and compress it again as if it were original - at least close to it.

from k4os.compression.lz4.

I have no idea about compression algorithms, at least a method is called that ends with "HC", probably "Huffman Coding" is meant.

Never thought about this way of reading "HC", but no, HC here stands for High Compression.

Now when I use lz4 directly, the result is almost the same, so it won't be a bug.

lz4.exe -z -12 Globals.lsf

Compressed filename will be : Globals.lsf.lz4
Compressed 20856981 bytes into 18077530 bytes ==> 86.67%

Ok, so it is as expected then.

But what I find interesting is that this is decompressed correctly. Only not compressed again.

This is also expected. There are more settings than just compression level, like block size, checksums, etc. So files might be slightly different, but compatible.

Basically, I just want to decompress the data and compress it again as if it were original - at least close to it.

So yes, this is the way to do it.

from k4os.compression.lz4.