isbn 2.0.4 → 2.0.5
Sign up to get free protection for your applications and to get access to all the features.
- data/{README → README.md} +5 -11
- data/Rakefile +20 -14
- data/isbn.gemspec +23 -0
- data/lib/isbn.rb +2 -0
- data/test/isbn_spec.rb +1 -1
- metadata +29 -316
- data/VERSION +0 -1
- data/src/gocr-0.48/.cvsignore +0 -6
- data/src/gocr-0.48/AUTHORS +0 -7
- data/src/gocr-0.48/BUGS +0 -55
- data/src/gocr-0.48/CREDITS +0 -17
- data/src/gocr-0.48/HISTORY +0 -243
- data/src/gocr-0.48/INSTALL +0 -83
- data/src/gocr-0.48/Makefile +0 -193
- data/src/gocr-0.48/Makefile.in +0 -193
- data/src/gocr-0.48/README +0 -165
- data/src/gocr-0.48/READMEde.txt +0 -80
- data/src/gocr-0.48/REMARK.txt +0 -18
- data/src/gocr-0.48/REVIEW +0 -538
- data/src/gocr-0.48/TODO +0 -65
- data/src/gocr-0.48/bin/.cvsignore +0 -2
- data/src/gocr-0.48/bin/create_db +0 -38
- data/src/gocr-0.48/bin/gocr.tcl +0 -527
- data/src/gocr-0.48/bin/gocr_chk.sh +0 -44
- data/src/gocr-0.48/configure +0 -4689
- data/src/gocr-0.48/configure.in +0 -71
- data/src/gocr-0.48/doc/.#Makefile.1.6 +0 -39
- data/src/gocr-0.48/doc/.cvsignore +0 -2
- data/src/gocr-0.48/doc/Makefile +0 -39
- data/src/gocr-0.48/doc/Makefile.in +0 -39
- data/src/gocr-0.48/doc/example.dtd +0 -53
- data/src/gocr-0.48/doc/example.xml +0 -21
- data/src/gocr-0.48/doc/examples.txt +0 -67
- data/src/gocr-0.48/doc/gocr.html +0 -578
- data/src/gocr-0.48/doc/unicode.txt +0 -57
- data/src/gocr-0.48/examples/.#Makefile.1.22 +0 -166
- data/src/gocr-0.48/examples/4x6.png +0 -0
- data/src/gocr-0.48/examples/4x6.txt +0 -2
- data/src/gocr-0.48/examples/5x7.png +0 -0
- data/src/gocr-0.48/examples/5x7.png.txt +0 -2
- data/src/gocr-0.48/examples/5x8.png +0 -0
- data/src/gocr-0.48/examples/5x8.png.txt +0 -2
- data/src/gocr-0.48/examples/Makefile +0 -166
- data/src/gocr-0.48/examples/color.fig +0 -20
- data/src/gocr-0.48/examples/ex.fig +0 -16
- data/src/gocr-0.48/examples/font.tex +0 -22
- data/src/gocr-0.48/examples/font1.tex +0 -46
- data/src/gocr-0.48/examples/font2.fig +0 -27
- data/src/gocr-0.48/examples/font_nw.tex +0 -24
- data/src/gocr-0.48/examples/handwrt1.jpg +0 -0
- data/src/gocr-0.48/examples/handwrt1.txt +0 -10
- data/src/gocr-0.48/examples/inverse.fig +0 -20
- data/src/gocr-0.48/examples/matrix.jpg +0 -0
- data/src/gocr-0.48/examples/ocr-a-subset.png +0 -0
- data/src/gocr-0.48/examples/ocr-a-subset.png.txt +0 -4
- data/src/gocr-0.48/examples/ocr-a.png +0 -0
- data/src/gocr-0.48/examples/ocr-a.txt +0 -6
- data/src/gocr-0.48/examples/ocr-b.png +0 -0
- data/src/gocr-0.48/examples/ocr-b.png.txt +0 -4
- data/src/gocr-0.48/examples/polish.tex +0 -28
- data/src/gocr-0.48/examples/rotate45.fig +0 -14
- data/src/gocr-0.48/examples/score +0 -36
- data/src/gocr-0.48/examples/text.tex +0 -28
- data/src/gocr-0.48/gpl.html +0 -537
- data/src/gocr-0.48/include/.cvsignore +0 -2
- data/src/gocr-0.48/include/config.h +0 -36
- data/src/gocr-0.48/include/config.h.in +0 -36
- data/src/gocr-0.48/include/version.h +0 -2
- data/src/gocr-0.48/install-sh +0 -3
- data/src/gocr-0.48/make.bat +0 -57
- data/src/gocr-0.48/man/.cvsignore +0 -2
- data/src/gocr-0.48/man/Makefile +0 -29
- data/src/gocr-0.48/man/Makefile.in +0 -29
- data/src/gocr-0.48/man/man1/gocr.1 +0 -166
- data/src/gocr-0.48/src/.cvsignore +0 -4
- data/src/gocr-0.48/src/Makefile +0 -132
- data/src/gocr-0.48/src/Makefile.in +0 -132
- data/src/gocr-0.48/src/amiga.h +0 -31
- data/src/gocr-0.48/src/barcode.c +0 -846
- data/src/gocr-0.48/src/barcode.c.orig +0 -593
- data/src/gocr-0.48/src/barcode.h +0 -11
- data/src/gocr-0.48/src/box.c +0 -372
- data/src/gocr-0.48/src/database.c +0 -462
- data/src/gocr-0.48/src/detect.c +0 -943
- data/src/gocr-0.48/src/gocr.c +0 -373
- data/src/gocr-0.48/src/gocr.h +0 -288
- data/src/gocr-0.48/src/jconv.c +0 -168
- data/src/gocr-0.48/src/job.c +0 -84
- data/src/gocr-0.48/src/lines.c +0 -350
- data/src/gocr-0.48/src/list.c +0 -334
- data/src/gocr-0.48/src/list.h +0 -90
- data/src/gocr-0.48/src/ocr0.c +0 -6756
- data/src/gocr-0.48/src/ocr0.h +0 -63
- data/src/gocr-0.48/src/ocr0n.c +0 -1475
- data/src/gocr-0.48/src/ocr1.c +0 -85
- data/src/gocr-0.48/src/ocr1.h +0 -3
- data/src/gocr-0.48/src/otsu.c +0 -289
- data/src/gocr-0.48/src/otsu.h +0 -23
- data/src/gocr-0.48/src/output.c +0 -289
- data/src/gocr-0.48/src/output.h +0 -37
- data/src/gocr-0.48/src/pcx.c +0 -153
- data/src/gocr-0.48/src/pcx.h +0 -9
- data/src/gocr-0.48/src/pgm2asc.c +0 -2893
- data/src/gocr-0.48/src/pgm2asc.h +0 -105
- data/src/gocr-0.48/src/pixel.c +0 -537
- data/src/gocr-0.48/src/pnm.c +0 -533
- data/src/gocr-0.48/src/pnm.h +0 -35
- data/src/gocr-0.48/src/progress.c +0 -87
- data/src/gocr-0.48/src/progress.h +0 -42
- data/src/gocr-0.48/src/remove.c +0 -703
- data/src/gocr-0.48/src/tga.c +0 -87
- data/src/gocr-0.48/src/tga.h +0 -6
- data/src/gocr-0.48/src/unicode.c +0 -1314
- data/src/gocr-0.48/src/unicode.h +0 -1257
- data/src/jpeg-7/Makefile.am +0 -133
- data/src/jpeg-7/Makefile.in +0 -1089
- data/src/jpeg-7/README +0 -322
- data/src/jpeg-7/aclocal.m4 +0 -8990
- data/src/jpeg-7/ansi2knr.1 +0 -36
- data/src/jpeg-7/ansi2knr.c +0 -739
- data/src/jpeg-7/cderror.h +0 -132
- data/src/jpeg-7/cdjpeg.c +0 -181
- data/src/jpeg-7/cdjpeg.h +0 -187
- data/src/jpeg-7/change.log +0 -270
- data/src/jpeg-7/cjpeg.1 +0 -325
- data/src/jpeg-7/cjpeg.c +0 -616
- data/src/jpeg-7/ckconfig.c +0 -402
- data/src/jpeg-7/coderules.txt +0 -118
- data/src/jpeg-7/config.guess +0 -1561
- data/src/jpeg-7/config.sub +0 -1686
- data/src/jpeg-7/configure +0 -17139
- data/src/jpeg-7/configure.ac +0 -317
- data/src/jpeg-7/depcomp +0 -630
- data/src/jpeg-7/djpeg.1 +0 -251
- data/src/jpeg-7/djpeg.c +0 -617
- data/src/jpeg-7/example.c +0 -433
- data/src/jpeg-7/filelist.txt +0 -215
- data/src/jpeg-7/install-sh +0 -520
- data/src/jpeg-7/install.txt +0 -1097
- data/src/jpeg-7/jaricom.c +0 -148
- data/src/jpeg-7/jcapimin.c +0 -282
- data/src/jpeg-7/jcapistd.c +0 -161
- data/src/jpeg-7/jcarith.c +0 -921
- data/src/jpeg-7/jccoefct.c +0 -453
- data/src/jpeg-7/jccolor.c +0 -459
- data/src/jpeg-7/jcdctmgr.c +0 -482
- data/src/jpeg-7/jchuff.c +0 -1612
- data/src/jpeg-7/jcinit.c +0 -65
- data/src/jpeg-7/jcmainct.c +0 -293
- data/src/jpeg-7/jcmarker.c +0 -667
- data/src/jpeg-7/jcmaster.c +0 -770
- data/src/jpeg-7/jcomapi.c +0 -106
- data/src/jpeg-7/jconfig.bcc +0 -48
- data/src/jpeg-7/jconfig.cfg +0 -45
- data/src/jpeg-7/jconfig.dj +0 -38
- data/src/jpeg-7/jconfig.mac +0 -43
- data/src/jpeg-7/jconfig.manx +0 -43
- data/src/jpeg-7/jconfig.mc6 +0 -52
- data/src/jpeg-7/jconfig.sas +0 -43
- data/src/jpeg-7/jconfig.st +0 -42
- data/src/jpeg-7/jconfig.txt +0 -155
- data/src/jpeg-7/jconfig.vc +0 -45
- data/src/jpeg-7/jconfig.vms +0 -37
- data/src/jpeg-7/jconfig.wat +0 -38
- data/src/jpeg-7/jcparam.c +0 -632
- data/src/jpeg-7/jcprepct.c +0 -358
- data/src/jpeg-7/jcsample.c +0 -545
- data/src/jpeg-7/jctrans.c +0 -381
- data/src/jpeg-7/jdapimin.c +0 -396
- data/src/jpeg-7/jdapistd.c +0 -275
- data/src/jpeg-7/jdarith.c +0 -762
- data/src/jpeg-7/jdatadst.c +0 -151
- data/src/jpeg-7/jdatasrc.c +0 -212
- data/src/jpeg-7/jdcoefct.c +0 -736
- data/src/jpeg-7/jdcolor.c +0 -396
- data/src/jpeg-7/jdct.h +0 -393
- data/src/jpeg-7/jddctmgr.c +0 -382
- data/src/jpeg-7/jdhuff.c +0 -1309
- data/src/jpeg-7/jdinput.c +0 -384
- data/src/jpeg-7/jdmainct.c +0 -512
- data/src/jpeg-7/jdmarker.c +0 -1360
- data/src/jpeg-7/jdmaster.c +0 -663
- data/src/jpeg-7/jdmerge.c +0 -400
- data/src/jpeg-7/jdpostct.c +0 -290
- data/src/jpeg-7/jdsample.c +0 -361
- data/src/jpeg-7/jdtrans.c +0 -136
- data/src/jpeg-7/jerror.c +0 -252
- data/src/jpeg-7/jerror.h +0 -304
- data/src/jpeg-7/jfdctflt.c +0 -174
- data/src/jpeg-7/jfdctfst.c +0 -230
- data/src/jpeg-7/jfdctint.c +0 -4348
- data/src/jpeg-7/jidctflt.c +0 -242
- data/src/jpeg-7/jidctfst.c +0 -368
- data/src/jpeg-7/jidctint.c +0 -5137
- data/src/jpeg-7/jinclude.h +0 -91
- data/src/jpeg-7/jmemansi.c +0 -167
- data/src/jpeg-7/jmemdos.c +0 -638
- data/src/jpeg-7/jmemdosa.asm +0 -379
- data/src/jpeg-7/jmemmac.c +0 -289
- data/src/jpeg-7/jmemmgr.c +0 -1118
- data/src/jpeg-7/jmemname.c +0 -276
- data/src/jpeg-7/jmemnobs.c +0 -109
- data/src/jpeg-7/jmemsys.h +0 -198
- data/src/jpeg-7/jmorecfg.h +0 -369
- data/src/jpeg-7/jpegint.h +0 -395
- data/src/jpeg-7/jpeglib.h +0 -1135
- data/src/jpeg-7/jpegtran.1 +0 -272
- data/src/jpeg-7/jpegtran.c +0 -546
- data/src/jpeg-7/jquant1.c +0 -856
- data/src/jpeg-7/jquant2.c +0 -1310
- data/src/jpeg-7/jutils.c +0 -179
- data/src/jpeg-7/jversion.h +0 -14
- data/src/jpeg-7/libjpeg.map +0 -4
- data/src/jpeg-7/libjpeg.txt +0 -3067
- data/src/jpeg-7/ltmain.sh +0 -8406
- data/src/jpeg-7/makcjpeg.st +0 -36
- data/src/jpeg-7/makdjpeg.st +0 -36
- data/src/jpeg-7/makeadsw.vc6 +0 -77
- data/src/jpeg-7/makeasln.vc9 +0 -33
- data/src/jpeg-7/makecdep.vc6 +0 -82
- data/src/jpeg-7/makecdsp.vc6 +0 -130
- data/src/jpeg-7/makecmak.vc6 +0 -159
- data/src/jpeg-7/makecvcp.vc9 +0 -186
- data/src/jpeg-7/makeddep.vc6 +0 -82
- data/src/jpeg-7/makeddsp.vc6 +0 -130
- data/src/jpeg-7/makedmak.vc6 +0 -159
- data/src/jpeg-7/makedvcp.vc9 +0 -186
- data/src/jpeg-7/makefile.ansi +0 -220
- data/src/jpeg-7/makefile.bcc +0 -291
- data/src/jpeg-7/makefile.dj +0 -226
- data/src/jpeg-7/makefile.manx +0 -220
- data/src/jpeg-7/makefile.mc6 +0 -255
- data/src/jpeg-7/makefile.mms +0 -224
- data/src/jpeg-7/makefile.sas +0 -258
- data/src/jpeg-7/makefile.unix +0 -234
- data/src/jpeg-7/makefile.vc +0 -217
- data/src/jpeg-7/makefile.vms +0 -142
- data/src/jpeg-7/makefile.wat +0 -239
- data/src/jpeg-7/makejdep.vc6 +0 -423
- data/src/jpeg-7/makejdsp.vc6 +0 -285
- data/src/jpeg-7/makejdsw.vc6 +0 -29
- data/src/jpeg-7/makejmak.vc6 +0 -425
- data/src/jpeg-7/makejsln.vc9 +0 -17
- data/src/jpeg-7/makejvcp.vc9 +0 -328
- data/src/jpeg-7/makeproj.mac +0 -213
- data/src/jpeg-7/makerdep.vc6 +0 -6
- data/src/jpeg-7/makerdsp.vc6 +0 -78
- data/src/jpeg-7/makermak.vc6 +0 -110
- data/src/jpeg-7/makervcp.vc9 +0 -133
- data/src/jpeg-7/maketdep.vc6 +0 -43
- data/src/jpeg-7/maketdsp.vc6 +0 -122
- data/src/jpeg-7/maketmak.vc6 +0 -131
- data/src/jpeg-7/maketvcp.vc9 +0 -178
- data/src/jpeg-7/makewdep.vc6 +0 -6
- data/src/jpeg-7/makewdsp.vc6 +0 -78
- data/src/jpeg-7/makewmak.vc6 +0 -110
- data/src/jpeg-7/makewvcp.vc9 +0 -133
- data/src/jpeg-7/makljpeg.st +0 -68
- data/src/jpeg-7/maktjpeg.st +0 -30
- data/src/jpeg-7/makvms.opt +0 -4
- data/src/jpeg-7/missing +0 -376
- data/src/jpeg-7/rdbmp.c +0 -439
- data/src/jpeg-7/rdcolmap.c +0 -253
- data/src/jpeg-7/rdgif.c +0 -38
- data/src/jpeg-7/rdjpgcom.1 +0 -63
- data/src/jpeg-7/rdjpgcom.c +0 -515
- data/src/jpeg-7/rdppm.c +0 -459
- data/src/jpeg-7/rdrle.c +0 -387
- data/src/jpeg-7/rdswitch.c +0 -365
- data/src/jpeg-7/rdtarga.c +0 -500
- data/src/jpeg-7/structure.txt +0 -945
- data/src/jpeg-7/testimg.bmp +0 -0
- data/src/jpeg-7/testimg.jpg +0 -0
- data/src/jpeg-7/testimg.ppm +0 -4
- data/src/jpeg-7/testimgp.jpg +0 -0
- data/src/jpeg-7/testorig.jpg +0 -0
- data/src/jpeg-7/testprog.jpg +0 -0
- data/src/jpeg-7/transupp.c +0 -1533
- data/src/jpeg-7/transupp.h +0 -205
- data/src/jpeg-7/usage.txt +0 -605
- data/src/jpeg-7/wizard.txt +0 -211
- data/src/jpeg-7/wrbmp.c +0 -442
- data/src/jpeg-7/wrgif.c +0 -399
- data/src/jpeg-7/wrjpgcom.1 +0 -103
- data/src/jpeg-7/wrjpgcom.c +0 -583
- data/src/jpeg-7/wrppm.c +0 -269
- data/src/jpeg-7/wrrle.c +0 -305
- data/src/jpeg-7/wrtarga.c +0 -253
data/src/jpeg-7/install.txt
DELETED
@@ -1,1097 +0,0 @@
|
|
1
|
-
INSTALLATION INSTRUCTIONS for the Independent JPEG Group's JPEG software
|
2
|
-
|
3
|
-
Copyright (C) 1991-2009, Thomas G. Lane, Guido Vollbeding.
|
4
|
-
This file is part of the Independent JPEG Group's software.
|
5
|
-
For conditions of distribution and use, see the accompanying README file.
|
6
|
-
|
7
|
-
|
8
|
-
This file explains how to configure and install the IJG software. We have
|
9
|
-
tried to make this software extremely portable and flexible, so that it can be
|
10
|
-
adapted to almost any environment. The downside of this decision is that the
|
11
|
-
installation process is complicated. We have provided shortcuts to simplify
|
12
|
-
the task on common systems. But in any case, you will need at least a little
|
13
|
-
familiarity with C programming and program build procedures for your system.
|
14
|
-
|
15
|
-
If you are only using this software as part of a larger program, the larger
|
16
|
-
program's installation procedure may take care of configuring the IJG code.
|
17
|
-
For example, Ghostscript's installation script will configure the IJG code.
|
18
|
-
You don't need to read this file if you just want to compile Ghostscript.
|
19
|
-
|
20
|
-
If you are on a Unix machine, you may not need to read this file at all.
|
21
|
-
Try doing
|
22
|
-
./configure
|
23
|
-
make
|
24
|
-
make test
|
25
|
-
If that doesn't complain, do
|
26
|
-
make install
|
27
|
-
(better do "make -n install" first to see if the makefile will put the files
|
28
|
-
where you want them). Read further if you run into snags or want to customize
|
29
|
-
the code for your system.
|
30
|
-
|
31
|
-
|
32
|
-
TABLE OF CONTENTS
|
33
|
-
-----------------
|
34
|
-
|
35
|
-
Before you start
|
36
|
-
Configuring the software:
|
37
|
-
using the automatic "configure" script
|
38
|
-
using one of the supplied jconfig and makefile files
|
39
|
-
by hand
|
40
|
-
Building the software
|
41
|
-
Testing the software
|
42
|
-
Installing the software
|
43
|
-
Optional stuff
|
44
|
-
Optimization
|
45
|
-
Hints for specific systems
|
46
|
-
|
47
|
-
|
48
|
-
BEFORE YOU START
|
49
|
-
================
|
50
|
-
|
51
|
-
Before installing the software you must unpack the distributed source code.
|
52
|
-
Since you are reading this file, you have probably already succeeded in this
|
53
|
-
task. However, there is a potential for error if you needed to convert the
|
54
|
-
files to the local standard text file format (for example, if you are on
|
55
|
-
MS-DOS you may have converted LF end-of-line to CR/LF). You must apply
|
56
|
-
such conversion to all the files EXCEPT those whose names begin with "test".
|
57
|
-
The test files contain binary data; if you change them in any way then the
|
58
|
-
self-test will give bad results.
|
59
|
-
|
60
|
-
Please check the last section of this file to see if there are hints for the
|
61
|
-
specific machine or compiler you are using.
|
62
|
-
|
63
|
-
|
64
|
-
CONFIGURING THE SOFTWARE
|
65
|
-
========================
|
66
|
-
|
67
|
-
To configure the IJG code for your system, you need to create two files:
|
68
|
-
* jconfig.h: contains values for system-dependent #define symbols.
|
69
|
-
* Makefile: controls the compilation process.
|
70
|
-
(On a non-Unix machine, you may create "project files" or some other
|
71
|
-
substitute for a Makefile. jconfig.h is needed in any environment.)
|
72
|
-
|
73
|
-
We provide three different ways to generate these files:
|
74
|
-
* On a Unix system, you can just run the "configure" script.
|
75
|
-
* We provide sample jconfig files and makefiles for popular machines;
|
76
|
-
if your machine matches one of the samples, just copy the right sample
|
77
|
-
files to jconfig.h and Makefile.
|
78
|
-
* If all else fails, read the instructions below and make your own files.
|
79
|
-
|
80
|
-
|
81
|
-
Configuring the software using the automatic "configure" script
|
82
|
-
---------------------------------------------------------------
|
83
|
-
|
84
|
-
If you are on a Unix machine, you can just type
|
85
|
-
./configure
|
86
|
-
and let the configure script construct appropriate configuration files.
|
87
|
-
If you're using "csh" on an old version of System V, you might need to type
|
88
|
-
sh configure
|
89
|
-
instead to prevent csh from trying to execute configure itself.
|
90
|
-
Expect configure to run for a few minutes, particularly on slower machines;
|
91
|
-
it works by compiling a series of test programs.
|
92
|
-
|
93
|
-
Configure was created with GNU Autoconf and it follows the usual conventions
|
94
|
-
for GNU configure scripts. It makes a few assumptions that you may want to
|
95
|
-
override. You can do this by providing optional switches to configure:
|
96
|
-
|
97
|
-
* Configure will build both static and shared libraries, if possible.
|
98
|
-
If you want to build libjpeg only as a static library, say
|
99
|
-
./configure --disable-shared
|
100
|
-
If you want to build libjpeg only as a shared library, say
|
101
|
-
./configure --disable-static
|
102
|
-
Configure uses GNU libtool to take care of system-dependent shared library
|
103
|
-
building methods.
|
104
|
-
|
105
|
-
* Configure will use gcc (GNU C compiler) if it's available, otherwise cc.
|
106
|
-
To force a particular compiler to be selected, use the CC option, for example
|
107
|
-
./configure CC='cc'
|
108
|
-
The same method can be used to include any unusual compiler switches.
|
109
|
-
For example, on HP-UX you probably want to say
|
110
|
-
./configure CC='cc -Aa'
|
111
|
-
to get HP's compiler to run in ANSI mode.
|
112
|
-
|
113
|
-
* The default CFLAGS setting is "-g" for non-gcc compilers, "-g -O2" for gcc.
|
114
|
-
You can override this by saying, for example,
|
115
|
-
./configure CFLAGS='-O2'
|
116
|
-
if you want to compile without debugging support.
|
117
|
-
|
118
|
-
* Configure will set up the makefile so that "make install" will install files
|
119
|
-
into /usr/local/bin, /usr/local/man, etc. You can specify an installation
|
120
|
-
prefix other than "/usr/local" by giving configure the option "--prefix=PATH".
|
121
|
-
|
122
|
-
* If you don't have a lot of swap space, you may need to enable the IJG
|
123
|
-
software's internal virtual memory mechanism. To do this, give the option
|
124
|
-
"--enable-maxmem=N" where N is the default maxmemory limit in megabytes.
|
125
|
-
This is discussed in more detail under "Selecting a memory manager", below.
|
126
|
-
You probably don't need to worry about this on reasonably-sized Unix machines,
|
127
|
-
unless you plan to process very large images.
|
128
|
-
|
129
|
-
Configure has some other features that are useful if you are cross-compiling
|
130
|
-
or working in a network of multiple machine types; but if you need those
|
131
|
-
features, you probably already know how to use them.
|
132
|
-
|
133
|
-
|
134
|
-
Configuring the software using one of the supplied jconfig and makefile files
|
135
|
-
-----------------------------------------------------------------------------
|
136
|
-
|
137
|
-
If you have one of these systems, you can just use the provided configuration
|
138
|
-
files:
|
139
|
-
|
140
|
-
Makefile jconfig file System and/or compiler
|
141
|
-
|
142
|
-
makefile.manx jconfig.manx Amiga, Manx Aztec C
|
143
|
-
makefile.sas jconfig.sas Amiga, SAS C
|
144
|
-
makeproj.mac jconfig.mac Apple Macintosh, Metrowerks CodeWarrior
|
145
|
-
mak*jpeg.st jconfig.st Atari ST/STE/TT, Pure C or Turbo C
|
146
|
-
makefile.bcc jconfig.bcc MS-DOS or OS/2, Borland C
|
147
|
-
makefile.dj jconfig.dj MS-DOS, DJGPP (Delorie's port of GNU C)
|
148
|
-
makefile.mc6 jconfig.mc6 MS-DOS, Microsoft C (16-bit only)
|
149
|
-
makefile.wat jconfig.wat MS-DOS, OS/2, or Windows NT, Watcom C
|
150
|
-
makefile.vc jconfig.vc Windows NT/95, MS Visual C++
|
151
|
-
make*.vc6 jconfig.vc Windows NT/95, MS Visual C++ 6
|
152
|
-
make*.vc9 jconfig.vc Windows NT/95, MS Visual C++ 2008 (v9)
|
153
|
-
makefile.mms jconfig.vms Digital VMS, with MMS software
|
154
|
-
makefile.vms jconfig.vms Digital VMS, without MMS software
|
155
|
-
|
156
|
-
Copy the proper jconfig file to jconfig.h and the makefile to Makefile (or
|
157
|
-
whatever your system uses as the standard makefile name). For more info see
|
158
|
-
the appropriate system-specific hints section near the end of this file.
|
159
|
-
|
160
|
-
|
161
|
-
Configuring the software by hand
|
162
|
-
--------------------------------
|
163
|
-
|
164
|
-
First, generate a jconfig.h file. If you are moderately familiar with C,
|
165
|
-
the comments in jconfig.txt should be enough information to do this; just
|
166
|
-
copy jconfig.txt to jconfig.h and edit it appropriately. Otherwise, you may
|
167
|
-
prefer to use the ckconfig.c program. You will need to compile and execute
|
168
|
-
ckconfig.c by hand --- we hope you know at least enough to do that.
|
169
|
-
ckconfig.c may not compile the first try (in fact, the whole idea is for it
|
170
|
-
to fail if anything is going to). If you get compile errors, fix them by
|
171
|
-
editing ckconfig.c according to the directions given in ckconfig.c. Once
|
172
|
-
you get it to run, it will write a suitable jconfig.h file, and will also
|
173
|
-
print out some advice about which makefile to use.
|
174
|
-
|
175
|
-
You may also want to look at the canned jconfig files, if there is one for a
|
176
|
-
system similar to yours.
|
177
|
-
|
178
|
-
Second, select a makefile and copy it to Makefile (or whatever your system
|
179
|
-
uses as the standard makefile name). The most generic makefiles we provide
|
180
|
-
are
|
181
|
-
makefile.ansi: if your C compiler supports function prototypes
|
182
|
-
makefile.unix: if not.
|
183
|
-
(You have function prototypes if ckconfig.c put "#define HAVE_PROTOTYPES"
|
184
|
-
in jconfig.h.) You may want to start from one of the other makefiles if
|
185
|
-
there is one for a system similar to yours.
|
186
|
-
|
187
|
-
Look over the selected Makefile and adjust options as needed. In particular
|
188
|
-
you may want to change the CC and CFLAGS definitions. For instance, if you
|
189
|
-
are using GCC, set CC=gcc. If you had to use any compiler switches to get
|
190
|
-
ckconfig.c to work, make sure the same switches are in CFLAGS.
|
191
|
-
|
192
|
-
If you are on a system that doesn't use makefiles, you'll need to set up
|
193
|
-
project files (or whatever you do use) to compile all the source files and
|
194
|
-
link them into executable files cjpeg, djpeg, jpegtran, rdjpgcom, and wrjpgcom.
|
195
|
-
See the file lists in any of the makefiles to find out which files go into
|
196
|
-
each program. Note that the provided makefiles all make a "library" file
|
197
|
-
libjpeg first, but you don't have to do that if you don't want to; the file
|
198
|
-
lists identify which source files are actually needed for compression,
|
199
|
-
decompression, or both. As a last resort, you can make a batch script that
|
200
|
-
just compiles everything and links it all together; makefile.vms is an example
|
201
|
-
of this (it's for VMS systems that have no make-like utility).
|
202
|
-
|
203
|
-
Here are comments about some specific configuration decisions you'll
|
204
|
-
need to make:
|
205
|
-
|
206
|
-
Command line style
|
207
|
-
------------------
|
208
|
-
|
209
|
-
These programs can use a Unix-like command line style which supports
|
210
|
-
redirection and piping, like this:
|
211
|
-
cjpeg inputfile >outputfile
|
212
|
-
cjpeg <inputfile >outputfile
|
213
|
-
source program | cjpeg >outputfile
|
214
|
-
The simpler "two file" command line style is just
|
215
|
-
cjpeg inputfile outputfile
|
216
|
-
You may prefer the two-file style, particularly if you don't have pipes.
|
217
|
-
|
218
|
-
You MUST use two-file style on any system that doesn't cope well with binary
|
219
|
-
data fed through stdin/stdout; this is true for some MS-DOS compilers, for
|
220
|
-
example. If you're not on a Unix system, it's safest to assume you need
|
221
|
-
two-file style. (But if your compiler provides either the Posix-standard
|
222
|
-
fdopen() library routine or a Microsoft-compatible setmode() routine, you
|
223
|
-
can safely use the Unix command line style, by defining USE_FDOPEN or
|
224
|
-
USE_SETMODE respectively.)
|
225
|
-
|
226
|
-
To use the two-file style, make jconfig.h say "#define TWO_FILE_COMMANDLINE".
|
227
|
-
|
228
|
-
Selecting a memory manager
|
229
|
-
--------------------------
|
230
|
-
|
231
|
-
The IJG code is capable of working on images that are too big to fit in main
|
232
|
-
memory; data is swapped out to temporary files as necessary. However, the
|
233
|
-
code to do this is rather system-dependent. We provide five different
|
234
|
-
memory managers:
|
235
|
-
|
236
|
-
* jmemansi.c This version uses the ANSI-standard library routine tmpfile(),
|
237
|
-
which not all non-ANSI systems have. On some systems
|
238
|
-
tmpfile() may put the temporary file in a non-optimal
|
239
|
-
location; if you don't like what it does, use jmemname.c.
|
240
|
-
|
241
|
-
* jmemname.c This version creates named temporary files. For anything
|
242
|
-
except a Unix machine, you'll need to configure the
|
243
|
-
select_file_name() routine appropriately; see the comments
|
244
|
-
near the head of jmemname.c. If you use this version, define
|
245
|
-
NEED_SIGNAL_CATCHER in jconfig.h to make sure the temp files
|
246
|
-
are removed if the program is aborted.
|
247
|
-
|
248
|
-
* jmemnobs.c (That stands for No Backing Store :-).) This will compile on
|
249
|
-
almost any system, but it assumes you have enough main memory
|
250
|
-
or virtual memory to hold the biggest images you work with.
|
251
|
-
|
252
|
-
* jmemdos.c This should be used with most 16-bit MS-DOS compilers.
|
253
|
-
See the system-specific notes about MS-DOS for more info.
|
254
|
-
IMPORTANT: if you use this, define USE_MSDOS_MEMMGR in
|
255
|
-
jconfig.h, and include the assembly file jmemdosa.asm in the
|
256
|
-
programs. The supplied makefiles and jconfig files for
|
257
|
-
16-bit MS-DOS compilers already do both.
|
258
|
-
|
259
|
-
* jmemmac.c Custom version for Apple Macintosh; see the system-specific
|
260
|
-
notes for Macintosh for more info.
|
261
|
-
|
262
|
-
To use a particular memory manager, change the SYSDEPMEM variable in your
|
263
|
-
makefile to equal the corresponding object file name (for example, jmemansi.o
|
264
|
-
or jmemansi.obj for jmemansi.c).
|
265
|
-
|
266
|
-
If you have plenty of (real or virtual) main memory, just use jmemnobs.c.
|
267
|
-
"Plenty" means about ten bytes for every pixel in the largest images
|
268
|
-
you plan to process, so a lot of systems don't meet this criterion.
|
269
|
-
If yours doesn't, try jmemansi.c first. If that doesn't compile, you'll have
|
270
|
-
to use jmemname.c; be sure to adjust select_file_name() for local conditions.
|
271
|
-
You may also need to change unlink() to remove() in close_backing_store().
|
272
|
-
|
273
|
-
Except with jmemnobs.c or jmemmac.c, you need to adjust the DEFAULT_MAX_MEM
|
274
|
-
setting to a reasonable value for your system (either by adding a #define for
|
275
|
-
DEFAULT_MAX_MEM to jconfig.h, or by adding a -D switch to the Makefile).
|
276
|
-
This value limits the amount of data space the program will attempt to
|
277
|
-
allocate. Code and static data space isn't counted, so the actual memory
|
278
|
-
needs for cjpeg or djpeg are typically 100 to 150Kb more than the max-memory
|
279
|
-
setting. Larger max-memory settings reduce the amount of I/O needed to
|
280
|
-
process a large image, but too large a value can result in "insufficient
|
281
|
-
memory" failures. On most Unix machines (and other systems with virtual
|
282
|
-
memory), just set DEFAULT_MAX_MEM to several million and forget it. At the
|
283
|
-
other end of the spectrum, for MS-DOS machines you probably can't go much
|
284
|
-
above 300K to 400K. (On MS-DOS the value refers to conventional memory only.
|
285
|
-
Extended/expanded memory is handled separately by jmemdos.c.)
|
286
|
-
|
287
|
-
|
288
|
-
BUILDING THE SOFTWARE
|
289
|
-
=====================
|
290
|
-
|
291
|
-
Now you should be able to compile the software. Just say "make" (or
|
292
|
-
whatever's necessary to start the compilation). Have a cup of coffee.
|
293
|
-
|
294
|
-
Here are some things that could go wrong:
|
295
|
-
|
296
|
-
If your compiler complains about undefined structures, you should be able to
|
297
|
-
shut it up by putting "#define INCOMPLETE_TYPES_BROKEN" in jconfig.h.
|
298
|
-
|
299
|
-
If you have trouble with missing system include files or inclusion of the
|
300
|
-
wrong ones, read jinclude.h. This shouldn't happen if you used configure
|
301
|
-
or ckconfig.c to set up jconfig.h.
|
302
|
-
|
303
|
-
There are a fair number of routines that do not use all of their parameters;
|
304
|
-
some compilers will issue warnings about this, which you can ignore. There
|
305
|
-
are also a few configuration checks that may give "unreachable code" warnings.
|
306
|
-
Any other warning deserves investigation.
|
307
|
-
|
308
|
-
If you don't have a getenv() library routine, define NO_GETENV.
|
309
|
-
|
310
|
-
Also see the system-specific hints, below.
|
311
|
-
|
312
|
-
|
313
|
-
TESTING THE SOFTWARE
|
314
|
-
====================
|
315
|
-
|
316
|
-
As a quick test of functionality we've included a small sample image in
|
317
|
-
several forms:
|
318
|
-
testorig.jpg Starting point for the djpeg tests.
|
319
|
-
testimg.ppm The output of djpeg testorig.jpg
|
320
|
-
testimg.bmp The output of djpeg -bmp -colors 256 testorig.jpg
|
321
|
-
testimg.jpg The output of cjpeg testimg.ppm
|
322
|
-
testprog.jpg Progressive-mode equivalent of testorig.jpg.
|
323
|
-
testimgp.jpg The output of cjpeg -progressive -optimize testimg.ppm
|
324
|
-
(The first- and second-generation .jpg files aren't identical since JPEG is
|
325
|
-
lossy.) If you can generate duplicates of the testimg* files then you
|
326
|
-
probably have working programs.
|
327
|
-
|
328
|
-
With most of the makefiles, "make test" will perform the necessary
|
329
|
-
comparisons.
|
330
|
-
|
331
|
-
If you're using a makefile that doesn't provide the test option, run djpeg
|
332
|
-
and cjpeg by hand and compare the output files to testimg* with whatever
|
333
|
-
binary file comparison tool you have. The files should be bit-for-bit
|
334
|
-
identical.
|
335
|
-
|
336
|
-
If the programs complain "MAX_ALLOC_CHUNK is wrong, please fix", then you
|
337
|
-
need to reduce MAX_ALLOC_CHUNK to a value that fits in type size_t.
|
338
|
-
Try adding "#define MAX_ALLOC_CHUNK 65520L" to jconfig.h. A less likely
|
339
|
-
configuration error is "ALIGN_TYPE is wrong, please fix": defining ALIGN_TYPE
|
340
|
-
as long should take care of that one.
|
341
|
-
|
342
|
-
If the cjpeg test run fails with "Missing Huffman code table entry", it's a
|
343
|
-
good bet that you needed to define RIGHT_SHIFT_IS_UNSIGNED. Go back to the
|
344
|
-
configuration step and run ckconfig.c. (This is a good plan for any other
|
345
|
-
test failure, too.)
|
346
|
-
|
347
|
-
If you are using Unix (one-file) command line style on a non-Unix system,
|
348
|
-
it's a good idea to check that binary I/O through stdin/stdout actually
|
349
|
-
works. You should get the same results from "djpeg <testorig.jpg >out.ppm"
|
350
|
-
as from "djpeg -outfile out.ppm testorig.jpg". Note that the makefiles all
|
351
|
-
use the latter style and therefore do not exercise stdin/stdout! If this
|
352
|
-
check fails, try recompiling with USE_SETMODE or USE_FDOPEN defined.
|
353
|
-
If it still doesn't work, better use two-file style.
|
354
|
-
|
355
|
-
If you chose a memory manager other than jmemnobs.c, you should test that
|
356
|
-
temporary-file usage works. Try "djpeg -bmp -colors 256 -max 0 testorig.jpg"
|
357
|
-
and make sure its output matches testimg.bmp. If you have any really large
|
358
|
-
images handy, try compressing them with -optimize and/or decompressing with
|
359
|
-
-colors 256 to make sure your DEFAULT_MAX_MEM setting is not too large.
|
360
|
-
|
361
|
-
NOTE: this is far from an exhaustive test of the JPEG software; some modules,
|
362
|
-
such as 1-pass color quantization, are not exercised at all. It's just a
|
363
|
-
quick test to give you some confidence that you haven't missed something
|
364
|
-
major.
|
365
|
-
|
366
|
-
|
367
|
-
INSTALLING THE SOFTWARE
|
368
|
-
=======================
|
369
|
-
|
370
|
-
Once you're done with the above steps, you can install the software by
|
371
|
-
copying the executable files (cjpeg, djpeg, jpegtran, rdjpgcom, and wrjpgcom)
|
372
|
-
to wherever you normally install programs. On Unix systems, you'll also want
|
373
|
-
to put the man pages (cjpeg.1, djpeg.1, jpegtran.1, rdjpgcom.1, wrjpgcom.1)
|
374
|
-
in the man-page directory. The pre-fab makefiles don't support this step
|
375
|
-
since there's such a wide variety of installation procedures on different
|
376
|
-
systems.
|
377
|
-
|
378
|
-
If you generated a Makefile with the "configure" script, you can just say
|
379
|
-
make install
|
380
|
-
to install the programs and their man pages into the standard places.
|
381
|
-
(You'll probably need to be root to do this.) We recommend first saying
|
382
|
-
make -n install
|
383
|
-
to see where configure thought the files should go. You may need to edit
|
384
|
-
the Makefile, particularly if your system's conventions for man page
|
385
|
-
filenames don't match what configure expects.
|
386
|
-
|
387
|
-
If you want to install the IJG library itself, for use in compiling other
|
388
|
-
programs besides ours, then you need to put the four include files
|
389
|
-
jpeglib.h jerror.h jconfig.h jmorecfg.h
|
390
|
-
into your include-file directory, and put the library file libjpeg.a
|
391
|
-
(extension may vary depending on system) wherever library files go.
|
392
|
-
If you generated a Makefile with "configure", it will do what it thinks
|
393
|
-
is the right thing if you say
|
394
|
-
make install-lib
|
395
|
-
|
396
|
-
|
397
|
-
OPTIONAL STUFF
|
398
|
-
==============
|
399
|
-
|
400
|
-
Progress monitor:
|
401
|
-
|
402
|
-
If you like, you can #define PROGRESS_REPORT (in jconfig.h) to enable display
|
403
|
-
of percent-done progress reports. The routine provided in cdjpeg.c merely
|
404
|
-
prints percentages to stderr, but you can customize it to do something
|
405
|
-
fancier.
|
406
|
-
|
407
|
-
Utah RLE file format support:
|
408
|
-
|
409
|
-
We distribute the software with support for RLE image files (Utah Raster
|
410
|
-
Toolkit format) disabled, because the RLE support won't compile without the
|
411
|
-
Utah library. If you have URT version 3.1 or later, you can enable RLE
|
412
|
-
support as follows:
|
413
|
-
1. #define RLE_SUPPORTED in jconfig.h.
|
414
|
-
2. Add a -I option to CFLAGS in the Makefile for the directory
|
415
|
-
containing the URT .h files (typically the "include"
|
416
|
-
subdirectory of the URT distribution).
|
417
|
-
3. Add -L... -lrle to LDLIBS in the Makefile, where ... specifies
|
418
|
-
the directory containing the URT "librle.a" file (typically the
|
419
|
-
"lib" subdirectory of the URT distribution).
|
420
|
-
|
421
|
-
Support for 12-bit-deep pixel data:
|
422
|
-
|
423
|
-
The JPEG standard allows either 8-bit or 12-bit data precision. (For color,
|
424
|
-
this means 8 or 12 bits per channel, of course.) If you need to work with
|
425
|
-
deeper than 8-bit data, you can compile the IJG code for 12-bit operation.
|
426
|
-
To do so:
|
427
|
-
1. In jmorecfg.h, define BITS_IN_JSAMPLE as 12 rather than 8.
|
428
|
-
2. In jconfig.h, undefine BMP_SUPPORTED, RLE_SUPPORTED, and TARGA_SUPPORTED,
|
429
|
-
because the code for those formats doesn't handle 12-bit data and won't
|
430
|
-
even compile. (The PPM code does work, as explained below. The GIF
|
431
|
-
code works too; it scales 8-bit GIF data to and from 12-bit depth
|
432
|
-
automatically.)
|
433
|
-
3. Compile. Don't expect "make test" to pass, since the supplied test
|
434
|
-
files are for 8-bit data.
|
435
|
-
|
436
|
-
Currently, 12-bit support does not work on 16-bit-int machines.
|
437
|
-
|
438
|
-
Note that a 12-bit version will not read 8-bit JPEG files, nor vice versa;
|
439
|
-
so you'll want to keep around a regular 8-bit compilation as well.
|
440
|
-
(Run-time selection of data depth, to allow a single copy that does both,
|
441
|
-
is possible but would probably slow things down considerably; it's very low
|
442
|
-
on our to-do list.)
|
443
|
-
|
444
|
-
The PPM reader (rdppm.c) can read 12-bit data from either text-format or
|
445
|
-
binary-format PPM and PGM files. Binary-format PPM/PGM files which have a
|
446
|
-
maxval greater than 255 are assumed to use 2 bytes per sample, MSB first
|
447
|
-
(big-endian order). As of early 1995, 2-byte binary format is not
|
448
|
-
officially supported by the PBMPLUS library, but it is expected that a
|
449
|
-
future release of PBMPLUS will support it. Note that the PPM reader will
|
450
|
-
read files of any maxval regardless of the BITS_IN_JSAMPLE setting; incoming
|
451
|
-
data is automatically rescaled to either maxval=255 or maxval=4095 as
|
452
|
-
appropriate for the cjpeg bit depth.
|
453
|
-
|
454
|
-
The PPM writer (wrppm.c) will normally write 2-byte binary PPM or PGM
|
455
|
-
format, maxval 4095, when compiled with BITS_IN_JSAMPLE=12. Since this
|
456
|
-
format is not yet widely supported, you can disable it by compiling wrppm.c
|
457
|
-
with PPM_NORAWWORD defined; then the data is scaled down to 8 bits to make a
|
458
|
-
standard 1-byte/sample PPM or PGM file. (Yes, this means still another copy
|
459
|
-
of djpeg to keep around. But hopefully you won't need it for very long.
|
460
|
-
Poskanzer's supposed to get that new PBMPLUS release out Real Soon Now.)
|
461
|
-
|
462
|
-
Of course, if you are working with 12-bit data, you probably have it stored
|
463
|
-
in some other, nonstandard format. In that case you'll probably want to
|
464
|
-
write your own I/O modules to read and write your format.
|
465
|
-
|
466
|
-
Note that a 12-bit version of cjpeg always runs in "-optimize" mode, in
|
467
|
-
order to generate valid Huffman tables. This is necessary because our
|
468
|
-
default Huffman tables only cover 8-bit data.
|
469
|
-
|
470
|
-
Removing code:
|
471
|
-
|
472
|
-
If you need to make a smaller version of the JPEG software, some optional
|
473
|
-
functions can be removed at compile time. See the xxx_SUPPORTED #defines in
|
474
|
-
jconfig.h and jmorecfg.h. If at all possible, we recommend that you leave in
|
475
|
-
decoder support for all valid JPEG files, to ensure that you can read anyone's
|
476
|
-
output. Taking out support for image file formats that you don't use is the
|
477
|
-
most painless way to make the programs smaller. Another possibility is to
|
478
|
-
remove some of the DCT methods: in particular, the "IFAST" method may not be
|
479
|
-
enough faster than the others to be worth keeping on your machine. (If you
|
480
|
-
do remove ISLOW or IFAST, be sure to redefine JDCT_DEFAULT or JDCT_FASTEST
|
481
|
-
to a supported method, by adding a #define in jconfig.h.)
|
482
|
-
|
483
|
-
|
484
|
-
OPTIMIZATION
|
485
|
-
============
|
486
|
-
|
487
|
-
Unless you own a Cray, you'll probably be interested in making the JPEG
|
488
|
-
software go as fast as possible. This section covers some machine-dependent
|
489
|
-
optimizations you may want to try. We suggest that before trying any of
|
490
|
-
this, you first get the basic installation to pass the self-test step.
|
491
|
-
Repeat the self-test after any optimization to make sure that you haven't
|
492
|
-
broken anything.
|
493
|
-
|
494
|
-
The integer DCT routines perform a lot of multiplications. These
|
495
|
-
multiplications must yield 32-bit results, but none of their input values
|
496
|
-
are more than 16 bits wide. On many machines, notably the 680x0 and 80x86
|
497
|
-
CPUs, a 16x16=>32 bit multiply instruction is faster than a full 32x32=>32
|
498
|
-
bit multiply. Unfortunately there is no portable way to specify such a
|
499
|
-
multiplication in C, but some compilers can generate one when you use the
|
500
|
-
right combination of casts. See the MULTIPLYxxx macro definitions in
|
501
|
-
jdct.h. If your compiler makes "int" be 32 bits and "short" be 16 bits,
|
502
|
-
defining SHORTxSHORT_32 is fairly likely to work. When experimenting with
|
503
|
-
alternate definitions, be sure to test not only whether the code still works
|
504
|
-
(use the self-test), but also whether it is actually faster --- on some
|
505
|
-
compilers, alternate definitions may compute the right answer, yet be slower
|
506
|
-
than the default. Timing cjpeg on a large PGM (grayscale) input file is the
|
507
|
-
best way to check this, as the DCT will be the largest fraction of the runtime
|
508
|
-
in that mode. (Note: some of the distributed compiler-specific jconfig files
|
509
|
-
already contain #define switches to select appropriate MULTIPLYxxx
|
510
|
-
definitions.)
|
511
|
-
|
512
|
-
If your machine has sufficiently fast floating point hardware, you may find
|
513
|
-
that the float DCT method is faster than the integer DCT methods, even
|
514
|
-
after tweaking the integer multiply macros. In that case you may want to
|
515
|
-
make the float DCT be the default method. (The only objection to this is
|
516
|
-
that float DCT results may vary slightly across machines.) To do that, add
|
517
|
-
"#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h. Even if you don't change
|
518
|
-
the default, you should redefine JDCT_FASTEST, which is the method selected
|
519
|
-
by djpeg's -fast switch. Don't forget to update the documentation files
|
520
|
-
(usage.txt and/or cjpeg.1, djpeg.1) to agree with what you've done.
|
521
|
-
|
522
|
-
If access to "short" arrays is slow on your machine, it may be a win to
|
523
|
-
define type JCOEF as int rather than short. This will cost a good deal of
|
524
|
-
memory though, particularly in some multi-pass modes, so don't do it unless
|
525
|
-
you have memory to burn and short is REALLY slow.
|
526
|
-
|
527
|
-
If your compiler can compile function calls in-line, make sure the INLINE
|
528
|
-
macro in jmorecfg.h is defined as the keyword that marks a function
|
529
|
-
inline-able. Some compilers have a switch that tells the compiler to inline
|
530
|
-
any function it thinks is profitable (e.g., -finline-functions for gcc).
|
531
|
-
Enabling such a switch is likely to make the compiled code bigger but faster.
|
532
|
-
|
533
|
-
In general, it's worth trying the maximum optimization level of your compiler,
|
534
|
-
and experimenting with any optional optimizations such as loop unrolling.
|
535
|
-
(Unfortunately, far too many compilers have optimizer bugs ... be prepared to
|
536
|
-
back off if the code fails self-test.) If you do any experimentation along
|
537
|
-
these lines, please report the optimal settings to jpeg-info@jpegclub.org so
|
538
|
-
we can mention them in future releases. Be sure to specify your machine and
|
539
|
-
compiler version.
|
540
|
-
|
541
|
-
|
542
|
-
HINTS FOR SPECIFIC SYSTEMS
|
543
|
-
==========================
|
544
|
-
|
545
|
-
We welcome reports on changes needed for systems not mentioned here. Submit
|
546
|
-
'em to jpeg-info@jpegclub.org. Also, if configure or ckconfig.c is wrong
|
547
|
-
about how to configure the JPEG software for your system, please let us know.
|
548
|
-
|
549
|
-
|
550
|
-
Acorn RISC OS:
|
551
|
-
|
552
|
-
(Thanks to Simon Middleton for these hints on compiling with Desktop C.)
|
553
|
-
After renaming the files according to Acorn conventions, take a copy of
|
554
|
-
makefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' and
|
555
|
-
change these definitions as indicated:
|
556
|
-
|
557
|
-
CFLAGS= -throwback -IC: -Wn
|
558
|
-
LDLIBS=C:o.Stubs
|
559
|
-
SYSDEPMEM=jmemansi.o
|
560
|
-
LN=Link
|
561
|
-
AR=LibFile -c -o
|
562
|
-
|
563
|
-
Also add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'. Remove the
|
564
|
-
lines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'
|
565
|
-
dependency section.
|
566
|
-
|
567
|
-
Copy jconfig.txt to jconfig.h. Edit jconfig.h to define TWO_FILE_COMMANDLINE
|
568
|
-
and CHAR_IS_UNSIGNED.
|
569
|
-
|
570
|
-
Run the makefile using !AMU not !Make. If you want to use the 'clean' and
|
571
|
-
'test' makefile entries then you will have to fiddle with the syntax a bit
|
572
|
-
and rename the test files.
|
573
|
-
|
574
|
-
|
575
|
-
Amiga:
|
576
|
-
|
577
|
-
SAS C 6.50 reportedly is too buggy to compile the IJG code properly.
|
578
|
-
A patch to update to 6.51 is available from SAS or AmiNet FTP sites.
|
579
|
-
|
580
|
-
The supplied config files are set up to use jmemname.c as the memory
|
581
|
-
manager, with temporary files being created on the device named by
|
582
|
-
"JPEGTMP:".
|
583
|
-
|
584
|
-
|
585
|
-
Atari ST/STE/TT:
|
586
|
-
|
587
|
-
Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.st
|
588
|
-
to cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively. The
|
589
|
-
project files should work as-is with Pure C. For Turbo C, change library
|
590
|
-
filenames "pc..." to "tc..." in each project file. Note that libjpeg.prj
|
591
|
-
selects jmemansi.c as the recommended memory manager. You'll probably want to
|
592
|
-
adjust the DEFAULT_MAX_MEM setting --- you want it to be a couple hundred K
|
593
|
-
less than your normal free memory. Put "#define DEFAULT_MAX_MEM nnnn" into
|
594
|
-
jconfig.h to do this.
|
595
|
-
|
596
|
-
To use the 68881/68882 coprocessor for the floating point DCT, add the
|
597
|
-
compiler option "-8" to the project files and replace pcfltlib.lib with
|
598
|
-
pc881lib.lib in cjpeg.prj and djpeg.prj. Or if you don't have a
|
599
|
-
coprocessor, you may prefer to remove the float DCT code by undefining
|
600
|
-
DCT_FLOAT_SUPPORTED in jmorecfg.h (since without a coprocessor, the float
|
601
|
-
code will be too slow to be useful). In that case, you can delete
|
602
|
-
pcfltlib.lib from the project files.
|
603
|
-
|
604
|
-
Note that you must make libjpeg.lib before making cjpeg.ttp, djpeg.ttp,
|
605
|
-
or jpegtran.ttp. You'll have to perform the self-test by hand.
|
606
|
-
|
607
|
-
We haven't bothered to include project files for rdjpgcom and wrjpgcom.
|
608
|
-
Those source files should just be compiled by themselves; they don't
|
609
|
-
depend on the JPEG library. You can use the default.prj project file
|
610
|
-
of the Pure C distribution to make the programs.
|
611
|
-
|
612
|
-
There is a bug in some older versions of the Turbo C library which causes the
|
613
|
-
space used by temporary files created with "tmpfile()" not to be freed after
|
614
|
-
an abnormal program exit. If you check your disk afterwards, you will find
|
615
|
-
cluster chains that are allocated but not used by a file. This should not
|
616
|
-
happen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitly
|
617
|
-
close temp files before exiting. But if you use the JPEG library with your
|
618
|
-
own code, be sure to supply a signal catcher, or else use a different
|
619
|
-
system-dependent memory manager.
|
620
|
-
|
621
|
-
|
622
|
-
Cray:
|
623
|
-
|
624
|
-
Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
|
625
|
-
compiler bug in old versions of Cray's Standard C (prior to 3.1). If you
|
626
|
-
still have an old compiler, you'll need to insert a line reading
|
627
|
-
"#pragma novector" just before the loop
|
628
|
-
for (i = 1; i <= (int) htbl->bits[l]; i++)
|
629
|
-
huffsize[p++] = (char) l;
|
630
|
-
in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).
|
631
|
-
[This bug may or may not still occur with the current IJG code, but it's
|
632
|
-
probably a dead issue anyway...]
|
633
|
-
|
634
|
-
|
635
|
-
HP-UX:
|
636
|
-
|
637
|
-
If you have HP-UX 7.05 or later with the "software development" C compiler,
|
638
|
-
you should run the compiler in ANSI mode. If using the configure script,
|
639
|
-
say
|
640
|
-
./configure CC='cc -Aa'
|
641
|
-
(or -Ae if you prefer). If configuring by hand, use makefile.ansi and add
|
642
|
-
"-Aa" to the CFLAGS line in the makefile.
|
643
|
-
|
644
|
-
If you have a pre-7.05 system, or if you are using the non-ANSI C compiler
|
645
|
-
delivered with a minimum HP-UX system, then you must use makefile.unix
|
646
|
-
(and do NOT add -Aa); or just run configure without the CC option.
|
647
|
-
|
648
|
-
On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
|
649
|
-
to A.08.07. If you get complaints about "not a typedef name", you'll have to
|
650
|
-
use makefile.unix, or run configure without the CC option.
|
651
|
-
|
652
|
-
|
653
|
-
Macintosh, generic comments:
|
654
|
-
|
655
|
-
The supplied user-interface files (cjpeg.c, djpeg.c, etc) are set up to
|
656
|
-
provide a Unix-style command line interface. You can use this interface on
|
657
|
-
the Mac by means of the ccommand() library routine provided by Metrowerks
|
658
|
-
CodeWarrior or Think C. This is only appropriate for testing the library,
|
659
|
-
however; to make a user-friendly equivalent of cjpeg/djpeg you'd really want
|
660
|
-
to develop a Mac-style user interface. There isn't a complete example
|
661
|
-
available at the moment, but there are some helpful starting points:
|
662
|
-
1. Sam Bushell's free "To JPEG" applet provides drag-and-drop conversion to
|
663
|
-
JPEG under System 7 and later. This only illustrates how to use the
|
664
|
-
compression half of the library, but it does a very nice job of that part.
|
665
|
-
The CodeWarrior source code is available from http://www.pobox.com/~jsam.
|
666
|
-
2. Jim Brunner prepared a Mac-style user interface for both compression and
|
667
|
-
decompression. Unfortunately, it hasn't been updated since IJG v4, and
|
668
|
-
the library's API has changed considerably since then. Still it may be of
|
669
|
-
some help, particularly as a guide to compiling the IJG code under Think C.
|
670
|
-
Jim's code is available from the Info-Mac archives, at sumex-aim.stanford.edu
|
671
|
-
or mirrors thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.
|
672
|
-
|
673
|
-
jmemmac.c is the recommended memory manager back end for Macintosh. It uses
|
674
|
-
NewPtr/DisposePtr instead of malloc/free, and has a Mac-specific
|
675
|
-
implementation of jpeg_mem_available(). It also creates temporary files that
|
676
|
-
follow Mac conventions. (That part of the code relies on System-7-or-later OS
|
677
|
-
functions. See the comments in jmemmac.c if you need to run it on System 6.)
|
678
|
-
NOTE that USE_MAC_MEMMGR must be defined in jconfig.h to use jmemmac.c.
|
679
|
-
|
680
|
-
You can also use jmemnobs.c, if you don't care about handling images larger
|
681
|
-
than available memory. If you use any memory manager back end other than
|
682
|
-
jmemmac.c, we recommend replacing "malloc" and "free" by "NewPtr" and
|
683
|
-
"DisposePtr", because Mac C libraries often have peculiar implementations of
|
684
|
-
malloc/free. (For instance, free() may not return the freed space to the
|
685
|
-
Mac Memory Manager. This is undesirable for the IJG code because jmemmgr.c
|
686
|
-
already clumps space requests.)
|
687
|
-
|
688
|
-
|
689
|
-
Macintosh, Metrowerks CodeWarrior:
|
690
|
-
|
691
|
-
The Unix-command-line-style interface can be used by defining USE_CCOMMAND.
|
692
|
-
You'll also need to define TWO_FILE_COMMANDLINE to avoid stdin/stdout.
|
693
|
-
This means that when using the cjpeg/djpeg programs, you'll have to type the
|
694
|
-
input and output file names in the "Arguments" text-edit box, rather than
|
695
|
-
using the file radio buttons. (Perhaps USE_FDOPEN or USE_SETMODE would
|
696
|
-
eliminate the problem, but I haven't heard from anyone who's tried it.)
|
697
|
-
|
698
|
-
On 680x0 Macs, Metrowerks defines type "double" as a 10-byte IEEE extended
|
699
|
-
float. jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power
|
700
|
-
of 2. Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.
|
701
|
-
|
702
|
-
The supplied configuration file jconfig.mac can be used for your jconfig.h;
|
703
|
-
it includes all the recommended symbol definitions. If you have AppleScript
|
704
|
-
installed, you can run the supplied script makeproj.mac to create CodeWarrior
|
705
|
-
project files for the library and the testbed applications, then build the
|
706
|
-
library and applications. (Thanks to Dan Sears and Don Agro for this nifty
|
707
|
-
hack, which saves us from trying to maintain CodeWarrior project files as part
|
708
|
-
of the IJG distribution...)
|
709
|
-
|
710
|
-
|
711
|
-
Macintosh, Think C:
|
712
|
-
|
713
|
-
The documentation in Jim Brunner's "JPEG Convert" source code (see above)
|
714
|
-
includes detailed build instructions for Think C; it's probably somewhat
|
715
|
-
out of date for the current release, but may be helpful.
|
716
|
-
|
717
|
-
If you want to build the minimal command line version, proceed as follows.
|
718
|
-
You'll have to prepare project files for the programs; we don't include any
|
719
|
-
in the distribution since they are not text files. Use the file lists in
|
720
|
-
any of the supplied makefiles as a guide. Also add the ANSI and Unix C
|
721
|
-
libraries in a separate segment. You may need to divide the JPEG files into
|
722
|
-
more than one segment; we recommend dividing compression and decompression
|
723
|
-
modules. Define USE_CCOMMAND in jconfig.h so that the ccommand() routine is
|
724
|
-
called. You must also define TWO_FILE_COMMANDLINE because stdin/stdout
|
725
|
-
don't handle binary data correctly.
|
726
|
-
|
727
|
-
On 680x0 Macs, Think C defines type "double" as a 12-byte IEEE extended float.
|
728
|
-
jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power of 2.
|
729
|
-
Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.
|
730
|
-
|
731
|
-
jconfig.mac should work as a jconfig.h configuration file for Think C,
|
732
|
-
but the makeproj.mac AppleScript script is specific to CodeWarrior. Sorry.
|
733
|
-
|
734
|
-
|
735
|
-
MIPS R3000:
|
736
|
-
|
737
|
-
MIPS's cc version 1.31 has a rather nasty optimization bug. Don't use -O
|
738
|
-
if you have that compiler version. (Use "cc -V" to check the version.)
|
739
|
-
Note that the R3000 chip is found in workstations from DEC and others.
|
740
|
-
|
741
|
-
|
742
|
-
MS-DOS, generic comments for 16-bit compilers:
|
743
|
-
|
744
|
-
The IJG code is designed to work well in 80x86 "small" or "medium" memory
|
745
|
-
models (i.e., data pointers are 16 bits unless explicitly declared "far";
|
746
|
-
code pointers can be either size). You may be able to use small model to
|
747
|
-
compile cjpeg or djpeg by itself, but you will probably have to use medium
|
748
|
-
model for any larger application. This won't make much difference in
|
749
|
-
performance. You *will* take a noticeable performance hit if you use a
|
750
|
-
large-data memory model, and you should avoid "huge" model if at all
|
751
|
-
possible. Be sure that NEED_FAR_POINTERS is defined in jconfig.h if you use
|
752
|
-
a small-data memory model; be sure it is NOT defined if you use a large-data
|
753
|
-
model. (The supplied makefiles and jconfig files for Borland and Microsoft C
|
754
|
-
compile in medium model and define NEED_FAR_POINTERS.)
|
755
|
-
|
756
|
-
The DOS-specific memory manager, jmemdos.c, should be used if possible.
|
757
|
-
It needs some assembly-code routines which are in jmemdosa.asm; make sure
|
758
|
-
your makefile assembles that file and includes it in the library. If you
|
759
|
-
don't have a suitable assembler, you can get pre-assembled object files for
|
760
|
-
jmemdosa by FTP from ftp.uu.net:/graphics/jpeg/jdosaobj.zip. (DOS-oriented
|
761
|
-
distributions of the IJG source code often include these object files.)
|
762
|
-
|
763
|
-
When using jmemdos.c, jconfig.h must define USE_MSDOS_MEMMGR and must set
|
764
|
-
MAX_ALLOC_CHUNK to less than 64K (65520L is a typical value). If your
|
765
|
-
C library's far-heap malloc() can't allocate blocks that large, reduce
|
766
|
-
MAX_ALLOC_CHUNK to whatever it can handle.
|
767
|
-
|
768
|
-
If you can't use jmemdos.c for some reason --- for example, because you
|
769
|
-
don't have an assembler to assemble jmemdosa.asm --- you'll have to fall
|
770
|
-
back to jmemansi.c or jmemname.c. You'll probably still need to set
|
771
|
-
MAX_ALLOC_CHUNK in jconfig.h, because most DOS C libraries won't malloc()
|
772
|
-
more than 64K at a time. IMPORTANT: if you use jmemansi.c or jmemname.c,
|
773
|
-
you will have to compile in a large-data memory model in order to get the
|
774
|
-
right stdio library. Too bad.
|
775
|
-
|
776
|
-
wrjpgcom needs to be compiled in large model, because it malloc()s a 64KB
|
777
|
-
work area to hold the comment text. If your C library's malloc can't
|
778
|
-
handle that, reduce MAX_COM_LENGTH as necessary in wrjpgcom.c.
|
779
|
-
|
780
|
-
Most MS-DOS compilers treat stdin/stdout as text files, so you must use
|
781
|
-
two-file command line style. But if your compiler has either fdopen() or
|
782
|
-
setmode(), you can use one-file style if you like. To do this, define
|
783
|
-
USE_SETMODE or USE_FDOPEN so that stdin/stdout will be set to binary mode.
|
784
|
-
(USE_SETMODE seems to work with more DOS compilers than USE_FDOPEN.) You
|
785
|
-
should test that I/O through stdin/stdout produces the same results as I/O
|
786
|
-
to explicitly named files... the "make test" procedures in the supplied
|
787
|
-
makefiles do NOT use stdin/stdout.
|
788
|
-
|
789
|
-
|
790
|
-
MS-DOS, generic comments for 32-bit compilers:
|
791
|
-
|
792
|
-
None of the above comments about memory models apply if you are using a
|
793
|
-
32-bit flat-memory-space environment, such as DJGPP or Watcom C. (And you
|
794
|
-
should use one if you have it, as performance will be much better than
|
795
|
-
8086-compatible code!) For flat-memory-space compilers, do NOT define
|
796
|
-
NEED_FAR_POINTERS, and do NOT use jmemdos.c. Use jmemnobs.c if the
|
797
|
-
environment supplies adequate virtual memory, otherwise use jmemansi.c or
|
798
|
-
jmemname.c.
|
799
|
-
|
800
|
-
You'll still need to be careful about binary I/O through stdin/stdout.
|
801
|
-
See the last paragraph of the previous section.
|
802
|
-
|
803
|
-
|
804
|
-
MS-DOS, Borland C:
|
805
|
-
|
806
|
-
Be sure to convert all the source files to DOS text format (CR/LF newlines).
|
807
|
-
Although Borland C will often work OK with unmodified Unix (LF newlines)
|
808
|
-
source files, sometimes it will give bogus compile errors.
|
809
|
-
"Illegal character '#'" is the most common such error. (This is true with
|
810
|
-
Borland C 3.1, but perhaps is fixed in newer releases.)
|
811
|
-
|
812
|
-
If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
|
813
|
-
jconfig.bcc already includes #define USE_SETMODE to make this work.
|
814
|
-
(fdopen does not work correctly.)
|
815
|
-
|
816
|
-
|
817
|
-
MS-DOS, Microsoft C:
|
818
|
-
|
819
|
-
makefile.mc6 works with Microsoft C, DOS Visual C++, etc. It should only
|
820
|
-
be used if you want to build a 16-bit (small or medium memory model) program.
|
821
|
-
|
822
|
-
If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
|
823
|
-
jconfig.mc6 already includes #define USE_SETMODE to make this work.
|
824
|
-
(fdopen does not work correctly.)
|
825
|
-
|
826
|
-
Note that this makefile assumes that the working copy of itself is called
|
827
|
-
"makefile". If you want to call it something else, say "makefile.mak",
|
828
|
-
be sure to adjust the dependency line that reads "$(RFILE) : makefile".
|
829
|
-
Otherwise the make will fail because it doesn't know how to create "makefile".
|
830
|
-
Worse, some releases of Microsoft's make utilities give an incorrect error
|
831
|
-
message in this situation.
|
832
|
-
|
833
|
-
Old versions of MS C fail with an "out of macro expansion space" error
|
834
|
-
because they can't cope with the macro TRACEMS8 (defined in jerror.h).
|
835
|
-
If this happens to you, the easiest solution is to change TRACEMS8 to
|
836
|
-
expand to nothing. You'll lose the ability to dump out JPEG coefficient
|
837
|
-
tables with djpeg -debug -debug, but at least you can compile.
|
838
|
-
|
839
|
-
Original MS C 6.0 is very buggy; it compiles incorrect code unless you turn
|
840
|
-
off optimization entirely (remove -O from CFLAGS). 6.00A is better, but it
|
841
|
-
still generates bad code if you enable loop optimizations (-Ol or -Ox).
|
842
|
-
|
843
|
-
MS C 8.0 crashes when compiling jquant1.c with optimization switch /Oo ...
|
844
|
-
which is on by default. To work around this bug, compile that one file
|
845
|
-
with /Oo-.
|
846
|
-
|
847
|
-
|
848
|
-
Microsoft Windows (all versions), generic comments:
|
849
|
-
|
850
|
-
Some Windows system include files define typedef boolean as "unsigned char".
|
851
|
-
The IJG code also defines typedef boolean, but we make it "int" by default.
|
852
|
-
This doesn't affect the IJG programs because we don't import those Windows
|
853
|
-
include files. But if you use the JPEG library in your own program, and some
|
854
|
-
of your program's files import one definition of boolean while some import the
|
855
|
-
other, you can get all sorts of mysterious problems. A good preventive step
|
856
|
-
is to make the IJG library use "unsigned char" for boolean. To do that,
|
857
|
-
add something like this to your jconfig.h file:
|
858
|
-
/* Define "boolean" as unsigned char, not int, per Windows custom */
|
859
|
-
#ifndef __RPCNDR_H__ /* don't conflict if rpcndr.h already read */
|
860
|
-
typedef unsigned char boolean;
|
861
|
-
#endif
|
862
|
-
#define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
|
863
|
-
(This is already in jconfig.vc, by the way.)
|
864
|
-
|
865
|
-
windef.h contains the declarations
|
866
|
-
#define far
|
867
|
-
#define FAR far
|
868
|
-
Since jmorecfg.h tries to define FAR as empty, you may get a compiler
|
869
|
-
warning if you include both jpeglib.h and windef.h (which windows.h
|
870
|
-
includes). To suppress the warning, you can put "#ifndef FAR"/"#endif"
|
871
|
-
around the line "#define FAR" in jmorecfg.h.
|
872
|
-
(Something like this is already in jmorecfg.h, by the way.)
|
873
|
-
|
874
|
-
When using the library in a Windows application, you will almost certainly
|
875
|
-
want to modify or replace the error handler module jerror.c, since our
|
876
|
-
default error handler does a couple of inappropriate things:
|
877
|
-
1. it tries to write error and warning messages on stderr;
|
878
|
-
2. in event of a fatal error, it exits by calling exit().
|
879
|
-
|
880
|
-
A simple stopgap solution for problem 1 is to replace the line
|
881
|
-
fprintf(stderr, "%s\n", buffer);
|
882
|
-
(in output_message in jerror.c) with
|
883
|
-
MessageBox(GetActiveWindow(),buffer,"JPEG Error",MB_OK|MB_ICONERROR);
|
884
|
-
It's highly recommended that you at least do that much, since otherwise
|
885
|
-
error messages will disappear into nowhere. (Beginning with IJG v6b, this
|
886
|
-
code is already present in jerror.c; just define USE_WINDOWS_MESSAGEBOX in
|
887
|
-
jconfig.h to enable it.)
|
888
|
-
|
889
|
-
The proper solution for problem 2 is to return control to your calling
|
890
|
-
application after a library error. This can be done with the setjmp/longjmp
|
891
|
-
technique discussed in libjpeg.txt and illustrated in example.c. (NOTE:
|
892
|
-
some older Windows C compilers provide versions of setjmp/longjmp that
|
893
|
-
don't actually work under Windows. You may need to use the Windows system
|
894
|
-
functions Catch and Throw instead.)
|
895
|
-
|
896
|
-
The recommended memory manager under Windows is jmemnobs.c; in other words,
|
897
|
-
let Windows do any virtual memory management needed. You should NOT use
|
898
|
-
jmemdos.c nor jmemdosa.asm under Windows.
|
899
|
-
|
900
|
-
For Windows 3.1, we recommend compiling in medium or large memory model;
|
901
|
-
for newer Windows versions, use a 32-bit flat memory model. (See the MS-DOS
|
902
|
-
sections above for more info about memory models.) In the 16-bit memory
|
903
|
-
models only, you'll need to put
|
904
|
-
#define MAX_ALLOC_CHUNK 65520L /* Maximum request to malloc() */
|
905
|
-
into jconfig.h to limit allocation chunks to 64Kb. (Without that, you'd
|
906
|
-
have to use huge memory model, which slows things down unnecessarily.)
|
907
|
-
jmemnobs.c works without modification in large or flat memory models, but to
|
908
|
-
use medium model, you need to modify its jpeg_get_large and jpeg_free_large
|
909
|
-
routines to allocate far memory. In any case, you might like to replace
|
910
|
-
its calls to malloc and free with direct calls on Windows memory allocation
|
911
|
-
functions.
|
912
|
-
|
913
|
-
You may also want to modify jdatasrc.c and jdatadst.c to use Windows file
|
914
|
-
operations rather than fread/fwrite. This is only necessary if your C
|
915
|
-
compiler doesn't provide a competent implementation of C stdio functions.
|
916
|
-
|
917
|
-
You might want to tweak the RGB_xxx macros in jmorecfg.h so that the library
|
918
|
-
will accept or deliver color pixels in BGR sample order, not RGB; BGR order
|
919
|
-
is usually more convenient under Windows. Note that this change will break
|
920
|
-
the sample applications cjpeg/djpeg, but the library itself works fine.
|
921
|
-
|
922
|
-
|
923
|
-
Many people want to convert the IJG library into a DLL. This is reasonably
|
924
|
-
straightforward, but watch out for the following:
|
925
|
-
|
926
|
-
1. Don't try to compile as a DLL in small or medium memory model; use
|
927
|
-
large model, or even better, 32-bit flat model. Many places in the IJG code
|
928
|
-
assume the address of a local variable is an ordinary (not FAR) pointer;
|
929
|
-
that isn't true in a medium-model DLL.
|
930
|
-
|
931
|
-
2. Microsoft C cannot pass file pointers between applications and DLLs.
|
932
|
-
(See Microsoft Knowledge Base, PSS ID Number Q50336.) So jdatasrc.c and
|
933
|
-
jdatadst.c don't work if you open a file in your application and then pass
|
934
|
-
the pointer to the DLL. One workaround is to make jdatasrc.c/jdatadst.c
|
935
|
-
part of your main application rather than part of the DLL.
|
936
|
-
|
937
|
-
3. You'll probably need to modify the macros GLOBAL() and EXTERN() to
|
938
|
-
attach suitable linkage keywords to the exported routine names. Similarly,
|
939
|
-
you'll want to modify METHODDEF() and JMETHOD() to ensure function pointers
|
940
|
-
are declared in a way that lets application routines be called back through
|
941
|
-
the function pointers. These macros are in jmorecfg.h. Typical definitions
|
942
|
-
for a 16-bit DLL are:
|
943
|
-
#define GLOBAL(type) type _far _pascal _loadds _export
|
944
|
-
#define EXTERN(type) extern type _far _pascal _loadds
|
945
|
-
#define METHODDEF(type) static type _far _pascal
|
946
|
-
#define JMETHOD(type,methodname,arglist) \
|
947
|
-
type (_far _pascal *methodname) arglist
|
948
|
-
For a 32-bit DLL you may want something like
|
949
|
-
#define GLOBAL(type) __declspec(dllexport) type
|
950
|
-
#define EXTERN(type) extern __declspec(dllexport) type
|
951
|
-
Although not all the GLOBAL routines are actually intended to be called by
|
952
|
-
the application, the performance cost of making them all DLL entry points is
|
953
|
-
negligible.
|
954
|
-
|
955
|
-
The unmodified IJG library presents a very C-specific application interface,
|
956
|
-
so the resulting DLL is only usable from C or C++ applications. There has
|
957
|
-
been some talk of writing wrapper code that would present a simpler interface
|
958
|
-
usable from other languages, such as Visual Basic. This is on our to-do list
|
959
|
-
but hasn't been very high priority --- any volunteers out there?
|
960
|
-
|
961
|
-
|
962
|
-
Microsoft Windows, Borland C:
|
963
|
-
|
964
|
-
The provided jconfig.bcc should work OK in a 32-bit Windows environment,
|
965
|
-
but you'll need to tweak it in a 16-bit environment (you'd need to define
|
966
|
-
NEED_FAR_POINTERS and MAX_ALLOC_CHUNK). Beware that makefile.bcc will need
|
967
|
-
alteration if you want to use it for Windows --- in particular, you should
|
968
|
-
use jmemnobs.c not jmemdos.c under Windows.
|
969
|
-
|
970
|
-
Borland C++ 4.5 fails with an internal compiler error when trying to compile
|
971
|
-
jdmerge.c in 32-bit mode. If enough people complain, perhaps Borland will fix
|
972
|
-
it. In the meantime, the simplest known workaround is to add a redundant
|
973
|
-
definition of the variable range_limit in h2v1_merged_upsample(), at the head
|
974
|
-
of the block that handles odd image width (about line 268 in v6 jdmerge.c):
|
975
|
-
/* If image width is odd, do the last output column separately */
|
976
|
-
if (cinfo->output_width & 1) {
|
977
|
-
register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
|
978
|
-
cb = GETJSAMPLE(*inptr1);
|
979
|
-
Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
|
980
|
-
doesn't trigger the bug.
|
981
|
-
Recent reports suggest that this bug does not occur with "bcc32a" (the
|
982
|
-
Pentium-optimized version of the compiler).
|
983
|
-
|
984
|
-
Another report from a user of Borland C 4.5 was that incorrect code (leading
|
985
|
-
to a color shift in processed images) was produced if any of the following
|
986
|
-
optimization switch combinations were used:
|
987
|
-
-Ot -Og
|
988
|
-
-Ot -Op
|
989
|
-
-Ot -Om
|
990
|
-
So try backing off on optimization if you see such a problem. (Are there
|
991
|
-
several different releases all numbered "4.5"??)
|
992
|
-
|
993
|
-
|
994
|
-
Microsoft Windows, Microsoft Visual C++:
|
995
|
-
|
996
|
-
jconfig.vc should work OK with any Microsoft compiler for a 32-bit memory
|
997
|
-
model. makefile.vc is intended for command-line use. (If you are using
|
998
|
-
the Developer Studio environment, you may prefer the DevStudio project
|
999
|
-
files; see below.)
|
1000
|
-
|
1001
|
-
v7 adds extern "C" to jpeglib.h. This avoids the need to put extern "C"
|
1002
|
-
{ ... } around #include "jpeglib.h" in your C++ application.
|
1003
|
-
You can also force VC++ to treat the library as C++ code by renaming
|
1004
|
-
all the *.c files to *.cpp (and adjusting the makefile to match).
|
1005
|
-
In this case you also need to define the symbol DONT_USE_EXTERN_C in
|
1006
|
-
the configuration to prevent jpeglib.h from using extern "C".
|
1007
|
-
|
1008
|
-
|
1009
|
-
Microsoft Windows, Microsoft Visual C++ 6 Developer Studio:
|
1010
|
-
|
1011
|
-
We include makefiles that should work as project files in DevStudio 6.0 or
|
1012
|
-
later. There is a library makefile that builds the IJG library as a static
|
1013
|
-
Win32 library, and application makefiles that build the sample applications
|
1014
|
-
as Win32 console applications. (Even if you only want the library, we
|
1015
|
-
recommend building the applications so that you can run the self-test.)
|
1016
|
-
|
1017
|
-
To use:
|
1018
|
-
1. Copy jconfig.vc to jconfig.h, makejdsw.vc6 to jpeg.dsw,
|
1019
|
-
makeadsw.vc6 to apps.dsw, makejmak.vc6 to jpeg.mak,
|
1020
|
-
makejdep.vc6 to jpeg.dep, makejdsp.vc6 to jpeg.dsp,
|
1021
|
-
makecmak.vc6 to cjpeg.mak, makecdep.vc6 to cjpeg.dep,
|
1022
|
-
makecdsp.vc6 to cjpeg.dsp, makedmak.vc6 to djpeg.mak,
|
1023
|
-
makeddep.vc6 to djpeg.dep, makeddsp.vc6 to djpeg.dsp,
|
1024
|
-
maketmak.vc6 to jpegtran.mak, maketdep.vc6 to jpegtran.dep,
|
1025
|
-
maketdsp.vc6 to jpegtran.dsp, makermak.vc6 to rdjpgcom.mak,
|
1026
|
-
makerdep.vc6 to rdjpgcom.dep, makerdsp.vc6 to rdjpgcom.dsp,
|
1027
|
-
makewmak.vc6 to wrjpgcom.mak, makewdep.vc6 to wrjpgcom.dep, and
|
1028
|
-
makewdsp.vc6 to wrjpgcom.dsp. (Note that the renaming is critical!)
|
1029
|
-
2. Click on jpeg.dsw and apps.dsw to load the project workspaces.
|
1030
|
-
(If you are using DevStudio more recent than 6.0, you'll probably
|
1031
|
-
get a message saying that the project files are being updated.)
|
1032
|
-
3. Build the library project, then the applications project.
|
1033
|
-
4. Move the application .exe files from `app`\Release to an
|
1034
|
-
appropriate location on your path.
|
1035
|
-
5. To perform the self-test, execute the command line
|
1036
|
-
NMAKE /f makefile.vc test
|
1037
|
-
|
1038
|
-
|
1039
|
-
Microsoft Windows, Microsoft Visual C++ 2008 Developer Studio (v9):
|
1040
|
-
|
1041
|
-
We include makefiles that should work as project files in Visual Studio
|
1042
|
-
2008 or later. There is a library makefile that builds the IJG library
|
1043
|
-
as a static Win32 library, and application makefiles that build the sample
|
1044
|
-
applications as Win32 console applications. (Even if you only want the
|
1045
|
-
library, we recommend building the applications so that you can run the
|
1046
|
-
self-test.)
|
1047
|
-
|
1048
|
-
To use:
|
1049
|
-
1. Copy jconfig.vc to jconfig.h, makejsln.vc9 to jpeg.sln,
|
1050
|
-
makeasln.vc9 to apps.sln, makejvcp.vc9 to jpeg.vcproj,
|
1051
|
-
makecvcp.vc9 to cjpeg.vcproj, makedvcp.vc9 to djpeg.vcproj,
|
1052
|
-
maketvcp.vc9 to jpegtran.vcproj, makervcp.vc9 to rdjpgcom.vcproj, and
|
1053
|
-
makewvcp.vc9 to wrjpgcom.vcproj. (Note that the renaming is critical!)
|
1054
|
-
2. Click on jpeg.sln and apps.sln to load the project solutions.
|
1055
|
-
(If you are using Visual Studio more recent than 2008 (v9), you'll
|
1056
|
-
probably get a message saying that the project files are being
|
1057
|
-
updated.)
|
1058
|
-
3. Build the library project, then the applications project.
|
1059
|
-
4. Move the application .exe files from `app`\Release to an
|
1060
|
-
appropriate location on your path.
|
1061
|
-
5. To perform the self-test, execute the command line
|
1062
|
-
NMAKE /f makefile.vc test
|
1063
|
-
|
1064
|
-
|
1065
|
-
OS/2, Borland C++:
|
1066
|
-
|
1067
|
-
Watch out for optimization bugs in older Borland compilers; you may need
|
1068
|
-
to back off the optimization switch settings. See the comments in
|
1069
|
-
makefile.bcc.
|
1070
|
-
|
1071
|
-
|
1072
|
-
SGI:
|
1073
|
-
|
1074
|
-
On some SGI systems, you may need to set "AR2= ar -ts" in the Makefile.
|
1075
|
-
If you are using configure, you can do this by saying
|
1076
|
-
./configure RANLIB='ar -ts'
|
1077
|
-
This change is not needed on all SGIs. Use it only if the make fails at the
|
1078
|
-
stage of linking the completed programs.
|
1079
|
-
|
1080
|
-
On the MIPS R4000 architecture (Indy, etc.), the compiler option "-mips2"
|
1081
|
-
reportedly speeds up the float DCT method substantially, enough to make it
|
1082
|
-
faster than the default int method (but still slower than the fast int
|
1083
|
-
method). If you use -mips2, you may want to alter the default DCT method to
|
1084
|
-
be float. To do this, put "#define JDCT_DEFAULT JDCT_FLOAT" in jconfig.h.
|
1085
|
-
|
1086
|
-
|
1087
|
-
VMS:
|
1088
|
-
|
1089
|
-
On an Alpha/VMS system with MMS, be sure to use the "/Marco=Alpha=1"
|
1090
|
-
qualifier with MMS when building the JPEG package.
|
1091
|
-
|
1092
|
-
VAX/VMS v5.5-1 may have problems with the test step of the build procedure
|
1093
|
-
reporting differences when it compares the original and test images. If the
|
1094
|
-
error points to the last block of the files, it is most likely bogus and may
|
1095
|
-
be safely ignored. It seems to be because the files are Stream_LF and
|
1096
|
-
Backup/Compare has difficulty with the (presumably) null padded files.
|
1097
|
-
This problem was not observed on VAX/VMS v6.1 or AXP/VMS v6.1.
|