1998.12.10 15:29 "Re: OJPEG_SUPPORT in 3.4b37", by Tom Lane

but i cannot process those using the latest tiff library (JPEG-Support enabled).

i've tried to enable OJPEG_SUPPORT - but i can't find the needed TIFFInitOJPEG() function anywhere in the source code....

There never has been, and probably never will be, any OJPEG support in the libtiff distribution --- only stubs. The old spec is too ambiguous to allow building a reliable reader for it (see TIFF Tech Note #2 for the gory details).

What's worse, most of the attempted implementations I've seen files from are demonstrably broken. Your example is broken in at least two ways:

Your dump shows PhotometricInterpretation = 5 (ie, CMYK) and SamplesPerPixel = 3. I don't think so ... one of those has to be wrong. Probably the PhotometricInterpretation ought to be YCbCr, since there's a YCbCrPositioning tag. On the other hand, YCbCr mode requires ReferenceBlackWhite to be given, and it isn't. (Congratulations to whoever this was on finding a novel new way to screw up an old-style TIFF/JPEG.)
Old-style JPEG mode requires a bunch of support fields; at minimum JPEGQTables, JPEGDCTables, and JPEGACTables, which are nowhere to be seen in the dump. There is no way for an OJPEG-compliant reader to do anything at all with this file.

Given point 2, it seems possible that what you really have here is a file with a complete JPEG datastream inside the one data strip. Which would mean it's really new-style TIFF/JPEG with a wrong compression tag. You might try changing the compression tag to 7, fixing the colorspace description, and seeing what happens. (But first, take a look with something like jpegdump to see if there are any JPEG markers inside the data strip. If not, you're pretty well hosed, I fear; the file must be depending on assumed table values, and there's no way to guess what Q tables to use...)

You might try what I did--closely examine the way OJPEG was implemented in the files you must work with, extract from them a JPEG file which you write to a temp file on disk, then do the decompression with libjpeg.

Yup, it seems that each alleged OJPEG file I run across requires a fresh reverse-engineering effort to figure out what creative misinterpretation of the spec was used...

regards, tom lane
organizer, Independent JPEG Group