Re: error compiling gd-1.8.3 under cygwin-1.1.7

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

"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
>