LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 1998
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1998.12.10 15:29 "Re: OJPEG_SUPPORT in 3.4b37", by Tom Lane
"Thies C. Arntzen" <thies@digicol.de> writes: >> 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: 1. 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.) 2. 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...) Thad Humphries <thad@blueridge.com> writes: > 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