Q&A

How do I select specific transforms at runtime instead of using compression levels?

You provide the transform using the -t (or --transform=) command line option followed by the transform(s).

Example: -t TEXT or -t RLT+TEXT+UTF+LZ

How many threads are going to be used during (de)compression ?

By default, kanzi detects the number of cores in the CPU and uses half of the cores. The maximum number of parallel jobs allowed is hard coded to 64.

Providing -j 1 on the command line makes (de)compression use one core.

Providing -j 0 on the command line makes (de)compression use all available cores.

Can kanzi (de)compress full folders ?

Yes, if the input source provided on the command line is a directory, all files under that folder are going be recursively processed.

The files will be processed in parallel if more than one core is available.

To avoid recursion and process only the top level folder, use a dot syntax:

EG. -i ~/myfolder/. on Linux
EB. -i c:\users\programs\. on Windows

When processing a folder, can kanzi avoid processing link files or dot files ?

Yes, to avoid processing link files, add this option to the command line --no-link

To avoid processing dt files, add this option to the command line --no-dot-file

Does kanzi support pipes and input/output redirection ?

Yes, one way to do it is to use STDIN/STDOUT as input/output on the commans line:

 gunzip /tmp/kanzi.1.gz  | kanzi  -c -i stdin -l 2 -o /tmp/kanzi.1.knz

Or, using redirections,

kanzi -c -f -l 2 < /tmp/enwik8 > /tmp/enwik8.knz

If -i is absent from the command line, the data is assumed to come from STDIN and go to STDOUT. Another example (processing a 0 length pseudo-file !):

cat /proc/stat  | kanzi -c -i stdin -l 0 -o /tmp/stat.knz 
kanzi -d -i /tmp/stat.knz -o stdout

Notice that, during compression, kanzi uses the size of the input file (when it is available) to provide a hint in the bitstream that the decompressor can use to optimize the amount of resources to allocate. Thus, providing -i and -o is recommended over redirection for performance.

Does kanzi produce a seekable stream ?

Yes, it is possible to decompress only one or a sequence of consecutive blocks by using the --from and --to options during decompression.

kanzi -d -i /tmp/book1.knz -v 4 -f

Block 1: 34451 => 36530 [0 ms] => 65536 [0 ms]
Block 2: 33295 => 35330 [0 ms] => 65536 [0 ms]
Block 3: 33702 => 35807 [0 ms] => 65536 [0 ms]
Block 4: 33555 => 35502 [0 ms] => 65536 [0 ms]
Block 5: 34057 => 36065 [0 ms] => 65536 [0 ms]
Block 6: 33556 => 35622 [0 ms] => 65536 [0 ms]
Block 7: 33357 => 35167 [0 ms] => 65536 [0 ms]
Block 8: 33460 => 35446 [0 ms] => 65536 [0 ms]
Block 9: 33428 => 35431 [0 ms] => 65536 [0 ms]
Block 10: 33177 => 35180 [0 ms] => 65536 [0 ms]
Block 11: 33218 => 35156 [0 ms] => 65536 [0 ms]
Block 12: 24871 => 26246 [0 ms] => 47875 [0 ms]

Decompressing:     1 ms
Input size:        394176
Output size:       768771
Throughput (KB/s): 750752


kanzi -d -i /tmp/book1.knz -v 4 -f  --from=4 --to=10

Block 4: 33555 => 35502 [0 ms] => 65536 [0 ms]
Block 5: 34057 => 36065 [0 ms] => 65536 [0 ms]
Block 6: 33556 => 35622 [0 ms] => 65536 [0 ms]
Block 7: 33357 => 35167 [0 ms] => 65536 [0 ms]
Block 8: 33460 => 35446 [0 ms] => 65536 [0 ms]
Block 9: 33428 => 35431 [0 ms] => 65536 [0 ms]

Decompressing:     1 ms
Input size:        394176
Output size:       393216
Throughput (KB/s): 384000

Will kanzi bitstream be backward compatible in future releases ?

Yes, the bitstream version is part of the bitstream header and will be used during decompression to ensure that old versions can be decompressed.