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: <3A7AFDB2.1B35804B@ece.gatech.edu>
Date: Fri, 02 Feb 2001 13:34:26 -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: Thomas Boutell <boutell AT vader DOT boutell DOT com>
CC: "Dr. Volker Zell" <Dr DOT Volker DOT Zell AT oracle 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 1010202091628 DOT 2121G-100000 AT vader DOT boutell DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Thomas Boutell wrote:
> 
> On Fri, 2 Feb 2001, Charles S. Wilson wrote:
> 
> > 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.
> 
> Why is this structure in the publicly exported 'jpeglib.h' if
> it isn't safe to inspect it? Just curious. The fella who wrote
> the (quick and dirty, but useful) jpeg support for gd probably
> looked at the words "this file defines the application interface
> for the JPEG library" and got a warm, fuzzy feeling.

Don't blame me -- I didn't write the library.  There are ways to declare
a struct differently for an app and a lib, so that the app never knows
about the private fields -- but that can cause problems if the app tries
to create an array of the structs.  Hence, actual documentation in the
.h file that application programmers are supposed to read.

> 
> In this case, gd is trying to determine whether the JPEG it is
> currently loading is progressively stored or not, in order to
> set gd's own interlace flag so that the same behavior can be
> maintained when the image is saved again. A good idea, but is
> there a safe way to get that information? If not, we're
> probably better off removing this little featurelet to gain
> greater compatibility with other versions of libjpeg.
> 
> The /* Remaining fields should be treated as private by applications. */
> message appears in the middle of the jpeg_component_info structure.
> It doesn't appear to be relevant to the rest of the file; I wouldn't
> have read it that way before reading your message.

Well, there is another message within the declaration of both
jpeg_compress_struct{} and jpeg_decompress_sturct{}:

/* Remaining fields are known throughout the {de}compressor, but
generally
 * should not be touched by a surrounding applicaiton.
 */

four lines above the 'J_CODEC_PROCESS process' field declaration which
is at the same location as the old 'boolean progressive_mode' field
declaration
 
> I'm not criticizing the generally fabulous jpeg library or the
> generous work of its authors; just pointing out that it would be
> quite difficult for most programmers to figure out that there
> was anything unwise about inspecting the progressive_mode boolean.
> I suppose it's academic at this point. We should probably
> just yank that feature.

It's useful for some applications, such as medical imaging.  (Also, it's
helpful in lossless-jpeg encoded TIFF-format files).  The only time you
run into problems is when you're messing with the internal aspects of
the codec itself.  I agree, testing the encoding status of an incoming
image to insure that a re-encoded output matches is a good idea. 
However, I don't see any accessor function to determine cleanly the
value of cinfo->process.  Perhaps the app could do:

#if defined (C_LOSSLESS_SUPPORTED) || defined(D_LOSSLESS_SUPPORTED)
#define cinfo->progressive_mode ((boolean)(cinfo->process ==
JPROC_PROGRESSIVE))
#endif

--Chuck