Re: error compiling gd-1.8.3 under cygwin-1.1.7

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

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