LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.10.02 15:05 "Re: 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