AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.12.14 22:00 "JBIG compression", by Kyriakos Georgiou
1994.12.14 23:51 "Re: JBIG compression", by Sam Leffler
1994.12.16 18:00 "Re: JBIG compression", by Fredrik Lundh
1994.12.16 21:02 "Re: JBIG compression", by Kyriakos Georgiou
1994.12.16 21:17 "Re: JBIG compression", by Sam Leffler
1994.12.16 22:04 "Re: JBIG compression", by Rick Richardson
1994.12.16 22:18 "Re: JBIG compression (really G3/G4 decompression)", by Sam Leffler
1994.12.15 09:59 "Further G4 improvement", by Karsten Spang

1994.12.16 21:02 "Re: JBIG compression", by Kyriakos Georgiou

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

What's wrong with the current implementation?

The current implementation is fine, but.. I have in my hands a commercial product (no source) that does decompression in noticable less time. That suggests that there are faster ways to decompress G4 in software, alas my question.

I don't want to get into algorithmic issues, my question is, is there room for >15% improvement on G4 for the implementation 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.

Unless you didn't understand what I am talking about - CCITT Group 4 decompression speed - I find this answer silly. What does the architecture have to do with algorithmic improvements? Perhaps you should read a computational theory and algorithms book before defining what silly questions are.

In response to your 2nd comment, why would I be looking for improvements if I had not measured the performance of the current algorithm? If you remember, few weeks ago I sent some remarks on the new improved G4 decompression running on a pentium.

K.Georgiou