Alien-FreeImage

 view release on metacpan or  search on metacpan

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

read files of any maxval regardless of the BITS_IN_JSAMPLE setting; incoming
data is automatically rescaled to maxval=MAXJSAMPLE as appropriate for the
cjpeg bit depth.

The PPM writer (wrppm.c) will normally write 2-byte binary PPM or PGM
format, maxval=MAXJSAMPLE, when compiled with BITS_IN_JSAMPLE>8.  Since this
format is not yet widely supported, you can disable it by compiling wrppm.c
with PPM_NORAWWORD defined; then the data is scaled down to 8 bits to make a
standard 1-byte/sample PPM or PGM file.  (Yes, this means still another copy
of djpeg to keep around.  But hopefully you won't need it for very long.
Poskanzer's supposed to get that new PBMPLUS release out Real Soon Now.)

Of course, if you are working with 9-bit to 12-bit data, you probably have
it stored in some other, nonstandard format.  In that case you'll probably
want to write your own I/O modules to read and write your format.

Note:
The standard Huffman tables are only valid for 8-bit data precision.  If
you selected more than 8-bit data precision, cjpeg uses arithmetic coding
by default.  The Huffman encoder normally uses entropy optimization to
compute usable tables for higher precision.  Otherwise, you'll have to
supply different default Huffman tables.

Removing code:

If you need to make a smaller version of the JPEG software, some optional
functions can be removed at compile time.  See the xxx_SUPPORTED #defines in
jconfig.h and jmorecfg.h.  If at all possible, we recommend that you leave in
decoder support for all valid JPEG files, to ensure that you can read anyone's
output.  Taking out support for image file formats that you don't use is the
most painless way to make the programs smaller.  Another possibility is to
remove some of the DCT methods: in particular, the "IFAST" method may not be
enough faster than the others to be worth keeping on your machine.  (If you
do remove ISLOW or IFAST, be sure to redefine JDCT_DEFAULT or JDCT_FASTEST
to a supported method, by adding a #define in jconfig.h.)


OPTIMIZATION
============

Unless you own a Cray, you'll probably be interested in making the JPEG
software go as fast as possible.  This section covers some machine-dependent
optimizations you may want to try.  We suggest that before trying any of
this, you first get the basic installation to pass the self-test step.
Repeat the self-test after any optimization to make sure that you haven't
broken anything.

The integer DCT routines perform a lot of multiplications.  These
multiplications must yield 32-bit results, but none of their input values
are more than 16 bits wide.  On many machines, notably the 680x0 and 80x86
CPUs, a 16x16=>32 bit multiply instruction is faster than a full 32x32=>32
bit multiply.  Unfortunately there is no portable way to specify such a
multiplication in C, but some compilers can generate one when you use the
right combination of casts.  See the MULTIPLYxxx macro definitions in
jdct.h.  If your compiler makes "int" be 32 bits and "short" be 16 bits,
defining SHORTxSHORT_32 is fairly likely to work.  When experimenting with
alternate definitions, be sure to test not only whether the code still works
(use the self-test), but also whether it is actually faster --- on some
compilers, alternate definitions may compute the right answer, yet be slower
than the default.  Timing cjpeg on a large PGM (grayscale) input file is the
best way to check this, as the DCT will be the largest fraction of the runtime
in that mode.  (Note: some of the distributed compiler-specific jconfig files
already contain #define switches to select appropriate MULTIPLYxxx
definitions.)

If your machine has sufficiently fast floating point hardware, you may find
that the float DCT method is faster than the integer DCT methods, even
after tweaking the integer multiply macros.  In that case you may want to
make the float DCT be the default method.  (The only objection to this is
that float DCT results may vary slightly across machines.)  To do that, add
"#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h.  Even if you don't change
the default, you should redefine JDCT_FASTEST, which is the method selected
by djpeg's -fast switch.  Don't forget to update the documentation files
(usage.txt and/or cjpeg.1, djpeg.1) to agree with what you've done.

If access to "short" arrays is slow on your machine, it may be a win to
define type JCOEF as int rather than short.  This will cost a good deal of
memory though, particularly in some multi-pass modes, so don't do it unless
you have memory to burn and short is REALLY slow.

If your compiler can compile function calls in-line, make sure the INLINE
macro in jmorecfg.h is defined as the keyword that marks a function
inline-able.  Some compilers have a switch that tells the compiler to inline
any function it thinks is profitable (e.g., -finline-functions for gcc).
Enabling such a switch is likely to make the compiled code bigger but faster.

In general, it's worth trying the maximum optimization level of your compiler,
and experimenting with any optional optimizations such as loop unrolling.
(Unfortunately, far too many compilers have optimizer bugs ... be prepared to
back off if the code fails self-test.)  If you do any experimentation along
these lines, please report the optimal settings to jpeg-info@jpegclub.org so
we can mention them in future releases.  Be sure to specify your machine and
compiler version.


HINTS FOR SPECIFIC SYSTEMS
==========================

We welcome reports on changes needed for systems not mentioned here.  Submit
'em to jpeg-info@jpegclub.org.  Also, if configure or ckconfig.c is wrong
about how to configure the JPEG software for your system, please let us know.


Acorn RISC OS:

(Thanks to Simon Middleton for these hints on compiling with Desktop C.)
After renaming the files according to Acorn conventions, take a copy of
makefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' and
change these definitions as indicated:

CFLAGS= -throwback -IC: -Wn
LDLIBS=C:o.Stubs
SYSDEPMEM=jmemansi.o
LN=Link
AR=LibFile -c -o

Also add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'.  Remove the
lines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'
dependency section.

Copy jconfig.txt to jconfig.h.  Edit jconfig.h to define TWO_FILE_COMMANDLINE



( run in 2.146 seconds using v1.01-cache-2.11-cpan-13bb782fe5a )