2004.10.02 15:05 "Re: [Tiff] quad-tile", by Joris Van Damme

The test suite I'm working on right now doesn't use the external image set. All test images are generated by the test cases from the internal data arrays and being compared with that images after reading the files back. Any help will be greatly appreciated.

I'm not completely sure I understand. Do you mean sortoff closed-circuit testing, like this

- for all encoding schemes/parameters
    - generating some testimage
    - encoding it (to a temp file), with some encoding scheme/parameters
    - decoding it (from a temp file)
    - comparing it to original testimage
    - if same, then library ok for this encoding scheme/parameters

I guess you probably are, 'cause I can see how that can be an extremely nice auto test tool in the auto make schemes you're concerned with. Am I right?

If so, I think we might best be able to help each other by being somewhat complementary. The thing I am most concerned with, is that very first line in this scheme, the enumeration of all issues/schemes/parameters/whatever that set TIFF files apart, and that makes that some work with some decoders, and others don't. I'd like to enumerate that, think about all issues, document it, link it with the tag pages and vice versa, etc.

When I say 'enumeration', I am, as always, thinking raw data in any proprietary scheme, managed by on-the-fly written code, from which my code can assemble and maintain the HTML presentation of this data. Perhaps we ought to look at ways to integrate our schemes, having the data drive your closed-circuit loop. That would yield

very extensive closed-circuit libtiff testing
testimage suite generation by libtiff
the html index pages into this testimage suite, crossreferenced with tag pages etc

Two minor complications I foresee:

Closed-circuit testing is a tiny bit problematic when lossy storage is involved. I'm not just thinking jpeg, even mere YCbCr subsampled images, whatever compression scheme, are lossy. This tiny problem can perhaps be solved by having the data include tolerance levels for the closed-circuit testing?
I'm planning also stuff that LibTiff can't handle, most notably different bitdepths and different datatypes per channel. This tiny problem can perhaps be solved by having the data include a 'skip in LibTiff generation/closed-circuit-testing' flag?

But perhaps I'm going from wrong assumptions as to what your intentions are. Your thoughts?

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html