Mail Archives: cygwin-apps/2001/02/02/02:48:25
"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
>
- Raw text -