Mail Archives: cygwin-apps/2001/02/02/13:34:43
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
- Raw text -