2000.10.06 17:56 "Re: Old-style JPEG and HP 9100C Digital Sender", by Joris Van Damme

I am not sure who would be up to publishing a whole TIFF V7.0 specification, but I think a first step would be to write up some proposed ammendments for work that has been done - essentially more tech notes. Two items that come to mind for me are the addition of SAMPLEFORMAT_COMPLEXINT/COMPLEXIEEEFP, and the deflate (aka zip) compression scheme.

Yeap; that and most of the other stuff mentioned already by others. I'ld be especially interested in deflate compression, and a way to get a 'toc' quickly and early.

What all sorts of things do people want to put in a V7.0 spec? Assuming we were trying to do something minimal what really needs to be done? Do you bring this up mainly in the hopes of settling the "OJPEG" issue once and for all?

Well, settling the OJPEG issue 'once and for all' would be one of the very nice consequences. Though I agree with mister Lane that is de facto already settled because reading any vendor's interpretation of the OJPEG is not feasable.

If we really want to extend TIFF significantly we should really try to bring a few of the major software vendors onside (folks who sell imaging libraries like ImageGear) and major software vendors like... Microsoft, Corel, etc.

Well, I am but a humble shrimp. I do not work in the printing bussiness, hell, I don't even have any knowledge on half of the TIFF tags. I'm simply trying to put together a more or less complete group of codecs that could be usefull for those of us who try to keep life simple, and as such I use public libraries like LibTiff.

Nevertheless, I must say this talk about 'major software vendors' does not fill me with great expectations. Didn't we start of by saying the major software vendor Adobe is neglecting this format? When is the last time you tried to read any of the more exotic tiffs in microsoft, adobe or corel software? Now even I am able to read the vast majority of the 'exotic' tiffs with the aid of LibTiff while those 'major software vendors' often aren't. So, as far as this humble shrimp is concerned, the LibTiff community has far more credibility than those 'major software venders'.

Finally, I don't think we need to worry about TIFF being replaced by anything else too quickly. It is a stable and popular format. But even if it did fade in importance, is that the end of the world if some new format is able to what needs to be done?

As someone else already pointed out, much of the value of the TIFF format is a consequence of the existence of LibTiff. This seems to be a rather general phenomenon in computer science today. For example, JPEG would probably not have a tenth of the importance it has today without mister Lane. The existence of a complete public library is almost more important than the existence of a good spec, in that regard. Most of us can interface with the format relatively painlessly. Those of us who want more control can use the library as a spec. In fact, the 'major software vendors' who write their own stuff miss out on more files than we do.

So, the existence of LibTiff is why I'ld like to see the TIFF format kept alive.

Was it you that responded in another mail on the tile issue, Frank? Anyway, my remark on that was not meant specifically on tiles (I am not native english, and I have to put in a lot of work to try to be comprehensible). Rather, I meant the number of substantially different storage 'modes', tiled being just an example of one of them. Tiled or stripped, downsampled or not, planar or continues, variable number of alpha channels,.... My interface to LibTiff needed 16 (16!!!) different retrieval strategies.

Best regards,

Joris