AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.01.27 23:05 "latest libs - where?", by Paul Kaiser
[...]
2000.02.01 05:39 "Re: G4 and DCT documentation [was: tiff2ps: G4 compression in PostScript]", by Tom Lane
2000.02.02 00:37 "Re: G4 and DCT documentation [was: tiff2ps: G4 compression in PostScript]", by Joris Van Damme
[...]

2000.02.02 00:37 "Re: G4 and DCT documentation [was: tiff2ps: G4 compression in PostScript]", by Joris Van Damme

The D_MAX_BLOCKS_IN_MCU = 64 setting is perfectly safe for compatibility, since it only affects what libjpeg's decoder will accept, not what the encoder will allow you to emit.

But having said that, I don't see any really good reason to change the default setting of 10. Peter Deutsch claims to have seen Postscript files containing JPEG datastreams with more than 10 blocks/MCU, but I've never seen one, nor ever heard a bug report from anyone else about libjpeg refusing a file that had more than 10. So I don't believe there are many files in the wild with more than 10 blocks/MCU. Certainly I would rather not encourage people to produce such non-spec-compliant files, so I won't consider making the stock distribution of libjpeg accept them.

That's perfectly clear. Thanks.

BTW, I've just compiled my own libjpeg DLL from your excellent source. (I had always worked with the Borland pre-compiled versions up to now.) It's really hard to get it to work from within my libtiff DLL. Are there any known compatibility or source problems in that area that are documented somewhere? (I'm pretty sure it's not a compilation/DLL issue... anymore.) Anyone else ever succeeded in this?

News to me; anyone have any info? I'm afraid I'm not much of a Windows user, so I can't be much help in solving this. But please let me know what you find out. I'm hoping to put out a libjpeg update in the next month or so, so now is a great time for fixing any compatibility problems or documentation shortcomings...

I haven't found the problem (yet), but I have found a way around it. It seems the mistery bug disappears when I instruct libjpeg to do a Ycbcr->RGB conversion, through the appropriate libtiff pseudo-tag. I have only encountered one single jpeg-embedding tiff so far, and not one other Ycbcr tiff, so I cannot possible know where the problem really resides. But I don't think it's a libjpeg problem. I guess it might perhaps be a problem in the interface of libtiff to libjpeg (tif_jpeg, I think you contributed it), but I've no way of knowing for sure (sofar). (It's really hard to debug, since I link the DLL's into a borland pascal application (Delphi) while I compile them with a m$ c compiler (Visual C++) and so far I've not even succeeded in tracing into the DLL's.)

Anyway, as long as I do not encounter any more jpeg embedding tiff's I consider the problem to be solved this way. My graphics library considers Ycbcr in jpeg to be a step in the compression, so the images themselves are considered to be RGB and libjpeg is instructed to deliver them that way anyway.

I'm looking forward to the libjpeg update.

Best regards,

Joris