view release on metacpan or  search on metacpan

src/Source/LibJPEG/install.txt  view on Meta::CPAN

We haven't bothered to include project files for rdjpgcom and wrjpgcom.
Those source files should just be compiled by themselves; they don't
depend on the JPEG library.  You can use the default.prj project file
of the Pure C distribution to make the programs.

There is a bug in some older versions of the Turbo C library which causes the
space used by temporary files created with "tmpfile()" not to be freed after
an abnormal program exit.  If you check your disk afterwards, you will find
cluster chains that are allocated but not used by a file.  This should not
happen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitly
close temp files before exiting.  But if you use the JPEG library with your
own code, be sure to supply a signal catcher, or else use a different
system-dependent memory manager.


Cray:

Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
compiler bug in old versions of Cray's Standard C (prior to 3.1).  If you
still have an old compiler, you'll need to insert a line reading
"#pragma novector" just before the loop	
    for (i = 1; i <= (int) htbl->bits[l]; i++)
      huffsize[p++] = (char) l;
in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).
[This bug may or may not still occur with the current IJG code, but it's
probably a dead issue anyway...]


HP-UX:

If you have HP-UX 7.05 or later with the "software development" C compiler,
you should run the compiler in ANSI mode.  If using the configure script,
say
	./configure CC='cc -Aa'
(or -Ae if you prefer).  If configuring by hand, use makefile.ansi and add
"-Aa" to the CFLAGS line in the makefile.

If you have a pre-7.05 system, or if you are using the non-ANSI C compiler
delivered with a minimum HP-UX system, then you must use makefile.unix
(and do NOT add -Aa); or just run configure without the CC option.

On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
to A.08.07.  If you get complaints about "not a typedef name", you'll have to
use makefile.unix, or run configure without the CC option.


Macintosh, generic comments:

The supplied user-interface files (cjpeg.c, djpeg.c, etc) are set up to
provide a Unix-style command line interface.  You can use this interface on
the Mac by means of the ccommand() library routine provided by Metrowerks
CodeWarrior or Think C.  This is only appropriate for testing the library,
however; to make a user-friendly equivalent of cjpeg/djpeg you'd really want
to develop a Mac-style user interface.  There isn't a complete example
available at the moment, but there are some helpful starting points:
1. Sam Bushell's free "To JPEG" applet provides drag-and-drop conversion to
JPEG under System 7 and later.  This only illustrates how to use the
compression half of the library, but it does a very nice job of that part.
The CodeWarrior source code is available from http://www.pobox.com/~jsam.
2. Jim Brunner prepared a Mac-style user interface for both compression and
decompression.  Unfortunately, it hasn't been updated since IJG v4, and
the library's API has changed considerably since then.  Still it may be of
some help, particularly as a guide to compiling the IJG code under Think C.
Jim's code is available from the Info-Mac archives, at sumex-aim.stanford.edu
or mirrors thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.

jmemmac.c is the recommended memory manager back end for Macintosh.  It uses
NewPtr/DisposePtr instead of malloc/free, and has a Mac-specific
implementation of jpeg_mem_available().  It also creates temporary files that
follow Mac conventions.  (That part of the code relies on System-7-or-later OS
functions.  See the comments in jmemmac.c if you need to run it on System 6.)
NOTE that USE_MAC_MEMMGR must be defined in jconfig.h to use jmemmac.c.

You can also use jmemnobs.c, if you don't care about handling images larger
than available memory.  If you use any memory manager back end other than
jmemmac.c, we recommend replacing "malloc" and "free" by "NewPtr" and
"DisposePtr", because Mac C libraries often have peculiar implementations of
malloc/free.  (For instance, free() may not return the freed space to the
Mac Memory Manager.  This is undesirable for the IJG code because jmemmgr.c
already clumps space requests.)


Macintosh, Metrowerks CodeWarrior:

The Unix-command-line-style interface can be used by defining USE_CCOMMAND.
You'll also need to define TWO_FILE_COMMANDLINE to avoid stdin/stdout.
This means that when using the cjpeg/djpeg programs, you'll have to type the
input and output file names in the "Arguments" text-edit box, rather than
using the file radio buttons.  (Perhaps USE_FDOPEN or USE_SETMODE would
eliminate the problem, but I haven't heard from anyone who's tried it.)

On 680x0 Macs, Metrowerks defines type "double" as a 10-byte IEEE extended
float.  jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power
of 2.  Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.

The supplied configuration file jconfig.mac can be used for your jconfig.h;
it includes all the recommended symbol definitions.  If you have AppleScript
installed, you can run the supplied script makeproj.mac to create CodeWarrior
project files for the library and the testbed applications, then build the
library and applications.  (Thanks to Dan Sears and Don Agro for this nifty
hack, which saves us from trying to maintain CodeWarrior project files as part
of the IJG distribution...)


Macintosh, Think C:

The documentation in Jim Brunner's "JPEG Convert" source code (see above)
includes detailed build instructions for Think C; it's probably somewhat
out of date for the current release, but may be helpful.

If you want to build the minimal command line version, proceed as follows.
You'll have to prepare project files for the programs; we don't include any
in the distribution since they are not text files.  Use the file lists in
any of the supplied makefiles as a guide.  Also add the ANSI and Unix C
libraries in a separate segment.  You may need to divide the JPEG files into
more than one segment; we recommend dividing compression and decompression
modules.  Define USE_CCOMMAND in jconfig.h so that the ccommand() routine is
called.  You must also define TWO_FILE_COMMANDLINE because stdin/stdout
don't handle binary data correctly.

On 680x0 Macs, Think C defines type "double" as a 12-byte IEEE extended float.

src/Source/LibJPEG/install.txt  view on Meta::CPAN

but you'll need to tweak it in a 16-bit environment (you'd need to define
NEED_FAR_POINTERS and MAX_ALLOC_CHUNK).  Beware that makefile.bcc will need
alteration if you want to use it for Windows --- in particular, you should
use jmemnobs.c not jmemdos.c under Windows.

Borland C++ 4.5 fails with an internal compiler error when trying to compile
jdmerge.c in 32-bit mode.  If enough people complain, perhaps Borland will fix
it.  In the meantime, the simplest known workaround is to add a redundant
definition of the variable range_limit in h2v1_merged_upsample(), at the head
of the block that handles odd image width (about line 268 in v6 jdmerge.c):
  /* If image width is odd, do the last output column separately */
  if (cinfo->output_width & 1) {
    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
    cb = GETJSAMPLE(*inptr1);
Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
doesn't trigger the bug.
Recent reports suggest that this bug does not occur with "bcc32a" (the
Pentium-optimized version of the compiler).

Another report from a user of Borland C 4.5 was that incorrect code (leading
to a color shift in processed images) was produced if any of the following
optimization switch combinations were used: 
	-Ot -Og
	-Ot -Op
	-Ot -Om
So try backing off on optimization if you see such a problem.  (Are there
several different releases all numbered "4.5"??)


Microsoft Windows, Microsoft Visual C++:

jconfig.vc should work OK with any Microsoft compiler for a 32-bit memory
model.  makefile.vc is intended for command-line use.  (If you are using
the Developer Studio environment, you may prefer the DevStudio project
files; see below.)

IJG JPEG 7 adds extern "C" to jpeglib.h.  This avoids the need to put
extern "C" { ... } around #include "jpeglib.h" in your C++ application.
You can also force VC++ to treat the library as C++ code by renaming
all the *.c files to *.cpp (and adjusting the makefile to match).
In this case you also need to define the symbol DONT_USE_EXTERN_C in
the configuration to prevent jpeglib.h from using extern "C".


Microsoft Windows, Microsoft Visual C++ 6 Developer Studio:

We include makefiles that should work as project files in DevStudio 6.0 or
later.  There is a library makefile that builds the IJG library as a static
Win32 library, and application makefiles that build the sample applications
as Win32 console applications.  (Even if you only want the library, we
recommend building the applications so that you can run the self-test.)

To use:
1. Open the command prompt, change to the main directory and execute the
   command line
	NMAKE /f makefile.vc  setup-vc6
   This will move jconfig.vc to jconfig.h and makefiles to project files.
   (Note that the renaming is critical!)
2. Open the workspace file jpeg.dsw, build the library project.
   (If you are using DevStudio more recent than 6.0, you'll probably
   get a message saying that the project files are being updated.)
3. Open the workspace file apps.dsw, build the application projects.
4. To perform the self-test, execute the command line
	NMAKE /f makefile.vc  test-build
5. Move the application .exe files from `app`\Release to an
   appropriate location on your path.


Microsoft Windows, Microsoft Visual C++ 2010 Developer Studio (v10):

We include makefiles that should work as project files in Visual Studio
2010 or later.  There is a library makefile that builds the IJG library
as a static Win32 library, and application makefiles that build the sample
applications as Win32 console applications.  (Even if you only want the
library, we recommend building the applications so that you can run the
self-test.)

To use:
1. Open the command prompt, change to the main directory and execute the
   command line
	NMAKE /f makefile.vc  setup-v10
   This will move jconfig.vc to jconfig.h and makefiles to project files.
   (Note that the renaming is critical!)
2. Open the solution file jpeg.sln, build the library project.
   (If you are using Visual Studio more recent than 2010 (v10), you'll
   probably get a message saying that the project files are being updated.)
3. Open the solution file apps.sln, build the application projects.
4. To perform the self-test, execute the command line
	NMAKE /f makefile.vc  test-build
5. Move the application .exe files from `app`\Release to an
   appropriate location on your path.

Note:
There seems to be an optimization bug in the compiler which causes the
self-test to fail with the color quantization option.
We have disabled optimization for the file jquant2.c in the library
project file which causes the self-test to pass properly.


OS/2, Borland C++:

Watch out for optimization bugs in older Borland compilers; you may need
to back off the optimization switch settings.  See the comments in
makefile.bcc.


SGI:

On some SGI systems, you may need to set "AR2= ar -ts" in the Makefile.
If you are using configure, you can do this by saying
	./configure RANLIB='ar -ts'
This change is not needed on all SGIs.  Use it only if the make fails at the
stage of linking the completed programs.

On the MIPS R4000 architecture (Indy, etc.), the compiler option "-mips2"
reportedly speeds up the float DCT method substantially, enough to make it
faster than the default int method (but still slower than the fast int
method).  If you use -mips2, you may want to alter the default DCT method to
be float.  To do this, put "#define JDCT_DEFAULT JDCT_FLOAT" in jconfig.h.


VMS:

On an Alpha/VMS system with MMS, be sure to use the "/Marco=Alpha=1"
qualifier with MMS when building the JPEG package.

VAX/VMS v5.5-1 may have problems with the test step of the build procedure
reporting differences when it compares the original and test images.  If the
error points to the last block of the files, it is most likely bogus and may
be safely ignored.  It seems to be because the files are Stream_LF and
Backup/Compare has difficulty with the (presumably) null padded files.
This problem was not observed on VAX/VMS v6.1 or AXP/VMS v6.1.