2001.10.05 02:21 "Re: OJPEG & Wang Images (long)", by Joris Van Damme
However, I still believe that the proper solution to this problem is to have HP supply us with updated firmware for the 9100C which doesn't create OJPEG tiffs.
Here's wishing you every luck on that cruisade.
Honestly, I don't think they care. The one thing companies like this care about, is the paper plan of some manager that says 'support for jpeg in tiff'. They've been able to put a 'v' mark on that piece of paper. Job well done. If anyone start nagging, they've got the spec to wave about (though they usually do not care enough to do even that - unless you go nagging for a month first).
I still think the only way to solve this and some other problems is for this list to come up with tiff 7.0. Nobody needs to fear adobe in this matter; some adobe manager included 'no more tiff' in his paper plan, long time ago. They simply couldn't care less.
This are just some of the things that would make tiff 7.0 worthwhile:
- integration of technote #2 in the spec; fully abondoning OJPEG in the spec
- values in the IFD should be (up to) 48bit; offsets should change from 32bit to 48bit; which is a minor change in the spec but solves the tiff size limit (perhaps the signature can show the difference between 'tiff32' and 'tiff48', and readers can be build to support both)
- a better and more complete tag (set of tags?) to define page relationships (hiërarchically, not lineairly, and including relationships like eg 'part of', 'next animation frame', 'delta movie frame',...)
- instead of ordinary raster description, images should be allowed to contain a wmf-like vector-based description (this image is a big title in this font and such that says 'Hello world')
- it should be allowed for parts and pieces (individual images in the hiërarchy) to have 'outer' dimensions (this image contains this part of the page) and 'inner' dimensions (this image is nevertheless stored twice a big)
- somehow (but I can't see how, without an additional level of indirection and some reference counting), an individual image should be able to be used in different places of the hiërarchy (eg a common element of layout that gets used on most of the pages of a book).
- the tiff spec should finally include a true 'memory managment' standard. the ways to delete pages, add pages, reuse empty space in a proper 'allocation' routine and such should be standardized; it should be part of the spec because the need is inherent to the tiff format, and also because the problem cannot be properly solved without some extra dat in the tiff file ('scanning through' a tiff file to build this data should be considered not feasable because it limits the size of a _usefull_ tiff file).
- related to this, somehow (but again, I can't see how without a lot of extra hassle) accessing individual pages in the 'main' linked list should be faster than browsing through the complete file, because this in fact does impose a limit on the number of pages that can _usefully_ be stored in a single tiff.
I say forget about HP and adobe and WANG and M$. Their paper plans do not include noticing us. Is there any reason for us to notice them? Make TIFF worthwhile again, instead. A TIFF 7.0 that truely is the next logical step in the tiff story, is an incredebly interesting and usefull format. I'm willing to bet a lot on the fact that some of their managers will notice, and include 'support for tiff 7.0' in their paper plans.
There is a need for a tiff-like open format that can handle a broad number of compression scemes, multi-page, has an open and free spec and is supported by a public library. There has always been that need and I can't see how that would change. However, needs evolve. TIFF does not. That is the problem here. Persistence of 6.0 mistakes is but one of the symptoms.
OK, I suppose I've got a little cruisade of my own going here. But I'm not expecting anything to actually happen, except that maybe some people will raise an eyebrow for a second or two. (In tiff terms, that's about the equivalent of a tropical storm.)
Good luck though, seriously,