1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/media/libjpeg/jmorecfg.h Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,393 @@
1.4 +/*
1.5 + * jmorecfg.h
1.6 + *
1.7 + * This file was part of the Independent JPEG Group's software:
1.8 + * Copyright (C) 1991-1997, Thomas G. Lane.
1.9 + * Modifications:
1.10 + * Copyright (C) 2009, 2011, D. R. Commander.
1.11 + * For conditions of distribution and use, see the accompanying README file.
1.12 + *
1.13 + * This file contains additional configuration options that customize the
1.14 + * JPEG software for special applications or support machine-dependent
1.15 + * optimizations. Most users will not need to touch this file.
1.16 + */
1.17 +
1.18 +#include <stdint.h>
1.19 +
1.20 +/*
1.21 + * Define BITS_IN_JSAMPLE as either
1.22 + * 8 for 8-bit sample values (the usual setting)
1.23 + * 12 for 12-bit sample values
1.24 + * Only 8 and 12 are legal data precisions for lossy JPEG according to the
1.25 + * JPEG standard, and the IJG code does not support anything else!
1.26 + * We do not support run-time selection of data precision, sorry.
1.27 + */
1.28 +
1.29 +#define BITS_IN_JSAMPLE 8 /* use 8 or 12 */
1.30 +
1.31 +
1.32 +/*
1.33 + * Maximum number of components (color channels) allowed in JPEG image.
1.34 + * To meet the letter of the JPEG spec, set this to 255. However, darn
1.35 + * few applications need more than 4 channels (maybe 5 for CMYK + alpha
1.36 + * mask). We recommend 10 as a reasonable compromise; use 4 if you are
1.37 + * really short on memory. (Each allowed component costs a hundred or so
1.38 + * bytes of storage, whether actually used in an image or not.)
1.39 + */
1.40 +
1.41 +#define MAX_COMPONENTS 10 /* maximum number of image components */
1.42 +
1.43 +
1.44 +/*
1.45 + * Basic data types.
1.46 + * You may need to change these if you have a machine with unusual data
1.47 + * type sizes; for example, "char" not 8 bits, "short" not 16 bits,
1.48 + * or "long" not 32 bits. We don't care whether "int" is 16 or 32 bits,
1.49 + * but it had better be at least 16.
1.50 + */
1.51 +
1.52 +/* Representation of a single sample (pixel element value).
1.53 + * We frequently allocate large arrays of these, so it's important to keep
1.54 + * them small. But if you have memory to burn and access to char or short
1.55 + * arrays is very slow on your hardware, you might want to change these.
1.56 + */
1.57 +
1.58 +#if BITS_IN_JSAMPLE == 8
1.59 +/* JSAMPLE should be the smallest type that will hold the values 0..255.
1.60 + * You can use a signed char by having GETJSAMPLE mask it with 0xFF.
1.61 + */
1.62 +
1.63 +#ifdef HAVE_UNSIGNED_CHAR
1.64 +
1.65 +typedef unsigned char JSAMPLE;
1.66 +#define GETJSAMPLE(value) ((int) (value))
1.67 +
1.68 +#else /* not HAVE_UNSIGNED_CHAR */
1.69 +
1.70 +typedef char JSAMPLE;
1.71 +#ifdef __CHAR_UNSIGNED__
1.72 +#define GETJSAMPLE(value) ((int) (value))
1.73 +#else
1.74 +#define GETJSAMPLE(value) ((int) (value) & 0xFF)
1.75 +#endif /* __CHAR_UNSIGNED__ */
1.76 +
1.77 +#endif /* HAVE_UNSIGNED_CHAR */
1.78 +
1.79 +#define MAXJSAMPLE 255
1.80 +#define CENTERJSAMPLE 128
1.81 +
1.82 +#endif /* BITS_IN_JSAMPLE == 8 */
1.83 +
1.84 +
1.85 +#if BITS_IN_JSAMPLE == 12
1.86 +/* JSAMPLE should be the smallest type that will hold the values 0..4095.
1.87 + * On nearly all machines "short" will do nicely.
1.88 + */
1.89 +
1.90 +typedef short JSAMPLE;
1.91 +#define GETJSAMPLE(value) ((int) (value))
1.92 +
1.93 +#define MAXJSAMPLE 4095
1.94 +#define CENTERJSAMPLE 2048
1.95 +
1.96 +#endif /* BITS_IN_JSAMPLE == 12 */
1.97 +
1.98 +
1.99 +/* Representation of a DCT frequency coefficient.
1.100 + * This should be a signed value of at least 16 bits; "short" is usually OK.
1.101 + * Again, we allocate large arrays of these, but you can change to int
1.102 + * if you have memory to burn and "short" is really slow.
1.103 + */
1.104 +
1.105 +typedef short JCOEF;
1.106 +
1.107 +
1.108 +/* Compressed datastreams are represented as arrays of JOCTET.
1.109 + * These must be EXACTLY 8 bits wide, at least once they are written to
1.110 + * external storage. Note that when using the stdio data source/destination
1.111 + * managers, this is also the data type passed to fread/fwrite.
1.112 + */
1.113 +
1.114 +#ifdef HAVE_UNSIGNED_CHAR
1.115 +
1.116 +typedef unsigned char JOCTET;
1.117 +#define GETJOCTET(value) (value)
1.118 +
1.119 +#else /* not HAVE_UNSIGNED_CHAR */
1.120 +
1.121 +typedef char JOCTET;
1.122 +#ifdef __CHAR_UNSIGNED__
1.123 +#define GETJOCTET(value) (value)
1.124 +#else
1.125 +#define GETJOCTET(value) ((value) & 0xFF)
1.126 +#endif /* __CHAR_UNSIGNED__ */
1.127 +
1.128 +#endif /* HAVE_UNSIGNED_CHAR */
1.129 +
1.130 +
1.131 +/* These typedefs are used for various table entries and so forth.
1.132 + * They must be at least as wide as specified; but making them too big
1.133 + * won't cost a huge amount of memory, so we don't provide special
1.134 + * extraction code like we did for JSAMPLE. (In other words, these
1.135 + * typedefs live at a different point on the speed/space tradeoff curve.)
1.136 + */
1.137 +
1.138 +/* UINT8 must hold at least the values 0..255. */
1.139 +
1.140 +typedef uint8_t UINT8;
1.141 +
1.142 +/* UINT16 must hold at least the values 0..65535. */
1.143 +
1.144 +typedef uint16_t UINT16;
1.145 +
1.146 +/* INT16 must hold at least the values -32768..32767. */
1.147 +
1.148 +typedef int16_t INT16;
1.149 +
1.150 +/* INT32 must hold at least signed 32-bit values. */
1.151 +
1.152 +typedef int32_t INT32;
1.153 +
1.154 +/* Datatype used for image dimensions. The JPEG standard only supports
1.155 + * images up to 64K*64K due to 16-bit fields in SOF markers. Therefore
1.156 + * "unsigned int" is sufficient on all machines. However, if you need to
1.157 + * handle larger images and you don't mind deviating from the spec, you
1.158 + * can change this datatype.
1.159 + */
1.160 +
1.161 +typedef unsigned int JDIMENSION;
1.162 +
1.163 +#define JPEG_MAX_DIMENSION 65500L /* a tad under 64K to prevent overflows */
1.164 +
1.165 +
1.166 +/* These macros are used in all function definitions and extern declarations.
1.167 + * You could modify them if you need to change function linkage conventions;
1.168 + * in particular, you'll need to do that to make the library a Windows DLL.
1.169 + * Another application is to make all functions global for use with debuggers
1.170 + * or code profilers that require it.
1.171 + */
1.172 +
1.173 +/* a function called through method pointers: */
1.174 +#define METHODDEF(type) static type
1.175 +/* a function used only in its module: */
1.176 +#define LOCAL(type) static type
1.177 +/* a function referenced thru EXTERNs: */
1.178 +#define GLOBAL(type) type
1.179 +/* a reference to a GLOBAL function: */
1.180 +#define EXTERN(type) extern type
1.181 +
1.182 +
1.183 +/* This macro is used to declare a "method", that is, a function pointer.
1.184 + * We want to supply prototype parameters if the compiler can cope.
1.185 + * Note that the arglist parameter must be parenthesized!
1.186 + * Again, you can customize this if you need special linkage keywords.
1.187 + */
1.188 +
1.189 +#ifdef HAVE_PROTOTYPES
1.190 +#define JMETHOD(type,methodname,arglist) type (*methodname) arglist
1.191 +#else
1.192 +#define JMETHOD(type,methodname,arglist) type (*methodname) ()
1.193 +#endif
1.194 +
1.195 +
1.196 +/* Here is the pseudo-keyword for declaring pointers that must be "far"
1.197 + * on 80x86 machines. Most of the specialized coding for 80x86 is handled
1.198 + * by just saying "FAR *" where such a pointer is needed. In a few places
1.199 + * explicit coding is needed; see uses of the NEED_FAR_POINTERS symbol.
1.200 + */
1.201 +
1.202 +#ifdef NEED_FAR_POINTERS
1.203 +#ifndef FAR
1.204 +#define FAR far
1.205 +#endif
1.206 +#else
1.207 +#undef FAR
1.208 +#define FAR
1.209 +#endif
1.210 +
1.211 +
1.212 +/*
1.213 + * On a few systems, type boolean and/or its values FALSE, TRUE may appear
1.214 + * in standard header files. Or you may have conflicts with application-
1.215 + * specific header files that you want to include together with these files.
1.216 + * Defining HAVE_BOOLEAN before including jpeglib.h should make it work.
1.217 + */
1.218 +
1.219 +#ifndef HAVE_BOOLEAN
1.220 +typedef int boolean;
1.221 +#endif
1.222 +#ifndef FALSE /* in case these macros already exist */
1.223 +#define FALSE 0 /* values of boolean */
1.224 +#endif
1.225 +#ifndef TRUE
1.226 +#define TRUE 1
1.227 +#endif
1.228 +
1.229 +
1.230 +/*
1.231 + * The remaining options affect code selection within the JPEG library,
1.232 + * but they don't need to be visible to most applications using the library.
1.233 + * To minimize application namespace pollution, the symbols won't be
1.234 + * defined unless JPEG_INTERNALS or JPEG_INTERNAL_OPTIONS has been defined.
1.235 + */
1.236 +
1.237 +#ifdef JPEG_INTERNALS
1.238 +#define JPEG_INTERNAL_OPTIONS
1.239 +#endif
1.240 +
1.241 +#ifdef JPEG_INTERNAL_OPTIONS
1.242 +
1.243 +
1.244 +/*
1.245 + * These defines indicate whether to include various optional functions.
1.246 + * Undefining some of these symbols will produce a smaller but less capable
1.247 + * library. Note that you can leave certain source files out of the
1.248 + * compilation/linking process if you've #undef'd the corresponding symbols.
1.249 + * (You may HAVE to do that if your compiler doesn't like null source files.)
1.250 + */
1.251 +
1.252 +/* Capability options common to encoder and decoder: */
1.253 +
1.254 +#define DCT_ISLOW_SUPPORTED /* slow but accurate integer algorithm */
1.255 +#define DCT_IFAST_SUPPORTED /* faster, less accurate integer method */
1.256 +#define DCT_FLOAT_SUPPORTED /* floating-point: accurate, fast on fast HW */
1.257 +
1.258 +/* Encoder capability options: */
1.259 +
1.260 +#define C_MULTISCAN_FILES_SUPPORTED /* Multiple-scan JPEG files? */
1.261 +#define C_PROGRESSIVE_SUPPORTED /* Progressive JPEG? (Requires MULTISCAN)*/
1.262 +#define ENTROPY_OPT_SUPPORTED /* Optimization of entropy coding parms? */
1.263 +/* Note: if you selected 12-bit data precision, it is dangerous to turn off
1.264 + * ENTROPY_OPT_SUPPORTED. The standard Huffman tables are only good for 8-bit
1.265 + * precision, so jchuff.c normally uses entropy optimization to compute
1.266 + * usable tables for higher precision. If you don't want to do optimization,
1.267 + * you'll have to supply different default Huffman tables.
1.268 + * The exact same statements apply for progressive JPEG: the default tables
1.269 + * don't work for progressive mode. (This may get fixed, however.)
1.270 + */
1.271 +#define INPUT_SMOOTHING_SUPPORTED /* Input image smoothing option? */
1.272 +
1.273 +/* Decoder capability options: */
1.274 +
1.275 +#define D_MULTISCAN_FILES_SUPPORTED /* Multiple-scan JPEG files? */
1.276 +#define D_PROGRESSIVE_SUPPORTED /* Progressive JPEG? (Requires MULTISCAN)*/
1.277 +#define SAVE_MARKERS_SUPPORTED /* jpeg_save_markers() needed? */
1.278 +#define BLOCK_SMOOTHING_SUPPORTED /* Block smoothing? (Progressive only) */
1.279 +#define IDCT_SCALING_SUPPORTED /* Output rescaling via IDCT? */
1.280 +#undef UPSAMPLE_SCALING_SUPPORTED /* Output rescaling at upsample stage? */
1.281 +#define UPSAMPLE_MERGING_SUPPORTED /* Fast path for sloppy upsampling? */
1.282 +#define QUANT_1PASS_SUPPORTED /* 1-pass color quantization? */
1.283 +#define QUANT_2PASS_SUPPORTED /* 2-pass color quantization? */
1.284 +
1.285 +/* more capability options later, no doubt */
1.286 +
1.287 +
1.288 +/*
1.289 + * Ordering of RGB data in scanlines passed to or from the application.
1.290 + * If your application wants to deal with data in the order B,G,R, just
1.291 + * change these macros. You can also deal with formats such as R,G,B,X
1.292 + * (one extra byte per pixel) by changing RGB_PIXELSIZE. Note that changing
1.293 + * the offsets will also change the order in which colormap data is organized.
1.294 + * RESTRICTIONS:
1.295 + * 1. The sample applications cjpeg,djpeg do NOT support modified RGB formats.
1.296 + * 2. These macros only affect RGB<=>YCbCr color conversion, so they are not
1.297 + * useful if you are using JPEG color spaces other than YCbCr or grayscale.
1.298 + * 3. The color quantizer modules will not behave desirably if RGB_PIXELSIZE
1.299 + * is not 3 (they don't understand about dummy color components!). So you
1.300 + * can't use color quantization if you change that value.
1.301 + */
1.302 +
1.303 +#define RGB_RED 0 /* Offset of Red in an RGB scanline element */
1.304 +#define RGB_GREEN 1 /* Offset of Green */
1.305 +#define RGB_BLUE 2 /* Offset of Blue */
1.306 +#define RGB_PIXELSIZE 3 /* JSAMPLEs per RGB scanline element */
1.307 +
1.308 +#define JPEG_NUMCS 16
1.309 +
1.310 +#define EXT_RGB_RED 0
1.311 +#define EXT_RGB_GREEN 1
1.312 +#define EXT_RGB_BLUE 2
1.313 +#define EXT_RGB_PIXELSIZE 3
1.314 +
1.315 +#define EXT_RGBX_RED 0
1.316 +#define EXT_RGBX_GREEN 1
1.317 +#define EXT_RGBX_BLUE 2
1.318 +#define EXT_RGBX_PIXELSIZE 4
1.319 +
1.320 +#define EXT_BGR_RED 2
1.321 +#define EXT_BGR_GREEN 1
1.322 +#define EXT_BGR_BLUE 0
1.323 +#define EXT_BGR_PIXELSIZE 3
1.324 +
1.325 +#define EXT_BGRX_RED 2
1.326 +#define EXT_BGRX_GREEN 1
1.327 +#define EXT_BGRX_BLUE 0
1.328 +#define EXT_BGRX_PIXELSIZE 4
1.329 +
1.330 +#define EXT_XBGR_RED 3
1.331 +#define EXT_XBGR_GREEN 2
1.332 +#define EXT_XBGR_BLUE 1
1.333 +#define EXT_XBGR_PIXELSIZE 4
1.334 +
1.335 +#define EXT_XRGB_RED 1
1.336 +#define EXT_XRGB_GREEN 2
1.337 +#define EXT_XRGB_BLUE 3
1.338 +#define EXT_XRGB_PIXELSIZE 4
1.339 +
1.340 +static const int rgb_red[JPEG_NUMCS] = {
1.341 + -1, -1, RGB_RED, -1, -1, -1, EXT_RGB_RED, EXT_RGBX_RED,
1.342 + EXT_BGR_RED, EXT_BGRX_RED, EXT_XBGR_RED, EXT_XRGB_RED,
1.343 + EXT_RGBX_RED, EXT_BGRX_RED, EXT_XBGR_RED, EXT_XRGB_RED
1.344 +};
1.345 +
1.346 +static const int rgb_green[JPEG_NUMCS] = {
1.347 + -1, -1, RGB_GREEN, -1, -1, -1, EXT_RGB_GREEN, EXT_RGBX_GREEN,
1.348 + EXT_BGR_GREEN, EXT_BGRX_GREEN, EXT_XBGR_GREEN, EXT_XRGB_GREEN,
1.349 + EXT_RGBX_GREEN, EXT_BGRX_GREEN, EXT_XBGR_GREEN, EXT_XRGB_GREEN
1.350 +};
1.351 +
1.352 +static const int rgb_blue[JPEG_NUMCS] = {
1.353 + -1, -1, RGB_BLUE, -1, -1, -1, EXT_RGB_BLUE, EXT_RGBX_BLUE,
1.354 + EXT_BGR_BLUE, EXT_BGRX_BLUE, EXT_XBGR_BLUE, EXT_XRGB_BLUE,
1.355 + EXT_RGBX_BLUE, EXT_BGRX_BLUE, EXT_XBGR_BLUE, EXT_XRGB_BLUE
1.356 +};
1.357 +
1.358 +static const int rgb_pixelsize[JPEG_NUMCS] = {
1.359 + -1, -1, RGB_PIXELSIZE, -1, -1, -1, EXT_RGB_PIXELSIZE, EXT_RGBX_PIXELSIZE,
1.360 + EXT_BGR_PIXELSIZE, EXT_BGRX_PIXELSIZE, EXT_XBGR_PIXELSIZE, EXT_XRGB_PIXELSIZE,
1.361 + EXT_RGBX_PIXELSIZE, EXT_BGRX_PIXELSIZE, EXT_XBGR_PIXELSIZE, EXT_XRGB_PIXELSIZE
1.362 +};
1.363 +
1.364 +/* Definitions for speed-related optimizations. */
1.365 +
1.366 +/* On some machines (notably 68000 series) "int" is 32 bits, but multiplying
1.367 + * two 16-bit shorts is faster than multiplying two ints. Define MULTIPLIER
1.368 + * as short on such a machine. MULTIPLIER must be at least 16 bits wide.
1.369 + */
1.370 +
1.371 +#ifndef MULTIPLIER
1.372 +#ifndef WITH_SIMD
1.373 +#define MULTIPLIER int /* type for fastest integer multiply */
1.374 +#else
1.375 +#define MULTIPLIER short /* prefer 16-bit with SIMD for parellelism */
1.376 +#endif
1.377 +#endif
1.378 +
1.379 +
1.380 +/* FAST_FLOAT should be either float or double, whichever is done faster
1.381 + * by your compiler. (Note that this type is only used in the floating point
1.382 + * DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.)
1.383 + * Typically, float is faster in ANSI C compilers, while double is faster in
1.384 + * pre-ANSI compilers (because they insist on converting to double anyway).
1.385 + * The code below therefore chooses float if we have ANSI-style prototypes.
1.386 + */
1.387 +
1.388 +#ifndef FAST_FLOAT
1.389 +#ifdef HAVE_PROTOTYPES
1.390 +#define FAST_FLOAT float
1.391 +#else
1.392 +#define FAST_FLOAT double
1.393 +#endif
1.394 +#endif
1.395 +
1.396 +#endif /* JPEG_INTERNAL_OPTIONS */
