TIFF and LibTiff Mail List Archive


1997.06.02 08:39 "CCITT Grp 4 decoder bug", by Dieter Stueken
1997.06.02 16:14 "Re: CCITT Grp 4 decoder bug", by Ken Land
1997.06.02 17:00 "Re: CCITT Grp 4 decoder bug", by Bjorn Brox
1997.06.02 17:26 "Re: CCITT Grp 4 decoder bug", by Dieter Stueken
1997.06.03 08:41 "Re: CCITT Grp 4 decoder bug", by Dr. Klaus Bartz

1997.06.03 08:41 "Re: CCITT Grp 4 decoder bug", by Dr. Klaus Bartz

hello Dieter,

it is not a bug, it is a feature!

Do you have realy a real TIFF file with the compression format CCITT t.6 and the data coherence format untiled ( striped is a problem (but possible), because the expanded strip size is greater than 8K bytes) bigger than 64 K pixel in one dimension as input? Can I have it ( if the second dimension is big too and if it is a real image)? Or do you want to create that images? Then use tiles and you can go to the next problem of limitations. It is possible, that there are more problems than you want. You are going out of the 32 bit world.

In the last monthes there are some discussions related to limits of tiflib / TIFF ( if needed I can forward that emails ).

For some years I have implemented a 32 bit encoder/decoder for TIFF G4 by my self with theoretical support up to 1 M * 1 M pixel ( tested up to 210 K * 130 K pixel). Of course with tiles, 32 bit buffers, buffer police, scaling and rotation on a intermediaer code an so on. It works with 32 MB RAM. But if I should look into that code, I hate that decision. And the "simple" FaxG4 en/decoder of tiflib is faster as my en/decoder :-( ( realy that coder is not so simple; I have no idea to speed it up). Most of our users have images up to DIN-A3 400 dpi, some up to DIN-A0 400 dpi and one ore three up to ~ 60 K * 10 K pixel.

I am interested to discuss the problems ( I think outside this mailing list).

Klaus Bartz

Dr. Klaus Bartz                      
COI GmbH / Abt. KOU3    Industriestr. 1-3    D-91072 Herzogenaurach
Tel: +49 (9132) 82-3433                        Fax: +49-9132-824959