2004.10.01 09:59 "[Tiff] quad-tile", by Joris Van Damme

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:

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
Download your free TIFF tag viewer for windows here: