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:37 "Re: quad-tile", by Andrey Kiselev
Hi Joris, On Sat, Oct 02, 2004 at 05:05:50PM +0200, Joris wrote: > > 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 Exactly, with except of one thing: my test code is very basic for now and word "all" is not yet acceptable. :-) But even so small test suite already helps me to found several bugs/oddities in the library. > 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? You are absolutely right, there is a built-in support for such tests in the autotools environment. We can run the tests after every change in the library code to ensure that nothing is broken. > 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 Mmm... I think I don't understand in details what do you mean. Do you mean integrating the internal libtiff tests with the external data sets? > 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? Yes, that is a problem I don't thinking too much. A lot of code should be written before this problem becomes valuable and I'm sure some good idea comes to us at some point. > - 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? Well, that is not a stuff for the test suite, it should go to Bugzilla ;-) Andrey -- Andrey V. Kiselev Home phone: +7 812 5274898 ICQ# 26871517