2000.02.01 05:39 "Re: G4 and DCT documentation [was: tiff2ps: G4 compression in PostScript]", by Tom Lane
> #define D_MAX_BLOCKS_IN_MCU 64
Yes, the standard specifies a limit of 10 blocks/MCU.
Just so we simple minds can get things wright: what D_MAX_BLOCKS_IN_MCU should we define? If we define it to be 10, can we read all Adobe JPEG's? And if we define it to be 64, can we read all others, and will all other readers be able to read ours?
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.
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...
regards, tom lane
organizer, Independent JPEG Group