Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3A7A6641.2534253B@ece.gatech.edu>
Date: Fri, 02 Feb 2001 02:48:17 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dr. Volker Zell" <Dr DOT Volker DOT Zell AT oracle DOT com>
CC: Thomas Boutell <boutell AT vader DOT boutell DOT com>, cygwin-apps AT cygwin DOT com
Subject: Re: error compiling gd-1.8.3 under cygwin-1.1.7
References: <Pine DOT LNX DOT 3 DOT 95 DOT 1010201102210 DOT 11386B-100000 AT vader DOT boutell DOT com> <kvy9vpinju DOT fsf AT vzell DOT de DOT oracle DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Dr. Volker Zell" wrote:
> 
> I found my mistake. I'm using jpeg-6b but with the lossless jpeg patch applied. Actually this patch
> removes the definition of progressive_mode. :-(
> 
> The lossless jpeg libs and headers are standard now in the cygwin emnvironment.
> http://sources.redhat.com/cygwin/

Hmmm...then your app (gd ?) was probably accessing private fields that
were subject to modification -- as Ken puts it below, "playing with
fire."  Progressive mode isn't gone, but how it is handled internally is
different:
  before : cinfo->progressive_mode   
           was a "boolean" (int)
  with lj: cinfo->process is a int that takes one 
           of several values (e.g. JPROC_PROGRESSIVE)
Again, this is all handled *inside* the private area of libjpeg.  It
really shouldn't break your program unless your program was doing
naughty things, like messing with internal data structures.

--Chuck

From an exchange on the ijg mailing list last November:

> Charles Wilson said:
> > Perhaps this should be considered a bug in the lossless jpeg stuff, but
> > because of the API renames required for ljpeg, some programs written for
> > regular jpeg can't use the extended library that implements both
> > lossless and regular jpeg.

Ken Murchison replied:
> The renaming of some of the fields was done primarily to make the code
> more readable/understandable in a two codec system.  For example
> 'width_in_blocks' make no sense for lossless, because lossless only
> deals with single samples. 
> 
> I made an effort to not change the existing external API, and I *think*
> I was successful (I may have hacked something and forgot about it).  I
> wasn't too worried about changing the fields in question because I
> believe they were intended to only be used inside the library itself. 
> In fact, these fields fall in an area of jpeglib.h which contains the
> following warning:
> /* Remaining fields should be treated as private by applications. */
> 
> If you have an app which is using these fields directly I apologize for
> the inconvenience, but IMHO you were kind of playing with fire.  That
> being said, if your level of JPEG expertise is such that you are
> comfortable using these fields, you most likely have the level of
> expertise to solve this problem by either modifying the patch or setting
> up defines in the Makefiles like
> '-Dwidth_in_data_units=width_in_blocks'.  I currently don't have the
> time to attack this myself (in fact the project for which I developed
> lossless never happened), but I'd be willing to help provide guidance.
> 
> Regards,
> Ken
> -- 
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
>