Message-ID: 38977C39.97014EEE@planetinternet.be
To: Tom Lane <tgl@sss.pgh.pa.us>, tiff@olympiakos.com
Subject: Re: G4 and DCT documentation [was: tiff2ps: G4 compression in PostScript]
From: Joris Van Damme <as.van.damme.joris@planetinternet.be>
Date: Wed, 02 Feb 2000 01:37:13 +0100
Organization: AWare Systems
References: <Pine.GSO.4.10.10001291156070.4594-100000@sun06.ams.org> <12744.949378612@sss.pgh.pa.us> <38966880.CE4AC3F1@planetinternet.be> <12899.949383571@sss.pgh.pa.us>
Sender: owner-tiff@olympiakos.com


Tom Lane wrote:
> 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


