2008.08.11 10:44 "[Tiff] Supporting images > 2gb", by alexander johnson

2008.08.19 08:57 "Re: [Tiff] Premature EOL at line 0 of strip 4294967295 (got 0, expected 1728).", by Bogdan Cristea

On Mon, Aug 18, 2008 at 6:43 PM, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:

> On Mon, 18 Aug 2008, Bogdan Cristea wrote:
>> It is odd for me that the strip number is so big. I want to get rid of
>> this
>> warning. Any suggestions?

> I suggest that you tell us what version of libtiff you are using, as well as > the operating system and CPU type. Then maybe there is something to

> discuss.

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

     I use libtiff 3.8.2 with openSuSE 10.3 on P4 32 bits.
     I have been able to remove the warning using

TIFFSetWarningHandler(NULL) before the while loop:

        TIFFErrorHandler whandler = TIFFSetWarningHandler(NULL);
        while (fakeFile->tif_rawcc > 0)
                if (!((*fakeFile->tif_decoderow)(fakeFile, (tidataval_t *)rowBuf,
(tsize_t)lineSize, (tsample_t)0)))
                          //bad line detected
                } else
                         //good line

fakeFile is a TIFF file handler used only to decompress received data and then to compute the image length, the number of bad lines, etc. I have used as model "fax2tiff.c". Here is how fakeFile is initialized:

                fakeFile = TIFFClientOpen("(FakeInput)", "w", NULL,

                                dummyReadProc, dummyWriteProc,
                                dummySeekProc, dummyCloseProc, dummySizeProc,
                                dummyMapProc, dummyUnmapProc);

                TIFFSetMode(fakeFile, O_RDONLY);

all dummy functions return 0 except for "dummyWriteProc" which returns "size", the last of its arguments.

However, I would like to know if there is a better way to remove this warning, because it seems that some internal variable of the tiff library is not initialized.

Further, when computing the number of bad lines, "badFaxLines", actually it's the number of detections of bad lines, since a bad line could contain several lines of the actual fax image. Is this correct? Is there a better way to detect the number of bad lines?


Bogdan Cristea