1994.12.14 23:51 "Re: JBIG compression", by Sam Leffler

Is there anybody that is working on JBIG compression/decompression? (besides Image Magic, MA USA)

My understanding is that JBIG requires the licensing of several patents. This makes it an unlikely candidate for a free software package such as mine. I have, however, gotten together with the JBIG folks so that the next distribution of the library will better support "plug-in decoders", such as JBIG. That is, to add a new codec you won't need to modify the library; all that you'll need is an additional .o file and either recompilation or a substitute for the codec configuration table.

Also, can the current libtiff G4 decompression implementation be improved? What sort of improvements can be expected?

What's wrong with the current implementation?

I was surprised to find a reference to J.D.Murray, W.vanRyper, "Encyclopedia of Graphics File Formats", O'Reilly & Associates, Inc. 1994, pp.148 which stated that some implementations of G4 encode as fast as G3, and decode even faster.

G4 decoding can be faster than G3 depending on the algorithm used. the above statement is, however, fairly specious.

The G3/G4 decoder in the TIFF library is built on a single set of FSM tables and is quite fast; though the size of the state tables can cause problems on small-memory machines. The v3.3beta021 code has some mods to speed up the decoder. I've just received some other mods that inline certain routines and speedup the decoder some more on certain CISC-style architectures.

I don't want to get into algorithmic issues, my question is, is there room for >15% improvement on G4 for the impelmentation of libtiff?

Until you cite specific goals (and architecture for running the software) this question is silly. Try measuring the performance of the current algorithm before looking for improvements.

    Sam