@ai-ecoverse/wasm-libjpeg-turbo 0.0.0 → 3.1.2-2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,385 @@
1
+ /*
2
+ * jmorecfg.h
3
+ *
4
+ * This file was part of the Independent JPEG Group's software:
5
+ * Copyright (C) 1991-1997, Thomas G. Lane.
6
+ * Modified 1997-2009 by Guido Vollbeding.
7
+ * Lossless JPEG Modifications:
8
+ * Copyright (C) 1999, Ken Murchison.
9
+ * libjpeg-turbo Modifications:
10
+ * Copyright (C) 2009, 2011, 2014-2015, 2018, 2020, 2022, D. R. Commander.
11
+ * For conditions of distribution and use, see the accompanying README.ijg
12
+ * file.
13
+ *
14
+ * This file contains additional configuration options that customize the
15
+ * JPEG software for special applications or support machine-dependent
16
+ * optimizations. Most users will not need to touch this file.
17
+ */
18
+
19
+
20
+ /*
21
+ * Maximum number of components (color channels) allowed in JPEG image.
22
+ * To meet the letter of Rec. ITU-T T.81 | ISO/IEC 10918-1, set this to 255.
23
+ * However, darn few applications need more than 4 channels (maybe 5 for CMYK +
24
+ * alpha mask). We recommend 10 as a reasonable compromise; use 4 if you are
25
+ * really short on memory. (Each allowed component costs a hundred or so
26
+ * bytes of storage, whether actually used in an image or not.)
27
+ */
28
+
29
+ #define MAX_COMPONENTS 10 /* maximum number of image components */
30
+
31
+
32
+ /*
33
+ * Basic data types.
34
+ * You may need to change these if you have a machine with unusual data
35
+ * type sizes; for example, "char" not 8 bits, "short" not 16 bits,
36
+ * or "long" not 32 bits. We don't care whether "int" is 16 or 32 bits,
37
+ * but it had better be at least 16.
38
+ */
39
+
40
+ /* Representation of a single sample (pixel element value).
41
+ * We frequently allocate large arrays of these, so it's important to keep
42
+ * them small. But if you have memory to burn and access to char or short
43
+ * arrays is very slow on your hardware, you might want to change these.
44
+ */
45
+
46
+ /* JSAMPLE should be the smallest type that will hold the values 0..255. */
47
+
48
+ typedef unsigned char JSAMPLE;
49
+ #define GETJSAMPLE(value) ((int)(value))
50
+
51
+ #define MAXJSAMPLE 255
52
+ #define CENTERJSAMPLE 128
53
+
54
+
55
+ /* J12SAMPLE should be the smallest type that will hold the values 0..4095. */
56
+
57
+ typedef short J12SAMPLE;
58
+
59
+ #define MAXJ12SAMPLE 4095
60
+ #define CENTERJ12SAMPLE 2048
61
+
62
+
63
+ /* J16SAMPLE should be the smallest type that will hold the values 0..65535. */
64
+
65
+ typedef unsigned short J16SAMPLE;
66
+
67
+ #define MAXJ16SAMPLE 65535
68
+ #define CENTERJ16SAMPLE 32768
69
+
70
+
71
+ /* Representation of a DCT frequency coefficient.
72
+ * This should be a signed value of at least 16 bits; "short" is usually OK.
73
+ * Again, we allocate large arrays of these, but you can change to int
74
+ * if you have memory to burn and "short" is really slow.
75
+ */
76
+
77
+ typedef short JCOEF;
78
+
79
+
80
+ /* Compressed datastreams are represented as arrays of JOCTET.
81
+ * These must be EXACTLY 8 bits wide, at least once they are written to
82
+ * external storage. Note that when using the stdio data source/destination
83
+ * managers, this is also the data type passed to fread/fwrite.
84
+ */
85
+
86
+ typedef unsigned char JOCTET;
87
+ #define GETJOCTET(value) (value)
88
+
89
+
90
+ /* These typedefs are used for various table entries and so forth.
91
+ * They must be at least as wide as specified; but making them too big
92
+ * won't cost a huge amount of memory, so we don't provide special
93
+ * extraction code like we did for JSAMPLE. (In other words, these
94
+ * typedefs live at a different point on the speed/space tradeoff curve.)
95
+ */
96
+
97
+ /* UINT8 must hold at least the values 0..255. */
98
+
99
+ typedef unsigned char UINT8;
100
+
101
+ /* UINT16 must hold at least the values 0..65535. */
102
+
103
+ typedef unsigned short UINT16;
104
+
105
+ /* INT16 must hold at least the values -32768..32767. */
106
+
107
+ #ifndef XMD_H /* X11/xmd.h correctly defines INT16 */
108
+ typedef short INT16;
109
+ #endif
110
+
111
+ /* INT32 must hold at least signed 32-bit values.
112
+ *
113
+ * NOTE: The INT32 typedef dates back to libjpeg v5 (1994.) Integers were
114
+ * sometimes 16-bit back then (MS-DOS), which is why INT32 is typedef'd to
115
+ * long. It also wasn't common (or at least as common) in 1994 for INT32 to be
116
+ * defined by platform headers. Since then, however, INT32 is defined in
117
+ * several other common places:
118
+ *
119
+ * Xmd.h (X11 header) typedefs INT32 to int on 64-bit platforms and long on
120
+ * 32-bit platforms (i.e always a 32-bit signed type.)
121
+ *
122
+ * basetsd.h (Win32 header) typedefs INT32 to int (always a 32-bit signed type
123
+ * on modern platforms.)
124
+ *
125
+ * qglobal.h (Qt header) typedefs INT32 to int (always a 32-bit signed type on
126
+ * modern platforms.)
127
+ *
128
+ * This is a recipe for conflict, since "long" and "int" aren't always
129
+ * compatible types. Since the definition of INT32 has technically been part
130
+ * of the libjpeg API for more than 20 years, we can't remove it, but we do not
131
+ * use it internally any longer. We instead define a separate type (JLONG)
132
+ * for internal use, which ensures that internal behavior will always be the
133
+ * same regardless of any external headers that may be included.
134
+ */
135
+
136
+ #ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
137
+ #ifndef _BASETSD_H_ /* Microsoft defines it in basetsd.h */
138
+ #ifndef _BASETSD_H /* MinGW is slightly different */
139
+ #ifndef QGLOBAL_H /* Qt defines it in qglobal.h */
140
+ typedef long INT32;
141
+ #endif
142
+ #endif
143
+ #endif
144
+ #endif
145
+
146
+ /* Datatype used for image dimensions. The JPEG standard only supports
147
+ * images up to 64K*64K due to 16-bit fields in SOF markers. Therefore
148
+ * "unsigned int" is sufficient on all machines. However, if you need to
149
+ * handle larger images and you don't mind deviating from the spec, you
150
+ * can change this datatype. (Note that changing this datatype will
151
+ * potentially require modifying the SIMD code. The x86-64 SIMD extensions,
152
+ * in particular, assume a 32-bit JDIMENSION.)
153
+ */
154
+
155
+ typedef unsigned int JDIMENSION;
156
+
157
+ #define JPEG_MAX_DIMENSION 65500L /* a tad under 64K to prevent overflows */
158
+
159
+
160
+ /* These macros are used in all function definitions and extern declarations.
161
+ * You could modify them if you need to change function linkage conventions;
162
+ * in particular, you'll need to do that to make the library a Windows DLL.
163
+ * Another application is to make all functions global for use with debuggers
164
+ * or code profilers that require it.
165
+ */
166
+
167
+ /* a function called through method pointers: */
168
+ #define METHODDEF(type) static type
169
+ /* a function used only in its module: */
170
+ #define LOCAL(type) static type
171
+ /* a function referenced thru EXTERNs: */
172
+ #define GLOBAL(type) type
173
+ /* a reference to a GLOBAL function: */
174
+ #define EXTERN(type) extern type
175
+
176
+
177
+ /* Originally, this macro was used as a way of defining function prototypes
178
+ * for both modern compilers as well as older compilers that did not support
179
+ * prototype parameters. libjpeg-turbo has never supported these older,
180
+ * non-ANSI compilers, but the macro is still included because there is some
181
+ * software out there that uses it.
182
+ */
183
+
184
+ #define JMETHOD(type, methodname, arglist) type (*methodname) arglist
185
+
186
+
187
+ /* libjpeg-turbo no longer supports platforms that have far symbols (MS-DOS),
188
+ * but again, some software relies on this macro.
189
+ */
190
+
191
+ #undef FAR
192
+ #define FAR
193
+
194
+
195
+ /*
196
+ * On a few systems, type boolean and/or its values FALSE, TRUE may appear
197
+ * in standard header files. Or you may have conflicts with application-
198
+ * specific header files that you want to include together with these files.
199
+ * Defining HAVE_BOOLEAN before including jpeglib.h should make it work.
200
+ */
201
+
202
+ #ifndef HAVE_BOOLEAN
203
+ typedef int boolean;
204
+ #endif
205
+ #ifndef FALSE /* in case these macros already exist */
206
+ #define FALSE 0 /* values of boolean */
207
+ #endif
208
+ #ifndef TRUE
209
+ #define TRUE 1
210
+ #endif
211
+
212
+
213
+ /*
214
+ * The remaining options affect code selection within the JPEG library,
215
+ * but they don't need to be visible to most applications using the library.
216
+ * To minimize application namespace pollution, the symbols won't be
217
+ * defined unless JPEG_INTERNALS or JPEG_INTERNAL_OPTIONS has been defined.
218
+ */
219
+
220
+ #ifdef JPEG_INTERNALS
221
+ #define JPEG_INTERNAL_OPTIONS
222
+ #endif
223
+
224
+ #ifdef JPEG_INTERNAL_OPTIONS
225
+
226
+
227
+ /*
228
+ * These defines indicate whether to include various optional functions.
229
+ * Undefining some of these symbols will produce a smaller but less capable
230
+ * library. Note that you can leave certain source files out of the
231
+ * compilation/linking process if you've #undef'd the corresponding symbols.
232
+ * (You may HAVE to do that if your compiler doesn't like null source files.)
233
+ */
234
+
235
+ /* Capability options common to encoder and decoder: */
236
+
237
+ #define DCT_ISLOW_SUPPORTED /* accurate integer method */
238
+ #define DCT_IFAST_SUPPORTED /* less accurate int method [legacy feature] */
239
+ #define DCT_FLOAT_SUPPORTED /* floating-point method [legacy feature] */
240
+
241
+ /* Encoder capability options: */
242
+
243
+ #define C_MULTISCAN_FILES_SUPPORTED /* Multiple-scan JPEG files? */
244
+ #define C_PROGRESSIVE_SUPPORTED /* Progressive JPEG? (Requires MULTISCAN)*/
245
+ #define C_LOSSLESS_SUPPORTED /* Lossless JPEG? */
246
+ #define ENTROPY_OPT_SUPPORTED /* Optimization of entropy coding parms? */
247
+ /* Note: if you selected 12-bit data precision, it is dangerous to turn off
248
+ * ENTROPY_OPT_SUPPORTED. The standard Huffman tables are only good for 8-bit
249
+ * precision, so jchuff.c normally uses entropy optimization to compute
250
+ * usable tables for higher precision. If you don't want to do optimization,
251
+ * you'll have to supply different default Huffman tables.
252
+ * The exact same statements apply for progressive and lossless JPEG:
253
+ * the default tables don't work for progressive mode or lossless mode.
254
+ * (This may get fixed, however.)
255
+ */
256
+ #define INPUT_SMOOTHING_SUPPORTED /* Input image smoothing option? */
257
+
258
+ /* Decoder capability options: */
259
+
260
+ #define D_MULTISCAN_FILES_SUPPORTED /* Multiple-scan JPEG files? */
261
+ #define D_PROGRESSIVE_SUPPORTED /* Progressive JPEG? (Requires MULTISCAN)*/
262
+ #define D_LOSSLESS_SUPPORTED /* Lossless JPEG? */
263
+ #define SAVE_MARKERS_SUPPORTED /* jpeg_save_markers() needed? */
264
+ #define BLOCK_SMOOTHING_SUPPORTED /* Block smoothing? (Progressive only) */
265
+ #define IDCT_SCALING_SUPPORTED /* Output rescaling via IDCT? */
266
+ #undef UPSAMPLE_SCALING_SUPPORTED /* Output rescaling at upsample stage? */
267
+ #define UPSAMPLE_MERGING_SUPPORTED /* Fast path for sloppy upsampling? */
268
+ #define QUANT_1PASS_SUPPORTED /* 1-pass color quantization? */
269
+ #define QUANT_2PASS_SUPPORTED /* 2-pass color quantization? */
270
+
271
+ /* more capability options later, no doubt */
272
+
273
+
274
+ /*
275
+ * The RGB_RED, RGB_GREEN, RGB_BLUE, and RGB_PIXELSIZE macros are a vestigial
276
+ * feature of libjpeg. The idea was that, if an application developer needed
277
+ * to compress from/decompress to a BGR/BGRX/RGBX/XBGR/XRGB buffer, they could
278
+ * change these macros, rebuild libjpeg, and link their application statically
279
+ * with it. In reality, few people ever did this, because there were some
280
+ * severe restrictions involved (cjpeg and djpeg no longer worked properly,
281
+ * compressing/decompressing RGB JPEGs no longer worked properly, and the color
282
+ * quantizer wouldn't work with pixel sizes other than 3.) Furthermore, since
283
+ * all of the O/S-supplied versions of libjpeg were built with the default
284
+ * values of RGB_RED, RGB_GREEN, RGB_BLUE, and RGB_PIXELSIZE, many applications
285
+ * have come to regard these values as immutable.
286
+ *
287
+ * The libjpeg-turbo colorspace extensions provide a much cleaner way of
288
+ * compressing from/decompressing to buffers with arbitrary component orders
289
+ * and pixel sizes. Thus, we do not support changing the values of RGB_RED,
290
+ * RGB_GREEN, RGB_BLUE, or RGB_PIXELSIZE. In addition to the restrictions
291
+ * listed above, changing these values will also break the SIMD extensions and
292
+ * the regression tests.
293
+ */
294
+
295
+ #define RGB_RED 0 /* Offset of Red in an RGB scanline element */
296
+ #define RGB_GREEN 1 /* Offset of Green */
297
+ #define RGB_BLUE 2 /* Offset of Blue */
298
+ #define RGB_PIXELSIZE 3 /* JSAMPLEs per RGB scanline element */
299
+
300
+ #define JPEG_NUMCS 17
301
+
302
+ #define EXT_RGB_RED 0
303
+ #define EXT_RGB_GREEN 1
304
+ #define EXT_RGB_BLUE 2
305
+ #define EXT_RGB_PIXELSIZE 3
306
+
307
+ #define EXT_RGBX_RED 0
308
+ #define EXT_RGBX_GREEN 1
309
+ #define EXT_RGBX_BLUE 2
310
+ #define EXT_RGBX_PIXELSIZE 4
311
+
312
+ #define EXT_BGR_RED 2
313
+ #define EXT_BGR_GREEN 1
314
+ #define EXT_BGR_BLUE 0
315
+ #define EXT_BGR_PIXELSIZE 3
316
+
317
+ #define EXT_BGRX_RED 2
318
+ #define EXT_BGRX_GREEN 1
319
+ #define EXT_BGRX_BLUE 0
320
+ #define EXT_BGRX_PIXELSIZE 4
321
+
322
+ #define EXT_XBGR_RED 3
323
+ #define EXT_XBGR_GREEN 2
324
+ #define EXT_XBGR_BLUE 1
325
+ #define EXT_XBGR_PIXELSIZE 4
326
+
327
+ #define EXT_XRGB_RED 1
328
+ #define EXT_XRGB_GREEN 2
329
+ #define EXT_XRGB_BLUE 3
330
+ #define EXT_XRGB_PIXELSIZE 4
331
+
332
+ static const int rgb_red[JPEG_NUMCS] = {
333
+ -1, -1, RGB_RED, -1, -1, -1, EXT_RGB_RED, EXT_RGBX_RED,
334
+ EXT_BGR_RED, EXT_BGRX_RED, EXT_XBGR_RED, EXT_XRGB_RED,
335
+ EXT_RGBX_RED, EXT_BGRX_RED, EXT_XBGR_RED, EXT_XRGB_RED,
336
+ -1
337
+ };
338
+
339
+ static const int rgb_green[JPEG_NUMCS] = {
340
+ -1, -1, RGB_GREEN, -1, -1, -1, EXT_RGB_GREEN, EXT_RGBX_GREEN,
341
+ EXT_BGR_GREEN, EXT_BGRX_GREEN, EXT_XBGR_GREEN, EXT_XRGB_GREEN,
342
+ EXT_RGBX_GREEN, EXT_BGRX_GREEN, EXT_XBGR_GREEN, EXT_XRGB_GREEN,
343
+ -1
344
+ };
345
+
346
+ static const int rgb_blue[JPEG_NUMCS] = {
347
+ -1, -1, RGB_BLUE, -1, -1, -1, EXT_RGB_BLUE, EXT_RGBX_BLUE,
348
+ EXT_BGR_BLUE, EXT_BGRX_BLUE, EXT_XBGR_BLUE, EXT_XRGB_BLUE,
349
+ EXT_RGBX_BLUE, EXT_BGRX_BLUE, EXT_XBGR_BLUE, EXT_XRGB_BLUE,
350
+ -1
351
+ };
352
+
353
+ static const int rgb_pixelsize[JPEG_NUMCS] = {
354
+ -1, -1, RGB_PIXELSIZE, -1, -1, -1, EXT_RGB_PIXELSIZE, EXT_RGBX_PIXELSIZE,
355
+ EXT_BGR_PIXELSIZE, EXT_BGRX_PIXELSIZE, EXT_XBGR_PIXELSIZE, EXT_XRGB_PIXELSIZE,
356
+ EXT_RGBX_PIXELSIZE, EXT_BGRX_PIXELSIZE, EXT_XBGR_PIXELSIZE, EXT_XRGB_PIXELSIZE,
357
+ -1
358
+ };
359
+
360
+ /* Definitions for speed-related optimizations. */
361
+
362
+ /* On some machines (notably 68000 series) "int" is 32 bits, but multiplying
363
+ * two 16-bit shorts is faster than multiplying two ints. Define MULTIPLIER
364
+ * as short on such a machine. MULTIPLIER must be at least 16 bits wide.
365
+ */
366
+
367
+ #ifndef MULTIPLIER
368
+ #ifndef WITH_SIMD
369
+ #define MULTIPLIER int /* type for fastest integer multiply */
370
+ #else
371
+ #define MULTIPLIER short /* prefer 16-bit with SIMD for parellelism */
372
+ #endif
373
+ #endif
374
+
375
+
376
+ /* FAST_FLOAT should be either float or double, whichever is done faster
377
+ * by your compiler. (Note that this type is only used in the floating point
378
+ * DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.)
379
+ */
380
+
381
+ #ifndef FAST_FLOAT
382
+ #define FAST_FLOAT float
383
+ #endif
384
+
385
+ #endif /* JPEG_INTERNAL_OPTIONS */