2000.02.06 04:59 "Re: Microsoft Imaging and Jpeg in TIFF", by Andy
About the Wang JPEG algorithm, the way I extract the JPEG data stream from them is detailed in the previous messages on this thread. Essentially, write the JPEG headers which are offset into the file, then write a JPEG "DRI" marker as noted, with an Ri parameter for it determined as noted, then write each strip, raw, and between each strip write an RST marker, which is "0xFFD0" through "OxFFD7", where the last four bits cycle from 0 to seven, ie, the index of the restart marker in the stream modulo 8. From this, a JPEG data stream that can be read with IJG JPEG tools is generated.
I attach a simple file to read the OJPEG tags only, largely copied from other codecs. I do not warranty it for that or any other use. The TIFFFieldInfo struct may be incorrect.
> I agree.
> Niles Ritter wrote:
> I use to make Wang JPEG images the freely available "Wang Imaging for
> Windows 95."
I wouldn't trust the M$ Wang Imaging solution for generating JPEG in TIFF.
Yeah, sure, but the whole point of this thread was to explore the possibility of reading these bogus files from our non-bogus software, wasn't it?
Andy, did you come up with a reliable way to read these Wang JPEG embedding TIFFs in the end? I would be very interested in hearing about it if you did.
> Do you know where I can find TIFF files with thumbnails as one of the > SubIFDs or an IFD using the SUBFILETYPE or OSUBFILETYPE or preferably common usages
> of each of these?
In general, I think it is very unfortunate the libtiff publication does not include a complete testpics library, like eg libpng does. I have read many questions for specific TIFF files, and I have asked them frequently myself, too, in many places. These questions are seldom answered - probably because of the very limited number of TIFF's 'in the wild', compared to eg JPEG. The absence of a good and complete testpics library is one of the main reasons for the absence of a good and complete tiff reading implementation in current software, I think. It makes our job implementing *good* TIFF reading even harder than it already is. Somebody should *REALLY* take care of that, it would even make a big difference to the future of the TIFF format!
But as for your question, Andy, sorry, I do not even know if my *limited* testpics collection contains any. I don't understand why you bother with thumbnails anyway, today's processing power is sufficient to simply read the whole file and present your user with a preview from that. You can use a secondary thread to first produce a fast nearest-neighbour resized preview thumbnail, and a second lab-interpolated one afterwards. If you build this thread carefully and design it to be interuptable/restartable as a consequence of user action, there is no need at all to include or use space-wasting thumbail images anymore...
The thumbnail mistake was mine, not "thumbnail"'s. I know better now how TIFFGetField(tiff, TIFFTAG_SUBIFD, ...) works with TIFFSetSubDirectory(tiff, offset), ie, using an offset as argument to TIFFSetSubDirectory as opposed to an index like TIFFSetDirectory.
The only reason I am concerned is to read the images besides the thumbnails and actually discard the thumbnails as I do recreate them later. So, now I think that that is resolved.
An updated testpics archive, eg, inc. Zip TIFFs and JBIG TIFFs, would be good. A copy of the TIFF 7.0 draft or specification would be better.