2004.10.02 17:02 "Re: [Tiff] quad-tile", by Joris Van Damme

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?

• - 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

I'll try to be more clear. Allow me to specify the whole process.

- I'm wading throught the spec, once again, through all tags, all related documents...

- While doing this, I identify all 'issues' I can find. Examples of what I mean by 'issues': bitdepth, indexed tag, ycbcr subsampling

- On each issue, I do some thinking, and try to define a small as possible set of testimages that would be sufficient to identify with reasonable certainty whether a library decoder can handle these tiffs.

Example bitdepth: I guess a grayscale min is white image with bitdepth 8 and one with bitdepth 16 are the basic testimages. Next, thinking about it, I realize a decoder/interpreter/image library/whatever must probably have generic bitdepth handling for all non-optimized cases, in order to fully support tiff. So I'm thinking also an image with grayscale say bitdepth 5 and one with grayscale bitdepth 18 might be in order.

Example indexed tag: Thinking about it, this doesn't yield much options, and doesn't interfere with anything else. One example image of the usage of index with say a CMYK palette may be sufficient.

- We come up with a standardized way to define the thus thought up collection of test images. A plain text based format for convinience and easy manual fiddling when necessary, is best. A testimage definition should be sufficient to easilly interpret by a LibTiff based testimage-definition to testimage-tiff-file 'converter'. It should also contain 'group' information, an identifier, a plain text description, etc. Thus, this centrally managed set of testimage definitions can also serve a testimage-definition-collection to testimage-description-html-pages 'converter'. Additional data per testimage definition is the 'can be generated by libtiff' flag, and the 'closed-circuit-testing tolerance data'.

- This first converter, is mainly what you are after. It will serve in extensive closed-circuit testing, and the same LibTiff based testimage-definition to testimage-tiff-file converter code can also be used to actually generate the complete library of testimages (as far as supported by LibTiff)

- The second converter definition-date to html-index-pages, mainly aids in documenting/indexing the testimage library, and what I need to integrate it with my site. This converter can also integrate the testfile generator, thumbnailing code, zipping code to zip the testimages per subsection as well as the while, etc. This converter should be written to build HTML index pages with tag dumps, the reference thumbnail, and downloadable zips, etc.

Three more minor notes:

• Of course, I'm over-defining the process. In practice, the 'testimage definition language' will not be much more then a collection of hacks used to trigger some procedures in a set of LibTiff testimage generation building block procedure set, amonst other things. It's not like algebra or something, it's more like hacking it together. Much like you're generating your current set, I imagine, except that the very highest level of calling the generation building blocks is not hard-coded, but triggered from data.
• Depending on what you're actually after, library testing or building a good testimage suite, the specified process is probably either much more then what you're after, or merely a bit more then what you're after. But I am not saying the specified process is the best way to achieve what you're after. I am instead saying that I plan to do the above anyhow because I need it for my own purposes, really, so if what you're after can be helped with the specified process, all the better. This is why I don't really care in this matter that LibTiff does not support different bitdepths per channel. My only concern in that matter is that, to enable the LibTiff testimage generator code to use my data, I'll merely have to include an extra flag 'can be generated by LibTiff', but that doesn't really change my process.
• And of course, I'm not asking you to solve the problem that some testimages cannot be generated by LibTiff. Actually, what I planned to do is really independent from LibTiff in that I plan to generate the images with something different. So these images, too, will get generated anyhow.

The benefit for you, as far as I can see, is a exaustive closed-circuit tester instead of a limited one (which may be very small benefit, if any, I think), and the fact that the testimage generation can be done with LibTiff (as far as it supports the testimages) (which, thinking of it, is not all that great either, possibly, since I'll be generating all images in another way too, anyhow). The cost is merely that I design the testimage definition data with easy generation of LibTiff in mind, amongst other concerns. Which is not at all a great cost.

What do you think? Is this interesting, or is it for your purposes mostly overkill and beside your point?

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