The JBIG2 format allows countless ways to encode any given image.
One of the first things a JBIG2 encoder must do is segment the image into its constituent symbols. The JBIG2 specs place no restrictions on how to do that. Therefore, every vendor creates their own proprietary algorithm to segment the image in the manner which they believe will lead to the greatest compression savings. Each of these symbols must then be encoded, as well as the information on how to position them.
Each of these decisions presents a wide range of options to the encoder. For example, let’s say an image contains 5,000 characters and the symbol stream contains 5,000 symbols, one for each character. As the JBIG2 specs don’t say in what order the symbols should be encoded, the encoder must choose the optimal ordering of the symbols. Of all the possible orderings, some of them will result in the smallest file size, while some of them may be so bad that the JBIG2 file could be even bigger than the original TIFF file!
Algorithms and Quality of JBIG2 Implementations
Because the encoder can decide on the ordering, various JBIG2 vendors can each develop their own algorithms to minimize this part of the file size cost. The JBIG2 specifications provide a framework which enables great compression savings when used properly. The best manner to take advantage of it is an area of ongoing research and so the difference in file size between different JBIG2 implementations can vary drastically.
The ordering of the symbols within a JBIG2 stream does not in anyway affect image quality. While a naive ordering may not get the full compression savings available under the JBIG2 format, the resulting compressed file will still look fine. It does, however, provide another way for a good JBIG2 encoder to differentiate itself from the pack, by offering a significantly better compression ratio.
Because the encoder can decide on the ordering, various JBIG2 vendors can each develop their own algorithms to minimize this part of the file size cost.