src/lib/vampimg/JpegLib/imjmorecfg.pas

   1 unit imjmorecfg;
   2
   3 { This file contains additional configuration options that customize the
   4   JPEG software for special applications or support machine-dependent
   5   optimizations.  Most users will not need to touch this file. }
   6
   7 { Source: jmorecfg.h; Copyright (C) 1991-1996, Thomas G. Lane. }
   8
   9 interface
  10
  11 {$I imjconfig.inc}
  12
  13 type
  14   int = Integer;
  15   uInt = Cardinal;
  16   short = SmallInt;
  17   ushort = Word;
  18   long = LongInt;
  19
  20 type
  21   voidp = pointer;
  22
  23 type
  24   int_ptr = ^int;
  25   size_t = int;
  26
  27 { Define BITS_IN_JSAMPLE as either
  28     8   for 8-bit sample values (the usual setting)
  29     12  for 12-bit sample values
  30   Only 8 and 12 are legal data precisions for lossy JPEG according to the
  31   JPEG standard, and the IJG code does not support anything else!
  32   We do not support run-time selection of data precision, sorry. }
  33
  34
  35 {$ifdef BITS_IN_JSAMPLE_IS_8}   { use 8 or 12 }
  36 const
  37   BITS_IN_JSAMPLE = 8;
  38 {$else}
  39 const
  40   BITS_IN_JSAMPLE = 12;
  41 {$endif}
  42
  43
  44 { Maximum number of components (color channels) allowed in JPEG image.
  45   To meet the letter of the JPEG spec, set this to 255.  However, darn
  46   few applications need more than 4 channels (maybe 5 for CMYK + alpha
  47   mask).  We recommend 10 as a reasonable compromise; use 4 if you are
  48   really short on memory.  (Each allowed component costs a hundred or so
  49   bytes of storage, whether actually used in an image or not.) }
  50
  51
  52 const
  53   MAX_COMPONENTS = 10;          { maximum number of image components }
  54
  55
  56 { Basic data types.
  57   You may need to change these if you have a machine with unusual data
  58   type sizes; for example, "char" not 8 bits, "short" not 16 bits,
  59   or "long" not 32 bits.  We don't care whether "int" is 16 or 32 bits,
  60   but it had better be at least 16. }
  61
  62
  63 { Representation of a single sample (pixel element value).
  64   We frequently allocate large arrays of these, so it's important to keep
  65   them small.  But if you have memory to burn and access to char or short
  66   arrays is very slow on your hardware, you might want to change these. }
  67
  68
  69 {$ifdef BITS_IN_JSAMPLE_IS_8}
  70 { JSAMPLE should be the smallest type that will hold the values 0..255.
  71   You can use a signed char by having GETJSAMPLE mask it with $FF. }
  72
  73 { CHAR_IS_UNSIGNED }
  74 type
  75   JSAMPLE = byte; { Pascal unsigned char }
  76   GETJSAMPLE = int;
  77
  78 const
  79   MAXJSAMPLE = 255;
  80   CENTERJSAMPLE = 128;
  81
  82 {$endif}
  83
  84 {$ifndef BITS_IN_JSAMPLE_IS_8}
  85 { JSAMPLE should be the smallest type that will hold the values 0..4095.
  86   On nearly all machines "short" will do nicely. }
  87
  88 type
  89   JSAMPLE = short;
  90   GETJSAMPLE = int;
  91
  92 const
  93   MAXJSAMPLE = 4095;
  94   CENTERJSAMPLE = 2048;
  95
  96 {$endif} { BITS_IN_JSAMPLE = 12 }
  97
  98
  99 { Representation of a DCT frequency coefficient.
 100   This should be a signed value of at least 16 bits; "short" is usually OK.
 101   Again, we allocate large arrays of these, but you can change to int
 102   if you have memory to burn and "short" is really slow. }
 103 type
 104   JCOEF = int;
 105   JCOEF_PTR = ^JCOEF;
 106
 107
 108 { Compressed datastreams are represented as arrays of JOCTET.
 109   These must be EXACTLY 8 bits wide, at least once they are written to
 110   external storage.  Note that when using the stdio data source/destination
 111   managers, this is also the data type passed to fread/fwrite. }
 112
 113
 114 type
 115   JOCTET = Byte;
 116   jTOctet = 0..(MaxInt div SizeOf(JOCTET))-1;
 117   JOCTET_FIELD = array[jTOctet] of JOCTET;
 118   JOCTET_FIELD_PTR = ^JOCTET_FIELD;
 119   JOCTETPTR = ^JOCTET;
 120
 121   GETJOCTET = JOCTET; { A work around }
 122
 123
 124 { These typedefs are used for various table entries and so forth.
 125   They must be at least as wide as specified; but making them too big
 126   won't cost a huge amount of memory, so we don't provide special
 127   extraction code like we did for JSAMPLE.  (In other words, these
 128   typedefs live at a different point on the speed/space tradeoff curve.) }
 129
 130
 131 { UINT8 must hold at least the values 0..255. }
 132
 133 type
 134   UINT8 = Byte;
 135
 136 { UINT16 must hold at least the values 0..65535. }
 137
 138   UINT16 = Word;
 139
 140 { INT16 must hold at least the values -32768..32767. }
 141
 142   INT16 = SmallInt;
 143
 144 { INT32 must hold at least signed 32-bit values. }
 145
 146   INT32 = LongInt;
 147 type
 148   INT32PTR = ^INT32;
 149
 150 { Datatype used for image dimensions.  The JPEG standard only supports
 151   images up to 64K*64K due to 16-bit fields in SOF markers.  Therefore
 152   "unsigned int" is sufficient on all machines.  However, if you need to
 153   handle larger images and you don't mind deviating from the spec, you
 154   can change this datatype. }
 155
 156 type
 157   JDIMENSION = uInt;
 158
 159 const
 160   JPEG_MAX_DIMENSION = 65500;  { a tad under 64K to prevent overflows }
 161
 162
 163 { Ordering of RGB data in scanlines passed to or from the application.
 164   If your application wants to deal with data in the order B,G,R, just
 165   change these macros.  You can also deal with formats such as R,G,B,X
 166   (one extra byte per pixel) by changing RGB_PIXELSIZE.  Note that changing
 167   the offsets will also change the order in which colormap data is organized.
 168   RESTRICTIONS:
 169   1. The sample applications cjpeg,djpeg do NOT support modified RGB formats.
 170   2. These macros only affect RGB<=>YCbCr color conversion, so they are not
 171      useful if you are using JPEG color spaces other than YCbCr or grayscale.
 172   3. The color quantizer modules will not behave desirably if RGB_PIXELSIZE
 173      is not 3 (they don't understand about dummy color components!).  So you
 174      can't use color quantization if you change that value. }
 175
 176 {$ifdef RGB_RED_IS_0}
 177 const
 178   RGB_RED       = 0;    { Offset of Red in an RGB scanline element }
 179   RGB_GREEN     = 1;    { Offset of Green }
 180   RGB_BLUE      = 2;    { Offset of Blue }
 181 {$else}
 182 const
 183   RGB_RED       = 2;    { Offset of Red in an RGB scanline element }
 184   RGB_GREEN     = 1;    { Offset of Green }
 185   RGB_BLUE      = 0;    { Offset of Blue }
 186 {$endif}
 187
 188 {$ifdef RGB_PIXELSIZE_IS_3}
 189 const
 190   RGB_PIXELSIZE = 3;    { JSAMPLEs per RGB scanline element }
 191 {$else}
 192 const
 193   RGB_PIXELSIZE = ??;   { Nomssi: deliberate syntax error. Set this value }
 194 {$endif}
 195
 196 { Definitions for speed-related optimizations. }
 197
 198 { On some machines (notably 68000 series) "int" is 32 bits, but multiplying
 199   two 16-bit shorts is faster than multiplying two ints.  Define MULTIPLIER
 200   as short on such a machine.  MULTIPLIER must be at least 16 bits wide. }
 201 type
 202   MULTIPLIER = int;     { type for fastest integer multiply }
 203
 204
 205 { FAST_FLOAT should be either float or double, whichever is done faster
 206   by your compiler.  (Note that this type is only used in the floating point
 207   DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.)
 208   Typically, float is faster in ANSI C compilers, while double is faster in
 209   pre-ANSI compilers (because they insist on converting to double anyway).
 210   The code below therefore chooses float if we have ANSI-style prototypes. }
 211
 212 type
 213   FAST_FLOAT = double; {float}
 214
 215
 216 implementation
 217
 218
 219 end.