Compare commits

..

682 Commits

Author SHA1 Message Date
Kornel
0826579077 Fix PNG detection in CMake 2025-06-23 18:05:19 +01:00
Kornel
9b8d11f05e Fix -revert in tests 2025-01-04 02:11:32 +00:00
Kornel
1d3b119320 Fix djpeg tests 2025-01-04 00:52:39 +00:00
Kornel
38869c2d5d Use BUILD_SHARED_LIBS in cmake 2025-01-04 00:48:50 +00:00
Attila Repka
b6e0d504f7 fix(build): link to libmath on unix 2025-01-04 00:38:01 +00:00
Brendan Polin
3611168b5a Update BUILDING.md
Edited the vcpkg instructions for windows so they just work if you copy and paste
2025-01-04 00:37:38 +00:00
Kornel
97e2e1df43 Allow disabling fopen in SIMD 2025-01-03 10:04:01 +00:00
Kornel
ed667d4bfd Merge remote-tracking branch 'libjpeg-turbo/3.0.x' into mozjpeg
* libjpeg-turbo/3.0.x: (135 commits)
  Ensure methods called by global funcs are init'd
  Build: Generate 32-bit supplementary ppc64 .deb
  Build: Fix float test errors with Xcode 14.2/Arm
  AltiVec: Disable/Fix some strict compiler warnings
  Neon: Disable some strict compiler warnings
  Build: Make Mac packaging architecture-agnostic
  Exclude more code if !(C|D)_LOSSLESS_SUPPORTED
  Fix OSS-Fuzz decompress_yuv fuzzer MSan failure
  TJ doc: Density params require YCbCr or grayscale
  Allow disabling prog/opt/lossless if prev. enabled
  GitHub: Use macos-13 runner image w/ Xcode 14.2
  LICENSE.md: Update copyright year
  ChangeLog: Document accidental fix from 9983840e
  tj3Set(): Allow TJPARAM_LOSSLESSPT vals from 0..15
  Build: Support LLVM/Windows
  tj3Transform: Don't calc dst subsamp unless needed
  Fuzz: Calc. xformed buf size based on dst. subsamp
  TJ: Calc. xformed buf sizes based on dst. subsamp
  Minor TurboJPEG doc tweaks
  turbojpeg.c: Fix -Wsign-compare compiler warning
  ...
2025-01-03 09:57:35 +00:00
Kornel
c6d33b6d69 Merge commit '15274b901acb75d6d2433e8578f3cfbc6f4f5fd9' into mozjpeg
* commit '15274b901acb75d6d2433e8578f3cfbc6f4f5fd9': (98 commits)
  AppVeyor: Use SignPath release cert/only sign tags
  xform fuzz: Use only xform opts to set entropy alg
  jchuff.c: Test for out-of-range coefficients
  turbojpeg.h: Make customFilter() proto match doc
  ChangeLog.md: Fix typo
  djpeg: Fix -map option with 12-bit data precision
  Disallow color quantization with lossless decomp
  tj3Transform: Calc dst buf size from xformed dims
  README.md: Include link to project home page
  AppVeyor: Only add installers to zip file
  AppVeyor: Integrate with SignPath.io
  Fix build warnings/errs w/ -DNO_GETENV/-DNO_PUTENV
  GitHub: Fix x32 build
  Bump version to 3.0.0
  tjexample.c: Prevent integer overflow
  Disallow merged upsampling with lossless decomp
  SECURITY.md: Wordsmithing and clarifications
  GitHub: Add security policy
  ChangeLog.md: List CVE ID fixed by 9f756bc6
  jpeg_crop_scanline: Fix calc w/sclg + 2x4,4x2 samp
  ...
2024-12-23 01:25:43 +00:00
Kornel
15274b901a Merge tag '3.0.0' into '2.1.5.1'
# By DRC (96) and others
# Via DRC
* tag '3.0.0': (98 commits)
  AppVeyor: Use SignPath release cert/only sign tags
  xform fuzz: Use only xform opts to set entropy alg
  jchuff.c: Test for out-of-range coefficients
  turbojpeg.h: Make customFilter() proto match doc
  ChangeLog.md: Fix typo
  djpeg: Fix -map option with 12-bit data precision
  Disallow color quantization with lossless decomp
  tj3Transform: Calc dst buf size from xformed dims
  README.md: Include link to project home page
  AppVeyor: Only add installers to zip file
  AppVeyor: Integrate with SignPath.io
  Fix build warnings/errs w/ -DNO_GETENV/-DNO_PUTENV
  GitHub: Fix x32 build
  Bump version to 3.0.0
  tjexample.c: Prevent integer overflow
  Disallow merged upsampling with lossless decomp
  SECURITY.md: Wordsmithing and clarifications
  GitHub: Add security policy
  ChangeLog.md: List CVE ID fixed by 9f756bc6
  jpeg_crop_scanline: Fix calc w/sclg + 2x4,4x2 samp
  ...

# Conflicts:
#	CMakeLists.txt
#	ChangeLog.md
#	fuzz/decompress.cc
#	fuzz/decompress_yuv.cc
2024-12-23 00:23:06 +00:00
Kornel
d04cff3d6c Normalize whitespace and other merge details 2024-12-23 00:18:20 +00:00
DRC
e81cb16e0f Ensure methods called by global funcs are init'd
If a hypothetical calling application does something really stupid and
changes cinfo->data_precision after calling jpeg_start_*compress(), then
the precision-specific methods called by jpeg_write_scanlines(),
jpeg_write_raw_data(), jpeg_finish_compress(), jpeg_read_scanlines(),
jpeg_read_raw_data(), or jpeg_start_output() may not be initialized.

Ensure that the first precision-specific method (which will always be
cinfo->main->process_data*(), cinfo->coef->compress_data*(), or
cinfo->coef->decompress_data()) called by any global function that may
be called after jpeg_start_*compress() is initialized and non-NULL.
This increases the likelihood (but does not guarantee) that a
hypothetical stupid calling application will fail gracefully rather than
segfault if it changes cinfo->data_precision after calling
jpeg_start_*compress().  A hypothetical stupid calling application can
still bork itself by changing cinfo->data_precision after initializing
the source manager but before calling jpeg_start_compress(), or after
initializing the destination manager but before calling
jpeg_start_decompress().
2024-12-18 16:37:02 -05:00
DRC
3e703af408 Build: Generate 32-bit supplementary ppc64 .deb
As with x86-64, the Power ISA basically implements 64-bit instructions
as extensions of their 32-bit counterparts.  Thus, 64-bit Power ISA CPUs
can natively execute legacy 32-bit PowerPC instructions when running in
big-endian mode.  Most Power ISA support has shifted (pun intended) to
little-endian mode, so there are few remaining operating systems that
support big-endian mode.  Debian is one of them, however (albeit
unofficially.)
2024-12-18 10:15:24 -05:00
DRC
b4ca1ba192 Build: Fix float test errors with Xcode 14.2/Arm
Unlike other versions of Clang 14.0.0, AppleClang 14.0.0 in Xcode 14.2
retains the old -ffp-contract=off default.  Apple didn't adopt
-ffp-contract=on as the default until Xcode 14.3 (AppleClang 14.0.3.)
This has been confirmed in the Xcode 14.3 release notes.
2024-12-12 16:02:05 -05:00
DRC
1c864a9d15 AltiVec: Disable/Fix some strict compiler warnings
We use a standard set of strict compiler warnings with Clang and GCC to
continuously test and maintain C89 conformance in the libjpeg API code.
However, SIMD extensions need not comply with that.  The AltiVec code
specifically uses some C99isms, so disable -Wc99-extensions and
-Wpedantic in the scope of that code.  Also disable -Wshadow, because
I'm too lazy to fix the TRANSPOSE() macro.  Also
use #ifdef __BIG_ENDIAN__ and #if defined(__BIG_ENDIAN__) instead
of #if __BIG_ENDIAN__
2024-12-12 10:48:26 -05:00
DRC
ab56b9841c Neon: Disable some strict compiler warnings
We use a standard set of strict compiler warnings with Clang and GCC to
continuously test and maintain C89 conformance in the libjpeg API code.
However, SIMD extensions need not comply with that.  The Neon code
specifically uses some C99isms, so disable
-Wdeclaration-after-statement, -Wc99-extensions, and -Wpedantic in the
scope of that code.  Also modify the Neon feature tests so that they
will succeed if any of the aforementioned compiler warnings are enabled.
2024-12-11 17:19:02 -05:00
DRC
f23981b0aa Build: Make Mac packaging architecture-agnostic
Rename the ARMV8_BUILD CMake variable to SECONDARY_BUILD, and modify the
makemacpkg script so that it allows any architecture in a primary or
secondary build.  The idea is that Apple Silicon users can package an
arm64 primary build and a secondary x86_64 build, and Intel users can
package an x86_64 primary build and a secondary arm64 build, using the
same procedure.

Also simplify the iOS build instructions, using the
CMAKE_OSX_ARCHITECTURES variable rather than a toolchain.
2024-12-11 17:19:01 -05:00
DRC
3358df7da4 Exclude more code if !(C|D)_LOSSLESS_SUPPORTED 2024-11-18 16:20:00 -05:00
DRC
4e55d44658 Fix OSS-Fuzz decompress_yuv fuzzer MSan failure 2024-11-15 08:32:08 -05:00
DRC
3be781679c TJ doc: Density params require YCbCr or grayscale
Since libjpeg-turbo does not support Exif, the only way it can embed
density information in a JPEG image is by using the JFIF marker, which
is only written if the JPEG colorspace is YCbCr or grayscale.
(Referring to the conversation under #793, we may need to further
restrict that to 8-bit-per-sample JPEG images, because the JFIF spec
requires 8-bit data precision.)
2024-10-30 12:27:02 -04:00
DRC
45fa88190f Allow disabling prog/opt/lossless if prev. enabled
- Due to an oversight, a113506d17
  (libjpeg-turbo 1.4 beta1) effectively made the call to
  std_huff_tables() in jpeg_set_defaults() a no-op if the Huffman tables
  were previously defined, which made it impossible to disable Huffman
  table optimization or progressive mode if they were previously enabled
  in the same API instance.  std_huff_tables() retains its previous
  behavior for decompression instances, but it now force-enables the
  standard (baseline) Huffman tables for compression instances.

- Due to another oversight, there was no way to disable lossless mode
  if it was previously enabled in a particular API instance.
  jpeg_set_defaults() now accomplishes this, which makes
  TJ*PARAM_LOSSLESS behave as intended/documented.

- Due to yet another oversight, setCompDefaults() in the TurboJPEG API
  library permanently modified the value of TJ*PARAM_SUBSAMP when
  generating a lossless JPEG image, which affected subsequent lossy
  compression operations.  This issue was hidden by the issue above and
  thus does not need to be publicly documented.

Fixes #792
2024-10-24 19:06:02 -04:00
DRC
00e71d4c07 GitHub: Use macos-13 runner image w/ Xcode 14.2
(macos-12 is deprecated.)
2024-10-23 18:06:42 -04:00
DRC
b20e7f17dd LICENSE.md: Update copyright year 2024-09-24 10:46:56 -04:00
DRC
60a75c8a47 ChangeLog: Document accidental fix from 9983840e
Closes #789
2024-09-23 15:50:04 -04:00
DRC
63f4cf4222 tj3Set(): Allow TJPARAM_LOSSLESSPT vals from 0..15
The target data precision isn't known at the time that the calling
program sets TJPARAM_LOSSLESSPT, so tj3Set() needs to allow all possible
values (from 0 to 15.)  jpeg_enable_lossless(), which is called within
the body of tj3Compress*(), will throw an error if the point transform
value is greater than {data precision} - 1.
2024-09-23 13:31:20 -04:00
DRC
7f200a2acc Build: Support LLVM/Windows
Since LLVM/Windows emulates Visual Studio, CMake sets
CMAKE_C_SIMULATE_ID="MSVC" but does not set MSVC.  Thus, our build
system needs to enable most (but not all) of the Visual Studio features
when CMAKE_C_SIMLUATE_ID="MSVC".  Support for LLVM/Windows is currently
undocumented because it isn't a standalone build environment.  (It
requires the Visual Studio and Windows SDK headers and link libraries.)

Closes #786
2024-09-16 14:20:46 -04:00
DRC
f29eda6485 tj3Transform: Don't calc dst subsamp unless needed
This just improves code readability by emphasizing that we don't care
about the destination image's level of subsampling unless
TJPARAM_NOREALLOC is set or lossless cropping will be performed.
2024-09-14 11:10:59 -04:00
DRC
bcbca8b9bc Fuzz: Calc. xformed buf size based on dst. subsamp
(oversight from b3f0abe377)
2024-09-12 21:07:51 -04:00
DRC
b3f0abe377 TJ: Calc. xformed buf sizes based on dst. subsamp
With respect to tj3Transform(), this addresses an oversight from
bb1d540a80.

Note to self: A convenience function/method for computing the worst-case
transformed JPEG size for a particular transform would be nice.
2024-09-06 19:04:28 -04:00
DRC
6d9591703f Minor TurboJPEG doc tweaks
- When transforming, the worst-case JPEG buffer size depends on the
  subsampling level used in the destination image, since a grayscale
  transform might have been applied.

- Parentheses Police
2024-09-05 22:31:40 -04:00
DRC
2e40a6875d turbojpeg.c: Fix -Wsign-compare compiler warning
(introduced by previous commit)
2024-09-05 16:49:44 -04:00
DRC
758e8a8e9f Java: Use Java-style method nomenclature
:: is a C++ thing.
2024-09-05 14:57:15 -04:00
DRC
fe1e555a73 tjbenchtest.in: Grammar Police 2024-09-05 14:46:04 -04:00
DRC
bb1d540a80 TJ: Explicitly reject OOB lossless crop regions
tj*Transform() relied upon the underlying transupp API to check the
cropping region.  However, transupp uses unsigned integers for the
cropping region, whereas the tjregion structure uses signed integers.
Thus, casting negative values from a tjregion structure produced very
large unsigned values.  In the case of the left and upper boundary, this
was innocuous, because jtransform_request_workspace() rejected the
values as being out of bounds.  However, jtransform_request_workspace()
did not always reject very large width and height values, because it
supports expanding the destination image by specifying a cropping region
larger than the source image.  In certain cases, it allowed those
values, and the libjpeg memory manager subsequently ran out of memory.

NOTE: Prior to this commit, image expansion technically worked with
tj*Transform() as long as the cropping width and height were valid and
automatic JPEG buffer (re)allocation was used.  However, that behavior
is not a documented feature of the TurboJPEG API, nor do we have any way
of testing it at the moment.  Official support for image expansion can
be added later, if there is sufficient demand for it.

Similarly, this commit modifies tj3SetCroppingRegion() so that it
explicitly checks for left boundary values exactly equal to the scaled
image width and upper boundary values exactly equal to the scaled image
height.  If the specified cropping width or height was 0 (which is
interpreted as {scaled image width} - {left boundary} or
{scaled image height} - {upper boundary}), then such values caused a
cropping width or height of 0 to be passed to the libjpeg API.  In the
case of the width, this was innocuous, because jpeg_crop_scanline()
rejected the value.  In the case of the height, however, this caused
unexpected and hard-to-diagnose errors farther down the pipeline.
2024-09-05 14:37:12 -04:00
DRC
dd8b15ee82 tjbenchtest.in: Formatting tweak
(oversight from a5689cd45b)
2024-09-04 07:52:51 -04:00
DRC
e7e9344db1 TJ: Honor TJ*OPT_COPYNONE for individual xforms
jcopy_markers_execute() has historically ignored its option argument,
which is OK for jpegtran, but tj*Transform() needs to be able to save a
set of markers from the source image and write a subset of those markers
to each destination image.  Without that ability, the function
effectively behaved as if TJ*OPT_COPYNONE was not specified unless all
transforms specified it.
2024-09-04 07:34:42 -04:00
DRC
5550c80fdc Doc: "compress operation"="compression operation"
(consistification)
2024-09-03 17:20:10 -04:00
DRC
939f3814ab Test: Replace test2.icc with test3.icc
test3.icc is smaller, and it is also an RGB profile rather than a CMYK
profile.  (test1.icc is a CMYK profile.)
2024-09-03 15:47:57 -04:00
DRC
a5689cd45b Test: Replace big_tree8.bmp and big_building16.ppm
These images were only used with tjbenchtest and tjexampletest, but I
was concerned about introducing additional licensing provisions into the
libjpeg-turbo source tree.  Thus, this commit replaces them with images
that I own and can thus make available under the libjpeg-turbo licenses
with no additional provisions.
2024-09-03 15:47:37 -04:00
DRC
f5f8f5aadc TJ: Reorder functions to improve readability
Put all general functions at the top of the list, and ensure that all
functions are defined before they are mentioned.  Also consistify the
function ordering between turbojpeg.h and turbojpeg.c
2024-09-03 09:02:55 -04:00
DRC
843d04d9d4 CI: Run regression tests in parallel 2024-09-01 11:52:01 -04:00
DRC
797c6ccd98 Doc: Further clarify MCU definition 2024-09-01 11:25:29 -04:00
DRC
7ec70ee891 testclean.cmake: Remove croptest.log 2024-09-01 09:59:10 -04:00
DRC
174672af4e jquant1.c: Formatting tweak
Extending the Bayer matrix past Column 80 seems like a lesser
readability sin than not putting a space after each comma, especially
since we had to explicitly whitelist the file in checkstyle.
2024-09-01 09:55:52 -04:00
DRC
eb75363004 Update URLs
- Eliminate unnecessary "www."
- Use HTTPS.
- Update Java, MSYS, tdm-gcc, and NSIS URLs.
- Update URL and title of Agner Fog's assembly language optimization
  manual.
- Remove extraneous information about MASM and Borland Turbo Assembler
  and outdated NASM URLs from the x86 assembly headers, and mention
  Yasm.
2024-08-31 16:50:08 -04:00
DRC
0fb8fbe158 CMakeLists.txt: libjpeg-turbo "2.2.x" = "3.0.x" 2024-08-31 15:39:34 -04:00
DRC
8d76e4e550 Doc: "EXIF" = "Exif" 2024-08-31 15:33:55 -04:00
DRC
9983840eb6 TJ/xform: Check crop region against dest. image
Lossless cropping is performed after other lossless transform
operations, so the cropping region must be specified relative to the
destination image dimensions and level of chrominance subsampling, not
the source image dimensions and level of chrominance subsampling.

More specifically, if the lossless transform operation swaps the X and Y
axes, or if the image is converted to grayscale, then that changes the
cropping region requirements.
2024-08-31 15:04:30 -04:00
DRC
8456d2b98c Doc: "MCU block" = "iMCU" or "MCU"
The JPEG-1 spec never uses the term "MCU block".  That term is rarely
used in other literature to describe the equivalent of an MCU in an
interleaved JPEG image, but the libjpeg documentation uses "iMCU" to
describe the same thing.  "iMCU" is a better term, since the equivalent
of an interleaved MCU can contain multiple DCT blocks (or samples in
lossless mode) that are only grouped together if the image is
interleaved.

In the case of restart markers, "MCU block" was used in the libjpeg
documentation instead of "MCU", but "MCU" is more accurate and less
confusing.  (The restart interval is literally in MCUs, where one MCU
is one data unit in a non-interleaved JPEG image and multiple data units
in a multi-component interleaved JPEG image.)

In the case of 9b704f96b2, the issue was
actually with progressive JPEG images exactly two DCT blocks wide, not
two MCU blocks wide.

This commit also defines "MCU" and "MCU row" in the description of the
various restart marker options/parameters.  Although an MCU row is
technically always a row of samples in lossless mode, "sample row" was
confusing, since it is used in other places to describe a row of samples
for a single component (whereas an MCU row in a typical lossless JPEG
image consists of a row of interleaved samples for all components.)
2024-08-30 14:16:09 -04:00
DRC
5cf7960678 Undocument TJ*PARAM_RESTARTBLOCKS for lossless
TJ*PARAM_RESTARTBLOCKS technically works with lossless compression, but
it is not useful, since the value must be equal to the number of samples
in a row.  (In other words, it is no different than
TJ*PARAM_RESTARTINROWS, except that it requires the user to do more
math.)
2024-08-28 18:36:37 -04:00
DRC
d62079717c TJBench: Don't override subsamp until args parsed
Otherwise, passing -subsamp after -lossless might cause the worst-case
JPEG buffer size to be too small.
2024-08-28 18:21:55 -04:00
DRC
c72bbd9c06 tjbench.c: (Re)allow unreduced scaling factors
For reasons I can't recall, fc01f4673b
(the TurboJPEG 3 API overhaul) changed the C version of TJBench, but not
the Java version, so that it requires an exact scaling factor match (as
opposed to allowing unreduced scaling factors, as djpeg does and prior
versions of TJBench did.)  That might have been temporary testing code
that was accidentally committed.
2024-08-26 18:14:12 -04:00
DRC
35199878f6 TurboJPEG doc: Fix incorrect/confusing parentheses 2024-08-26 16:35:30 -04:00
DRC
00a261c473 tjbench.c: Code formatting tweak 2024-08-26 16:31:02 -04:00
DRC
4851cbe406 djpeg/jpeg_crop_scanline(): Disallow crop vals < 0
Because the crop spec was parsed using unsigned 32-bit integers,
negative numbers were interpreted as values ~= UINT_MAX (4,294,967,295).
This had the following ramifications:

- If the cropping region width was negative and the adjusted width + the
  adjusted left boundary was greater than 0, then the 32-bit unsigned
  integer bounds checks in djpeg and jpeg_crop_scanline() overflowed and
  failed to detect the out-of-bounds width, jpeg_crop_scanline() set
  cinfo->output_width to a value ~= UINT_MAX, and a buffer overrun and
  subsequent segfault occurred in the upsampling or color conversion
  routine.  The segfault occurred in the body of
  jpeg_skip_scanlines() --> read_and_discard_scanlines() if the cropping
  region upper boundary was greater than 0 and the JPEG image used
  chrominance subsampling and in the body of jpeg_read_scanlines()
  otherwise.

- If the cropping region width was negative and the adjusted width + the
  adjusted left boundary was 0, then a zero-width output image was
  generated.

- If the cropping region left boundary was negative, then an output
  image with bogus data was generated.

This commit modifies djpeg and jpeg_crop_scanline() so that the
aforementioned bounds checks use 64-bit unsigned integers, thus guarding
against overflow.  It similarly modifies jpeg_skip_scanlines().  In the
case of jpeg_skip_scanlines(), the issue was not reproducible with
djpeg, but passing a negative number of lines to jpeg_skip_scanlines()
caused a similar overflow if the number of lines +
cinfo->output_scanline was greater than 0.  That caused
jpeg_skip_scanlines() to read past the end of the JPEG image, throw a
warning ("Corrupt JPEG data: premature end of data segment"), and fail
to return unless warnings were treated as fatal.  Also, djpeg now parses
the crop spec using signed integers and checks for negative values.
2024-08-26 16:24:33 -04:00
DRC
548f732432 TJBench: Usage screen tweak
Indicate that -maxmemory and -maxpixels take an integer argument.
2024-08-26 10:14:11 -04:00
DRC
de4bbac55e TJCompressor.compress(): Fix lossls buf size calc 2024-08-23 12:48:34 -04:00
DRC
0acb084464 JNI: Fix *Image() array size issues w/ align != 1
+ check for mismatch between C and Java APIs in *saveImage().
2024-08-22 16:58:50 -04:00
DRC
d44fc54f94 Java: Unset srcBuf12/16 with BufferedImage/YUV src
Due to an oversight in the multi-precision feature,
TJCompressor.srcBuf12 and TJCompressor.srcBuf16 were not set to null
in TJCompressor.setSourceImage(YUVImage) or
TJCompressor.setSourceImage(BufferedImage, ...).  Thus, if an
application set a 12-bit or 16-bit packed-pixel buffer as the source
image then set a BufferedImage with integer pixels as the source image,
TJCompress.compress() would compress from the 12-bit or 16-bit
packed-pixel buffer instead of the BufferedImage.  The odds of an
application actually doing that are very slim, however.
2024-08-21 16:44:46 -04:00
DRC
8c2e7306cf Java doc: Minor formatting tweak 2024-08-21 13:03:41 -04:00
DRC
49f1b5807d TJBench.java: Explicitly set restartIntervalBlocks
This is just a readability thing.  Java initializes integer fields to 0
by default.
2024-08-20 15:11:20 -04:00
DRC
a9723f8a98 cjpeg/djpeg/jpegtran: Restore jpeg-6b arg abbrevs
There are two approaches to handling abbreviated command-line options:

1. If a new option is introduced that begins with the same letters as an
existing option, require a longer abbreviation for the existing option
in order to ensure that abbreviations are always unique.

2. Require a unique abbreviation only for new options, and match all
non-unique abbreviations with existing options, thus maintaining
backward compatibility.

keymatch() supports either approach, and Tom Lane historically seemed to
prefer Approach 2, whereas both approaches have been applied
inconsistently in the years since.  This commit consistently applies
Approach 2.

More specific notes:

We unnecessarily required 'cjpeg -progressive' to be abbreviated as
'cjpeg -pro' rather than 'cjpeg -p' when the -precision option was
introduced in libjpeg-turbo 3.0 beta.

The IJG unnecessarily required 'cjpeg -scans' to be abbreviated as
'cjpeg -scan' rather than 'cjpeg -sc' when the -scale option was
introduced in jpeg-7.  We even more unnecessarily adopted that
requirement, even though we never adopted the -scale option.

We unnecessarily required 'djpeg -scale' to be abbreviated as
'djpeg -sc' rather than 'djpeg -s' when the -skip option was introduced
in libjpeg-turbo 1.5 beta.

The IJG unnecessarily required 'jpegtran -copy' to be abbreviated as
'jpegtran -co' rather than 'jpegtran -c' when the -crop option was
introduced in jpeg-7.

The IJG unnecessarily required 'jpegtran -progressive' to be abbreviated
as 'jpegtran -pr' rather than 'jpegtran -p' when the -perfect option was
introduced in jpeg-7.
2024-08-19 17:12:33 -04:00
DRC
562ad7612e OSS-Fuzz: More MSan fixes
We need to use tj3Alloc() (which, when ZERO_BUFFERS is defined, calls
calloc() instead of malloc()) to allocate all destination buffers.
Otherwise, if the compression/decompression/transform operation fails,
then the buffer checksum (which is computed to prevent the compiler from
optimizing out the whole test, since the destination buffer is never
used otherwise) will depend upon values in the destination buffer that
were never written, and MSan will complain.
2024-08-19 10:06:59 -04:00
DRC
488d42a8a5 OSS-Fuzz: Define ZERO_BUFFERS for MSan build
... and use tj3Alloc() to allocate compression/transformation
destination buffers.
2024-08-16 12:17:17 -04:00
DRC
0c23b0ad60 Various doc tweaks
- "Optimized baseline entropy coding" = "Huffman table optimization"

  "Optimized baseline entropy coding" was meant to emphasize that the
  feature is only useful when generating baseline (single-scan lossy
  8-bit-per-sample Huffman-coded) JPEG images, because it is
  automatically enabled when generating Huffman-coded progressive
  (multi-scan), 12-bit-per-sample, and lossless JPEG images.  However,
  Huffman table optimization isn't actually an integral part of those
  non-baseline modes.  You can forego Huffman table optimization with
  12-bit data precision if you supply your own Huffman tables.  The spec
  doesn't require it with progressive or lossless mode, either, although
  our implementation does.  Furthermore, "baseline" describes more than
  just the type of entropy coding used.  It was incorrect to say that
  optimized "baseline" entropy coding is automatically enabled for
  Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG
  images, since those are clearly not baseline images.

- "Progressive entropy coding" = "Progressive JPEG"

  "Progressive" describes more than just the type of entropy coding
  used.  (In fact, both Huffman-coded and arithmetic-coded images can be
  progressive.)

- Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with
  lossless transformation as well.

- General wordsmithing

- Formatting tweaks
2024-08-16 11:49:00 -04:00
DRC
b4336c3afb Work around valgrind/MSan SIMD false positives
Referring to
https://sourceforge.net/p/libjpeg-turbo/bugs/48,
https://sourceforge.net/p/libjpeg-turbo/bugs/82,
 #15, #238, #253, and #619,
valgrind and MSan have failed to properly detect data initialization by
libjpeg-turbo's x86 SIMD extensions for the entire 14 years that
libjpeg-turbo has been a project, resulting in false positives unless
libjpeg-turbo is built with WITH_SIMD=0 or run with JSIMD_FORCENONE=1.
This commit introduces a new C preprocessor macro (ZERO_BUFFERS) that,
if set, causes libjpeg-turbo to zero certain buffers in order to work
around the specific valgrind/MSan test failures caused by the
aforementioned false positives.  This allows us to more closely
approximate the production configuration of libjpeg-turbo when testing
with valgrind or MSan.

Closes #781
2024-08-13 16:23:40 -04:00
DRC
8db0312668 example.c: Write correct dimensions to PPM header
The dimensions in the PPM header of the output file generated by
'example decompress' were always 640 x 480, regardless of the size of
the JPEG image being decompressed.  Our regression tests (which this
commit also fixes) missed the bug because they decompressed the
640 x 480 image generated by 'example compress'.

Fixes #778
2024-08-02 09:06:40 -04:00
DRC
0566d51e09 GitHub Actions: Specify Monterey for macOS build
The Big Sur hosted runner is no longer available.
2024-07-09 17:18:53 -04:00
DRC
e287a35762 Build: Put gastest.o in ${CMAKE_BINARY_DIR}/simd
Closes #776
2024-07-04 10:03:50 -04:00
DRC
51d021bf01 TurboJPEG: Fix 12-bit-per-sample arith-coded compr
(Regression introduced by 7bb958b732)

Because of 7bb958b732, the TurboJPEG
compression and encoding functions no longer transfer the value of
TJPARAM_OPTIMIZE into cinfo->data_precision unless the data precision
is 8.  The intent of that was to prevent using_std_huff_tables() from
being called more than once when reusing the same compressor object to
generate multiple 12-bit-per-sample JPEG images.  However, because
cinfo->optimize_coding is always set to TRUE by jpeg_set_defaults() if
the data precision is 12, calling applications that use 12-bit data
precision had to unset cinfo->optimize_coding if they set
cinfo->arith_code after calling jpeg_set_defaults().  Because of
7bb958b732, the TurboJPEG API stopped
doing that except with 8-bit data precision.  Thus, attempting to
generate a 12-bit-per-sample arithmetic-coded lossy JPEG image using
the TurboJPEG API failed with "Requested features are incompatible."

Since the compressor will always fail if cinfo->arith_code and
cinfo->optimize_coding are both set, and since cinfo->optimize_coding
has no relevance for arithmetic coding, the most robust and user-proof
solution is for jinit_c_master_control() to set cinfo->optimize_coding
to FALSE if cinfo->arith_code is TRUE.

This commit also:
- modifies TJBench so that it no longer reports that it is using
  optimized baseline entropy coding in modes where that setting
  is irrelevant,
- amends the cjpeg documentation to clarify that -optimize is implied
  when specifying -progressive or '-precision 12' without -arithmetic,
  and
- prevents jpeg_set_defaults() from uselessly checking the value of
  cinfo->arith_code immediately after it has been set to FALSE.
2024-06-24 22:15:55 -04:00
DRC
bb3ab53157 cjpeg: Don't enable lossless until precision known
jpeg_enable_lossless() checks the point transform value against the data
precision, so we need to defer calling jpeg_enable_lossless() until
after all command-line options have been parsed.
2024-06-24 22:15:55 -04:00
DRC
a8aaaf5d5b cjpeg -verbose: Print PBMPLUS input file precision
This gives the user a hint as to whether converting the input file into
a JPEG file with a particular data precision will result in a loss of
precision.  Also modify usage.txt and the cjpeg man page to warn the
user about that possibility.
2024-06-24 22:15:55 -04:00
DRC
94c64ead85 Various doc tweaks
- "bits per component" = "bits per sample"

  Describing the data precision of a JPEG image using "bits per
  component" is technically correct, but "bits per sample" is the
  terminology that the JPEG-1 spec uses.  Also, "bits per component" is
  more commonly used to describe the precision of packed-pixel formats
  (as opposed to "bits per pixel") rather than planar formats, in which
  all components are grouped together.

- Unmention legacy display technologies.  Colormapped and monochrome
  displays aren't a thing anymore, and even when they were still a
  thing, it was possible to display full-color images to them.  In 1991,
  when JPEG decompression time was measured in minutes per megapixel, it
  made sense to keep a decompressed copy of JPEG images on disk, in a
  format that could be displayed without further color conversion (since
  color conversion was slow and memory-intensive.)  In 2024, JPEG
  decompression time is measured in milliseconds per megapixel, and
  color conversion is even faster.  Thus, JPEG images can be
  decompressed, displayed, and color-converted (if necessary) "on the
  fly" at speeds too fast for human vision to perceive.  (In fact, your
  TV performs much more complicated decompression algorithms at least 60
  times per second.)

- Document that color quantization (and associated features), GIF
  input/output, Targa input/output, and OS/2 BMP input/output are legacy
  features.  Legacy status doesn't necessarily mean that the features
  are deprecated.  Rather, it is meant to discourage users from using
  features that may be of little or no benefit on modern machines (such
  as low-quality modes that had significant performance advantages in
  the early 1990s but no longer do) and that are maintained on a
  break/fix basis only.

- General wordsmithing, grammar/punctuation policing, and formatting
  tweaks

- Clarify which data precisions each cjpeg input format and each djpeg
  output format supports.

- cjpeg.1: Remove unnecessary and impolitic statement about the -targa
  switch.

- Adjust or remove performance claims to reflect the fact that:
  * On modern machines, the djpeg "-fast" switch has a negligible effect
    on performance.
  * There is a measurable difference between the performance of Floyd-
    Steinberg dithering and no dithering, but it is not likely
    perceptible to most users.
  * There is a measurable difference between the performance of 1-pass
    and 2-pass color quantization, but it is not likely perceptible to
    most users.
  * There is a measurable difference between the performance of
    full-color and grayscale output when decompressing a full-color JPEG
    image, but it is not likely perceptible to most users.
  * IDCT scaling does not necessarily improve performance.  (It
    generally does if the scaling factor is <= 1/2 and generally doesn't
    if the scaling factor is > 1/2, at least on my machine.  The
    performance claim made in jpeg-6b was probably invalidated when we
    merged the additional scaling factors from jpeg-7.)

- Clarify which djpeg switches/output formats cannot be used when
  decompressing lossless JPEG images.

- Remove djpeg hints, since those involve quality vs. speed tradeoffs
  that are no longer relevant for modern machines.

- Remove documentation regarding using color quantization with 16-bit
  data precision.  (Color quantization requires lossy mode.)

- Java: Fix typos in TJDecompressor.decompress12() and
  TJDecompressor.decompress16() documentation.

- jpegtran.1: Fix truncated paragraph

  In a man page, a single quote at the start of a line is interpreted as
  a macro.

  Closes #775

- libjpeg.txt:
  * Mention J16SAMPLE data type (oversight.)
  * Remove statement about extending jdcolor.c.  (libjpeg-turbo is not
    quite as DIY as libjpeg once was.)
  * Remove paragraph about tweaking the various typedefs in jmorecfg.h.
    It is no longer relevant for modern machines.
  * Remove caveat regarding systems with ints less than 16 bits wide.
    (ANSI/ISO C requires an int to be at least 16 bits wide, and
    libjpeg-turbo has never supported non-ANSI compilers.)

- usage.txt:
  * Add copyright header.
  * Document cjpeg -icc, -memdst, -report, -strict, and -version
    switches.
  * Document djpeg -icc, -maxscans, -memsrc, -report, -skip, -crop,
    -strict, and -version switches.
  * Document jpegtran -icc, -maxscans, -report, -strict, and -version
    switches.
2024-06-24 22:11:43 -04:00
DRC
2c5312fd12 cderror.h: Always include all img I/O err messages
The 8-bit-per-sample image I/O modules have always been built with BMP,
GIF, PBMPLUS, and Targa support, and the 12-bit-per-sample image I/O
modules have always been built with only GIF and PBMPLUS support.  In
libjpeg-turbo 2.1.x and prior, cjpeg and djpeg were built with the same
image format support as the image I/O modules.  However, because of the
multi-precision feature introduced in libjpeg-turbo 3.0.x, cjpeg and
djpeg are now always built with support for all image formats.  Thus,
the error message table compiled into cjpeg and djpeg was a superset of
the error message table compiled into the 12-bit-per-sample and
16-bit-per-sample image I/O modules.  If, for example, the
12-bit-per-sample PPM writer threw JERR_PPM_COLORSPACE (== 15, because
it was built with only GIF and PBMPLUS support), then djpeg interpreted
that as JERR_GIF_COLORSPACE (== 15, because it was built with support
for all image formats.)  There was no chance of a buffer overrun, since
the error message table lookup was performed against the table compiled
into cjpeg and djpeg, which contained all possible entries.  However,
this issue caused an incorrect error message to be displayed by cjpeg or
djpeg if a 12-bit-per-sample or 16-bit-per-sample image I/O module threw
an error.  This commit simply removes the *_SUPPORTED #ifdefs from
cderror.h so that all image I/O error messages are always included in
every instance of the image I/O error message table.

Note that a similar issue could have also occurred with the
12-bit-per-sample and 16-bit-per-sample TurboJPEG image I/O functions,
since the 12-bit-per-sample and 16-bit-per-sample image I/O modules
supporting those functions are built with only PBMPLUS support whereas
the library as a whole is built with BMP and PBMPLUS support.
2024-06-13 22:34:23 -04:00
DRC
3c17063ef1 Guard against dupe SOF w/ incorrect source manager
Referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1898606,
attempting to decompress a specially-crafted malformed JPEG image
(specifically an image with a complete 12-bit Start Of Frame segment
followed by an incomplete 8-bit Start Of Frame segment) using the
default marker processor, buffered-image mode, and input prefetching
triggered the following sequence of events:

- When the 12-bit SOF segment was encountered (in the body of
  jpeg_read_header()), the marker processor's read_markers() method
  called the get_sof() function, which processed the 12-bit SOF segment
  and set cinfo->data_precision to 12.

- If the application subsequently called jpeg_consume_input() in a loop
  to prefetch input data, and it didn't stop calling
  jpeg_consume_input() when the function returned JPEG_REACHED_SOS, then
  the 8-bit SOF segment was encountered in the body of
  jpeg_consume_input().  As a result, the marker processor's
  read_markers() method called get_sof(), which started to process the
  8-bit SOF segment and set cinfo->data_precision to 8.

- Since the 8-bit SOF segment was incomplete, the end of the JPEG data
  stream was encountered when get_sof() attempted to read the image
  height, width, and number of components.

- If the fill_input_buffer() method in the application's custom source
  manager incorrectly returned FALSE in response to a prematurely-
  terminated JPEG data stream, then get_sof() returned FALSE while
  attempting to read the image height, width, and number of components
  (before the duplicate SOF check was reached.)  That caused the default
  marker processor's read_markers() method, and subsequently
  jpeg_consume_input(), to return JPEG_SUSPENDED.

- If the application failed to respond to the JPEG_SUSPENDED return
  value and subsequently attempted to call jpeg_read_scanlines(),
  then the data precision check in jpeg_read_scanlines() succeeded
  (because cinfo->data_precision was now 8.)  However, because
  cinfo->data_precision had been 12 during the previous call to
  jpeg_start_decompress(), only the 12-bit version of the main
  controller was initialized, and the cinfo->main->process_data() method
  was undefined.  Thus, a segfault occurred when jpeg_read_scanlines()
  attempted to invoke that method.

Scenarios in which the issue was thwarted:

1. The default source managers handle a prematurely-terminated JPEG data
stream by inserting a fake EOI marker into the data stream.  Thus, when
using one of those source managers, the INPUT_2BYTES() and INPUT_BYTE()
macros (which get_sof() invokes to read the image height, width, and
number of components) succeeded-- albeit with bogus data, since the fake
EOI marker was read into those fields.  The duplicate SOF check in
get_sof() then failed, generating a fatal libjpeg error.

2. When using a custom source manager that correctly returns TRUE in
response to a prematurely-terminated JPEG data stream, the
aforementioned INPUT_2BYTES() and INPUT_BYTE() macros also succeeded
(albeit with bogus data read from the previous bytes of the data
stream), and the duplicate SOF check failed.

3. If the application did not prefetch input data, or if it stopped
invoking jpeg_consume_input() when the function returned
JPEG_REACHED_SOS, then the duplicate SOF segment was not read prior to
the first call to jpeg_read_scanlines().  Thus, the data precision check
in jpeg_read_scanlines() failed.  If the application instead called
jpeg12_read_scanlines() (that is, if it properly supported multiple data
precisions), then the duplicate SOF segment was not read until the body
of jpeg_finish_decompress().  At that point, its only negative effect
was to cause jpeg_finish_decompress() to return FALSE before the
duplicate SOF check was reached.

In other words, this issue depended not only upon an incorrectly-written
source manager but also upon a very specific sequence of API calls.  It
also depended upon the multi-precision feature introduced in
libjpeg-turbo 3.0.x.  When using an 8-bit-per-sample build of
libjpeg-turbo 2.1.x, jpeg_read_header() failed with "Unsupported JPEG
data precision 12" after the 12-bit SOF segment was processed.  When
using a 12-bit-per-sample build of libjpeg-turbo 2.1.x, the behavior
was the same as if the application called jpeg12_read_scanlines() in
Scenario 3 above.

This commit simply moves the duplicate SOF check to the top of
get_sof() so the check will fail before the marker processor attempts to
read the duplicate SOF.  It should be noted that this issue isn't a
libjpeg-turbo bug per se, because it occurs only when the calling
application does something it shouldn't.  It is, rather, an issue of API
hardening/caller-proofing.
2024-05-29 10:08:24 -04:00
DRC
46173635be Remove jpeg_std_message_table[] extern sym comment
jpeg_std_message_table[] was never a documented part of the libjpeg API,
nor was it exposed in jpegint.h or the Windows libjpeg API DLL.  Thus,
it was never a good idea (nor was it even remotely necessary) for
applications to use it.  However, referring to #763 and #767, one
application (RawTherapee) did use it.
34c055851e hid the symbol, which broke the
Un*x builds of RawTherapee.  (RawTherapee already did the right thing on
Windows, because jpeg_std_message_table[] was not exposed in the
Windows libjpeg API DLL.  Referring to
https://github.com/Beep6581/RawTherapee/issues/7074, RawTherapee now
does the right thing on Un*x platforms as well.)

The comment in jerror.c indicated that Tom Lane intended the symbol to
be external "just in case any applications want to refer to it
directly."  However, with respect to libjpeg-turbo, the comment was
effectively already a lie on Windows.  My choices at this point are:

1. Revert 34c055851e and start exposing
   the symbol on Windows, thus making the comment true again.
2. Remove the comment.

Option 1 would have created whiplash, since 3.0.3 has already been
released with the symbol hidden, and that option would have further
encouraged ill-advised behavior on the part of applications.  Since the
issue has already been fixed in RawTherapee, and since it is known to
affect only that application, I chose Option 2.

In my professional opinion, a code comment does not rise to the level
of a contract between a library and a calling application.  In other
words, the comment did not make the symbol part of the API, even though
the symbol was exposed on some platforms.  Applications that use
internal symbols (even the symbols defined in jpegint.h) do so at their
own risk.  There is no guarantee that those symbols will remain
unchanged from release to release, as it is sometimes necessary to
modify the internal (opaque) structures and methods in order to
implement new features or even fix bugs.  Some implementations of the
libjpeg API (such as the one in Jpegli, for instance), do not provide
those internal symbols at all.  Best practices are for applications that
use the internal libjpeg-turbo symbols to provide their own copy of
libjpeg-turbo (for instance, via static linking), so they can manage any
unexpected changes in those symbols.  (In fact, that is how libjpeg was
originally used.  Application developers built it from source with
compile-time options to exclude unneeded functionality.  Thus, no two
builds of libjpeg were guaranteed to be API/ABI-compatible.  The idea of
a libjpeg shared library that exposes a pseudo-standard ABI came later,
and that has always been an awkward fit for an API that was intended to
be modified at compile time to suit specific application needs.
libjpeg-turbo's colorspace extensions are but one example, among many,
of our attempts to reconcile that awkwardness while preserving backward
compatibility with the aforementioned pseudo-standard ABI.)
2024-05-29 00:18:05 -04:00
DRC
9ddcae4a8f jpeglib.h: Document the need to include stdio.h
libjpeg.txt documents the need to "include system headers that define at
least the typedefs FILE and size_t" before including jpeglib.h.
However, some software developers unfortunately assume that any
downstream build failure is due to an upstream oversight (as if such an
oversight would have gone unnoticed for 14 years in a library as
ubiquitous as libjpeg-turbo) and "come in hot" with a proposal and
arguments that have already been carefully considered and rejected
multiple times (as opposed to grepping the documentation or searching
existing issues and PRs to find out whether the upstream behavior is
intentional.)

Multiple issues and PRs (including #17, #18, #116, #737, and #766) have
been filed regarding this, so this commit adds a comment to jpeglib.h in
the hope of heading off future issues and PRs.  I suspect that some
people will still choose to waste my time by arguing about it, even
though the decision was made by Tom Lane nearly 20 years before
libjpeg-turbo even existed, the decision was supportable based on the
needs of early 1990s computing systems, and reversing that decision
would break backward API compatibility (which is one of the reasons that
many downstream projects adopted libjpeg-turbo in the first place.)  At
least now, if someone posts an issue or PR about this again, I can just
link to this commit and close the issue/PR without comment.
2024-05-20 13:03:49 -04:00
DRC
bc491b16e2 ChangeLog.md: Document previous commit 2024-05-16 17:32:02 -04:00
DRC
0fc7313e54 Don't traverse linked list when saving a marker
If the calling application invokes jpeg_save_markers() to save a
particular type of marker, then the save_marker() function will be
invoked for every marker of that type that is encountered.  Previously,
only the head of the marker linked list was stored (in
jpeg_decompress_struct), so save_marker() had to traverse the entire
linked list before it could add a new marker to the tail of the list.
That caused CPU usage to grow exponentially with the number of markers.
Referring to #764, it is possible to create a JPEG image that contains
an excessive number of markers.  The specific reproducer that uncovered
this issue is a specially-crafted 1-megabyte malformed JPEG image with
tens of thousands of APP1 markers, which required approximately 30
seconds of CPU time (on a modern Intel processor) to process.  However,
it should also be possible to create a legitimate JPEG image that
reproduces the issue (such as an image with tens of thousands of
duplicate EXIF tags.)

This commit introduces a new pointer (in jpeg_decomp_master, in order to
preserve backward ABI compatibility) that is used to store the tail of
the marker linked list whenever a marker is added to it.  Thus, it is no
longer necessary to traverse the list when adding a marker, and CPU
usage will grow linearly rather than exponentially with the number of
markers.

Fixes #764
2024-05-14 14:46:33 -04:00
DRC
7fa4b5b762 jerror.c: Silence MSan uninitialized value warning
If an error manager instance is passed to jpeg_std_error(), then its
format_message() method will point to the format_message() function in
jerror.c.  The format_message() function passes all eight values from
the jpeg_error_mgr::msg_parm.i[] array as arguments to
snprintf()/_snprintf_s(), even if the format string doesn't use all of
those values.  Subsequently invoking one of the ERREXIT[1-6]() macros
will leave the unused values uninitialized, and if the
-fsanitize-memory-param-retval option (introduced in Clang 14) is
enabled (which it is by default in Clang 16 and later), then MSan will
complain when the format_message() function tries to pass the
uninitialized-but-unused values as function arguments.

This commit modifies jpeg_std_error() so that it zeroes out the error
manager instance passed to it, thus working around the warning as well
as simplifying the code.

Closes #761
2024-05-06 18:24:15 -04:00
DRC
3f43bb3320 Build: Don't use COMPONENT w/install(INCLUDES ...)
(Regression introduced by 24e09baaf0)

The install() INCLUDES option is not an artifact option.  It specifies
a list of directories that will be added to the
INTERFACE_INCLUDE_DIRECTORIES target property when the target is
exported using the install() EXPORT option, which occurs when CMake
package config files are generated.  Specifying 'COMPONENT include' with
the install() INCLUDES option caused the INTERFACE_INCLUDE_DIRECTORIES
properties in our CMake package config files to contain
'${_IMPORT_PREFIX}/COMPONENT', which caused errors of the form 'Imported
target "libjpeg-turbo::XXXX" includes non-existent path' when downstream
build systems attempted to include libjpeg-turbo using find_package().

Fixes #759
Closes #760
2024-05-06 13:38:59 -04:00
Kleis Auke Wolthuizen
24e09baaf0 Build: Add COMPONENT to all install() commands
This makes it possible for downstream packagers and other integrators of
libjpeg-turbo to include only specific directories from the
libjpeg-turbo installation (or to install specific directories under a
different prefix, etc.)  The names of the components correspond to the
directories into which they will be installed.

Refer to libvips/libvips#3931, #265, #338

Closes #756
2024-05-04 14:36:14 -04:00
DRC
6a522fcda4 jpegtran -drop: Ensure all quant tables defined
It is possible to craft a malformed JPEG image in which all of the
scans contain fewer components than the number of components specified
in the Start Of Frame (SOF) segment.  Attempting to use such an image as
either an input image or a drop image with 'jpegtran -drop' caused a
NULL dereference and subsequent segfault in transupp.c:adjust_quant(),
so this commit adds appropriate checks to guard against that.

Since the issue involved an interface that is only exposed on the
jpegtran command line, it did not represent a security risk.
'jpegtran -drop' could not ever be used successfully with images such as
the ones described above.  This commit simply makes jpegtran fail
gracefully rather than crash.

Fixes #758
2024-05-02 14:54:36 -04:00
DRC
2dfe6c0fe9 CI: Work around segfaults in ASan/MSan jobs
Referring to actions/runner-images#9491, the sanitizers in LLVM 14 that
ships with Ubuntu 22.04 are incompatible with high-entropy address space
layout randomization (ASLR), which is enabled in the GitHub runners via
their use of a newer kernel than ubuntu 22.04 uses.
2024-03-18 14:51:04 -04:00
DRC
710865cf0e Build: Don't explicitly set CMP0065 to NEW
This is no longer necessary, because of
1644bdb7d2.
2024-03-18 12:56:42 -04:00
DRC
fe218ca19c Build: Handle CMAKE_C_COMPILER_ID=AppleClang
Because of 1644bdb7d2, we are now
effectively using the NEW behavior for all CMake policies introduced in
all CMake versions up to and including CMake 3.28.  The NEW behavior for
CMP0025, introduced in CMake 3.0, sets CMAKE_C_COMPILER_ID to
"AppleClang" instead of "Clang" when using Apple's variant of Clang (in
Xcode), so we need to match all values of CMAKE_C_COMPILER_ID that
contain "Clang".

This fixes three issues:

- -O2 was not replaced with -O3 in CMAKE_C_FLAGS_RELWITHDEBINFO.  This
  was a minor issue, since -O3 is now the default in
  CMAKE_C_FLAGS_RELEASE, and we use CMAKE_BUILD_TYPE=Release in our
  official builds.

- The build system erroneously set the default value of FLOATTEST8 and
  FLOATTEST12 to no-fp-contract when compiling for PowerPC or Arm using
  Apple Clang 14+ (effectively reverting
  5b2beb4bc4f41dd9dd2a905cb931b8d5054d909b.)  Because Clang 14+ now
  enables -ffp-contract=on by default, this issue caused floating point
  test failures unless FLOATTEST8 and FLOATTEST12 were overridden.

- The build system set MD5_PPM_3x2_FLOAT_FP_CONTRACT as appropriate for
  GCC, not as appropriate for Clang (effectively reverting
  47656a082091f9c9efda054674522513f4768c6c.)  This also caused floating
  point test failures.

Fixes #753
Closes #755
2024-03-18 12:46:11 -04:00
DRC
dfde1f857d Fix (and test) more Clang 14 compiler warnings
-Woverlength-strings, -Wshift-negative-value, -Wsign-compare
2024-03-08 12:50:32 -05:00
DRC
905ec0fa01 Avoid tautological comparisons
Several TurboJPEG functions store their return value in an unsigned
long long intermediate and compare it against the maximum value of
unsigned long or size_t in order to avoid integer overflow.  However,
such comparisons are tautological (always true, i.e. redundant) unless
the size of unsigned long or size_t is less than the size of unsigned
long long.  Explicitly guarding the comparisons with #if avoids compiler
warnings with -Wtautological-constant-in-range-compare in Clang and also
makes it clear to the reader that the comparisons are only intended for
32-bit code.

Refer to #752
2024-03-08 11:52:38 -05:00
DRC
34c055851e Fix warnings with -Wmissing-variable-declarations 2024-03-06 15:17:08 -05:00
DRC
7bb958b732 12-bit: Don't gen opt Huff tbls if tbls supplied
(regression introduced by e8b40f3c2b)

The documented behavior of the libjpeg API is to compute optimal Huffman
tables when generating 12-bit lossy Huffman-coded JPEG images, unless
the calling application supplies its own Huffman tables.  However,
e8b40f3c2b and
96bc40c1b3 modified
jinit_c_master_control() so that it always set cinfo->optimize_coding to
TRUE when generarating 12-bit lossy Huffman-coded JPEG images, which
prevented calling applications from supplying custom Huffman tables for
such images.

This commit modifies jinit_c_master_control() so that it only overrides
cinfo->optimize_coding when generating 12-bit lossy Huffman-coded JPEG
images if all Huffman table slots are empty or all slots contain default
Huffman tables.  Determining whether the latter is true requires using
memcmp() to compare the allocated Huffman tables with the default
Huffman tables, because:

- The documented behavior of jpeg_set_defaults() is to initialize any
  empty Huffman table slot with the default Huffman table corresponding
  to that slot, regardless of the data precision.  There is also no
  requirement that the data precision be specified prior to calling
  jpeg_set_defaults().  Thus, there is no reliable way to prevent
  jpeg_set_defaults() from initializing empty Huffman table slots with
  default Huffman tables, which are useless for 12-bit data precision.

- There is no requirement that custom Huffman tables be defined prior to
  calling jpeg_set_defaults().  A calling application could call
  jpeg_set_defaults() and modify the values in the default Huffman
  tables rather than allocating new tables.  Thus, there is no reliable
  way to detect whether the allocated Huffman tables contain default
  values without comparing the tables with the default Huffman tables.

Fortunately, comparing the allocated Huffman tables with the default
Huffman tables is the last stop on the logic train, so it won't happen
unless cinfo->data_precision == 12, cinfo->arith_code == FALSE,
cinfo->optimize_coding == FALSE, and one or more Huffman tables are
allocated.  (If the compressor object is reused, this ensures that the
full comparison will be performed at most once.)  Custom Huffman tables
will be flagged as non-default when the first non-default value is
encountered, and the worst case (comparing 400 bytes) is very fast on
modern CPUs anyhow.

Fixes #751
2024-03-04 17:45:40 -05:00
DRC
3202feb08a x86-64 SIMD: Support CET if C compiler enables it
- Detect at configure time, via the __CET__ C preprocessor macro,
  whether the C compiler will include either indirect branch tracking
  (IBT) or shadow stack support, and define a NASM macro (__CET__) if
  so.

- Modify the x86-64 SIMD code so that it includes appropriate endbr64
  instructions (to support IBT) and an appropriate .note.gnu.property
  section (to support both IBT and shadow stack) when __CET__ is
  defined.

Closes #350
2024-02-29 16:37:30 -05:00
DRC
1335547558 x86 SIMD: Capitalize all instruction-like macros
(to improve code readability)
2024-02-29 12:18:49 -05:00
DRC
26fc07c8d1 Build: Set MSVC run-time lib based on IDE config 2024-02-08 12:03:37 -05:00
Alyssa Ross
b6ee1016ab Build: Fix tests w/ emulators that don't check CWD
While QEMU will run executables from the current working directory,
other emulators may not.  It is more reliable to pass the full
executable path to the emulator.  The add_test(NAME ... COMMAND ...)
syntax automatically invokes the emulator (e.g. the command specified
in CMAKE_CROSSCOMPILING_EMULATOR) and passes the full executable path to
it, as long as the first COMMAND argument is the name of a target.  This
cleans up the CMake code somewhat as well, since it is no longer
necessary to manually invoke CMAKE_CROSSCOMPILING_EMULATOR.

Closes #747
2024-01-30 18:26:21 -05:00
DRC
d59b1a3bce Build: Reformat lines longer than 80 columns ...
... to ensure that no function argument starts beyond the 80th column.
2024-01-30 15:40:51 -05:00
DRC
36c51dd3eb GitHub: Update checkout, AWS credentials actions
... to silence deprecation warning regarding Node.js 12 and 16 actions.
2024-01-26 15:55:19 -05:00
DRC
9ef0d03e1e LICENSE.md: zlib License clarifications
Disclaimer: I am not a lawyer, nor do I play one on TV.

Referring to #744, mentioning the zlib License as a license that applies
to libjpeg-turbo is confusing, and it isn't actually necessary, since
the IJG License subsumes the terms of the zlib License in the context of
the libjpeg API library and associated programs.  This was presumably
understood to be the case by Miyasaka-san when he chose the zlib License
for the first libjpeg SIMD extensions.  The libjpeg/SIMD web site
(https://cetus.sakura.ne.jp/softlab/jpeg-x86simd/jpegsimd.html) states
(translated from Japanese): "The terms of use of this SIMD enhanced
version of IJG JPEG software are subject to the terms of use of the
original version of IJG JPEG software."

Detailed analysis of the zlib License terms:

    This software is provided 'as-is', without any express or implied
    warranty.  In no event will the authors be held liable for any
    damages arising from the use of this software.

This text is an almost literal subset of the warranty disclaimer text in
the IJG License.  The IJG License states everything above with only
slight differences in wording, and it further clarifies that the user
assumes all risk as to the software's quality and accuracy and that
vendors of commercial products based on the software must assume all
warranty and liability claims.

    Permission is granted to anyone to use this software for any
    purpose, including commercial applications, and to alter it and
    redistribute it freely, subject to the following restrictions:

This is semantically the same as the permission text in the IJG License,
since "use, copy, modify, and distribute this software (or portions
thereof) for any purpose, without fee" covers "use" for "any purpose,
including commercial applications" as well as alteration and
redistribution.

    1. The origin of this software must not be misrepresented; you must
       not claim that you wrote the original software. If you use this
       software in a product, an acknowledgment in the product
       documentation would be appreciated but is not required.

The IJG License requirement that "If any part of the source code for
this software is distributed, then this README file must be included,
with this copyright and no-warranty notice unaltered; and any additions,
deletions, or changes to the original files must be clearly indicated in
accompanying documentation" (Clause 1), as well as the requirement that
"If only executable code is distributed, then the accompanying
documentation must state that 'this software is based in part on the
work of the Independent JPEG Group'" (Clause 2), satisfies the
requirement of Clause 1 of the zlib License.

    2. Altered source versions must be plainly marked as such, and must
       not be misrepresented as being the original software.

Since Clause 1 of the IJG License applies only to the distribution of
source code, the copyright headers in the source code are effectively
"accompanying documentation" in that case.  This is why we ensure that
the copyright headers of individual source files indicate the year(s) in
which modifications were made by each contributor.  Doing so satisfies
the requirements of both Clause 2 of the zlib License and Clause 1 of
the IJG License.

    3. This notice may not be removed or altered from any source
       distribution.

Clauses 2 and 3 of the zlib License apply only to the source code that
bears that license.  Thus, as applied to the software as a whole, those
requirements of the inbound zlib License are compatible with the
outbound IJG License as long as the IJG License does not contradict
them (which it doesn't.)

NOTE: To be clear, existing source code that bears the zlib License
cannot literally be re-licensed under the IJG License, since that would
violate Clause 3 of the zlib License.  However, when considering the
terms under which the overall library is made available, the IJG License
effectively subsumes the terms of the zlib License.
https://www.gnu.org/licenses/license-compatibility.en.html is a
thorough, albeit somewhat GPL-biased, discussion of license
compatibility.
2024-01-26 15:48:17 -05:00
DRC
7d67c3495f Build/Win: Report CMAKE_MSVC_RUNTIME_LIBRARY value
... when using CMake 3.15+
2024-01-26 10:34:04 -05:00
DRC
17df25f92c Build/Win: Eliminate MSVC run-time DLL dependency
(regression introduced by 1644bdb7d2)

Setting a maximum version in cmake_minimum_required() effectively sets
the behavior to NEW for all policies introduced in all CMake versions up
to and including that maximum version.  The NEW behavior for CMP0091,
introduced in CMake 3.15, uses CMake variables to specify the MSVC
runtime library against which to link, rather than placing the relevant
flags in CMAKE_C_FLAGS*.  Thus, replacing /MD with /MT in CMAKE_C_FLAGS*
no longer has any effect when using CMake 3.15+.
2024-01-26 09:43:58 -05:00
DRC
289df647c0 Build: Add tjdoc target for building TurboJPEG dox 2024-01-23 17:35:53 -05:00
DRC
0ef07927c3 Bump copyright year to 2024 2024-01-23 10:47:40 -05:00
DRC
1644bdb7d2 BUILD: Silence CMake 3.28.x deprecation warning
Closes #740
2024-01-22 14:33:31 -05:00
DRC
5a2353c2da GNUInstallDirs.cmake: Various improvements
- Integrate
  c07bba2730 (diff-1e2deb5301e9481203102fcddd1b2d0d2bf0ddc1cbb445c7f4b6414a3b869ce8)
  so that the default man directory is <CMAKE_INSTALL_PREFIX>/share/man
  on FreeBSD systems.

- For good measure, integrate
  f835f189ae
  so that the default info directory is
  <CMAKE_INSTALL_PREFIX>/share/info on FreeBSD systems, even though we
  don't use that directory.

- Automatically set the CMake variable type to PATH for any
  user-specified CMAKE_INSTALL_*DIR variables.

Addresses concerns raised in #326, #346, #648

Closes #648
2024-01-22 14:15:02 -05:00
DRC
335ed793f9 Assume 3-comp lossls JPEG w/o Adobe marker is RGB
libjpeg-turbo always includes Adobe APP14 markers in the lossless JPEG
images that it generates, but some compressors (e.g. accusoft PICTools
Medical) do not.

Fixes #743
2024-01-19 13:14:21 -05:00
DRC
fa2b6ea092 Eliminate duplicate copies of jpeg_nbits_table
ef9a4e05ba (libjpeg-turbo 1.4.x), which
was based on
https://bug815473.bmoattachments.org/attachment.cgi?id=692126
(https://bugzilla.mozilla.org/show_bug.cgi?id=815473), modified the C
baseline Huffman encoder so that it precomputes jpeg_nbits_table, in
order to facilitate sharing the table among multiple processes.
However, libjpeg-turbo never shared the table, and because the table was
implemented as a static array, f3a8684cd1
(libjpeg-turbo 1.5.x) and 37bae1a0e9
(libjpeg-turbo 2.0.x) each introduced a duplicate copy of the table for
(respectively) the SSE2 baseline Huffman encoder and the C progressive
Huffman encoder.

This commit does the following:
- Move the duplicated code in jchuff.c and jcphuff.c, originally
  introduced in 0cfc4c17b7 and
  37bae1a0e9, into a header
  (jpeg_nbits.h).
- Credit the co-author of 0cfc4c17b7.
  (Refer to https://sourceforge.net/p/libjpeg-turbo/patches/57).
- Modify the SSE2 baseline Huffman encoder so that the C Huffman
  encoders can share its definition of jpeg_nbits_table.
- Move the definition of jpeg_nbits_table into a C source file
  (jpeg_nbits.c) rather than a header, and define the table only if
  USE_CLZ_INTRINSIC is undefined and the SSE2 baseline Huffman encoder
  will not be built.
- Apply hidden symbol visibility to the shared definition of
  jpeg_nbits_table, if the compiler supports the necessary attribute.
  (In practice, only Visual C++ doesn't.)

Closes #114

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1501523
2024-01-16 17:33:30 -05:00
DRC
be96fa0a40 Doc: Lossless JPEG clarifications
- Clarify that lossless JPEG is slower than and doesn't compress as well
  as lossy JPEG.  (That should be obvious, because "lossy" literally
  means that data is thrown away.)
- Re-generate TurboJPEG C API documentation using Doxygen 1.9.8.
- Clarify that setting the data_precision field in jpeg_compress_struct
  to 16 requires lossless mode.
- Explain what the predictor selection value actually does.  (Refer to
  Recommendation ITU-T T.81 (1992) | ISO/IEC 10918-1:1994, Section
  H.1.2.1.)
2023-12-14 13:33:46 -05:00
DRC
abeca1f0cc Move official releases to GitHub 2023-11-30 09:36:05 -05:00
DRC
3eee0dd747 ChangeLog.md: "since" = "relative to" 2023-11-29 10:03:49 -05:00
DRC
55d342c788 TurboJPEG: Expose/extend hidden "max pixels" param
TJPARAM_MAXPIXELS was previously hidden and used only for fuzz testing,
but it is potentially useful for calling applications as well,
particularly if they want to guard against excessive memory consumption
by the tj3LoadImage*() functions.  The parameter has also been extended
to decompression and lossless transformation functions/methods, mainly
as a convenience.  (It was already possible for calling applications to
impose their own JPEG image size limits by reading the JPEG header prior
to decompressing or transforming the image.)
2023-11-16 15:36:47 -05:00
DRC
6136a9e285 Java doc: Terminology tweaks
- "function" = "method"
- "decompression and transform functions" = "decompression and transform
  operations" (for consistency with the 2.1.x documentation)
- "return an error" = "throw an error"
- "ceil()" = "Math.ceil()"
2023-11-16 14:23:39 -05:00
DRC
40419472fa SECURITY.md: Further clarify security adv. policy
Security advisories should only be filed against official releases.
2023-11-15 13:42:34 -05:00
DRC
45f018cb22 SECURITY.md: Clarify security advisories policy
Unfortunately, most of the GitHub security advisories filed against
libjpeg-turbo thus far have been the result of non-exploitable API
abuses triggered by randomly-generated test programs and accompanied by
wild claims of denials of service with no demonstrable or even probable
exploit that might cause such a DoS (assuming a service even existed
that used the API in question.)  Security advisories remain private
unless accepted, and I cannot accept them if they do not describe an
actual security issue.  Thus, it's best to steer most users toward
regular bug reports.
2023-11-15 13:20:27 -05:00
DRC
d51830473a tjexampletest.in: Fix code formatting issue
(introduced by 837e471a90)
2023-11-15 11:06:23 -05:00
DRC
8a4ce73c92 tj3Transform(): Range check transform operations 2023-11-15 11:02:42 -05:00
DRC
a27bad6552 tj3Transform(): Ensure JPEG hdr successfully read
Because of the TurboJPEG 3 API overhaul, the legacy decompression and
lossless transformation functions now wrap the new TurboJPEG 3
functions.  For performance reasons, we don't want to read the JPEG
header more than once during the same operation, so the wrapped
functions do not read the header if it has already been read by a
wrapper function.  Initially the TurboJPEG 3 functions used a state
variable to track whether the header had already been read, but
b94041390c made this more robust by using
the libjpeg global decompression state instead.  If a wrapper function
has already read the JPEG header successfully, then the global
decompression state will be DSTATE_READY, and the logic introduced in
b94041390c will prevent the header from
being read again.

A subtle issue arises because tj3DecompressHeader() does not call
jpeg_abort_decompress() if jpeg_read_header() fails.  (That is arguably
a bug, but it has existed since the very first implementation of the
function.)  Depending on the nature of the failure, this can cause
tj3DecompressHeader() to return an error code and leave the libjpeg
global decompression state set to DSTATE_INHEADER.  If a misbehaved
application ignored the error and subsequently called a TurboJPEG
decompression or lossless transformation function, then the function
would fail to read the JPEG header because the global decompression
state was greater than DSTATE_START.  In the case of the decompression
functions, this was innocuous, because jpeg_calc_output_dimensions()
and jpeg_start_decompress() both sanity check the global decompression
state.  However, it was possible for a misbehaved application to call
tj3DecompressHeader() with junk data, ignore the return value, and pass
the same junk data into tj3Transform().  Because tj3DecompressHeader()
left the global decompression state set to DSTATE_INHEADER,
tj3Transform() failed to detect the junk data (because it didn't try to
read the JPEG header), and it called jtransform_request_workspace() with
dinfo->image_width and dinfo->image_height still initialized to 0.
Because jtransform_request_workspace() does not sanity check the
decompression state, a division-by-zero error occurred with certain
combinations of transform options in which TJXOPT_TRIM or TJXOPT_CROP
was specified.  However, it should be noted that TJXOPT_TRIM and
TJXOPT_CROP cannot be expected to work properly without foreknowledge of
the JPEG source image dimensions, which cannot be gained except by
calling tj3DecompressHeader() successfully.  Thus, a calling application
is inviting trouble if it does not check the return value of
tj3DecompressHeader() and sanity check the JPEG source image dimensions
before calling tj3Transform().  This commit softens the failure, but the
failure is still due to improper API usage.
2023-11-14 19:22:43 -05:00
DRC
837e471a90 tjexample.c: Fix error when decompressing
(regression introduced by 300a344d65)

300a344d65 fixed the recompression code
path but also broke the pure decompression code path, because the fix
caused the TurboJPEG decompression instance to be destroyed before
tj3SaveImage() could use it.  Furthermore, the fix in
300a344d65 prevented pixel density
information from being transferred from the input image to the output
image when recompressing.  This commit does the following:

- Modify tjexample.c so that a single TurboJPEG instance is initialized
  for lossless transformation and shared by all code paths.  In addition
  to fixing both of the aforementioned issues, this makes the code more
  readable.

- Extend tjexampletest to test the recompression code path, thus
  ensuring that the issues fixed by this commit and
  300a344d65 are not reintroduced.

- Modify tjexample.c to remove redundant fclose(), tj3Destroy(), and
  tj3Free() calls.
2023-11-14 12:08:02 -05:00
DRC
df9dbff830 TurboJPEG: New param to limit virt array mem usage
This corresponds to max_memory_to_use in the jpeg_memory_mgr struct in
the libjpeg API, except that the TurboJPEG parameter is specified in
megabytes.  Because this is 2023 and computers with less than 1 MB of
memory are not a thing (at least not within the scope of libjpeg-turbo
support), it isn't useful to allow a limit less than 1 MB to be
specified.  Furthermore, because TurboJPEG parameters are signed
integers, if we allowed the memory limit to be specified in bytes, then
it would be impossible to specify a limit larger than 2 GB on 64-bit
machines.  Because max_memory_to_use is a long signed integer,
effectively we can specify a limit of up to 2 petabytes on 64-bit
machines if the TurboJPEG parameter is specified in megabytes.  (2 PB
should be enough for anybody, right?)

This commit also bumps the TurboJPEG API version to 3.0.1.  Since the
TurboJPEG API version no longer tracks the libjpeg-turbo version, it
makes sense to increment the API revision number when adding constants,
to increment the minor version number when adding functions, and to
increment the major version number for a complete overhaul.

This commit also removes the vestigial TJ_NUMPARAM macro, which was
never defined because it proved unnecessary.

Partially implements #735
2023-11-14 10:19:06 -05:00
DRC
bf248a5093 tj3Compress*(): Free virt arrays if mem limit hit
This is very subtle, but if a user specifies a libjpeg virtual array
memory limit via the JPEGMEM environment variable and one of the
tj3Compress*() functions hits that limit, the libjpeg error handler
will be invoked in jpeg_start_compress() (more specifically in
realize_virt_arrays() in jinit_compress_master()) before the libjpeg
global compression state can be incremented.  Thus,
jpeg_abort_compress() will not be called before the tj3Compress*()
function exits, the unrealized virtual arrays will not be freed, and if
the TurboJPEG compression instance is reused, those unrealized virtual
arrays will count against the specified memory limit.  This could cause
subsequent compression operations that require smaller virtual arrays
(or even no virtual arrays at all) to fail when they would otherwise
succeed.  In reality, the vast majority of calling programs would abort
and free the TurboJPEG compression instance if one of the tj3Compress*()
functions failed, but TJBench is a rare exception.  This issue does not
bear documenting because of its subtlety and rarity and because JPEGMEM
is not a documented feature of the TurboJPEG API.

Note that the issue does not exist in the tj3Encode*() and tj3Decode*()
functions, because realize_virt_arrays() is never called in the body of
those functions.  The issue also does not exist in the tj3Decompress*()
and tj3Transform() functions, because those functions ensure that the
JPEG header is read (and thus the libjpeg global decompression state is
incremented) prior to calling a function that calls
realize_virt_arrays() (i.e. jpeg_start_decompress() or
jpeg_read_coefficients().)  If realize_virt_arrays() failed in the body
of jpeg_write_coefficients(), then tj3Transform() would abort without
calling jpeg_abort_compress().  However, since jpeg_start_compress() is
never called in the body of tj3Transform(), no virtual arrays are ever
requested from the compression object, so failing to call
jpeg_abort_compress() would be innocuous.
2023-11-11 15:59:09 -05:00
DRC
220bd76188 turbojpeg.h: Fix broken refs in API documentation
"TJPARAM_DENSITYUNIT" should be "TJPARAM_DENSITYUNITS" (oops.)
2023-11-10 11:08:22 -05:00
DRC
cbdc20fbf4 example.c: Remove comments regarding temp files
Those comments could be confusing to new libjpeg-turbo users, and the
same information already exists in libjpeg.txt and structure.txt.
2023-11-08 11:43:58 -05:00
DRC
7c61794faf jmemsys.h: Remove unused MS-DOS/Mac mem. mgr. code
Those obsolete memory managers have never been included in
libjpeg-turbo, nor has libjpeg-turbo ever claimed to support MS-DOS
or Mac operating systems prior to OS X 10.4 "Tiger."  Note that we
retain the ability to use temp files, even though libjpeg-turbo does
not use them.  This allows downstream implementations to write their own
memory managers that use temp files, if necessary.
2023-11-08 11:16:14 -05:00
DRC
78eaf0d46d tj3*YUV8(): Fix int overflow w/ huge row alignment
If the align parameter was set to an unreasonably large value, such as
0x2000000, strides[0] * ph0 and strides[1] * ph1 could have overflowed
the int datatype and wrapped around when computing (src|dst)Planes[1]
and (src|dst)Planes[2] (respectively.)  This would have caused
(src|dst)Planes[1] and (src|dst)Planes[2] to point to lower addresses in
the YUV buffer than expected, so the worst case would have been a
visually incorrect output image, not a buffer overrun or other
exploitable issue.
2023-11-07 15:39:16 -05:00
DRC
0e2d289fab Bump version to 3.0.2 to prepare for new commits 2023-11-07 12:38:05 -05:00
Kornel
6c9f0897af MozJPEG 4.1.5 2023-10-12 17:52:31 +01:00
DRC
ec32420f6b example.c: Fix 12-bit PPM write w/ big endian CPUs 2023-10-11 16:11:45 -04:00
DRC
5b2beb4bc4 Build: Set FLOATTEST* by default for AArch64, PPC
Because of 47656a0820, we can now
reliably determine the correct default values for FLOATTEST8 and
FLOATTEST12 when using Clang or GCC to build for AArch64 or PowerPC
platforms.  (Testing confirms that this is the case with GCC 5-13 and
Clang 5-14 on Ubuntu/AArch64, GCC 4 on CentOS 7/PPC, and GCC 8-10 and
Clang 6-12 on Ubuntu/PPCLE.)  Other CPU architectures and compilers can
be added on a case-by-case basis as they are tested.
2023-10-11 16:11:36 -04:00
DRC
da48edfc49 jchuff.c: Fix uninit read w/ AArch64, WITH_SIMD=0
Because of bf01ed2fbc, the simd field in
huff_entropy_encoder (and, by extension, the simd field in
savable_state) is only initialized if WITH_SIMD is defined.  Due to an
oversight, the simd field in savable_state was queried in flush_bits()
regardless of whether WITH_SIMD was defined.  In most cases, both
branches of the query have identical code, and the optimizer removes the
branch.  However, because the legacy Neon GAS Huffman encoder uses the
older bit buffer logic from libjpeg-turbo 2.0.x and prior (refer to
087c29e07f), the branches do not have
identical code when building for AArch64 with NEON_INTRINSICS undefined
(which will be the case if WITH_SIMD is undefined.)  Thus, if
libjpeg-turbo was built for AArch64 with the SIMD extensions disabled
at build time, it was possible for the Neon GAS branch in flush_bits()
to be taken, which would have set put_bits to a value that is incorrect
for the C Huffman encoder.  Referring to #728, a user reported that this
issue sometimes caused libjpeg-turbo to generate bogus JPEG images if it
was built for AArch64 without SIMD extensions and subsequently used
through the Qt framework.  (It should be noted, however, that disabling
the SIMD extensions in AArch64 builds of libjpeg-turbo is inadvisable
for performance reasons.)

I was unable to reproduce the issue on Linux/AArch64 using libjpeg-turbo
alone, despite testing various versions of GCC and Clang and various
optimization levels.  However, the issue is reproducible using MSan with
-O0, so this commit also modifies the GitHub Actions workflow so that
compiler optimization is disabled in the linux-msan job.  That should
prevent the issue or similar issues from re-emerging.

Fixes #728
2023-10-10 14:58:34 -04:00
DRC
3d1d68cf96 README.md: Mention 4:4:0 math. incomp. vs. jpeg-6b
libjpeg-turbo implements 4:4:0 "fancy" (smooth) upsampling, which is
enabled by default when decompressing JPEG images that use 4:4:0
chrominance subsampling.  libjpeg did not and does not implement fancy
4:4:0 upsampling.
2023-10-04 13:20:38 -04:00
DRC
2c97a1ff07 GitHub: Use Ubuntu 20.04 runner for x32 build/test
The Ubuntu 22.04 kernel no longer supports the x32 ABI.
2023-10-03 12:08:31 -04:00
DRC
47656a0820 Test: Fix float test errors w/ Clang & fp-contract
The MD5 sums associated with FLOATTEST8=fp-contract and
FLOATTEST12=fp-contract are appropriate for GCC (tested v5 through v13)
with -ffp-contract=fast, which is the default when compiling for an
architecture that has fused multiply-add (FMA) instructions.  However,
different MD5 sums are needed for Clang (tested v5 through v14) with
-ffp-contract=on, which is now the default in Clang 14 when compiling
for an architecture that has FMA instructions.

Refer to #705, #709, #710
2023-10-03 11:28:21 -04:00
Kornel
0c6302e086 Merge remote-tracking branch 'libjpeg-turbo/2.1.x' into HEAD
* libjpeg-turbo/2.1.x:
  ChangeLog.md: List CVE ID fixed by ccaba5d7
  jpeglib.h: Document that JCS_RGB565 is decomp-only
  Fix block smoothing w/vert.-subsampled prog. JPEGs
2023-09-23 22:31:18 +01:00
DRC
4ae5d3dac5 ChangeLog.md: List CVE ID fixed by ccaba5d7
Closes #724
2023-09-14 17:23:13 -04:00
DRC
c0412b56d6 ChangeLog.md: List CVE ID fixed by ccaba5d7
Closes #724
2023-09-14 17:20:37 -04:00
DRC
7722c54c63 jpeglib.h: Document that JCS_RGB565 is decomp-only
Closes #723
2023-09-11 12:47:39 -04:00
DRC
f3c7116eaf jpeglib.h: Document that JCS_RGB565 is decomp-only
Closes #723
2023-09-11 12:46:13 -04:00
Kornel
61e03cc6b2 Fix #220 2023-09-04 15:58:41 +01:00
Kornel
3a691f41f9 Merge commit 'eadd243'
# By DRC
# Via DRC
* commit 'eadd243':
  Fix interblock smoothing with narrow prog. JPEGs
  jchuff.c/flush_bits(): Guard against free_bits < 0
  jchuff.c/flush_bits(): Guard against put_bits < 0
  Restore xform fuzzer behavior from before 19f9d8f0
  xform fuzz: Use src subsamp to calc dst buf size
  Doc: Mention that we are a JPEG ref implementation
  jchuff.c: Test for out-of-range coefficients
  turbojpeg.h: Make customFilter() proto match doc
  ChangeLog.md: Fix typo
  tjTransform(): Calc dst buf size from xformed dims
  Fix build warnings/errs w/ -DNO_GETENV/-DNO_PUTENV
  GitHub: Fix x32 build
  tjexample.c: Prevent integer overflow
  jpeg_crop_scanline: Fix calc w/sclg + 2x4,4x2 samp
  Decomp: Don't enable 2-pass color quant w/ RGB565
  TJBench: w/JPEG input imgs, set min tile= MCU size
  Bump version to 2.1.6 to prepare for new commits
  GitHub: Add pull request template
  Build: Clarify CMAKE_OSX_ARCHITECTURES error
  Build: Fail if included with add_subdirectory()

# Conflicts:
#	.github/workflows/build.yml
#	CMakeLists.txt
#	README.md
#	release/deb-control.in
2023-08-26 21:52:39 +01:00
Kornel
3bd754ee68 Merge tag '2.1.5.1'
# By DRC
# Via DRC
* tag '2.1.5.1':
  ChangeLog.md: Document d743a2c1
  OSS-Fuzz: Bail out immediately on decomp failure
  SIMD/x86: Initialize simd_support before every use
  Build: Define THREAD_LOCAL even if !WITH_TURBOJPEG

# Conflicts:
#	CMakeLists.txt
2023-08-26 21:49:51 +01:00
DRC
a9d87361c8 Fix block smoothing w/vert.-subsampled prog. JPEGs
The 5x5 interblock smoothing implementation, introduced in libjpeg-turbo
2.1, improperly extended the logic from the traditional 3x3 smoothing
implementation.  Both implementations point prev_block_row and
next_block_row to the current block row when processing, respectively,
the first and the last block row in the image:

  if (block_row > 0 || cinfo->output_iMCU_row > 0)
    prev_block_row =
      buffer[block_row - 1] + cinfo->master->first_MCU_col[ci];
  else
    prev_block_row = buffer_ptr;

  if (block_row < block_rows - 1 ||
      cinfo->output_iMCU_row < last_iMCU_row)
    next_block_row =
      buffer[block_row + 1] + cinfo->master->first_MCU_col[ci];
  else
    next_block_row = buffer_ptr;

6d91e950c8 naively extended that logic to
accommodate a 5x5 smoothing window:

  if (block_row > 1 || cinfo->output_iMCU_row > 1)
    prev_prev_block_row =
      buffer[block_row - 2] + cinfo->master->first_MCU_col[ci];
  else
    prev_prev_block_row = prev_block_row;

  if (block_row < block_rows - 2 ||
      cinfo->output_iMCU_row + 1 < last_iMCU_row)
    next_next_block_row =
      buffer[block_row + 2] + cinfo->master->first_MCU_col[ci];
  else
    next_next_block_row = next_block_row;

However, this new logic was only correct if block_rows == 1, so the
values of prev_prev_block_row and next_next_block_row were incorrect
when processing, respectively, the second and second to last iMCU rows
in a vertically-subsampled progressive JPEG image.

The intent was to:
- point prev_block_row to the current block row when processing the
  first block row in the image,
- point prev_prev_block_row to prev_block_row when processing the first
  two block rows in the image,
- point next_block_row to the current block row when processing the
  last block row in the image, and
- point next_next_block_row to next_block_row when processing the last
  two block rows in the image.

This commit modifies decompress_smooth_data() so that it computes the
current block row's position relative to the whole image and sets
the block row pointers based on that value.

This commit also restores a line of code that was accidentally deleted
by 6d91e950c8:

  access_rows += compptr->v_samp_factor; /* prior iMCU row too */

access_rows is merely a sanity check that tells the access_virt_barray()
method to generate an error if accessing the specified number of rows
would cause a buffer overrun.  Essentially, it is a belt-and-suspenders
measure to ensure that j*init_d_coef_controller() allocated enough rows
for the full-image virtual array.  Thus, excluding that line of code did
not cause an observable issue.

This commit also documents eadd2436ee in
the change log.

Fixes #721
2023-08-15 15:40:37 -04:00
DRC
9b704f96b2 Fix block smoothing w/vert.-subsampled prog. JPEGs
The 5x5 interblock smoothing implementation, introduced in libjpeg-turbo
2.1, improperly extended the logic from the traditional 3x3 smoothing
implementation.  Both implementations point prev_block_row and
next_block_row to the current block row when processing, respectively,
the first and the last block row in the image:

  if (block_row > 0 || cinfo->output_iMCU_row > 0)
    prev_block_row =
      buffer[block_row - 1] + cinfo->master->first_MCU_col[ci];
  else
    prev_block_row = buffer_ptr;

  if (block_row < block_rows - 1 ||
      cinfo->output_iMCU_row < last_iMCU_row)
    next_block_row =
      buffer[block_row + 1] + cinfo->master->first_MCU_col[ci];
  else
    next_block_row = buffer_ptr;

6d91e950c8 naively extended that logic to
accommodate a 5x5 smoothing window:

  if (block_row > 1 || cinfo->output_iMCU_row > 1)
    prev_prev_block_row =
      buffer[block_row - 2] + cinfo->master->first_MCU_col[ci];
  else
    prev_prev_block_row = prev_block_row;

  if (block_row < block_rows - 2 ||
      cinfo->output_iMCU_row + 1 < last_iMCU_row)
    next_next_block_row =
      buffer[block_row + 2] + cinfo->master->first_MCU_col[ci];
  else
    next_next_block_row = next_block_row;

However, this new logic was only correct if block_rows == 1, so the
values of prev_prev_block_row and next_next_block_row were incorrect
when processing, respectively, the second and second to last iMCU rows
in a vertically-subsampled progressive JPEG image.

The intent was to:
- point prev_block_row to the current block row when processing the
  first block row in the image,
- point prev_prev_block_row to prev_block_row when processing the first
  two block rows in the image,
- point next_block_row to the current block row when processing the
  last block row in the image, and
- point next_next_block_row to next_block_row when processing the last
  two block rows in the image.

This commit modifies decompress_smooth_data() so that it computes the
current block row's position relative to the whole image and sets
the block row pointers based on that value.

This commit also restores a line of code that was accidentally deleted
by 6d91e950c8:

  access_rows += compptr->v_samp_factor; /* prior iMCU row too */

access_rows is merely a sanity check that tells the access_virt_barray()
method to generate an error if accessing the specified number of rows
would cause a buffer overrun.  Essentially, it is a belt-and-suspenders
measure to ensure that j*init_d_coef_controller() allocated enough rows
for the full-image virtual array.  Thus, excluding that line of code did
not cause an observable issue.

This commit also documents dbae59281f in
the change log.

Fixes #721
2023-08-15 15:21:29 -04:00
DRC
7b844bfda6 x86-64 SIMD: Use std stack frame/prologue/epilogue
This allows debuggers and profilers to reliably capture backtraces from
within the x86-64 SIMD functions.

In places where rbp was previously used to access temporary variables
(after stack alignment), we now use r15 and save/restore it accordingly.
The total amount of work is approximately the same, because the previous
code pushed the pre-alignment stack pointer to the aligned stack.  The
new prologue and epilogue actually have fewer instructions.

Also note that the {un}collect_args macros now use rbp instead of rax to
access arguments passed on the stack, so we save a few instructions
there as well.

Based on:
debcc7c3b4

Closes #707
Closes #708
2023-08-08 12:33:06 -04:00
DRC
e17fa3a271 Bump version to 3.0.1 to prepare for new commits 2023-08-08 11:28:12 -04:00
DRC
eadd2436ee Fix interblock smoothing with narrow prog. JPEGs
Due to an oversight, the assignment of DC05, DC10, DC15, DC20, and DC25
(the right edge coefficients in the 5x5 interblock smoothing window) in
decompress_smooth_data() was incorrect for images exactly two MCU blocks
wide.  For such images, DC04, DC09, DC14, DC19, and DC24 were assigned
values based on the last MCU column, but DC05, DC10, DC15, DC20, and
DC25 were assigned values based on the first MCU column (because
block_num + 1 was never less than last_block_column.)  This commit
modifies jdcoefct.c so that, for images at least two MCU blocks wide,
DC05, DC10, DC15, DC20, and DC25 are assigned the same values as DC04,
DC09, DC14, DC19, and DC24 (respectively.)  DC05, DC10, DC15, DC20, and
DC25 are then immediately overwritten for images more than two MCU
blocks wide.

Since this issue was minor and not likely obvious to an end user, the
fix is undocumented.

Fixes #700
2023-08-03 16:07:54 -04:00
DRC
dbae59281f Fix interblock smoothing with narrow prog. JPEGs
Due to an oversight, the assignment of DC05, DC10, DC15, DC20, and DC25
(the right edge coefficients in the 5x5 interblock smoothing window) in
decompress_smooth_data() was incorrect for images exactly two MCU blocks
wide.  For such images, DC04, DC09, DC14, DC19, and DC24 were assigned
values based on the last MCU column, but DC05, DC10, DC15, DC20, and
DC25 were assigned values based on the first MCU column (because
block_num + 1 was never less than last_block_column.)  This commit
modifies jdcoefct.c so that, for images at least two MCU blocks wide,
DC05, DC10, DC15, DC20, and DC25 are assigned the same values as DC04,
DC09, DC14, DC19, and DC24 (respectively.)  DC05, DC10, DC15, DC20, and
DC25 are then immediately overwritten for images more than two MCU
blocks wide.

Since this issue was minor and not likely obvious to an end user, the
fix is undocumented.

Fixes #700
2023-08-03 15:43:46 -04:00
DRC
300a344d65 tjexample.c: Fix error when recompressing
(regression introduced by fc01f4673b)

Because of the TurboJPEG 3 API overhaul, the pure compression code path
in tjexample.c now creates a TurboJPEG compression instance prior to
calling tj3LoadImage().  However, due to an oversight, a compression
instance was no longer created in the recompression code path.  Thus,
that code path attempted to reuse the TurboJPEG decompression instance,
which caused an error ("tj3Set(): TJPARAM_QUALITY is not applicable to
decompression instances.")  This commit modifies tjexample.c so that the
recompression code path creates a new TurboJPEG compression instance if
one has not already been created.

Fixes #716
2023-07-30 11:20:39 -04:00
DRC
21f5688aa4 jchuff.c/flush_bits(): Guard against free_bits < 0
This fixes a buffer overrun, reported by OSS-Fuzz, that occurred when
attempting to transform a specially-crafted malformed arithmetic-coded
JPEG image into a baseline Huffman-coded JPEG destination image with
default Huffman tables.  This issue probably had a similar root cause to
the issue fixed in 31a301389b, but in this
case, the issue only occurred with the SIMD baseline Huffman encoder in
libjpeg-turbo 2.1.x and 2.0.x.  It was not reproducible in 3.0.x or when
using the C baseline Huffman encoder.  (NOTE: In order to reproduce the
issue with 2.1.x, it was necessary to revert
58cee6d90cd616c86fae142891b987c289ea055a.)
2023-07-25 17:40:35 -04:00
DRC
ebca79d508 xform fuzz: Test optimized baseline entropy coding
Because of d011622f4b, optimized baseline
entropy coding wasn't actually being tested.
2023-07-25 16:47:44 -04:00
DRC
63bd71885f Build: Unset FLOATTEST* by default for non-x86
Because libjpeg-turbo 3.0.x now supports multiple data precisions in the
same build, the regression test system can test the 8-bit and 12-bit
floating point DCT/IDCT algorithms separately.  The expected MD5 sums
for those tests are communicated to the test system using the FLOATTEST8
and FLOATTEST12 CMake variables.  Whereas it is possible to
intelligently set a default value for FLOATTEST8 when building for
x86[-64] and a default value for FLOATTEST12 when building for x86-64,
it is not possible with other architectures.  (Refer to #705, #709,
and #710.)  Clang 14, for example, now enables FMA (fused multiply-add)
instructions by default on architectures that support them, but with
AArch64 builds, the results are not the same as when using GCC/AArch64
with FMA instructions enabled.  Thus, setting FLOATTEST12=fp-contract
doesn't make the tests pass.  It was already impossible to intelligently
set a default for FLOATTEST8 with i386 builds, but referring to #710,
that appears to be the case with other non-x86-64 builds as well.

Back in 1991, when Tom Lane first released libjpeg, some CPUs had
floating point units and some didn't.  It could take minutes to compress
or decompress a 1-megapixel JPEG image using the "slow" integer DCT/IDCT
algorithms, and the floating point algorithms were significantly faster
on systems that had an FPU.  On systems without FPUs, floating point
math was emulated and really slow, so Tom also developed "fast" integer
DCT/IDCT algorithms to speed up JPEG performance, at the expense of
accuracy, on those systems.  Because of libjpeg-turbo's SIMD extensions,
the floating point algorithms are now significantly slower than the
"slow" integer algorithms without being significantly more accurate, and
the "fast" integer algorithms fail the ISO/ITU-T conformance tests
without being any faster than the "slow" integer algorithms on x86
systems.  Thus, the floating point and "fast" integer algorithms are
considered legacy features.

In order for the floating point regression tests to be useful, the
results of the tests must be validated against an independent metric.
(In other words, it wouldn't be useful to use the floating point
DCT/IDCT algorithms to determine the expected results of the floating
point DCT/IDCT algorithms.)  In the past, I attempted without success to
develop a low-level floating point test that would run at configure time
and determine the appropriate default value of FLOATTEST*.  Barring that
approach, the only other possibilities would be:

1. Develop a test framework that compares the floating point results
with a margin of error, as TJUnitTest does.  However, that effort isn't
justified unless it could also benefit non-legacy features.

2. Compare the floating point results against an expected MD5 sum, as we
currently do.  However, as previously described, it isn't possible in
most cases to determine an appropriate default value for the expected
MD5 sum.

For the moment, it makes the most sense to disable the 8-bit floating
point tests by default except with x86[-64] builds and to disable the
12-bit floating point tests by default except with x86-64 builds.  That
means that the floating point algorithms will still be regression tested
when performing x86[-64] builds, but other types of builds will have to
opt in to the same regression tests.  Since the floating point DCT/IDCT
algorithms are unlikely to change ever again (the only reason they still
exist at all is to maintain backward compatibility with libjpeg), this
seems like a reasonable tradeoff.
2023-07-25 13:38:52 -04:00
DRC
d6914b6b1e CMakeLists.txt: Fix comment buglet 2023-07-24 16:41:18 -04:00
DRC
041c80a42e jchuff.c/flush_bits(): Guard against put_bits < 0
This fixes a UBSan negative shift warning, reported by OSS-Fuzz, that
occurred when attempting to transform a specially-crafted malformed
arithmetic-coded JPEG image into a baseline Huffman-coded JPEG
destination image with default Huffman tables.  This issue probably
had a similar root cause to the issue fixed in
31a301389b, but in this case, the issue
only occurred with the SIMD baseline Huffman encoder in libjpeg-turbo
2.1.x.  It was not reproducible in 2.0.x or 3.0.x or when using the
C baseline Huffman encoder.
2023-07-12 14:16:13 -04:00
DRC
e429e379b0 tjunittest.c: Use _getpid() on Windows 2023-07-06 16:58:20 -04:00
DRC
035ea386d1 Build: Fix regression test concurrency issues
- The example-*bit-*-decompress test must run after the
  example-*bit-*-compress test, since the latter generates
  testout*-example.jpg.

- Add -static to the filenames of all output files generated by the
  "static" regression tests, to avoid conflicts with the "shared"
  regression tests.

- Add the PID to the filenames of all files generated by the tjunittest
  packed-pixel image I/O tests.

- Check the return value of MD5File() in tjunittest to avoid a segfault
  if the file doesn't exist.  (Prior to the fix described above, that
  could occur if two instances of tjunittest ran concurrently from the
  same directory with the same -bmp and -precision arguments.)

Fixes #705
2023-07-06 14:08:07 -04:00
DRC
d011622f4b Restore xform fuzzer behavior from before c8d52f1c
The intent was for the final transform operation to be the same as the
first transform operation but without TJXOPT_COPYNONE or
TJPARAM_NOREALLOC.  Unrolling the transform operations in
c8d52f1c4c accidentally changed that.
2023-07-06 10:56:34 -04:00
DRC
58cee6d90c Restore xform fuzzer behavior from before 19f9d8f0
The intent was for the final transform operation to be the same as the
first transform operation but without TJXOPT_COPYNONE or
TJFLAG_NOREALLOC.  Unrolling the transform operations in
19f9d8f0fd accidentally changed that.
2023-07-06 10:29:27 -04:00
DRC
f48f73d4ec xform fuzz: Use src subsamp to calc dst buf size
Referring to
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60379
there are some specially-crafted malformed JPEG images that, when
transformed to grayscale, will exceed the worst-case transformed
grayscale JPEG image size.  This is similar in nature to the issue fixed
by 19f9d8f0fd, except that in this case,
the issue occurs regardless of the amount of metadata in the source
image.  Also, the tjTransform() function, the
Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function,
and TJBench were behaving correctly in this case, because the TurboJPEG
API documentation specifies that the source image's subsampling type
should be used when computing the worst-case transformed JPEG image
size.  (However, only the Java API documentation specified that.  Oops.
The C API documentation now does as well.)  The documented usage
mitigates the issue, and only the transform fuzzer did not adhere to
that.  Thus, this was an issue with the fuzzer itself rather than an
issue with the library.
2023-07-06 09:10:30 -04:00
DRC
895287572d xform fuzz: Use src subsamp to calc dst buf size
Referring to
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60379
there are some specially-crafted malformed JPEG images that, when
transformed to grayscale, will exceed the worst-case transformed
grayscale JPEG image size.  This is similar in nature to the issue fixed
by c8d52f1c4c, except that in this case,
the issue occurs regardless of the amount of metadata in the source
image.  Also, the tj3Transform() function, the
Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function,
and TJBench were behaving correctly in this case, because the TurboJPEG
API documentation specifies that the source image's subsampling type
should be used when computing the worst-case transformed JPEG image
size.  (However, only the Java API documentation specified that.  Oops.
The C API documentation now does as well.)  The documented usage
mitigates the issue, and only the transform fuzzer did not adhere to
that.  Thus, this was an issue with the fuzzer itself rather than an
issue with the library.
2023-07-06 08:48:40 -04:00
DRC
30c21e559d OSS-Fuzz: Ignore tj3DecompressHeader() return val
Unlike its predecessors, tj3DecompressHeader() does not fail if passed
a JPEG image with an unknown subsampling type.  This led me to believe
that it was OK for the fuzzers to abort if tj3DecompressHeader()
returned an error.  However, there are apparently some malformed JPEG
images that can expose issues in libjpeg-turbo while also causing
tj3DecompressHeader() to complain about header errors.  Thus, it is best
to ignore the return value of tj3DecompressHeader(), as the fuzzers in
libjpeg-turbo 2.1.x and prior did.
2023-07-05 16:13:34 -04:00
DRC
926f1f3daf README.md: Include GitHub Sponsors link/button
Closes #706
2023-07-05 12:43:22 -04:00
DRC
383286702c Doc: Mention that we are a JPEG ref implementation 2023-07-05 10:57:48 -04:00
DRC
762f8b4f21 Doc: Mention that we are a JPEG ref implementation 2023-07-05 10:56:42 -04:00
DRC
6c87537f60 AppVeyor: Use SignPath release cert/only sign tags
The SignPath release certificate for our project is not yet available as
of this writing, but this commit prepares the CI system to use the
release certificate whenever it becomes available.  It also restricts
signing only to tags, which correspond to official releases.  (That
mimics our traditional policy of not signing pre-release builds.)
2023-07-03 10:31:35 -04:00
DRC
31a301389b jchuff.c: Test for out-of-range coefficients
Restore two coefficient range checks from libjpeg to the C baseline
Huffman encoder.  This fixes an issue
(https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60253) whereby
the encoder could read from uninitialized memory when attempting to
transform a specially-crafted malformed arithmetic-coded JPEG source
image into a baseline Huffman-coded JPEG destination image with default
Huffman tables.  More specifically, the out-of-range coefficients caused
r to equal 256, which overflowed the actbl->ehufsi[] array.  Because the
overflow was contained within the huff_entropy_encoder structure, this
issue was not exploitable (nor was it observable at all on x86 or Arm
CPUs unless JSIMD_NOHUFFENC=1 or JSIMD_FORCENONE=1 was set in the
environment or unless libjpeg-turbo was built with WITH_SIMD=0.)

The fix is performance-neutral (+/- 1-2%) for x86-64 code and causes a
0-4% (avg. 1-2%, +/- 1-2%) compression regression for i386 code on Intel
CPUs when the C baseline Huffman encoder is used (JSIMD_NOHUFFENC=1).
The fix is performance-neutral (+/- 1-2%) on Intel CPUs when all of the
libjpeg-turbo SIMD extensions are disabled (JSIMD_FORCENONE=1).  The fix
causes a 0-2% (avg. <1%, +/- 1%) compression regression for PowerPC
code.
2023-07-01 08:20:38 -04:00
DRC
02b074fd90 xform fuzz: Use only xform opts to set entropy alg
This is subtle, but the tj3DecompressHeader() function sets the values
of TJPARAM_ARITHMETIC, TJPARAM_OPTIMIZE, and TJPARAM_PROGRESSIVE.
Unless we unset those values, the entropy algorithm used in the
transformed JPEG image will be determined by the union of the parameter
values and the transform options, which isn't what we want.
2023-07-01 08:14:44 -04:00
DRC
e0c53aa38f jchuff.c: Test for out-of-range coefficients
Restore two coefficient range checks from libjpeg to the C baseline
Huffman encoder.  This fixes an issue
(https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60253) whereby
the encoder could read from uninitialized memory when attempting to
transform a specially-crafted malformed arithmetic-coded JPEG source
image into a baseline Huffman-coded JPEG destination image with default
Huffman tables.  More specifically, the out-of-range coefficients caused
r to equal 256, which overflowed the actbl->ehufsi[] array.  Because the
overflow was contained within the huff_entropy_encoder structure, this
issue was not exploitable (nor was it observable at all on x86 or Arm
CPUs unless JSIMD_NOHUFFENC=1 or JSIMD_FORCENONE=1 was set in the
environment or unless libjpeg-turbo was built with WITH_SIMD=0.)

The fix is performance-neutral (+/- 1-2%) for x86-64 code and causes a
0-4% (avg. 1-2%, +/- 1-2%) compression regression for i386 code on Intel
CPUs when the C baseline Huffman encoder is used (JSIMD_NOHUFFENC=1).
The fix is performance-neutral (+/- 1-2%) on Intel CPUs when all of the
libjpeg-turbo SIMD extensions are disabled (JSIMD_FORCENONE=1).  The fix
causes a 0-2% (avg. <1%, +/- 1%) compression regression for PowerPC
code.
2023-07-01 07:56:50 -04:00
DRC
369b84a4ee turbojpeg.h: Make customFilter() proto match doc 2023-06-30 10:20:20 -04:00
DRC
4a831d6e48 turbojpeg.h: Make customFilter() proto match doc
Closes #704
2023-06-30 10:15:40 -04:00
DRC
53aafa949a ChangeLog.md: Fix typo 2023-06-29 17:45:21 -04:00
DRC
240a5a5cbb ChangeLog.md: Fix typo 2023-06-29 17:45:07 -04:00
DRC
7173889223 djpeg: Fix -map option with 12-bit data precision 2023-06-29 16:36:43 -04:00
DRC
bf9f319cb4 Disallow color quantization with lossless decomp
Color quantization is a legacy feature that serves little or no purpose
with lossless JPEG images.  9f756bc67a
eliminated interaction issues between the lossless decompressor and the
color quantizers related to out-of-range 12-bit samples, but referring
to #701, other interaction issues apparently still exist.  Such issues
are likely, given the fact that the color quantizers were not designed
with lossless decompression in mind.

This commit reverts 9f756bc67a, since the
issues it fixed are no longer relevant because of this commit and
2192560d74.

Fixed #672
Fixes #673
Fixes #674
Fixes #676
Fixes #677
Fixes #678
Fixes #679
Fixes #681
Fixes #683
Fixes #701
2023-06-29 16:36:29 -04:00
DRC
19f9d8f0fd tjTransform(): Calc dst buf size from xformed dims
When used with TJFLAG_NOREALLOC and with TJXOP_TRANSPOSE,
TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270, tjTransform()
incorrectly based the destination buffer size for a transform on the
source image dimensions rather than the transformed image dimensions.
This was apparently a long-standing bug that had existed in the
tjTransform() function since its inception.  As initially implemented in
the evolving libjpeg-turbo v1.2 code base, tjTransform() required
dstSizes[i] to be set regardless of whether TJFLAG_NOREALLOC was set.
ff78e37595, which was introduced later in
the evolving libjpeg-turbo v1.2 code base, removed that requirement and
planted the seed for the bug.  However, the bug was not activated until
9b49f0e4c7 was introduced still later in
the evolving libjpeg-turbo v1.2 code base, adding a subsampling type
argument to the (new at the time) tjBufSize() function and thus making
the width and height arguments no longer commutative.

The bug opened up the possibility that a JPEG source image could cause
tjTransform() to overflow the destination buffer for a transform if all
of the following were true:
- The JPEG source image used 4:2:2, 4:4:0, or 4:1:1 subsampling.  (These
  are the only supported subsampling types for which the width and
  height arguments to tjBufSize() are not commutative.)
- The width and height of the JPEG source image were such that
  tjBufSize(height, width, subsamplingType) returned a smaller value
  than tjBufSize(width, height, subsamplingType).
- The JPEG source image contained enough metadata that the size of the
  transformed image was larger than
  tjBufSize(height, width, subsamplingType).
- TJFLAG_NOREALLOC was set.
- TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270 was
  used.
- TJXOPT_COPYNONE was not set.
- TJXOPT_CROP was not set.
- The calling program allocated
  tjBufSize(height, width, subsamplingType) bytes for the
  destination buffer, as the API documentation instructs.

The API documentation cautions that JPEG source images containing a
large amount of extraneous metadata (EXIF, IPTC, ICC, etc.) cannot
reliably be transformed if TJFLAG_NOREALLOC is set and TJXOPT_COPYNONE
is not set.  Irrespective of the bug, there are still cases in which a
JPEG source image with a large amount of metadata can, when transformed,
exceed the worst-case transformed JPEG image size.  For instance, if you
try to losslessly crop a JPEG image with 3 kB of EXIF data to 16x16
pixels, then you are guaranteed to exceed the worst-case 16x16 JPEG
image size unless you discard the EXIF data.

Even without the bug, tjTransform() will still fail with "Buffer passed
to JPEG library is too small" when attempting to transform JPEG source
images that meet the aforementioned criteria.  The bug is that the
function segfaults rather than failing gracefully, but the chances of
that occurring in a real-world application are very slim.  Any
real-world application developers who attempted to transform arbitrary
JPEG source images with TJFLAG_NOREALLOC set would very quickly realize
that they cannot reliably do that without also setting TJXOPT_COPYNONE.
Thus, I posit that the actual risk posed by this bug is low.
Applications such as web browsers that are the most exposed to security
risks from arbitrary JPEG source images do not use the TurboJPEG
lossless transform feature.  (None of those applications even use the
TurboJPEG API, to the best of my knowledge, and the public libjpeg API
has no equivalent transform function.)  Our only command-line interface
to the tjTransform() function, TJBench, was not exposed to the bug
because it had a compatible bug whereby it allocated the JPEG
destination buffer to the same size that tjTransform() erroneously
expected.  The TurboJPEG Java API was also not exposed to the bug
because of a similar compatible bug in the
Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function.
(This commit fixes both compatible bugs.)

In short, best practices for tjTransform() are to use TJFLAG_NOREALLOC
only with JPEG source images that are known to be free of metadata (such
as images generated by tjCompress*()) or to use TJXOPT_COPYNONE along
with TJFLAG_NOREALLOC.  Still, however, the function shouldn't segfault
as long as the calling program allocates the suggested amount of space
for the JPEG destination buffer.

Usability notes:
tjTransform() could hypothetically require dstSizes[i] to be set
regardless of whether TJFLAG_NOREALLOC is set, but there are usability
pitfalls either way.  The main pitfall I sought to avoid with
ff78e37595 was a calling program failing
to set dstSizes[i] at all, thus leaving its value undefined.  It could
be argued that requiring dstSizes[i] to be set in all cases is more
consistent, but it could also be argued that not requiring it to be set
when TJFLAG_NOREALLOC is set is more user-proof.  tjTransform() could
also hypothetically set TJXOPT_COPYNONE automatically when
TJFLAG_NOREALLOC is set, but that could lead to user confusion.
2023-06-28 11:37:53 -04:00
DRC
c8d52f1c4c tj3Transform: Calc dst buf size from xformed dims
When used with TJPARAM_NOREALLOC and with TJXOP_TRANSPOSE,
TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270, tj3Transform()
incorrectly based the destination buffer size for a transform on the
source image dimensions rather than the transformed image dimensions.
This was apparently a long-standing bug that had existed in the
tj*Transform() function since its inception.  As initially implemented
in the evolving libjpeg-turbo v1.2 code base, tjTransform() required
dstSizes[i] to be set regardless of whether TJFLAG_NOREALLOC (the
predecessor to TJPARAM_NOREALLOC) was set.
ff78e37595, which was introduced later in
the evolving libjpeg-turbo v1.2 code base, removed that requirement and
planted the seed for the bug.  However, the bug was not activated until
9b49f0e4c7 was introduced still later in
the evolving libjpeg-turbo v1.2 code base, adding a subsampling type
argument to the (new at the time) tjBufSize() function and thus making
the width and height arguments no longer commutative.

The bug opened up the possibility that a JPEG source image could cause
tj3Transform() to overflow the destination buffer for a transform if all
of the following were true:
- The JPEG source image used 4:2:2, 4:4:0, 4:1:1, or 4:4:1 subsampling.
  (These are the only subsampling types for which the width and height
  arguments to tj3JPEGBufSize() are not commutative.)
- The width and height of the JPEG source image were such that
  tj3JPEGBufSize(height, width, subsamplingType) returned a smaller
  value than tj3JPEGBufSize(width, height, subsamplingType).
- The JPEG source image contained enough metadata that the size of the
  transformed image was larger than
  tj3JPEGBufSize(height, width, subsamplingType).
- TJPARAM_NOREALLOC was set.
- TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270 was
  used.
- TJXOPT_COPYNONE was not set.
- TJXOPT_CROP was not set.
- The calling program allocated
  tj3JPEGBufSize(height, width, subsamplingType) bytes for the
  destination buffer, as the API documentation instructs.

The API documentation cautions that JPEG source images containing a
large amount of extraneous metadata (EXIF, IPTC, ICC, etc.) cannot
reliably be transformed if TJPARAM_NOREALLOC is set and TJXOPT_COPYNONE
is not set.  Irrespective of the bug, there are still cases in which a
JPEG source image with a large amount of metadata can, when transformed,
exceed the worst-case transformed JPEG image size.  For instance, if you
try to losslessly crop a JPEG image with 3 kB of EXIF data to 16x16
pixels, then you are guaranteed to exceed the worst-case 16x16 JPEG
image size unless you discard the EXIF data.

Even without the bug, tj3Transform() will still fail with "Buffer passed
to JPEG library is too small" when attempting to transform JPEG source
images that meet the aforementioned criteria.  The bug is that the
function segfaults rather than failing gracefully, but the chances of
that occurring in a real-world application are very slim.  Any
real-world application developers who attempted to transform arbitrary
JPEG source images with TJPARAM_NOREALLOC set would very quickly realize
that they cannot reliably do that without also setting TJXOPT_COPYNONE.
Thus, I posit that the actual risk posed by this bug is low.
Applications such as web browsers that are the most exposed to security
risks from arbitrary JPEG source images do not use the TurboJPEG
lossless transform feature.  (None of those applications even use the
TurboJPEG API, to the best of my knowledge, and the public libjpeg API
has no equivalent transform function.)  Our only command-line interface
to the tj3Transform() function, TJBench, was not exposed to the bug
because it had a compatible bug whereby it allocated the JPEG
destination buffer to the same size that tj3Transform() erroneously
expected.  The TurboJPEG Java API was also not exposed to the bug
because of a similar compatible bug in the
Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function.
(This commit fixes both compatible bugs.)

In short, best practices for tj3Transform() are to use TJPARAM_NOREALLOC
only with JPEG source images that are known to be free of metadata (such
as images generated by tj3Compress*()) or to use TJXOPT_COPYNONE along
with TJPARAM_NOREALLOC.  Still, however, the function shouldn't segfault
as long as the calling program allocates the suggested amount of space
for the JPEG destination buffer.

Usability notes:
tj3Transform() could hypothetically require dstSizes[i] to be set
regardless of the value of TJPARAM_NOREALLOC, but there are usability
pitfalls either way.  The main pitfall I sought to avoid with
ff78e37595 was a calling program failing
to set dstSizes[i] at all, thus leaving its value undefined.  It could
be argued that requiring dstSizes[i] to be set in all cases is more
consistent, but it could also be argued that not requiring it to be set
when TJPARAM_NOREALLOC is set is more user-proof.  tj3Transform() could
also hypothetically set TJXOPT_COPYNONE automatically when
TJPARAM_NOREALLOC is set, but that could lead to user confusion.
Ultimately, I would like to address these issues in TurboJPEG v4 by
using managed buffer objects, but that would be an extensive overhaul.
2023-06-27 18:36:01 -04:00
DRC
6b9e3b0400 README.md: Include link to project home page
(for compliance with SignPath's Code of Conduct for Open Source
projects)
2023-06-19 11:11:16 -04:00
DRC
41b18e8d61 AppVeyor: Only add installers to zip file
Oops
2023-06-18 12:50:47 -04:00
DRC
a403ad5b52 AppVeyor: Integrate with SignPath.io 2023-06-16 16:16:42 -04:00
DRC
fcfd2ada75 Fix build warnings/errs w/ -DNO_GETENV/-DNO_PUTENV
- strtest.c: Fix unused variable warnings if both -DNO_GETENV and
  -DNO_PUTENV are specified or if only -DNO_GETENV is specified.

- jinclude.h: Fix build error if only -DNO_GETENV is specified.

Fixes #697
2023-06-16 11:55:01 -04:00
DRC
58cbda3e37 GitHub: Fix x32 build
1f55ae7b0f accidentally overrode the value
of CMAKE_C_FLAGS, thus eliminating the -mx32 flag that was necessary to
enable x32.
2023-06-16 11:54:34 -04:00
DRC
c27695a193 Fix build warnings/errs w/ -DNO_GETENV/-DNO_PUTENV
- strtest.c: Fix unused variable warnings if both -DNO_GETENV and
  -DNO_PUTENV are specified or if only -DNO_GETENV is specified.

- jinclude.h: Fix build error if only -DNO_GETENV is specified.

Fixes #697
2023-06-16 11:39:10 -04:00
DRC
65a85ce34e GitHub: Fix x32 build
1f55ae7b0f accidentally overrode the value
of CMAKE_C_FLAGS, thus eliminating the -mx32 flag that was necessary to
enable x32.
2023-06-16 11:19:33 -04:00
DRC
0e9683c4c6 Bump version to 3.0.0 2023-06-12 14:36:18 -04:00
DRC
be678e5a1b tjexample.c: Prevent integer overflow
Because width, height, and tjPixelSize[] are signed integers, signed
integer overflow will occur if width * height *
tjPixelSize[pixelFormat] > INT_MAX or jpegSize > INT_MAX, which would
cause an incorrect value to be passed to tjAlloc().  This commit
modifies tjexample.c in the following ways:

- Use malloc() rather than tjAlloc() to allocate the uncompressed image
  buffer.  (tjAlloc() is only necessary for JPEG buffers that will
  potentially be reallocated by the TurboJPEG API library.)

- Implicitly promote width, height, and tjPixelSize[pixelFormat] to
  size_t before multiplying them.

- If size_t is 32-bit, throw an error if width * height *
  tjPixelSize[pixelFormat] would overflow the data type.

- Throw an error if jpegSize would overflow a signed integer (which
  could only happen on a 64-bit machine.)

Since tjexample is not installed or packaged, the worst case for this
issue was that a downstream application might interpret tjexample.c
literally and introduce a similar overflow issue into its own code.
However, it's worth noting that such issues could also be introduced
when using malloc().
2023-06-02 11:02:11 -04:00
DRC
6b506ed397 tjexample.c: Prevent integer overflow
Because width, height, and tjPixelSize[] are signed integers, signed
integer overflow will occur if width * height *
tjPixelSize[pixelFormat] > INT_MAX, which would cause an incorrect value
to be passed to tj3Alloc().  This commit modifies tjexample.c in the
following ways:

- Implicitly promote width, height, and tjPixelSize[pixelFormat] to
  size_t before multiplying them.

- Use malloc() rather than tj3Alloc() to allocate the uncompressed image
  buffer.  (tj3Alloc() is only necessary for JPEG buffers that will
  potentially be reallocated by the TurboJPEG API library.)

- If size_t is 32-bit, throw an error if width * height *
  tjPixelSize[pixelFormat] would overflow the data type.

Since tjexample is not installed or packaged, the worst case for this
issue was that a downstream application might interpret tjexample.c
literally and introduce a similar overflow issue into its own code.
However, it's worth noting that such issues could also be introduced
when using malloc().
2023-06-01 14:22:13 -04:00
DRC
2192560d74 Disallow merged upsampling with lossless decomp
Colorspace conversion is explicitly not supported with lossless JPEG
images.  Merged upsampling implies YCbCr-to-RGB colorspace conversion,
so allowing it with lossless decompression was an oversight.
9f756bc67a eliminated interaction issues
between the lossless decompressor and the merged upsampler related to
out-of-range 12-bit samples, but referring to #690, other interaction
issues apparently still exist.  Such issues are likely, given the fact
that the merged upsampler was never designed with lossless decompression
in mind.

This commit also extends the decompress fuzzer so that it catches the
issue reported in #690.

Fixes #690
Redundantly fixes #670
Redundantly fixes #675
2023-05-31 14:42:49 -04:00
DRC
4e7ff7b922 SECURITY.md: Wordsmithing and clarifications
- Clarify that encrypted e-mail is optional.
- Mention the new GitHub security advisory system.
- Clarify that vulnerabilities against new features that are not yet in
  a Stable release series need not be reported securely.
2023-05-31 10:28:38 -04:00
DRC
10693e6441 GitHub: Add security policy 2023-05-30 18:22:50 -04:00
DRC
36aaeebb55 ChangeLog.md: List CVE ID fixed by 9f756bc6 2023-05-30 17:46:58 -04:00
DRC
2e1b8a462f jpeg_crop_scanline: Fix calc w/sclg + 2x4,4x2 samp
When computing the downsampled width for a particular component,
jpeg_crop_scanline() needs to take into account the fact that the
libjpeg code uses a combination of IDCT scaling and upsampling to
implement 4x2 and 2x4 upsampling with certain decompression scaling
factors.  Failing to account for that led to incomplete upsampling of
4x2- or 2x4-subsampled components, which caused the color converter to
read from uninitialized memory.  With 12-bit data precision, this caused
a buffer overrun or underrun and subsequent segfault if the
uninitialized memory contained a value that was outside of the valid
sample range (because the color converter uses the value as an array
index.)

Fixes #669
2023-04-06 22:05:10 -05:00
DRC
3a53627306 jpeg_crop_scanline: Fix calc w/sclg + 2x4,4x2 samp
When computing the downsampled width for a particular component,
jpeg_crop_scanline() needs to take into account the fact that the
libjpeg code uses a combination of IDCT scaling and upsampling to
implement 4x2 and 2x4 upsampling with certain decompression scaling
factors.  Failing to account for that led to incomplete upsampling of
4x2- or 2x4-subsampled components, which caused the color converter to
read from uninitialized memory.  With 12-bit data precision, this caused
a buffer overrun or underrun and subsequent segfault if the
uninitialized memory contained a value that was outside of the valid
sample range (because the color converter uses the value as an array
index.)

Fixes #669
2023-04-06 22:00:43 -05:00
DRC
42ce199c9c Decomp: Don't enable 2-pass color quant w/ RGB565
The 2-pass color quantization algorithm assumes 3-sample pixels.  RGB565
is the only 3-component colorspace that doesn't have 3-sample pixels, so
we need to treat it as a special case when determining whether to enable
2-pass color quantization.  Otherwise, attempting to initialize 2-pass
color quantization with an RGB565 output buffer could cause
prescan_quantize() to read from uninitialized memory and subsequently
underflow/overflow the histogram array.

djpeg is supposed to fail gracefully if both -rgb565 and -colors are
specified, because none of its destination managers (image writers)
support color quantization with RGB565.  However, prescan_quantize() was
called before that could occur.  It is possible but very unlikely that
these issues could have been reproduced in applications other than
djpeg.  The issues involve the use of two features (12-bit precision and
RGB565) that are incompatible, and they also involve the use of two
rarely-used legacy features (RGB565 and color quantization) that don't
make much sense when combined.

Fixes #668
Fixes #671
Fixes #680
2023-04-04 20:45:16 -05:00
DRC
62590d428b Decomp: Don't enable 2-pass color quant w/ RGB565
The 2-pass color quantization algorithm assumes 3-sample pixels.  RGB565
is the only 3-component colorspace that doesn't have 3-sample pixels, so
we need to treat it as a special case when determining whether to enable
2-pass color quantization.  Otherwise, attempting to initialize 2-pass
color quantization with an RGB565 output buffer could cause
prescan_quantize() to read from uninitialized memory and subsequently
underflow/overflow the histogram array.

djpeg is supposed to fail gracefully if both -rgb565 and -colors are
specified, because none of its destination managers (image writers)
support color quantization with RGB565.  However, prescan_quantize() was
called before that could occur.  It is possible but very unlikely that
these issues could have been reproduced in applications other than
djpeg.  The issues involve the use of two features (12-bit precision and
RGB565) that are incompatible, and they also involve the use of two
rarely-used legacy features (RGB565 and color quantization) that don't
make much sense when combined.

Fixes #668
Fixes #671
Fixes #680
2023-04-04 20:38:00 -05:00
DRC
9f756bc67a Lossless decomp: Range-limit 12-bit samples
12-bit is the only data precision for which the range of the sample data
type exceeds the valid sample range, so it is possible to craft a 12-bit
lossless JPEG image that contains out-of-range 12-bit samples.
Attempting to decompress such an image using color quantization or merged
upsampling (NOTE: libjpeg-turbo cannot generate YCbCr or subsampled
lossless JPEG images, but it can decompress them) caused segfaults or
buffer overruns when those algorithms attempted to use the out-of-range
sample values as array indices.  This commit modifies the lossless
decompressor so that it range-limits the output of the scaler when using
12-bit samples.

Fixes #670
Fixes #672
Fixes #673
Fixes #674
Fixes #675
Fixes #676
Fixes #677
Fixes #678
Fixes #679
Fixes #681
Fixes #683
2023-04-04 20:37:54 -05:00
DRC
3f43c6a310 jdlossls.c: Code formatting tweak 2023-04-04 13:27:11 -05:00
DRC
d491094b41 Build separate static/shared jpeg12/16 obj libs
If PIC isn't enabled for the entire build (using
CMAKE_POSITION_INDEPENDENT_CODE), then we need to enable it for any of
the objects in the libjpeg-turbo shared libraries.  Ideally, however, we
don't want to enable PIC for any of the objects in the libjpeg-turbo
static libraries, unless CMAKE_POSITION_INDEPENDENT_CODE is set.  Thus,
we need to build separate static and shared jpeg12 and jpeg16 object
libraries.

Fixes #684
2023-04-03 17:44:01 -05:00
DRC
0d20aa15ce TJBench: Require known subsamp type w/tiled decomp
(oversight from 386ec0abc7)

Tiled decompression will ultimately fail if the subsampling type of the
JPEG input image is unknown, but the C version of TJBench needs to fail
earlier in order to avoid using -1 (TJSAMP_UNKNOWN) as an array index
for tjMCUWidth[]/tjMCUHeight[].  The Java version now fails earlier as
well, although there is no benefit to that other than making the error
message less cryptic.
2023-03-31 11:06:52 -05:00
DRC
bc087d6aa9 TJBench: w/JPEG input imgs, set min tile= MCU size
When -tile is used with a JPEG input image, TJBench generates the tiles
using lossless cropping, which will fail if the cropping region doesn't
align with an MCU boundary.  Furthermore, there is no reason to avoid
8x8 tiles when decompressing 4:4:4 or grayscale JPEG images.
2023-03-13 17:50:38 -05:00
DRC
7313fe5aea Bump version to 2.1.6 to prepare for new commits 2023-03-13 17:49:43 -05:00
DRC
cc8c6d3667 tjbenchtest: Test all subsampling types 2023-03-13 17:36:59 -05:00
DRC
9d2f189c29 TJBench: Change subsamp for transposed 4:*:1 img
If we have transformed a 4:1:1 or 4:4:1 JPEG input image in such a way
that the horizontal and vertical dimensions are transposed, then we need
to change the subsampling type that is passed to the decomp() function.
Otherwise, tj3YUVBufSize() may return an incorrect value.

(oversight from fc881ebb21)
2023-03-13 17:36:53 -05:00
DRC
386ec0abc7 TJBench: w/JPEG input imgs, set min tile= MCU size
When -tile is used with a JPEG input image, TJBench generates the tiles
using lossless cropping, which will fail if the cropping region doesn't
align with an MCU boundary.  Furthermore, there is no reason to avoid
8x8 tiles when decompressing 4:4:4 or grayscale JPEG images.
2023-03-13 13:27:10 -05:00
DRC
fc881ebb21 TurboJPEG: Implement 4:4:1 chrominance subsampling
This allows losslessly transposed or rotated 4:1:1 JPEG images to be
losslessly cropped, partially decompressed, or decompressed to planar
YUV images.

Because tj3Transform() allows multiple lossless transformations to be
chained together, all subsampling options need to have a corresponding
transposed subsampling option.  (This is why 4:4:0 was originally
implemented as well.)  Otherwise, the documentation would be technically
incorrect.  It says that images with unknown subsampling types cannot be
losslessly cropped, partially decompressed, or decompressed to planar
YUV images, but it doesn't say anything about images with known
subsampling types whose subsampling type becomes unknown if the image is
rotated or transposed.  This is one of those situations in which it is
easier to implement a feature that works around the problem than to
document the problem.

Closes #659
2023-03-10 10:46:14 -06:00
DRC
58a3427ffc Bump version to 2.1.92 to prepare for new commits 2023-03-10 09:31:00 -06:00
DRC
0827eaff11 ChangeLog.md: Add literal vers # to 3.0 beta2 hdr
(per our convention)
2023-03-10 09:30:05 -06:00
DRC
9c432a4d40 GitHub: Add pull request template 2023-02-23 12:03:27 -06:00
DRC
c8a20e0c2f Build: Clarify CMAKE_OSX_ARCHITECTURES error
It's not that the build system doesn't support multiple values in
CMAKE_OSX_ARCHITECTURES.  It's that libjpeg-turbo, because of its SIMD
extensions, *cannot* support multiple values in CMAKE_OSX_ARCHITECTURES.
2023-02-23 12:03:06 -06:00
DRC
97df8ea9ed GitHub: Add pull request template 2023-02-23 11:57:25 -06:00
DRC
c13fe15955 Build: Clarify CMAKE_OSX_ARCHITECTURES error
It's not that the build system doesn't support multiple values in
CMAKE_OSX_ARCHITECTURES.  It's that libjpeg-turbo, because of its SIMD
extensions, *cannot* support multiple values in CMAKE_OSX_ARCHITECTURES.
2023-02-23 09:40:25 -06:00
DRC
33eaf17e5b Build: Fail if included with add_subdirectory()
Even though BUILDING.md and CONTRIBUTING.md explicitly state that the
libjpeg-turbo build system does not and will not support being
integrated into downstream build systems using add_subdirectory() (see
0565548191), people continue to file bug
reports, feature requests, and pull requests regarding that (see #265,
 #637, and #653 in addition to the issues listed in
05655481917a2d2761cf2fe19b76f639b7f159ef.)  Responding to those
issues wastes our project's limited resources.  Hopefully people will
get the hint if the build system explicitly tells them that it can't be
included using add_subdirectory(), which will prompt them to read the
comments in CMakeLists.txt explaining why.  To anyone stumbling upon
this commit message, please refer to the discussions under the issues
listed above, as well as the issues listed in
0565548191.  Our project's position on
this has been stated, explained, and defended numerous times.
2023-02-10 10:49:30 -06:00
DRC
d67edaff83 Ignore 2.1.5.1 ChangeLog header w/git diff --check
(Otherwise, checkstyle flags it as a leftover conflict marker.)
2023-02-10 10:49:10 -06:00
DRC
2af984fdae Build: Fail if included with add_subdirectory()
Even though BUILDING.md and CONTRIBUTING.md explicitly state that the
libjpeg-turbo build system does not and will not support being
integrated into downstream build systems using add_subdirectory() (see
0565548191), people continue to file bug
reports, feature requests, and pull requests regarding that (see #265,
 #637, and #653 in addition to the issues listed in
05655481917a2d2761cf2fe19b76f639b7f159ef.)  Responding to those
issues wastes our project's limited resources.  Hopefully people will
get the hint if the build system explicitly tells them that it can't be
included using add_subdirectory(), which will prompt them to read the
comments in CMakeLists.txt explaining why.  To anyone stumbling upon
this commit message, please refer to the discussions under the issues
listed above, as well as the issues listed in
0565548191.  Our project's position on
this has been stated, explained, and defended numerous times.
2023-02-10 10:48:35 -06:00
DRC
6c61033349 ChangeLog.md: Document 4e028ecd
+ bump version to 3.0 beta2
2023-02-08 10:14:04 -06:00
DRC
8ecba3647e ChangeLog.md: Document d743a2c1
+ bump version to 2.1.5.1
2023-02-08 09:29:21 -06:00
DRC
6316d4d752 OSS-Fuzz: Bail out immediately on decomp failure
Don't keep trying to decompress the same image if tj3Decompress*() has
already thrown an error.  Otherwise, if the image has an excessive
number of scans, then each iteration of the loop will try to decompress
up to the scan limit, which may cause the overall test to time out even
if one iteration doesn't time out.
2023-02-07 13:34:34 -06:00
DRC
2a5a3c6f0a OSS-Fuzz: Bail out immediately on decomp failure
Don't keep trying to decompress the same image if tj3Decompress*() has
already thrown an error.  Otherwise, if the image has an excessive
number of scans, then each iteration of the loop will try to decompress
up to the scan limit, which may cause the overall test to time out even
if one iteration doesn't time out.
2023-02-07 13:21:08 -06:00
Kornel
af265e7562 Merge tag '2.1.5'
* tag '2.1.5': (41 commits)
  BUILDING.md: Specify install prefix for MinGW/Un*x
  Java: Guard against int overflow in size methods
  turbojpeg.c: Fix UBSan warning
  tjPlane*(): Guard against int overflow
  Java doc: TJ.pixelSize --> TJ.getPixelSize()
  TJBench: Unset TJ*OPT_CROP when disabling tiling
  TJExample: Remove "underlying codec" references
  GitHub: Update to actions/checkout@v3
  TJBench: Set TJ*OPT_PROGRESSIVE with -progressive
  TJBench/Java: Fix parsing of quality ranges
  TJBench: Strictly check all non-boolean arguments
  TurboJPEG: More documentation improvements
  TJDecompressor.java: Exception message tweak
  12-bit: Set alpha channel to 4095 rather than 255
  TJDecompressor.java: "YUV" = "planar YUV"
  Java: Don't allow int overflow in buf size methods
  tjDecompressToYUV2: Use scaled dims for plane calc
  TurboJPEG: Numerous documentation improvements
  TurboJPEG: Don't use backward compatibility macros
  TurboJPEG: Ensure 'pad' arg is a power of 2
  ...
2023-02-03 20:54:24 +00:00
DRC
d743a2c12e SIMD/x86: Initialize simd_support before every use
As long as a libjpeg instance is only used by one thread at a time, a
program is technically within its rights to call jpeg_start_*compress()
in one thread and jpeg_(read|write)_*(), with the same libjpeg instance,
in a second thread.  However, because the various jsimd_can*() functions
are called within the body of jpeg_start_*compress() and simd_support is
now thread-local (due to f579cc11b3), that
led to a situation in which simd_support was initialized in the first
thread but not the second.  The uninitialized value of simd_support is
0xFFFFFFFF, which the second thread interpreted to mean that it could
use any instruction set, and when it attempted to use AVX2 instructions
on a CPU that didn't support them, an illegal instruction error
occurred.

This issue was known to affect libvips.

This commit modifies the i386 and x86-64 SIMD dispatchers so that the
various jsimd_*() functions always call init_simd(), if simd_support is
uninitialized, prior to dispatching based on the value of simd_support.
Note that the other SIMD dispatchers don't need this, because only the
x86 SIMD extensions currently support multiple instruction sets.

This patch has been verified to be performance-neutral to within
+/- 0.4% with 32-bit and 64-bit code running on a 2.8 GHz Intel Xeon
W3530 and a 3.6 GHz Intel Xeon W2123.

Fixes #649
2023-02-02 10:46:57 -06:00
DRC
4e028ecd63 SIMD/x86: Initialize simd_support before every use
As long as a libjpeg instance is only used by one thread at a time, a
program is technically within its rights to call jpeg_start_*compress()
in one thread and jpeg_(read|write)_*(), with the same libjpeg instance,
in a second thread.  However, because the various jsimd_can*() functions
are called within the body of jpeg_start_*compress() and simd_support is
now thread-local (due to f579cc11b3), that
led to a situation in which simd_support was initialized in the first
thread but not the second.  The uninitialized value of simd_support is
0xFFFFFFFF, which the second thread interpreted to mean that it could
use any instruction set, and when it attempted to use AVX2 instructions
on a CPU that didn't support them, an illegal instruction error
occurred.

This issue was known to affect libvips.

This commit modifies the i386 and x86-64 SIMD dispatchers so that the
various jsimd_*() functions always call init_simd(), if simd_support is
uninitialized, prior to dispatching based on the value of simd_support.
Note that the other SIMD dispatchers don't need this, because only the
x86 SIMD extensions currently support multiple instruction sets.

This patch has been verified to be performance-neutral to within
+/- 0.4% with 32-bit and 64-bit code running on a 2.8 GHz Intel Xeon
W3530 and a 3.6 GHz Intel Xeon W2123.

Fixes #649
2023-02-02 10:23:41 -06:00
DRC
89ceac8c85 Decompress fuzzer: Fix uninitialized memory access
(regression introduced by fc01f4673b)

Oops.  In the process of migrating the fuzzers to the TurboJPEG 3 API,
I accidentally left out the code in decompress.cc that updates the width
and height based on the scaling factor (but I apparently included that
code in decompress_yuv.cc.)

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55573
2023-02-01 12:31:58 -06:00
DRC
a93f6a7a63 Build: Define THREAD_LOCAL even if !WITH_TURBOJPEG
The SIMD dispatchers use thread-local storage now as well, because of
f579cc11b3.
2023-02-01 11:58:30 -06:00
DRC
dd89ce6cd6 Build: Define THREAD_LOCAL even if !WITH_TURBOJPEG
The SIMD dispatchers use thread-local storage now as well, because of
f579cc11b3.
2023-02-01 11:54:09 -06:00
DRC
fd93d98a95 Fix i386 transform fuzzer build
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55447
2023-01-28 12:13:32 -06:00
DRC
0205c6e04c tjbench.c: Remove vestigial int overflow checks
Since tj3Alloc() now accepts a size_t argument rather than an int
argument, it is no longer necessary to check for signed integer overflow
in the C version of TJBench.
2023-01-28 12:10:48 -06:00
DRC
6c5caf30e2 Merge branch 'main' into dev 2023-01-27 18:30:11 -06:00
DRC
3b19db4e6e BUILDING.md: Specify install prefix for MinGW/Un*x
The default install prefix when building under MinGW is chosen based on
the needs of the official build system, which uses MSYS2 to generate
Windows installer packages that install under c:\libjpeg-turbo-gcc[64].
However, attempting to configure the build with that install prefix on
a Un*x machine causes a CMake error.

Fixes #641
2023-01-27 18:24:41 -06:00
DRC
427c304595 tjbench.c: Fix Windows build error
(regression introduced by d7790789a6)
2023-01-27 14:31:48 -06:00
DRC
fd8c4da0ac Bump revision to 2.1.90 to prepare for beta
+ acknowledge upcoming 2.1.5 release
2023-01-27 14:05:07 -06:00
DRC
9b3a8f3641 jcapimin.c: Revert changes made in fc01f467
Those changes worked around an innocuous UBSan warning that was
exposed by the new TurboJPEG 3 transform fuzz target, due to the fact
that tj3Transform() no longer rejects images with unknown subsampling
configurations.  That UBSan warning was a false positive, and attempting
to fix it introduced a buffer overrun triggered by a malformed input
image that causes jpeg_write_marker() to be called with datalen == 0.  I
suspect that the UBSan false positive was only reproducible on my local
machine, but I guess we'll see.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55413
2023-01-27 13:52:26 -06:00
DRC
d0015876ec Fix build if [CD]_LOSSLESS_SUPPORTED undefined
(regression introduced by fc01f4673b)
2023-01-27 13:38:00 -06:00
DRC
d7790789a6 tjbench.c: Clean up THROW_TJ*() macro usage
- Don't report which function was being called when a TurboJPEG error
  occurred, because the TurboJPEG error message already contains that
  information.

- Use THROW_TJG() for functions that report errors globally instead of
  through an instance handle.

- Use THROW_TJ() for the image I/O functions.

- Formatting tweaks
2023-01-27 13:37:55 -06:00
DRC
54f571f8fb TurboJPEG: Clean up/repurpose THROWI() macro
We already had a use case for two integer arguments, and the new use
cases benefit from two integer arguments as well.
2023-01-27 12:31:44 -06:00
DRC
8c57aad0a3 turbojpeg.c: Use THROWG() macro whenever possible 2023-01-27 12:19:16 -06:00
DRC
b94041390c TurboJPEG: Robustify JPEG header prefetching
In decompression and transform functions, use the libjpeg API state
rather than a TurboJPEG instance variable to determine whether
jpeg_mem_src_tj() and jpeg_read_header() have already been called by a
wrapper function.
2023-01-27 11:58:01 -06:00
DRC
db9f297f1c ChangeLog.md: Document TurboJPEG 3 API overhaul 2023-01-27 07:10:49 -06:00
DRC
96bc40c1b3 Implement arithmetic coding with 12-bit precision
This actually works and apparently always has worked.  It only failed
because the libjpeg code, which did not originally support arithmetic
coding, assumed that optimize_coding should always be TRUE for 12-bit
data precision.
2023-01-26 13:11:58 -06:00
DRC
fc01f4673b TurboJPEG 3 API overhaul
(ChangeLog update forthcoming)

- Prefix all function names with "tj3" and remove version suffixes from
  function names.  (Future API overhauls will increment the prefix to
  "tj4", etc., thus retaining backward API/ABI compatibility without
  versioning each individual function.)

- Replace stateless boolean flags (including TJ*FLAG_ARITHMETIC and
  TJ*FLAG_LOSSLESS, which were never released) with stateful integer
  parameters, the value of which persists between function calls.
  * Use parameters for the JPEG quality and subsampling as well, in
    order to eliminate the awkwardness of specifying function arguments
    that weren't relevant for lossless compression.
  * tj3DecompressHeader() now stores all relevant information about the
    JPEG image, including the width, height, subsampling type, entropy
    coding type, etc. in parameters rather than returning that
    information in its arguments.
  * TJ*FLAG_LIMITSCANS has been reimplemented as an integer parameter
    (TJ*PARAM_SCANLIMIT) that allows the number of scans to be
    specified.

- Use the const keyword for all pointer arguments to unmodified
  buffers, as well as for both dimensions of 2D pointers.  Addresses
  #395.

- Use size_t rather than unsigned long to represent buffer sizes, since
  unsigned long is a 32-bit type on Windows.  Addresses #24.

- Return 0 from all buffer size functions if an error occurs, rather
  than awkwardly trying to return -1 in an unsigned data type.

- Implement 12-bit and 16-bit data precision using dedicated
  compression, decompression, and image I/O functions/methods.
  * Suffix the names of all data-precision-specific functions with 8,
    12, or 16.
  * Because the YUV functions are intended to be used for video, they
    are currently only implemented with 8-bit data precision, but they
    can be expanded to 12-bit data precision in the future, if
    necessary.
  * Extend TJUnitTest and TJBench to test 12-bit and 16-bit data
    precision, using a new -precision option.
  * Add appropriate regression tests for all of the above to the 'test'
    target.
  * Extend tjbenchtest to test 12-bit and 16-bit data precision, and
    add separate 'tjtest12' and 'tjtest16' targets.
  * BufferedImage I/O in the Java API is currently limited to 8-bit
    data precision, since the BufferedImage class does not
    straightforwardly support higher data precisions.
  * Extend the PPM reader to convert 12-bit and 16-bit PBMPLUS files
    to grayscale or CMYK pixels, as it already does for 8-bit files.

- Properly accommodate lossless JPEG using dedicated parameters
  (TJ*PARAM_LOSSLESS, TJ*PARAM_LOSSLESSPSV, and TJ*PARAM_LOSSLESSPT),
  rather than using a flag and awkwardly repurposing the JPEG quality.
  Update TJBench to properly reflect whether a JPEG image is lossless.

- Re-organize the TJBench usage screen.

- Update the Java docs using Java 11, to improve the formatting and
  eliminate HTML frames.

- Use the accurate integer DCT algorithm by default for both
  compression and decompression, since the "fast" algorithm is a legacy
  feature, it does not pass the ISO compliance tests, and it is not
  actually faster on modern x86 CPUs.
  * Remove the -accuratedct option from TJBench and TJExample.

- Re-implement the 'tjtest' target using a CMake script that enables
  the appropriate tests, depending on the data precision and whether or
  not the Java API is part of the build.

- Consolidate the C and Java versions of tjbenchtest into one script.

- Consolidate the C and Java versions of tjexampletest into one script.

- Combine all initialization functions into a single function
  (tj3Init()) that accepts an integer parameter specifying the
  subsystems to initialize.

- Enable decompression scaling explicitly, using a new function/method
  (tj3SetScalingFactor()/TJDecompressor.setScalingFactor()), rather
  than implicitly using awkward "desired width"/"desired height"
  parameters.

- Introduce a new macro/constant (TJUNSCALED/TJ.UNSCALED) that maps to
  a scaling factor of 1/1.

- Implement partial image decompression, using a new function/method
  (tj3SetCroppingRegion()/TJDecompressor.setCroppingRegion()) and
  TJBench option (-crop).  Extend tjbenchtest to test the new feature.
  Addresses #1.

- Allow the JPEG colorspace to be specified explicitly when
  compressing, using a new parameter (TJ*PARAM_COLORSPACE).  This
  allows JPEG images with the RGB and CMYK colorspaces to be created.

- Remove the error/difference image feature from TJBench.  Identical
  images to the ones that TJBench created can be generated using
  ImageMagick with
  'magick composite <original_image> <output_image> -compose difference <diff_image>'

- Handle JPEG images with unknown subsampling types.  TJ*PARAM_SUBSAMP
  is set to TJ*SAMP_UNKNOWN (== -1) for such images, but they can still
  be decompressed fully into packed-pixel images or losslessly
  transformed (with the exception of lossless cropping.)  They cannot
  be partially decompressed or decompressed into planar YUV images.
  Note also that TJBench, due to its lack of support for imperfect
  transforms, requires that the subsampling type be known when
  rotating, flipping, or transversely transposing an image.  Addresses
  #436

- The Java version of TJBench now has identical functionality to the C
  version.  This was accomplished by (somewhat hackishly) calling the
  TurboJPEG C image I/O functions through JNI and copying the pixels
  between the C heap and the Java heap.

- Add parameters (TJ*PARAM_RESTARTROWS and TJ*PARAM_RESTARTBLOCKS) and
  a TJBench option (-restart) to allow the restart marker interval to
  be specified when compressing.  Eliminate the undocumented TJ_RESTART
  environment variable.

- Add a parameter (TJ*PARAM_OPTIMIZE), a transform option
  (TJ*OPT_OPTIMIZE), and a TJBench option (-optimize) to allow
  optimized baseline Huffman coding to be specified when compressing.
  Eliminate the undocumented TJ_OPTIMIZE environment variable.

- Add parameters (TJ*PARAM_XDENSITY, TJ*PARAM_DENSITY, and
  TJ*DENSITYUNITS) to allow the pixel density to be specified when
  compressing or saving a Windows BMP image and to be queried when
  decompressing or loading a Windows BMP image.  Addresses #77.

- Refactor the fuzz targets to use the new API.
  * Extend decompression coverage to 12-bit and 16-bit data precision.
  * Replace the awkward cjpeg12 and cjpeg16 targets with proper
    TurboJPEG-based compress12, compress12-lossless, and
    compress16-lossless targets

- Fix innocuous UBSan warnings uncovered by the new fuzzers.

- Implement previous versions of the TurboJPEG API by wrapping the new
  functions (tested by running the 2.1.x versions of TJBench, via
  tjbenchtest, and TJUnitTest against the new implementation.)
  * Remove all JNI functions for deprecated Java methods and implement
    the deprecated methods using pure Java wrappers.  It should be
    understood that backward API compatibility in Java applies only to
    the Java classes and that one cannot mix and match a JAR file from
    one version of libjpeg-turbo with a JNI library from another
    version.

- tj3Destroy() now silently accepts a NULL handle.

- tj3Alloc() and tj3Free() now return/accept void pointers, as malloc()
  and free() do.

- The image I/O functions now accept a TurboJPEG instance handle, which
  is used to transmit/receive parameters and to receive error
  information.

Closes #517
2023-01-25 19:09:34 -06:00
DRC
1a1ea4eeba Merge branch 'main' into dev 2023-01-25 12:28:42 -06:00
DRC
27f4ff80ce Java: Guard against int overflow in size methods
Because Java array sizes are ints, the various size methods in the TJ
class have int return values.  Thus, we have to guard against signed
int overflow at the JNI level, because the C functions can return sizes
greater than INT_MAX.

This also adds a test for TJ.planeWidth() and TJ.planeHeight(), in order
to validate 8a1526a442 in Java.
2023-01-25 12:21:35 -06:00
DRC
1485beaa49 turbojpeg.c: Fix UBSan warning
(introduced by previous commit)
2023-01-25 12:14:14 -06:00
DRC
8a1526a442 tjPlane*(): Guard against int overflow
tjPlaneWidth() and tjPlaneHeight() could overflow a signed int and
return a negative value if passed a width/height argument of INT_MAX and
a subsampling type for which the MCU block size is larger than 8x8.
2023-01-25 10:00:07 -06:00
DRC
52659f4f47 Merge branch 'main' into dev 2023-01-23 09:55:13 -06:00
DRC
edbb7e6d43 Java doc: TJ.pixelSize --> TJ.getPixelSize()
TJ.pixelSize isn't actually a thing.  Oops.
2023-01-23 09:50:29 -06:00
DRC
af1b4c8df4 TJBench: Unset TJ*OPT_CROP when disabling tiling
Otherwise, if the input image is a JPEG image, then an unnecessary
lossless transformation will be performed.
2023-01-21 18:31:20 -06:00
DRC
2aac545899 TJExample: Remove "underlying codec" references
(Oversight from 9a146f0f23)
2023-01-20 16:06:57 -06:00
DRC
7ab6222cff Merge branch 'main' into dev 2023-01-20 14:09:25 -06:00
DRC
0738305ec5 GitHub: Update to actions/checkout@v3
... to silence deprecation warning regarding Node.js 12 actions.
2023-01-20 13:41:25 -06:00
DRC
98a6455875 TJBench: Set TJ*OPT_PROGRESSIVE with -progressive
The documented behavior of the -progressive option is to use progressive
entropy coding in JPEG images generated by compression and transform
operations.  However, setting TJFLAG_PROGRESSIVE was insufficient to
accomplish that, because TJBench doesn't enable lossless transformation
if xformOpt == 0.
2023-01-20 13:23:00 -06:00
DRC
b99e7590b0 TJBench/Java: Fix parsing of quality ranges 2023-01-20 13:02:38 -06:00
DRC
28c2e60770 TJBench: Strictly check all non-boolean arguments
+ document that the value of -yuvpad must be a power of 2 (refer to
d260858395)
2023-01-20 13:02:38 -06:00
DRC
fb15efe94f TurboJPEG: More documentation improvements
- TJBench/TJUnitTest: Wordsmith command-line output

- Java: "decompress operations"="decompression operations"

- tjLoadImage(): Error message tweak

- Don't mention compression performance in the description of
  TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has
  already been compressed at that point.

(Oversights from 9a146f0f23)
2023-01-20 12:50:21 -06:00
DRC
6a060d8c95 TJCompressor.java: (C) header formatting tweak
(apparently borked by one of the previous merge commits)
2023-01-17 18:32:15 -06:00
DRC
c7c02d9288 Merge branch 'main' into dev 2023-01-17 18:31:31 -06:00
DRC
7ed186ed79 TJDecompressor.java: Exception message tweak
NO_ASSOC_ERROR is specific to JPEG source images, but the decompress()
methods can handle YUV source images as well.
2023-01-17 18:18:27 -06:00
DRC
08cbc23334 12-bit: Set alpha channel to 4095 rather than 255 2023-01-17 15:29:02 -06:00
DRC
155a8b0321 Merge branch 'main' into dev 2023-01-16 17:02:01 -06:00
DRC
0c0df2d0c7 TJDecompressor.java: "YUV" = "planar YUV"
(Oversight from 9a146f0f23)
2023-01-16 16:54:08 -06:00
DRC
22a6636852 Java: Don't allow int overflow in buf size methods
This is similar to the fix that 2a9e3bd743
applied to the C API.  We have to apply it separately at the JNI level
because the Java API always stores buffer sizes in 32-bit integers, and
the C buffer size functions could overflow an int when using 64-bit
code.  (NOTE: The Java API stores buffer sizes in 32-bit integers
because Java itself always uses 32-bit integers for array sizes.)  Since
Java don't allow no buffer overruns 'round here, this commit doesn't
change the ultimate outcome.  It just makes the inevitable exception
easier to diagnose.
2023-01-16 16:48:40 -06:00
DRC
d859232da3 TurboJPEG: Use 4:4:4 for lossless JPEG buf calcs 2023-01-14 18:27:37 -06:00
DRC
d4589f4f1c Merge branch 'main' into dev 2023-01-14 18:07:53 -06:00
DRC
94a2b95342 tjDecompressToYUV2: Use scaled dims for plane calc
The documented behavior of the function is to use decompression scaling
to generate the largest possible image that will fit within the desired
image dimensions.  Thus, if the desired image dimensions are larger than
the scaled image dimensions, then tjDecompressToYUV2() should use the
scaled image dimensions when computing the plane pointers and strides to
pass to tjDecompressToYUVPlanes().

Note that this bug was not previously detected, because tjunittest and
tjbench always passed the scaled image dimensions to
tjDecompressToYUV2().
2023-01-14 17:26:17 -06:00
DRC
9a146f0f23 TurboJPEG: Numerous documentation improvements
- Wordsmithing, formatting, and grammar tweaks

- Various clarifications and corrections, including specifying whether
  a particular buffer or image is used as a source or destination

- Accommodate/mention features that were introduced since the API
  documentation was created.

- For clarity, use "packed-pixel" to describe uncompressed
  source/destination images that are not planar YUV.

- Use "row" rather than "line" to refer to a single horizontal group of
  pixels or component values, for consistency with the libjpeg API
  documentation.  (libjpeg also uses "scanline", which is a more archaic
  term.)

- Use "alignment" rather than "padding" to refer to the number of bytes
  by which a row's width is evenly divisible.  This consistifies the
  documention of the YUV functions and tjLoadImage().  ("Padding"
  typically refers to the number of bytes added to each row, which is
  not the same thing.)

- Remove all references to "the underlying codec."  Although the
  TurboJPEG API originated as a cross-platform wrapper for the Intel
  Integrated Performance Primitives, Sun mediaLib, QuickTime, and
  libjpeg, none of those TurboJPEG implementations has been maintained
  since 2009.  Nothing would prevent someone from implementing the
  TurboJPEG API without libjpeg-turbo, but such an implementation would
  not necessarily have an "underlying codec."  (It could be fully
  self-contained.)

- Use "destination image" rather than "output image", for consistency,
  or describe the type of image that will be output.

- Avoid the term "image buffer" and instead use "byte buffer" to
  refer to buffers that will hold JPEG images, or describe the type of
  image that will be contained in the buffer.  (The Java documentation
  doesn't use "byte buffer", because the buffer arrays literally have
  "byte" in front of them, and since Java doesn't have pointers, it is
  not possible for mere mortals to store any other type of data in those
  arrays.)

- C: Use "unified" to describe YUV images stored in a single buffer, for
  consistency with the Java documentation.

- Use "planar YUV" rather than "YUV planar".  Is is our convention to
  describe images using {component layout} {colorspace/pixel format}
  {image function}, e.g. "packed-pixel RGB source image" or "planar YUV
  destination image."

- C: Document the TurboJPEG API version in which a particular function
  or macro was introduced, and reorder the backward compatibility
  function stubs in turbojpeg.h alphabetically by API version.

- C: Use Markdown rather than HTML tags, where possible, in the Doxygen
  comments.
2023-01-14 17:10:31 -06:00
DRC
b03ee8b835 TurboJPEG: Don't use backward compatibility macros
Macros from older versions of the TurboJPEG API are supported but not
documented, so using the current version of those macros makes the code
more readable.
2023-01-05 14:26:36 -06:00
DRC
d260858395 TurboJPEG: Ensure 'pad' arg is a power of 2
Because the PAD() macro can only handle powers of 2, this is a necessary
restriction (and a documented one, except in the case of
tjCompressFromYUV()-- oops.)  Failing to check the 'pad' argument
caused tjBufSizeYUV2() to return bogus results if 'pad' was less than 1
or otherwise not a power of 2.  tjEncodeYUV3() and tjDecodeYUV()
effectively treated a 'pad' value of 0 as unpadded, but that was subtle
and undocumented behavior.  tjCompressFromYUV() did not check whether
'pad' was a power of 2, so the strides passed to
tjCompressFromYUVPlanes() would have been incorrect if 'pad' was not a
power of 2.  That would not have caused tjCompressFromYUV() to overrun
the source buffer, as long as the calling application allocated the
buffer based on the return value of tjBufSizeYUV2() (which computes the
strides in the same manner as tjCompressFromYUV().)  However, if the
calling application attempted to initialize the source buffer using
correctly-computed strides, then it could have overrun its own
buffer in certain cases or produced incorrect JPEG images in others.

Realistically, there is no reason why an application would want to pass
a non-power-of-2 'pad' value to a TurboJPEG API function, so this commit
is about user-proofing the API rather than fixing any known issue.
2023-01-05 14:22:17 -06:00
DRC
0e63514214 Decomp: Fix color quant w/ 16-bit lossless JPEGs
(oversight from 2241434eb9)

This fixes segfaults and other issues that occurred when attempting to
decompress a 16-bit lossless JPEG image using color quantization
(which is used when decompressing to a GIF image.)
2022-12-21 16:51:22 -06:00
DRC
d6d6ac739f Win: Add jpeg16* functions to DLL module def files
(oversight from previous commit)
2022-12-16 14:15:02 -06:00
DRC
2241434eb9 16-bit lossless JPEG support 2022-12-16 13:57:03 -06:00
DRC
ad4e2ad86f CONTRIBUTING.md: Include lossless JPEG in policy 2022-12-07 16:01:55 -06:00
DRC
803523402f Merge branch 'main' into dev 2022-12-07 14:11:37 -06:00
DRC
dc4a93fab3 jpegtran: Fix FPE w/ -drop & -trim on corrupt JPEG
requant_comp() in transupp.c, a function that supports the jpegtran
-drop option, borrows code from the C quantization function in order to
re-quantize the coefficients from the dropped image.  However, the
function does not guard against the possibility that a corrupt source
image could inject quantization table values equal to 0, thus causing a
divide-by-zero error.  Since this error affected only jpegtran and not
any of the libraries (the tjTransform() function in the TurboJPEG API
does not expose the image drop feature), it did not represent a security
risk.  In fact, this commit does not change the output of jpegtran when
attempting to transform the aforementioned corrupt source image.  It
merely eliminates the floating point exception.  Like most issues of
this type, however, eliminating the error prevents it from hiding
legitimate security issues that may later be introduced.

Fixes #635
Fixes #636
2022-12-07 14:01:40 -06:00
DRC
5da86f7430 ChangeLog.md: List CVE ID fixed by 9120a247 2022-12-07 09:45:57 -06:00
DRC
7bb5cb560e ChangeLog.md: List CVE ID fixed by f35fd27e 2022-12-07 09:39:03 -06:00
DRC
0f047a5747 Merge branch 'main' into dev 2022-11-30 18:45:50 -06:00
DRC
7f2eb09d6e BUILDING.md: Add Arm64 iOS sim build instructions
Unfortunately, iOS builds cannot be used with the iOS simulator on Macs
with Apple silicon CPUs.  Even more unfortunately, universal binaries
can only have one slice for each CPU architecture, so it would not be
possible to add a dedicated Arm64 iOS simulator slice to the existing
libjpeg-turbo iOS binaries.  (It would be necessary to release a
separate package solely for the iOS simulator.)  Because the Arm Neon
SIMD extensions for libjpeg-turbo now use compiler intrinsics when
building with Xcode, it is easy to build libjpeg-turbo from source when
targeting Arm64-based Apple platforms.  Thus, for the moment, I have
chosen to document how to avoid the pothole rather than to fill it in.
2022-11-30 18:44:45 -06:00
DRC
e2a98701e4 turbojpeg.c: Fix build if !C_LOSSLESS_SUPPORTED 2022-11-30 11:06:37 -06:00
DRC
73ca9712e3 Merge branch 'main' into dev 2022-11-30 11:03:43 -06:00
DRC
403cfad611 djpeg.c: Fix build if !SAVE_MARKERS_SUPPORTED 2022-11-30 10:43:29 -06:00
DRC
c4105ba7ef turbojpeg.c: Fix build if !C_PROGRESSIVE_SUPPORTED 2022-11-30 10:41:32 -06:00
DRC
e7a248ebb7 Merge branch 'main' into dev 2022-11-29 01:08:27 -06:00
DRC
45cd2ded88 12-bit: Prevent RGB-to-YCC table overrun/underrun
cjpeg relies on the various file I/O modules to range-limit the input
samples, but no range limiting is performed by the
jpeg_write_scanlines() function itself.  With 8-bit samples, that isn't
a problem, because sample values > MAXJSAMPLE will overflow the data
type and wrap around to 0.  With 12-bit samples, however, it is possible
to pass sample values < 0 or > 4095 to jpeg_write_scanlines(), which
would cause the RGB-to-YCbCr color converter to underflow or overflow
the RGB-to-YCbCr conversion tables.  That issue has existed in libjpeg
all along.  This commit mitigates the issue by masking off all but the
lowest 12 bits of each 12-bit input sample prior to using the input
sample value to index the RGB-to-YCbCr conversion tables.

Fixes #633
2022-11-29 00:53:55 -06:00
DRC
8b9bc4b963 jconfig.h: Restore BITS_IN_JSAMPLE macro
Because of e8b40f3c2b, we now support
multiple data precisions in the same libjpeg API library, so
BITS_IN_JSAMPLE is no longer used to specify the data precision at build
time.  However, some downstream software expects the macro to be
defined.  Since 12-bit data precision is an opt-in feature that requires
explicitly calling 12-bit-specific libjpeg API functions and using
12-bit-specific data types, the unmodified portion of the libjpeg API
still behaves as if it were built for 8-bit precision, and JSAMPLE is
still literally an 8-bit data type.  Thus, it is correct to externally
define BITS_IN_JSAMPLE to 8 in jconfig.h.  Since the build system also
uses BITS_IN_JSAMPLE internally to build both 8-bit and 12-bit versions
of relevant modules, the definition of BITS_IN_JSAMPLE in jconfig.h is
now guarded by #ifndef BITS_IN_JSAMPLE.  (Hopefully that doesn't cause
any problems.)

Fixes #632
2022-11-23 16:35:58 -06:00
DRC
4afa4d3ee8 jconfig.h: Restore MEM_SRCDST_SUPPORTED macro
That macro has been defined in jconfig.h since libjpeg-turbo 1.3.x, so
it is possible that some downstream software conditions the use of the
jpeg_mem_*() functions on whether MEM_SRCDST_SUPPORTED is defined or
JPEG_LIB_VERSION >= 80 (as libjpeg-turbo 2.1.x and prior did
internally.)
2022-11-23 16:35:54 -06:00
DRC
140a1ea315 tjEncodeYUVPlanes(): Ignore TJFLAG_LOSSLESS
TJFLAG_LOSSLESS is irrelevant to planar YUV encoding, and setting the
flag caused tjEncode*() to fail with "Invalid lossless parameters"
because tjEncodeYUVPlanes() passes a JPEG quality value of -1 to
setCompDefaults().  This commit modifies setCompDefaults() so that it
takes no action related to the jpegQual parameter unless jpegQual >= 0.
2022-11-22 10:47:44 -06:00
DRC
382563a58c Build: Add missing tjbenchtest -arithmetic tests
... if WITH_JAVA=0.

(Oversight from 6002720c37)
2022-11-21 22:46:30 -06:00
DRC
98ff1fd103 TurboJPEG: Add lossless JPEG detection capability
Add a new TurboJPEG C API function (tjDecompressHeader4()) and Java API
method (TJDecompressor.getFlags()) that return the bitwise OR of any
flags that are relevant to the JPEG image being decompressed (currently
TJFLAG_PROGRESSIVE, TJFLAG_ARITHMETIC, TJFLAG_LOSSLESS, and their Java
equivalents.)  This allows a calling program to determine whether the
image being decompressed is a lossless JPEG image, which means that the
decompression scaling feature will not be available and that a
full-sized destination buffer should be allocated.

More specifically, this fixes a buffer overrun in TJBench, TJExample,
and the decompress* fuzz targets that occurred when attempting (in vain)
to decompress a lossless JPEG image with decompression scaling enabled.
2022-11-21 22:46:12 -06:00
DRC
b85b028d2b OSS-Fuzz: Fix argument error in cjpeg12 target
Smoothing can only be used with 4:2:0 subsampling.
2022-11-21 22:42:59 -06:00
DRC
db9dd93da4 Lossless: Fix innocuous UBSan warnings 2022-11-21 22:42:59 -06:00
DRC
07129256e0 OSS-Fuzz: Add fuzz target for lossless JPEG 2022-11-21 22:42:59 -06:00
DRC
1a31176e0c Merge branch 'main' into dev 2022-11-21 22:42:46 -06:00
DRC
74d5b168f7 Build: Update tjtest target dependencies 2022-11-21 22:41:46 -06:00
DRC
25ccad99a0 TurboJPEG: 8-bit lossless JPEG support 2022-11-16 15:57:25 -06:00
DRC
3fb10c35d8 Merge branch 'ijg.lossless' into dev
Lossless: Accommodate LJT colorspace/SIMD exts

In libjpeg-turbo, grayscale_convert() and null_convert() aren't the only
lossless color conversion algorithms.  We can also losslessly convert
RGB to and from any of the extended RGB colorspaces, and some platforms
have SIMD-accelerated null color conversion.

This commit also disallows RGB565 output in lossless mode, and it moves
the IsExtRGB() macro from cdjpeg.h to jpegint.h and repurposes it to
make jinit_color_converter() and jinit_color_deconverter() more
readable.
2022-11-16 12:35:40 -06:00
DRC
af618ffe09 Clean up the lossless JPEG feature
- Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the
  function so that it stores the lossless parameters directly in the Ss
  and Al fields of jpeg_compress_struct rather than using a scan script.

- Move the cjpeg -lossless switch into "Switches for advanced users".

- Document the libjpeg API and run-time features that are unavailable in
  lossless mode, and ensure that all parameters, functions, and switches
  related to unavailable features are ignored or generate errors in
  lossless mode.

- Defer any action that depends on whether lossless mode is enabled
  until jpeg_start_compress()/jpeg_start_decompress() is called.

- Document the purpose of the point transform value.

- "Codec" stands for coder/decoder, so it is a bit awkward to say
  "lossless compression codec" and "lossless decompression codec".
  Use "lossless compressor" and "lossless decompressor" instead.

- Restore backward API/ABI compatibility with libjpeg v6b:

  * Move the new 'lossless' field from the exposed jpeg_compress_struct
    and jpeg_decompress_struct structures into the opaque
    jpeg_comp_master and jpeg_decomp_master structures, and allocate the
    master structures in the body of jpeg_create_compress() and
    jpeg_create_decompress().

  * Remove the new 'process' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with the old
    'progressive_mode' field and the new 'lossless' field.

  * Remove the new 'data_unit' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with a locally-computed
    data unit variable.

  * Restore the names of macros and fields that refer to DCT blocks, and
    document that they have a different meaning in lossless mode.  (Most
    of them aren't very meaningful in lossless mode anyhow.)

  * Remove the new alloc_darray() method from jpeg_memory_mgr and
    replace it with an internal macro that wraps the alloc_sarray()
    method.

  * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into
    jpegint.h.

  * Remove the new 'codec' field from jpeg_compress_struct and
    jpeg_decompress_struct and instead reuse the existing internal
    coefficient control, forward/inverse DCT, and entropy
    encoding/decoding structures for lossless compression/decompression.

  * Repurpose existing error codes rather than introducing new ones.
    (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain,
    although JWRN_MUST_DOWNSCALE will probably be removed in
    libjpeg-turbo, since we have a different way of handling multiple
    data precisions.)

- Automatically enable lossless mode when a scan script with parameters
  that are only valid for lossless mode is detected, and document the
  use of scan scripts to generate lossless JPEG images.

- Move the sequential and shared Huffman routines back into jchuff.c and
  jdhuff.c, and document that those routines are shared with jclhuff.c
  and jdlhuff.c as well as with jcphuff.c and jdphuff.c.

- Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where
  it is used.

- Move the predictor and scaler code into jclossls.c and jdlossls.c.

- Streamline register usage in the [un]differencers (inspired by similar
  optimizations in the color [de]converters.)

- Restructure the logic in a few places to reduce duplicated code.

- Ensure that all lossless-specific code is guarded by
  C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can
  be built successfully if either or both of those macros is undefined.

- Remove all short forms of external names introduced by the lossless
  JPEG patch.  (These will not be needed by libjpeg-turbo, so there is
  no use cleaning them up.)

- Various wordsmithing, formatting, and punctuation tweaks

- Eliminate various compiler warnings.
2022-11-16 11:27:18 -06:00
DRC
918ace631e example.c: Fix compiler warning 2022-11-16 10:36:57 -06:00
DRC
766910e8b2 Merge branch 'ijg.lossless' into dev
Fix segfault when decomp lossless JPEG w/ restarts

The predict_process_restart() method in jpeg_lossless_decompressor was
unset, because we now use the start_pass() method in jpeg_inverse_dct
instead.  Thus, a segfault occurred when attempting to decompress a
lossless JPEG that contained restart markers.
2022-11-16 01:03:15 -06:00
DRC
b56e8b28ba Clean up the lossless JPEG feature
- Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the
  function so that it stores the lossless parameters directly in the Ss
  and Al fields of jpeg_compress_struct rather than using a scan script.

- Move the cjpeg -lossless switch into "Switches for advanced users".

- Document the libjpeg API and run-time features that are unavailable in
  lossless mode, and ensure that all parameters, functions, and switches
  related to unavailable features are ignored or generate errors in
  lossless mode.

- Defer any action that depends on whether lossless mode is enabled
  until jpeg_start_compress()/jpeg_start_decompress() is called.

- Document the purpose of the point transform value.

- "Codec" stands for coder/decoder, so it is a bit awkward to say
  "lossless compression codec" and "lossless decompression codec".
  Use "lossless compressor" and "lossless decompressor" instead.

- Restore backward API/ABI compatibility with libjpeg v6b:

  * Move the new 'lossless' field from the exposed jpeg_compress_struct
    and jpeg_decompress_struct structures into the opaque
    jpeg_comp_master and jpeg_decomp_master structures, and allocate the
    master structures in the body of jpeg_create_compress() and
    jpeg_create_decompress().

  * Remove the new 'process' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with the old
    'progressive_mode' field and the new 'lossless' field.

  * Remove the new 'data_unit' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with a locally-computed
    data unit variable.

  * Restore the names of macros and fields that refer to DCT blocks, and
    document that they have a different meaning in lossless mode.  (Most
    of them aren't very meaningful in lossless mode anyhow.)

  * Remove the new alloc_darray() method from jpeg_memory_mgr and
    replace it with an internal macro that wraps the alloc_sarray()
    method.

  * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into
    jpegint.h.

  * Remove the new 'codec' field from jpeg_compress_struct and
    jpeg_decompress_struct and instead reuse the existing internal
    coefficient control, forward/inverse DCT, and entropy
    encoding/decoding structures for lossless compression/decompression.

  * Repurpose existing error codes rather than introducing new ones.
    (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain,
    although JWRN_MUST_DOWNSCALE will probably be removed in
    libjpeg-turbo, since we have a different way of handling multiple
    data precisions.)

- Automatically enable lossless mode when a scan script with parameters
  that are only valid for lossless mode is detected, and document the
  use of scan scripts to generate lossless JPEG images.

- Move the sequential and shared Huffman routines back into jchuff.c and
  jdhuff.c, and document that those routines are shared with jclhuff.c
  and jdlhuff.c as well as with jcphuff.c and jdphuff.c.

- Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where
  it is used.

- Move the predictor and scaler code into jclossls.c and jdlossls.c.

- Streamline register usage in the [un]differencers (inspired by similar
  optimizations in the color [de]converters.)

- Restructure the logic in a few places to reduce duplicated code.

- Ensure that all lossless-specific code is guarded by
  C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can
  be built successfully if either or both of those macros is undefined.

- Remove all short forms of external names introduced by the lossless
  JPEG patch.  (These will not be needed by libjpeg-turbo, so there is
  no use cleaning them up.)

- Various wordsmithing, formatting, and punctuation tweaks

- Eliminate various compiler warnings.
2022-11-16 00:49:15 -06:00
DRC
6002720c37 TurboJPEG: Opt. enable arithmetic entropy coding 2022-11-15 23:38:55 -06:00
DRC
bc086c4427 Merge branch 'main' into dev 2022-11-15 23:38:47 -06:00
DRC
eb1fd4ad34 Build: Fix typo in tjtest target 2022-11-15 23:38:19 -06:00
DRC
ed73fdc9be Merge branch 'main' into dev 2022-11-15 21:28:01 -06:00
Erin Melucci
37dd973bef Win: Use wchar_t for copyright string in RC files
llvm-rc doesn't like the copyright symbol in the LegalCopyright string.

Possible solutions:
1. Replace the copyright symbol with "(C)".
2. Prefix the string literal with L, thus making it a wide character
   string.
3. Pass -c65001 to the resource compiler to enable the UTF-8 code page.

Option 2 is the least disruptive, since it doesn't change the behavior
of the official builds or require any build system modifications.

Closes #627
2022-11-15 21:12:54 -06:00
DRC
78a36f6dc3 Fix buffer overrun in 12-bit prog Huffman encoder
Regression introduced by 16bd984557 and
5b177b3cab

The pre-computed absolute values used in encode_mcu_AC_first() and
encode_mcu_AC_refine() were stored in a JCOEF (signed short) array.
When attempting to losslessly transform a specially-crafted malformed
12-bit JPEG image with a coefficient value of -32768 into a progressive
12-bit JPEG image, the progressive Huffman encoder attempted to store
the absolute value of -32768 in the JCOEF array, thus overflowing the
16-bit signed data type.  Therefore, at this point in the code:
8c5e78ce29/jcphuff.c (L889)
the absolute value was read as -32768, which caused the test at
8c5e78ce29/jcphuff.c (L896)
to fail, falling through to
8c5e78ce29/jcphuff.c (L908)
with an overly large value of r (46) that, when shifted left four
places, incremented, and passed to emit_symbol(), exceeded the maximum
index (255) for the derived code tables.  Fortunately, the buffer
overrun was fully contained within phuff_entropy_encoder, so the issue
did not generate a segfault or other user-visible errant behavior, but
it did cause a UBSan failure that was detected by OSS-Fuzz.

This commit introduces an unsigned JCOEF (UJCOEF) data type and uses it
to store the absolute values of DCT coefficients computed by the
AC_first_prepare() and AC_refine_prepare() methods.

Note that the changes to the Arm Neon progressive Huffman encoder
extensions cause signed 16-bit instructions to be replaced with
equivalent unsigned 16-bit instructions, so the changes should be
performance-neutral.

Based on:
bbf61c0382

Closes #628
2022-11-15 19:07:50 -06:00
DRC
aa3dd0bd29 TurboJPEG: Nix unneeded setDecodeDefaults ret val
The return value was inherited from setDecompDefaults() in
34dca05227, but it was never needed.
2022-11-15 15:41:07 -06:00
DRC
1926ab4186 ChangeLog.md: Multi-precision feature wordsmithing
- Because of b5a9ef64ea, "by default" is
  no longer applicable.  (12-bit-per-component JPEG support is now part
  of the core libjpeg-turbo functionality and cannot be disabled.)

- Change awkward "can be used to enable the creation of" to less awkward
  "can be used to create".
2022-11-14 16:31:41 -06:00
DRC
99866007c6 jclhuff.c: Fix innocuous UBSan left shift warning
This applies the progressive Huffman encoder fixes from
aa769febf2 and
d65e768b2e to the new lossless mode
Huffman encoder.
2022-11-14 16:26:41 -06:00
DRC
8fc9356581 usage.txt: Move -precision into advanced switches
(to match cjpeg man page and usage screen)
2022-11-14 16:11:30 -06:00
DRC
97772cba65 Merge branch 'ijg.lossless' into dev
Refer to #402
2022-11-14 15:36:25 -06:00
DRC
217d1a75f5 Clean up the lossless JPEG feature
- Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the
  function so that it stores the lossless parameters directly in the Ss
  and Al fields of jpeg_compress_struct rather than using a scan script.

- Move the cjpeg -lossless switch into "Switches for advanced users".

- Document the libjpeg API and run-time features that are unavailable in
  lossless mode, and ensure that all parameters, functions, and switches
  related to unavailable features are ignored or generate errors in
  lossless mode.

- Defer any action that depends on whether lossless mode is enabled
  until jpeg_start_compress()/jpeg_start_decompress() is called.

- Document the purpose of the point transform value.

- "Codec" stands for coder/decoder, so it is a bit awkward to say
  "lossless compression codec" and "lossless decompression codec".
  Use "lossless compressor" and "lossless decompressor" instead.

- Restore backward API/ABI compatibility with libjpeg v6b:

  * Move the new 'lossless' field from the exposed jpeg_compress_struct
    and jpeg_decompress_struct structures into the opaque
    jpeg_comp_master and jpeg_decomp_master structures, and allocate the
    master structures in the body of jpeg_create_compress() and
    jpeg_create_decompress().

  * Remove the new 'process' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with the old
    'progressive_mode' field and the new 'lossless' field.

  * Remove the new 'data_unit' field from jpeg_compress_struct and
    jpeg_decompress_struct and replace it with a locally-computed
    data unit variable.

  * Restore the names of macros and fields that refer to DCT blocks, and
    document that they have a different meaning in lossless mode.  (Most
    of them aren't very meaningful in lossless mode anyhow.)

  * Remove the new alloc_darray() method from jpeg_memory_mgr and
    replace it with an internal macro that wraps the alloc_sarray()
    method.

  * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into
    jpegint.h.

  * Remove the new 'codec' field from jpeg_compress_struct and
    jpeg_decompress_struct and instead reuse the existing internal
    coefficient control, forward/inverse DCT, and entropy
    encoding/decoding structures for lossless compression/decompression.

  * Repurpose existing error codes rather than introducing new ones.
    (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain,
    although JWRN_MUST_DOWNSCALE will probably be removed in
    libjpeg-turbo, since we have a different way of handling multiple
    data precisions.)

- Automatically enable lossless mode when a scan script with parameters
  that are only valid for lossless mode is detected, and document the
  use of scan scripts to generate lossless JPEG images.

- Move the sequential and shared Huffman routines back into jchuff.c and
  jdhuff.c, and document that those routines are shared with jclhuff.c
  and jdlhuff.c as well as with jcphuff.c and jdphuff.c.

- Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where
  it is used.

- Move the predictor and scaler code into jclossls.c and jdlossls.c.

- Streamline register usage in the [un]differencers (inspired by similar
  optimizations in the color [de]converters.)

- Restructure the logic in a few places to reduce duplicated code.

- Ensure that all lossless-specific code is guarded by
  C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can
  be built successfully if either or both of those macros is undefined.

- Remove all short forms of external names introduced by the lossless
  JPEG patch.  (These will not be needed by libjpeg-turbo, so there is
  no use cleaning them up.)

- Various wordsmithing, formatting, and punctuation tweaks

- Eliminate various compiler warnings.
2022-11-14 14:55:04 -06:00
DRC
b5a9ef64ea Don't allow 12-bit JPEG support to be disabled
In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used
to enable 12-bit JPEG support at compile time, because the libjpeg API
library could not handle multiple JPEG data precisions at run time.  The
initial approach to handling multiple JPEG data precisions at run time
(7fec5074f9) created a whole new API,
library, and applications for 12-bit data precision, so it made sense to
repurpose WITH_12BIT to allow 12-bit data precision to be disabled.
e8b40f3c2b made it so that the libjpeg API
library can handle multiple JPEG data precisions at run time via a
handful of straightforward API extensions.  Referring to
6c2bc901e2, it hasn't been possible to
build libjpeg-turbo with both forward and backward libjpeg API/ABI
compatibility since libjpeg-turbo 1.4.x.  Thus, whereas we retain full
backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg
API/ABI compatibility ceased being realistic years ago, so it no longer
makes sense to provide compile-time options that give a false sense of
forward API/ABI compatibility by allowing some (but not all) of our
libjpeg API extensions to be disabled.  Such options are difficult to
maintain and clutter the code with #ifdefs.
2022-11-13 13:38:48 -06:00
DRC
9ca7919a40 OSS-Fuzz: Fix bug in the new cjpeg12 fuzzer
cjpeg doesn't accept image format arguments other than -targa (it
auto-detects the others), and since Targa images aren't supported with
12-bit precision, we don't need a second pass.
2022-11-07 10:39:03 -06:00
DRC
bf01ed2fbc Fix build when SIMD extensions are disabled
(Broken by previous commit)
2022-11-04 13:35:03 -05:00
DRC
e8b40f3c2b Vastly improve 12-bit JPEG integration
The Gordian knot that 7fec5074f9 attempted
to unravel was caused by the fact that there are several
data-precision-dependent (JSAMPLE-dependent) fields and methods in the
exposed libjpeg API structures, and if you change the exposed libjpeg
API structures, then you have to change the whole API.  If you change
the whole API, then you have to provide a whole new library to support
the new API, and that makes it difficult to support multiple data
precisions in the same application.  (It is not impossible, as example.c
demonstrated, but using data-precision-dependent libjpeg API structures
would have made the cjpeg, djpeg, and jpegtran source code hard to read,
so it made more sense to build, install, and package 12-bit-specific
versions of those applications.)

Unfortunately, the result of that initial integration effort was an
unreadable and unmaintainable mess, which is a problem for a library
that is an ISO/ITU-T reference implementation.  Also, as I dug into the
problem of lossless JPEG support, I realized that 16-bit lossless JPEG
images are a thing, and supporting yet another version of the libjpeg
API just for those images is untenable.

In fact, however, the touch points for JSAMPLE in the exposed libjpeg
API structures are minimal:

  - The colormap and sample_range_limit fields in jpeg_decompress_struct
  - The alloc_sarray() and access_virt_sarray() methods in
    jpeg_memory_mgr
  - jpeg_write_scanlines() and jpeg_write_raw_data()
  - jpeg_read_scanlines() and jpeg_read_raw_data()
  - jpeg_skip_scanlines() and jpeg_crop_scanline()
    (This is subtle, but both of those functions use JSAMPLE-dependent
    opaque structures behind the scenes.)

It is much more readable and maintainable to provide 12-bit-specific
versions of those six top-level API functions and to document that the
aforementioned methods and fields must be type-cast when using 12-bit
samples.  Since that eliminates the need to provide a 12-bit-specific
version of the exposed libjpeg API structures, we can:

  - Compile only the precision-dependent libjpeg modules (the
    coefficient buffer controllers, the colorspace converters, the
    DCT/IDCT managers, the main buffer controllers, the preprocessing
    and postprocessing controller, the downsampler and upsamplers, the
    quantizers, the integer DCT methods, and the IDCT methods) for
    multiple data precisions.
  - Introduce 12-bit-specific methods into the various internal
    structures defined in jpegint.h.
  - Create precision-independent data type, macro, method, field, and
    function names that are prefixed by an underscore, and use an
    internal header to convert those into precision-dependent data
    type, macro, method, field, and function names, based on the value
    of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg
    modules.
  - Expose precision-dependent jinit*() functions for each of the
    precision-dependent libjpeg modules.
  - Abstract the precision-dependent libjpeg modules by calling the
    appropriate precision-dependent jinit*() function, based on the
    value of cinfo->data_precision, from top-level libjpeg API
    functions.
2022-11-04 12:30:33 -05:00
DRC
6c2bc901e2 Don't allow disabling in-memory src/dest managers
By default, libjpeg-turbo 1.3.x and later have enabled the in-memory
source/destination manager functions from libjpeg v8 when emulating the
libjpeg v6b or v7 API/ABI, which has allowed operating system
distributors to provide those functions without adopting the
backward-incompatible libjpeg v8 API/ABI.

Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable
the in-memory source/destination manager functions at build time and
thus retain both backward and forward API/ABI compatibility relative to
libjpeg v6b or v7.  Since then, however, we have introduced several new
libjpeg API functions that break forward API/ABI compatibility, so it no
longer makes sense to allow the in-memory source/destination managers to
be disabled.  libjpeg-turbo only claims to be
backward-API/ABI-compatible, i.e. to allow applications built against
libjpeg or an older version of libjpeg-turbo to work properly with the
current version of libjpeg-turbo.
2022-11-03 15:22:19 -05:00
DRC
664b64a9ac Merge branch 'main' into dev 2022-11-03 14:25:35 -05:00
DRC
4f7a8afbb7 Build: Fix issues w/ Ninja Multi-Config generator
- Fix an issue whereby a build with ENABLE_SHARED=0 could not be
  installed when using the Ninja Multi-Config CMake generator.

- Fix an issue whereby a Windows installer could not be built when using
  the Ninja Multi-Config CMake generator.

- Fix an issue whereby the Java regression tests failed when using the
  Ninja Multi-Config CMake generator.

Based on:
4f169deeb0

Closes #626
2022-11-03 14:23:55 -05:00
DRC
8c5e78ce29 Build: Document SO_AGE and TURBOJPEG_SO_AGE vars 2022-11-03 14:23:03 -05:00
DRC
8917c54877 ChangeLog.md: Add colons to sub-headers
For some reason, I failed to add a colon to the "Significant changes
relative to 2.1 beta1" sub-header, and the mistake propagated from
there.
2022-11-03 14:20:22 -05:00
DRC
cb3642cb0b Bump version to 2.1.5 to prepare for new commits 2022-11-03 12:23:11 -05:00
DRC
ec6e451d05 Lossless JPEG support: Add copyright attributions
Referring to
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/402#issuecomment-768348440
and
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/402#issuecomment-770221584

Ken Murchison clarified that it was his intent to release the lossless
JPEG patch under the IJG License and that adding his name to the
copyright headers would be sufficient to acknowledge that any
derivatives are based on his work.
2022-10-21 16:53:53 -05:00
DRC
2df43f51f1 Lossless JPEG support: Fix build
(Modern compilers require function prototypes.)
2022-10-21 16:32:34 -05:00
Ken Murchison
2e8360e061 IJG's JPEG software v6b with lossless JPEG support
Patch obtained from:
https://sourceforge.net/projects/jpeg/files/ftp.oceana.com

Author date taken from original announcement and timestamp of patch
tarball:
https://groups.google.com/g/comp.protocols.dicom/c/rrkP8BxoMRk/m/Ij4dfprggp8J
2022-10-21 13:42:59 -05:00
DRC
4d269d7cd5 Merge branch 'main' into dev 2022-10-21 12:22:28 -05:00
DRC
51f1924e77 wizard.txt: Clarify scan script restrictions
The Wallace paper is not entirely clear on these restrictions, and the
spec itself requires some digging.

Closes #624
2022-10-21 12:20:41 -05:00
DRC
5acd9f2061 Merge branch 'main' into dev 2022-10-04 12:58:11 -05:00
DRC
eb0a024af2 Remove redundant jconfigint.h #includes
Because of 607b668ff9, jconfigint.h is
included by jinclude.h.
2022-10-04 12:51:52 -05:00
DRC
543bfc25f5 Merge branch 'main' into dev 2022-10-03 21:38:15 -05:00
DRC
f579cc11b3 Make SIMD capability variables thread-local ...
... on platforms that support TLS, which should include all
currently-supported platforms
(https://libjpeg-turbo.org/Documentation/OfficialBinaries)

Addresses a concern raised in #87

Although it is still my opinion that the data race in init_simd() was
innocuous, we can now fix it for free thanks to
ae87a95861, so why not?
2022-10-03 21:36:21 -05:00
DRC
2fd634b833 Merge branch 'main' into dev 2022-09-12 23:36:34 -05:00
DRC
2cad2169ae BUILDING.md: Acknowledge RHEL 9 2022-09-12 21:54:35 -05:00
DRC
b3d3cbf43d JNI: Remove deprecated methods
(oversight from 931884e78d)
2022-09-12 14:41:34 -05:00
DRC
fdfba4957c Merge branch 'main' into dev 2022-09-02 15:11:25 -05:00
DRC
c5db99e1aa GitHub Actions: Specify Big Sur for macOS build
The Catalina hosted runner is now fully deprecated.
2022-09-02 14:48:58 -05:00
Kornel
fd56921259 Merge commit '8162eddf041e0be26f5c671bb6528723c55fed9d'
* commit '8162eddf041e0be26f5c671bb6528723c55fed9d': (24 commits)
  Fix issues w/ partial img decompr + buf img mode
  Re-fix buf img mode decompr err w/short prog JPEGs
  jdcoefct.c: Fix signed/unsigned mismatch VC++ wrng
  Fix buf image mode decompr err w/ short prog JPEGs
  PowerPC: Detect AltiVec support on OS X
  tjDecompressHeader3(): Accept tables-only streams
  Fix build if UPSAMPLE_MERGING_SUPPORTED undefined
  Build: Don't enable Loongson MMI with MIPS R6+
  MinGW: Fix str*casecmp() macro redef. warning
  OSS-Fuzz: '.' --> '_' in fuzzer suffix
  Don't install libturbojpeg.pc if WITH_TURBOJPEG=0
  Fix non-SIMD alignment if void* bigger than double
  OSS-Fuzz: Allow fuzzer suffix to be specified
  CI: Un-integrate CIFuzz
  BUILDING.md: Generify PowerTools repo advice
  Build: Don't set DEFAULT_FLOATTEST for x86 MSVC
  Build/Win: Fix CMake warning when WITH_TURBOJPEG=0
  Win: Fix build with Visual Studio 2010
  Link Sponsor button to GitHub Sponsors ...
  example.txt: Fix a typo
  ...
2022-08-15 02:46:09 +01:00
Kornel
a2d2907ff0 Fix env var name typo 2022-08-15 02:13:17 +01:00
DRC
513f9e6628 Merge branch 'main' into dev 2022-08-09 04:27:33 -05:00
DRC
8162eddf04 Fix issues w/ partial img decompr + buf img mode
Fixes #611
2022-08-08 16:03:55 -05:00
DRC
931884e78d Java: Remove deprecated fields, ctors, and methods
Most of these have been deprecated since libjpeg-turbo 1.4.x.
It's time.
2022-08-08 15:41:01 -05:00
DRC
280784f7ab Merge branch 'main' into dev 2022-08-08 15:07:45 -05:00
DRC
2e136a7190 Re-fix buf img mode decompr err w/short prog JPEGs
This commit reverts 4dbc293125 and
9f8f683e74 (the previous two commits) and
fixes #613 the correct way.  The crux of the issue wasn't the size of
the whole_image virtual array but rather that, since last_iMCU_row is
unsigned, (last_iMCU_row - 1) wrapped around to 0xFFFFFFFF when
last_iMCU_row was 0.  This caused the interblock smoothing algorithm
introduced in 6d91e950c8 to erroneously
try to access the next two iMCU rows, neither of which existed.  The
first attempt at a fix (4dbc293125)
exposed a NULL dereference, detected by OSS-Fuzz, that occurred when
attempting to decompress a specially-crafted malformed JPEG image to a
YUV buffer using tjDecompressToYUV*() with 1/4 IDCT scaling.

Fixes #613 (again)
Also fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49898
2022-08-08 15:06:56 -05:00
DRC
f627319258 Merge branch 'main' into dev 2022-08-07 14:16:28 -05:00
DRC
9f8f683e74 jdcoefct.c: Fix signed/unsigned mismatch VC++ wrng
(introduced by previous commit)
2022-08-07 14:15:03 -05:00
DRC
9a60181b3d Merge branch 'main' into dev 2022-08-07 13:48:31 -05:00
DRC
4dbc293125 Fix buf image mode decompr err w/ short prog JPEGs
Regression introduced by 6d91e950c8

Because we're now using a 5x5 smoothing window when decompressing
progressive JPEG images, we need to ensure that the whole_image virtual
array contains at least five rows.  Previously that was not always the
case unless the progressive JPEG image being decompressed had at least
five iMCU rows.  Since an iMCU has a height of (8 * the vertical
sampling factor), attempting to decompress 4:2:2 and 4:4:4 images <= 32
pixels in height or 4:2:0 images <= 64 pixels in height triggered a
JERR_BAD_VIRTUAL_ACCESS error in decompress_smooth_data(), because
access_rows exceeded the number of rows in the virtual array.

Fixes #613
2022-08-07 13:38:47 -05:00
DRC
fc224c4889 Merge branch 'main' into dev 2022-07-07 13:11:05 -05:00
Donovan Watteau
59337a67b1 PowerPC: Detect AltiVec support on OS X
libjpeg-turbo's AltiVec SIMD extensions previously assumed that AltiVec
instructions were available on all Power Macs that supported OS X 10.4
"Tiger" (the earliest version of OS X that libjpeg-turbo has ever
supported), but Tiger can actually run on PowerPC G3 processors, which
lack AltiVec instructions.  This commit enables run-time detection of
AltiVec instructions on OS X/PowerPC systems if AltiVec instructions are
not force-enabled at compile time (using -maltivec).  This allows the
same build of libjpeg-turbo to support G3, G4, and G5 Power Macs.

Closes #609
2022-07-07 13:01:11 -05:00
DRC
8a3b0f70d2 Implement 12-bit-specific error/warn/trace macros
The macros in jerror.h refer to j_common_ptr, so it is unfortunately
necessary to introduce a 12-bit-specific version of that header file
(j12error.h) with 12-bit specific ERREXIT*(), WARNMS*(), and
TRACEMS*() macros.  (The message table is still shared between 8-bit and
12-bit implementations.)

Fixes #607
2022-06-24 15:36:28 -05:00
Jon Craton
08978e58db Update quant-table help
Update cjpeg -help for quant-table entry to include 3 additional tables listed in README-mozilla.txt and indicate the default table.
2022-06-24 21:20:21 +01:00
DRC
aa5a359945 Merge branch 'main' into dev 2022-06-24 14:21:33 -05:00
DRC
ba22c0f76d tjDecompressHeader3(): Accept tables-only streams
Inspired by:
b3b15cfe74

Closes #604
Closes #605
2022-06-24 14:10:44 -05:00
DRC
225781aff9 jchuff.c: Clean up aadd60ae + add code comments
Based on:
4d73f52032
184f10703e

Refer to #602
2022-06-14 15:15:34 -05:00
DRC
faa7c74aef ChangeLog.md: Acknowledge 2.1.4 release 2022-05-31 13:37:05 -05:00
Felix Hanau
aadd60ae49 Speed up computation of optimal Huffman tables
Closes #602
2022-05-31 13:37:00 -05:00
DRC
0000dadf17 Merge branch 'main' into dev 2022-05-27 12:15:04 -05:00
DRC
a405519e96 Fix build if UPSAMPLE_MERGING_SUPPORTED undefined
Although it is uncommon, some downstream implementations undefine one or
more of the *_SUPPORTED macros in jmorecfg.h in order to reduce the size
of the library.  In the interest of maintaining backward compatibility
with libjpeg, this is still a supported use case.

Regression introduced by 9120a24743

Based on:
74c4d032f0

Closes #601
2022-05-27 11:59:56 -05:00
Jiaxun Yang
fac8381441 Build: Don't enable Loongson MMI with MIPS R6+
MIPS R6 removed some instructions, so Loongson MMI cannot be built with
MIPS R6+ toolchains.

Closes #598
2022-05-24 09:25:55 -05:00
Kornel
5c6a0f0971 Update to libjpeg-turbo 2.1.3 2022-05-23 16:06:07 +01:00
Kornel
5e797fa699 Merge tag '2.1.3' into master-moz
* tag '2.1.3': (56 commits)
  Neon/AArch64: Explicitly unroll quant loop w/Clang
  Neon/AArch64: Fix/suppress UBSan warnings
  Neon/AArch64: Accelerate Huffman encoding
  AppVeyor: Test strict MSVC compiler warnings
  Eliminate incompatible pointer type warnings
  MSVC: Eliminate int conversion warnings (C4244)
  MSVC: Eliminate C4996 warnings in API libs
  BUILDING.md: Clarify that Ninja works with Windows
  BUILDING.md: Remove NASM RPM rebuild instructions
  BUILDING.md: Document NASM/Yasm path variables
  "YASM" = "Yasm"
  Build: Fix Neon capability detection w/ MSVC
  Ensure that strncpy() dest strings are terminated
  Eliminate unnecessary JFREAD()/JFWRITE() macros
  Build: Embed version/API/(C) info in MSVC DLLs
  Fix segv w/ h2v2 merged upsamp, jpeg_crop_scanline
  TJBench: Remove innocuous always-true condition
  GitHub Actions: Specify Catalina for macOS build
  Fix -Wpedantic compiler warnings
  Eliminate non-ANSI C compatibility macros
  ...
2022-05-23 16:04:06 +01:00
DRC
0f5d31e62f Merge branch 'main' into dev 2022-04-28 20:04:53 -05:00
modbw
290ddbf71a MinGW: Fix str*casecmp() macro redef. warning
MinGW defines strcasecmp() and strncasecmp() as macros in string.h if
__CRT__NO_INLINE is defined, which will be the case when including any
of the Win32 API headers.

Closes #594
2022-04-28 20:02:28 -05:00
DRC
b98dabac24 Merge branch 'main' into dev 2022-04-27 12:38:58 -05:00
DRC
9171fd4bde OSS-Fuzz: '.' --> '_' in fuzzer suffix
Referring to https://github.com/google/oss-fuzz/issues/7575, if the
fuzzer suffix contains periods, it can cause ClusterFuzz to misinterpret
the file extension of the fuzzer executables and thus misidentify them.
2022-04-27 12:34:28 -05:00
DRC
d0e7c4548a Don't install libturbojpeg.pc if WITH_TURBOJPEG=0
Fixes #593
2022-04-18 11:34:57 -05:00
Alex Richardson
dfc63d42ee Fix non-SIMD alignment if void* bigger than double
When building without the SIMD extensions, memory allocations are
currently aligned to sizeof(double).  However, this may be insufficient
on architectures such as Arm Morello or 64-bit CHERI-RISC-V where
pointers require 16-byte rather than 8-byte alignment.  This patch
causes memory allocations to be aligned to
MAX(sizeof(void *), sizeof(double)) when building without the SIMD
extensions.

(NOTE: With C11 we could instead use alignof(max_align_t), but C89
compatibility is still necessary in libjpeg-turbo.)

Closes #587
2022-04-12 13:53:56 -05:00
DRC
82081337a0 Merge branch 'main' into dev 2022-04-06 11:16:09 -05:00
DRC
67cb059046 OSS-Fuzz: Allow fuzzer suffix to be specified
This facilitates fuzzing multiple branches of the code.
2022-04-06 11:15:54 -05:00
DRC
5c8cac97c0 CI: Un-integrate CIFuzz
Referring to the conversation in
https://github.com/google/oss-fuzz/issues/7479 and #559, there was a
misunderstanding regarding how CIFuzz works.  It cannot be used to fuzz
arbitrary PRs or code branches, and it has a 90-day delay in downloading
corpora from OSS-Fuzz.  That makes it unsuitable for libjpeg-turbo.
2022-04-06 10:58:53 -05:00
DRC
89a369dec1 Merge branch 'main' into dev 2022-03-31 10:33:26 -05:00
DRC
df3c3dcb9b BUILDING.md: Generify PowerTools repo advice
This advice applies to CentOS Stream as well as to popular CentOS 8
replacements, such as Rocky Linux and AlmaLinux.
2022-03-31 10:28:17 -05:00
DRC
1b9edb5caf Build: Fix 12-bit FP tests w/ 32-bit builds
With x86-64 builds, the default value of FLOATTEST works with both the
8-bit-per-sample and 12-bit-per-sample flavors of the libjpeg API
library.  However, that is not the case with x86 builds.  Thus, we need
separate 8-bit-per-sample and 12-bit-per-sample FLOATTEST variables.
2022-03-11 17:41:18 -06:00
DRC
cb715fe1ae example.c: Fix compiler warning with GCC 4.4.7 2022-03-11 17:36:05 -06:00
DRC
ebd1930207 GitHub Actions: "linux-12bit" --> "linux-no12bit"
This job tests the non-default value of WITH_12BIT, which is now 0
instead of 1.
2022-03-11 17:36:05 -06:00
DRC
263386c23a Merge branch 'main' into dev 2022-03-11 17:35:59 -06:00
DRC
2ee7264d40 Build: Don't set DEFAULT_FLOATTEST for x86 MSVC
Newer versions of the 32-bit x86 Visual Studio compiler produce results
compatible with FLOATTEST=no-fp-contract, so we can no longer
intelligently set a default FLOATTEST value for that platform.
2022-03-11 17:32:58 -06:00
DRC
30cba2a2f8 Build/Win: Fix CMake warning when WITH_TURBOJPEG=0
When 12-bit-per-component JPEG support is enabled (WITH_12BIT=1) or the
TurboJPEG API library and associated test programs are disabled
(WITH_TURBOJPEG=0), the Windows installer target should not depend on
the turbojpeg, turbojpeg-static, and tjbench targets.
2022-03-11 11:55:50 -06:00
DRC
a014845403 Win: Fix build with Visual Studio 2010
(broken by 607b668ff9)

- Visual Studio 2010 apparently doesn't have the snprintf() inline
  function, so restore the macro that emulates that function using
  _snprintf_s().

- Explicitly include errno.h in strtest.c, since jinclude.h doesn't
  include it when building with Visual Studio.
2022-03-11 11:19:40 -06:00
DRC
b3ae777964 Fix in-tree builds
(oops)
2022-03-10 23:13:43 -06:00
DRC
a32038e3b3 Fix formatting issues detected by checkstyle 2022-03-10 23:10:12 -06:00
DRC
7fec5074f9 Support 8-bit & 12-bit JPEGs using the same build
Partially implements #199

This commit also implements a request from #178 (the ability to compile
the libjpeg example as a standalone program.)
2022-03-10 22:56:17 -06:00
DRC
fc562d11f0 Bump version to 2.2 alpha1 ...
... to prepare for new features
2022-03-10 22:56:17 -06:00
DRC
f3c716a2bc Link Sponsor button to GitHub Sponsors ...
... instead of PayPal.
2022-03-10 22:31:20 -06:00
DRC
6f1534d618 example.txt: Fix a typo 2022-03-09 12:58:55 -06:00
DRC
9abeff46d8 Remove extraneous #include directives
jinclude.h already includes stdio.h, stdlib.h, and string.h.
2022-03-09 11:49:27 -06:00
DRC
932b5bb0d5 IJG dox: Wordsmithing and formatting tweaks
- Remove the section in libjpeg.txt that advised against building
  libjpeg as a shared library.  We obviously do not follow that advice,
  and libjpeg-turbo does guarantee backward ABI compatibility in our
  libjpeg API library, even though libjpeg did not and does not.
  (Future expansion of our libjpeg API library, if necessary, will be
  accomplished using get/set functions that store the new parameters
  in the opaque master structs.  Refer to
  db2986c96f.)

- Unmention install.txt, which was never relevant to libjpeg-turbo and
  was removed in v1.3 (6f96153c67).

- Remove extraneous spaces.

- Document the fact that TWO_FILE_COMMANDLINE must be defined in order
  to use the two-file interface with cjpeg, djpeg, jpegtran, and
  wrjpgcom.  libjpeg-turbo never enables that interface by default.
2022-03-09 11:49:27 -06:00
Adam Fontenot
e8df8a2d63 Fix broken test jpegtran-*-420-islow-ari 2022-03-09 12:03:31 +00:00
DRC
fdab4a7af4 Progs: Eliminate obsolete Mac ccommand() interface
ccommand() was a 1990s-vintage hack for running console applications
without a console.  It doesn't exist in any modern macOS compiler.
2022-03-08 17:31:11 -06:00
DRC
0565548191 BUILDING.md: Mention sub-project best practices
People keep trying to include libjpeg-turbo into downstream CMake-based
build systems by way of the add_subdirectory() function and requesting
upstream support when something inevitably breaks.

(Refer to: #122, #173, #176, #202, #241, #349, #353, #412, #504,
a3d4aadd0d (commitcomment-67575889)).

libjpeg-turbo has never supported that method of sub-project
integration, because doing so would require that we (minimally):

1. avoid using certain CMake variables, such as CMAKE_SOURCE_DIR,
   CMAKE_BINARY_DIR, and CMAKE_PROJECT_NAME;
2. avoid using implicit include directories and relative paths;
3. provide a way to optionally skip the installation of libjpeg-turbo
   components in response to 'make install';
4. provide a way to optionally postfix target names, to avoid namespace
   conflicts;
5. restructure the top-level CMakeLists.txt so that it properly sets
   the PROJECT_VERSION variable; and
6. design automated CI tests to ensure that new commits don't break
   any of the above.

Even if we did all of that, issues would still arise, because it is
impossible for one upstream build system to anticipate the widely
varying needs of every downstream build system.  That's why the CMake
ExternalProject_Add() function exists, and it is my sincere hope that
adding a blurb to BUILDING.md mentioning the need to use that function
will head off future GitHub issues on this topic.  If not, then I can at
least post a link to this commit and the blurb and avoid doing the same
song and dance over and over again.
2022-02-28 22:27:58 -06:00
Jonathan Wright
c5f269eb96 Neon/AArch64: Explicitly unroll quant loop w/Clang
The loop in jsimd_quantize_neon() is only executed twice and should be
unrolled for AArch64 targets.  GCC does that by default, but Clang 11
and later versions available at the time of this writing do not.  This
patch adds an unroll pragma when targetting AArch64 with Clang.  We do
not use the unroll pragma for AArch32 targets, because it causes the
Clang-generated assembly code to exhaust the available Neon registers
(32 x 64-bit) and spill to the stack.  (DRC: Referring to the discussion
in #570, this is likely due to compiler confusion that results in poor
register allocation.  It is possible to eliminate the spillage and
reduce the instruction count by loading the data on a just-in-time
basis, thus explicitly interleaving compute and I/O, but the performance
implications of that are currently unknown.)

The effects of unrolling the quantization loop are:
1) elimination of the loop control flow overhead and
2) enabling the use of LDP/STP instructions that work from a single
   base pointer, instead of using double the number of LDR/STR
   instructions, each requiring an address calculation.

Closes #570
2022-02-25 12:53:05 -06:00
DRC
98bc3eeb3a Neon/AArch64: Fix/suppress UBSan warnings
- Suppress a UBSan warning regarding storing a 64-bit value to a
  non-64-bit-aligned address.  That behavior is technically undefined
  per the C spec but is supported in the context of the AArch64
  architecture and compilers.

- Explicitly promote block_diff[i] to unsigned int prior to left
  shifting it, in order to avoid a UBSan warning.  This warning also
  described behavior that is technically undefined per the C spec but is
  supported in the context of the AArch64 architecture and compilers.
  Changing the type cast order eliminated the warning without changing
  the generated assembly code.

Closes #582
2022-02-25 00:02:14 -06:00
Jonathan Wright
147548c055 Neon/AArch64: Accelerate Huffman encoding
- Make better use of 128-bit vector registers, thus reducing the number
  of Neon instructions required to construct the AC coefficient bitmap.

- Refactor the Neon computations of 'nbits' and 'diff' to use shorter
  and higher-throughput instruction sequences.

DRC's notes:

This commit partially integrates #570.  Arm reported a 1-4% speedup on
Cortex-A55 and Neoverse-N1 cores when using recent compilers but little
or no speedup with Clang 10.  I observed no speedup with Clang 10 on my
Cortex-A53 and Cortex-A72 cores.  Thus, referring to #582, the primary
purpose of this commit is to fix UBSan warnings regarding the shift
operations previously located at Line 253:

d640a45730/simd/arm/aarch64/jchuff-neon.c (L253)
2022-02-24 23:31:32 -06:00
DRC
d640a45730 AppVeyor: Test strict MSVC compiler warnings 2022-02-23 17:02:24 -06:00
DRC
eb21c023ab Eliminate incompatible pointer type warnings
(C4057 in MSVC and -Wincompatible-pointer-types in GCC/Clang)
2022-02-23 15:57:05 -06:00
DRC
13377e6b38 MSVC: Eliminate int conversion warnings (C4244) 2022-02-23 15:57:05 -06:00
DRC
607b668ff9 MSVC: Eliminate C4996 warnings in API libs
The primary purpose of this is to encourage adoption of libjpeg-turbo in
downstream Windows projects that forbid the use of "deprecated"
functions.  libjpeg-turbo's usage of those functions was not actually
unsafe, because:

- libjpeg-turbo always checks the return value of fopen() and ensures
  that a NULL filename can never be passed to it.

- libjpeg-turbo always checks the return value of getenv() and never
  passes a NULL argument to it.

- The sprintf() calls in format_message() (jerror.c) could never
  overflow the destination string buffer or leave it unterminated as
  long as the buffer was at least JMSG_LENGTH_MAX bytes in length, as
  instructed. (Regardless, this commit replaces those calls with
  snprintf() calls.)

- libjpeg-turbo never uses sscanf() to read strings or multi-byte
  character arrays.

- Because of b7d6e84d6a, wrjpgcom
  explicitly checks the bounds of the source and destination strings
  before calling strcat() and strcpy().

- libjpeg-turbo always ensures that the destination string is
  terminated when using strncpy().
  (548490fe5e made this explicit.)

Regarding thread safety:

Technically speaking, getenv() is not thread-safe, because the returned
pointer may be invalidated if another thread sets the same environment
variable between the time that the first thread calls getenv() and the
time that that thread uses the return value.  In practice, however, this
could only occur with libjpeg-turbo if:

(1) A multithreaded calling application used the deprecated and
undocumented TJFLAG_FORCEMMX/TJFLAG_FORCESSE/TJFLAG_FORCESSE2 flags in
the TurboJPEG API or set one of the corresponding environment variables
(which are only intended for testing purposes.)  Since the TurboJPEG API
library only ever passed string constants to putenv(), the only inherent
risk (i.e. the only risk introduced by the library and not the calling
application) was that the SIMD extensions may have read an incorrect
value from one of the aforementioned environment variables.

or

(2) A multithreaded calling application modified the value of the
JPEGMEM environment variable in one thread while another thread was
reading the value of that environment variable (in the body of
jpeg_create_compress() or jpeg_create_decompress().)  Given that the
libjpeg API provides a thread-safe way for applications to modify the
default memory limit without using the JPEGMEM environment variable,
direct modification of that environment variable by calling applications
is not supported.

Microsoft's implementation of getenv_s() does not claim to be
thread-safe either, so this commit uses getenv_s() solely to mollify
Visual Studio.  New inline functions and macros (GETENV_S() and
PUTENV_S) wrap getenv_s()/_putenv_s() when building for Visual Studio
and getenv()/setenv() otherwise, but GETENV_S()/PUTENV_S() provide no
advantages over getenv()/setenv() other than parameter validation.  They
are implemented solely for convenience.

Technically speaking, strerror() is not thread-safe, because the
returned pointer may be invalidated if another thread changes the locale
and/or calls strerror() between the time that the first thread calls
strerror() and the time that that thread uses the return value.  In
practice, however, this could only occur with libjpeg-turbo if a
multithreaded calling application encountered a file I/O error in
tjLoadImage() or tjSaveImage().  Since both of those functions
immediately copy the string returned from strerror() into a thread-local
buffer, the risk is minimal, and the worst case would involve an
incorrect error string being reported to the calling application.
Regardless, this commit uses strerror_s() in the TurboJPEG API library
when building for Visual Studio.  Note that strerror_r() could have been
used on Un*x systems, but it would have been necessary to handle both
the POSIX and GNU implementations of that function and perform
widespread compatibility testing.  Such is left as an exercise for
another day.

Fixes #568
2022-02-23 15:57:01 -06:00
DRC
ab6cae6f3b BUILDING.md: Clarify that Ninja works with Windows 2022-02-22 10:23:19 -06:00
DRC
3ccb6ead23 BUILDING.md: Remove NASM RPM rebuild instructions
All currently supported Linux platforms now provide a recent enough
version of either NASM or Yasm.
2022-02-11 10:05:18 -06:00
DRC
6441ad0f83 BUILDING.md: Document NASM/Yasm path variables
This was an oversight from the CMake build system overhaul in
libjpeg-turbo 2.0 (6abd39160c).

Closes #580
2022-02-11 10:02:28 -06:00
DRC
6d2d6d3baf "YASM" = "Yasm"
The assembler name was initially spelled "YASM", but it has been "Yasm"
for the entirety of libjpeg-turbo's existence.
2022-02-11 09:34:01 -06:00
DRC
e1588a2a7b Build: Fix Neon capability detection w/ MSVC
(broken by 57ba02a408)

Refer to #547
2022-02-10 22:24:19 -06:00
DRC
548490fe5e Ensure that strncpy() dest strings are terminated
- Since the ERREXITS() and TRACEMSS() macros are never used internally
  (they are a relic of the legacy memory managers that libjpeg
  provided), the only risk was that an external program might have
  invoked one of those macros with a string longer than 79 characters
  (JMSG_STR_PARM_MAX - 1).

- TJBench never invokes the THROW_TJ() macro with a string longer than
  199 (JMSG_LENGTH_MAX - 1) characters, so there was no risk.  However,
  it's a good idea to explicitly terminate the destination strings so
  that anyone looking at the code can immediately tell that it is safe.
2022-02-10 11:52:48 -06:00
DRC
b579fc114d Eliminate unnecessary JFREAD()/JFWRITE() macros 2022-02-09 16:07:18 -06:00
DRC
a3d4aadd0d Build: Embed version/API/(C) info in MSVC DLLs
Based on:
da7a18801a

Closes #576
2022-02-01 13:00:42 -06:00
DRC
d7d16df646 Fix segv w/ h2v2 merged upsamp, jpeg_crop_scanline
The h2v2 (4:2:0) merged upsampler uses a spare row buffer so that it can
upsample two rows at a time but return only one row to the application,
if necessary.  merged_2v_upsample() copies from this spare row buffer
into the application-supplied output buffer, using the out_row_width
field in the my_merged_upsampler struct to determine how many samples to
copy.  out_row_width is set in jinit_merged_upsampler(), which is called
within the body of jpeg_start_decompress().  Since jpeg_crop_scanline()
must be called after jpeg_start_decompress(), jpeg_crop_scanline() must
modify the value of out_row_width if the h2v2 merged upsampler will be
used.  Otherwise, merged_2v_upsample() can overflow the output buffer if
the number of bytes between the current output buffer position and the
end of the buffer is less than the number of bytes required to represent
an uncropped scanline of the output image.  All of the destination
managers used by djpeg allocate either a whole image buffer or a
scanline buffer based on the uncropped output image width, so this issue
is not reproducible using djpeg.

Fixes #574
2022-02-01 10:52:08 -06:00
DRC
14ce28a92d TJBench: Remove innocuous always-true condition
This was accidentally introduced into tjbench.c in
890f1e0413 and ported into the Java
version from there.

Based on
4be6d4e7bd

Refer to #571
2022-01-29 12:37:15 -06:00
DRC
da41ab94e7 GitHub Actions: Specify Catalina for macOS build
macos-latest now maps to the Big Sur image, which doesn't have Xcode
12.2 installed.
2022-01-06 12:57:26 -06:00
DRC
1f55ae7b0f Fix -Wpedantic compiler warnings
... and test for those warnings (and others) when performing CI builds.
2022-01-06 12:33:22 -06:00
DRC
172972394a Eliminate non-ANSI C compatibility macros
libjpeg-turbo has never supported non-ANSI C compilers.  Per the spec,
ANSI C compilers must have locale.h, stddef.h, stdlib.h, memset(),
memcpy(), unsigned char, and unsigned short.  They must also handle
undefined structures.
2022-01-06 11:50:26 -06:00
Dmitry Tsarevich
a7f0244e9b turbojpeg.h: Parenthesize TJSCALED() dimension arg
This ensures that, for example,
TJSCALED(dim0 + dim1, sf)

will evaluate to
(((dim0 + dim1) * sf.num + sf.denom - 1) / sf.denom)

rather than
((dim0 + (dim1 * sf.num) + sf.denom - 1) / sf.denom)
2022-01-06 05:26:02 -06:00
DRC
a01857cff6 Build: Disallow NEON_INTRINSICS=0 if GAS is broken
If NEON_INTRINSICS=0, then run the GAS sanity check from libjpeg-turbo
2.0.x and force-enable NEON_INTRINSICS if the test fails.  This fixes
the AArch32 build when using Clang 6.0 on Linux or the Clang toolchain
in the Android NDK r15*-r16*.  It also prevents users from manually
disabling NEON_INTRINSICS if doing so would break the build (such as
with Xcode 5.)
2021-12-01 19:10:14 -06:00
DRC
57ba02a408 Build: Improve Neon capability detection
- Use check_c_source_compiles() rather than check_symbol_exists() to
  detect the presence of vld1_s16_x3(), vld1_u16_x2(), and
  vld1q_u8_x4().  check_symbol_exists() is unreliable for detecting
  intrinsics, and in practice, it did not detect the presence of the
  aforementioned intrinsics in versions of GCC that support them.

- Set DEFAULT_NEON_INTRINSICS=0 for GCC < 12, even if the aforementioned
  intrinsics are available.  The AArch64 back end in GCC 10 and 11
  supports the necessary intrinsics, but the GAS implementation is still
  faster when using those compilers.

Fixes #547
2021-12-01 11:26:57 -06:00
DRC
8a9a6dd15a Make incompatible feature errs more user-friendly
- Use JERR_NOTIMPL ("Not implemented yet") rather than JERR_NOT_COMPILED
  ("Requested feature was omitted at compile time") to indicate that
  arithmetic coding is incompatible with Huffman table optimization.
  This is more consistent with other parts of the libjpeg API code.
  JERR_NOT_COMPILED is typically used to indicate that a major feature
  was not compiled in, whereas JERR_NOTIMPL is typically used to
  indicate that two features were compiled in but are incompatible with
  each other (such as, for instance, two-pass color quantization and
  partial image decompression.)

- Change the text of JERR_NOTIMPL to "Requested features are
  incompatible".  This is a more accurate description of the situation.
  "Not implemented yet" implies that it may be possible to support the
  requested combination of features in the future, but that is not true
  in most of the cases where JERR_NOTIMPL is used.

Fixes #567
2021-12-01 09:43:15 -06:00
DRC
73eff6effe cjpeg: auto. compr. gray BMP/GIF-->grayscale JPEG
aa7459050d was supposed to enable this for
BMP input images but didn't, due to a similar oversight to the one fixed
in the previous commit.
2021-11-30 16:10:23 -06:00
DRC
2ce32e0fe5 cjpeg: automatically compress PGM-->grayscale JPEG
(regression introduced by aa7459050d)

cjpeg sets cinfo.in_color_space to JCS_RGB as an "arbitrary guess."
Since tjLoadImage() never uses JCS_RGB, the PGM reader should treat
JCS_RGB the same as JCS_UNKNOWN.

Fixes #566
2021-11-30 16:09:21 -06:00
DRC
e869a81a7a jdarith.c: Require cinfo->Se == DCTSIZE2 - 1
This fixes an oversight from the integration of the arithmetic entropy
codec from libjpeg (66f97e6820).  I chose
to integrate the latest implementation available at the time, which was
from jpeg-8b.  However, I naively replaced cinfo->lim_Se with
DCTSIZE2 - 1, not realizing that-- because of SmartScale-- jpeg-8b
contains additional code
(https://github.com/libjpeg-turbo/libjpeg-turbo/blob/jpeg-8b/jdinput.c#L249-L334)
that guards against illegal values of cinfo->Se >= DCTSIZE2.  Thus,
libjpeg-turbo's implementation of arithmetic decoding has never guarded
against such illegal values.  This commit restores the relevant check
from the original jpeg-6b arithmetic entropy codec patch ("jpeg-ari",
1e247ac854).

Fixes #564
2021-11-23 10:41:29 -06:00
DRC
5446ff88d6 CI: CIFuzz integration
CIFuzz runs the project's fuzzers for a limited period of time any time
a commit is pushed or a PR is submitted.  This is not intended to
replace OSS-Fuzz but rather to allow us to more quickly catch some
fuzzing failures, including fuzzer build regressions like the one
introduced in ecf021bc0d.

Closes #559
2021-11-19 13:54:07 -06:00
DRC
0f88060b0f cjpeg.c: Fix fuzzer build failure
(caused by previous commit)
2021-11-19 13:36:42 -06:00
DRC
ecf021bc0d cjpeg: Add -strict arg to treat warnings as fatal
This adds fault tolerance to the LZW-compressed GIF reader, which is
the only compression-side code that can throw warnings.
2021-11-18 21:04:35 -06:00
DRC
4c5fa566b3 CI: Halt immediately on all sanitizer errors 2021-11-17 16:09:50 -06:00
Piotr Kubaj
d401d62514 PowerPC: Detect AltiVec support on FreeBSD
Recent FreeBSD/PowerPC compilers, such as Clang 11.0.x on FreeBSD 13, do
the equivalent of passing -maltivec to the compiler by default, so
run-time AltiVec detection is unnecessary.  However, it becomes
necessary when using other compilers or when passing -mno-altivec to the
compiler.

Closes #552
2021-10-30 16:53:51 -05:00
DRC
2fd4ae7b2c JNI: Fix warnings/errors reported by -Xcheck:jni
- Don't check for exceptions immediately after invoking the
  GetPrimitiveArrayCritical() method.  That method does not throw
  exceptions, and checking for them caused -Xcheck:jni to warn about
  calling other JNI functions in the scope of
  Get/ReleasePrimitiveArrayCritical().

- Check for exceptions immediately after invoking the
  CallStaticObjectMethod() method in the PROP2ENV() macro.

- Don't use the Get/ReleasePrimitiveArrayCritical() methods for small
  arrays.  -Xcheck:jni didn't complain about that, but there is no
  performance advantage to using those methods rather than the
  Get*ArrayRegion() methods for small arrays, and using
  Get*ArrayRegion() makes the code less error-prone.

- Don't release the source/destination planes arrays in the YUV methods
  until after the corresponding C TurboJPEG functions have returned.
2021-10-27 14:50:22 -05:00
Ash Kyd
5552483db9 Fix typo in readme 2021-10-14 11:40:48 +01:00
Alex Xu (Hello71)
18edeff4e8 Build: Set CMP0065 NEW (respect ENABLE_EXPORTS)
Referring to https://cmake.org/cmake/help/latest/policy/CMP0065.html,
CMake 3.3 and earlier automatically added compiler/linker flags such as
-rdynamic/-export-dynamic, which caused symbols to be exported from
executables.  The primary purpose of this is to allow plugins loaded via
dlopen() to access symbols from the calling program.  libjpeg-turbo
does not need this functionality, and enabling it needlessly increases
the size of the libjpeg-turbo executables.

Setting CMP0065 to NEW when using CMake 3.4 and later prevents CMake
from automatically adding the aforementioned compiler/linker flags
unless the ENABLE_EXPORTS property is set for a target (or the
CMAKE_ENABLE_EXPORTS variable is set, which causes ENABLE_EXPORTS to be
set for all targets.)

Closes #554
2021-10-03 13:39:38 -05:00
DRC
a9c41fbc4f Build: Don't enable Neon SIMD exts with Armv6-
When building for 32-bit Arm platforms, test whether basic Neon
intrinsics will compile with the specified compiler and C flags.  This
prevents the build system from enabling the Neon SIMD extensions when
targetting Armv6 and other legacy architectures that do not support Neon
instructions.

Regression introduced by bbd8089297.
(Checking whether gas-preprocessor.pl was needed for 32-bit Arm builds
had the effect of checking whether Neon instructions were supported.)

Fixes #553
2021-10-03 13:10:35 -05:00
DRC
739ecbc5ec ChangeLog.md: List CVE ID fixed by 2849d86a 2021-09-30 16:28:51 -05:00
DRC
4c313544e2 AppVeyor: Deploy artifacts to Amazon S3
We would have been perfectly happy for AppVeyor to delete all artifacts
other than those from the latest builds in each branch.  Instead, they
chose to change the global artifact retention policy to 1 month.  In
addition to being unworkable, that new policy uses more storage than the
policy we requested.  Lose/lose, so we'll just deploy to S3 like we do
with other platforms.
2021-09-20 17:12:02 -05:00
DRC
173900b1ca tjTrans: Allow 8x8 crop alignmnt w/odd 4:4:4 JPEGs
Fixes #549
2021-09-02 13:31:11 -05:00
DRC
5d2430f4da ChangeLog.md: Add missing sub-header for 2.1.2 2021-09-02 13:18:10 -05:00
DRC
129f0cb763 Neon/AArch64: Don't put GAS functions in .rodata
Regression introduced by 240ba417aa

Closes #546
2021-08-25 12:54:24 -05:00
DRC
0a9b972178 jmemmgr.c: Pass correct size arg to jpeg_free_*()
This issue was introduced in 5557fd2217
due to an oversight, so it has existed in libjpeg-turbo since the
project's inception.  However, the issue is effectively a non-issue.
Although #325 proposes allowing programs to override jpeg_get_*() and
jpeg_free_*() externally, there is currently no way to override those
functions without modifying the libjpeg-turbo source code.
libjpeg-turbo only includes the malloc()/free() memory manager from
libjpeg, and the implementation of jpeg_free_*() in that memory manager
ignores the size argument.  libjpeg had several additional memory
managers for legacy systems (MS-DOS, System 7, etc.), but those memory
managers ignored the size argument to jpeg_free_*() as well.  Thus, this
issue would have only potentially affected custom memory managers in
downstream libjpeg-turbo forks, and since no one has complained until
now, apparently those are rare.

Fixes #542
2021-08-09 18:16:57 -05:00
DRC
2849d86aaa SSE2/64-bit: Fix trans. segfault w/ malformed JPEG
Attempting to losslessly transform certain malformed JPEG images can
cause the nbits table index in the Huffman encoder to exceed 32768, so
we need to pad the SSE2 implementation of that table to 65536 entries as
we do with the C implementation.

Regression introduced by 087c29e07f

Fixes #543
2021-08-06 14:04:34 -05:00
DRC
84d6306f64 Fix build w/CMake 3.14+ when CMAKE_SYSTEM_NAME=iOS
Closes #539
2021-07-27 11:26:51 -05:00
Kornel
512a7c3a51 Merge tag '2.1.0'
* tag '2.1.0': (39 commits)
  TurboJPEG: Update JPEG buf ptrs on comp/xform err
  Include TJ.FLAG_LIMITSCANS in JNI header
  OSS-Fuzz: Code comment tweaks for compr. targets
  jdhuff.h: Fix ASan regression caused by 8fa70367
  cjpeg_fuzzer: Add cov for h2v2 smooth downsampling
  Huff decs: Fix/suppress more innocuous UBSan errs
  Huff dec: Fix non-deterministic output w/bad input
  OSS-Fuzz: Check img size b4 readers allocate mem
  OSS-Fuzz: More code coverage improvements
  jchuff.c: Fix MSan error
  compress_yuv_fuzzer: Minor code coverage tweak
  cjpeg.c: Code formatting tweak
  rdbmp.c: Fix more innocuous UBSan errors
  rdbmp.c/rdppm.c: Fix more innocuous UBSan errors
  OSS-Fuzz: cjpeg fuzz target
  compress_yuv_fuzzer: Use unique filename template
  OSS-Fuzz: Fix UBSan err caused by TJFLAG_FUZZING
  OSS-Fuzz: YUV encoding/compression fuzz target
  ...
2021-07-21 22:39:01 +01:00
y-guyon
e6e952d5d5 Suppress UBSan error in decode_mcu_fast()
This is the same error that d147be83e9
suppressed in decode_mcu_slow().  The image that reproduces this error
in decode_mcu_fast() has been added to the libjpeg-turbo seed corpora.

Closes #537
2021-07-16 12:58:00 -05:00
Alex Richardson
a72816ed07 Use uintptr_t, if avail, for pointer-to-int casts
Although sizeof(void *) == sizeof(size_t) for all architectures that are
currently supported by libjpeg-turbo, such is not guaranteed by the C
standard.  Specifically, CHERI-enabled architectures (e.g. CHERI-RISC-V
or Arm's Morello) use capability pointers that are twice the size of
size_t (128 bits for Morello and RV64), so casting to size_t strips the
upper bits of the pointer (including the validity bit) and makes it
non-deferenceable, as indicated by the following compiler warning:

  warning: cast from provenance-free integer type to pointer type will
  give pointer that can not be dereferenced
  [-Werror,-Wcheri-capability-misuse]
    cvalue = values = (JCOEF *)PAD((size_t)values_unaligned, 16);

Ignoring this warning results in a run-time crash.  Casting pointers to
uintptr_t, if it is available, avoids this problem, since uintptr_t is
defined as an unsigned integer type that can hold a pointer value.

Since C89 compatibility is still necessary in libjpeg-turbo, this commit
introduces a new typedef for pointer-to-integer casts that uses a
GNU-specific extension available in GCC 4.6+ and Clang 3.0+ and falls
back to using size_t if the extension is unavailable.  The only other
options would require C99 or Clang-specific builtins.

Closes #538
2021-07-16 12:23:29 -05:00
DRC
4d9f256b01 jpegtran: Add option to copy only ICC markers
Closes #533
2021-07-13 11:54:31 -05:00
Peter Kasting
b201838d8b Neon: Silence -Wimplicit-fallthrough warnings
Refer to https://bugs.chromium.org/p/chromium/issues/detail?id=995993

Closes #534
2021-07-13 10:21:38 -05:00
DRC
a1bfc05854 Neon/AArch32: Mark inline asm output as read/write
'buffer' is both passed into the inline assembly code and modified by
it.  See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, 6.47.2.3.

With GCC 4, this commit does not change the generated assembly code at
all.

With GCC 8, this commit fixes an assembly error:

  /tmp/{foo}.s: Assembler messages:
  /tmp/{foo}.s:775: Error: registers may not be the same --
                    `str r9,[r9],#4'

I'm not sure why that error went unnoticed, since I definitely
benchmarked the previous commit with GCC 8.  Anyhow, this commit changes
the generated assembly code slightly but does not alter performance.

With Clang 10, this commit changes the generated assembly code slightly
but does not alter performance.

Refer to #529
2021-07-12 15:22:24 -05:00
DRC
2a2970af67 Neon/AArch32: Work around Clang T32 miscompilation
Referring to the C standard
(http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf,
J.2 Undefined behavior), the behavior of the compiler is undefined if
"conversion between two pointer types produces a result that is
incorrectly aligned."  Thus, the behavior of this code

  *((uint32_t *)buffer) = BUILTIN_BSWAP32(put_buffer);

in the AArch32 version of the FLUSH() macro is undefined unless 'buffer'
is 32-bit-aligned.  Referring to
https://bugs.llvm.org/show_bug.cgi?id=50785, certain versions of Clang,
when generating Thumb (T32) instructions, miscompile that code into an
assembly instruction (stm) that requires the destination to be
32-bit-aligned.  Since such alignment cannot be guaranteed within the
Huffman encoder, this reportedly led to crashes (SIGBUS: illegal
alignment) with AArch32/Thumb builds of libjpeg-turbo running on Android
devices, although thus far I have been unable to reproduce those crashes
with a plain Linux/Arm system.

The miscompilation is visible with the Compiler Explorer:
https://godbolt.org/z/rv1ccx1Pb
However, it goes away when removing the return statement from the
function.  Thus, it seems that Clang's behavior in this regard is
somewhat variable, which may explain why the crashes are only
reproducible on certain platforms.

The suggested workaround is to use memcpy(), but whereas Clang and
recent GCC releases are smart enough to compile a 4-byte memcpy() call
into a str instruction, GCC < 6 is not.  Referring to
https://godbolt.org/z/ae7Wje3P6, the only way to consistently produce
the desired str instruction across all supported compilers is to use
inline assembly.  Visual C++ presumably does not miscompile the code in
question, since no issues have been reported with it, but since the code
relies on undefined compiler behavior, prudence dictates that
e4ec23d7ae should be reverted for Visual
C++, which this commit does.  The performance impact of
e4ec23d7ae for Visual C++/Arm builds is
unknown (I have no ability to test such builds), but regardless, this
commit reverts the Visual C++/Arm performance to that of libjpeg-turbo
2.1 beta1.

Closes #529
2021-07-09 19:37:58 -05:00
DRC
97a1575cb8 RPM: Don't include system lib dir in file list
This resolves a conflict between the RPM generated by the libjpeg-turbo
build system and the Red Hat 'filesystem' RPM if
CMAKE_INSTALL_LIBDIR=/usr/lib[64].  This code was largely borrowed from
the VirtualGL RPM spec.  (I can legally do that because I hold the
copyright on VirtualGL's implementation.)

Fixes #532
2021-07-07 14:51:09 -05:00
DRC
0081c2de20 Neon/AArch32: Fix build if 'soft' float ABI used
Arm compilers have three floating point ABI options:

'soft' compiles floating point operations as function calls into a
software floating point library, which emulates floating point
operations using integer operations.  Floating point function arguments
are passed using integer registers.

'softfp' also compiles floating point operations as function calls into
a floating point library and passes floating point function arguments
using integer registers, but the floating point library functions can
use FPU instructions if the CPU supports them.

'hard' compiles floating point operations into inline FPU instructions,
similarly to x86 and other architectures, and passes floating point
function arguments using FPU registers.

Not all AArch32 CPUs have FPUs or support Neon instructions, so on Linux
and Android platforms, the AArch32 SIMD dispatcher in libjpeg-turbo only
enables the Neon SIMD extensions at run time if /proc/cpuinfo indicates
that the CPU supports Neon instructions or if Neon instructions are
explicitly enabled (e.g. by passing -mfpu=neon to the compiler.)  In
order to support all AArch32 CPUs using the same code base, i.e. to
support run-time FPU and Neon auto-detection, it is necessary to compile
the scalar C source code using -mfloat-abi=soft.  However, the 'soft'
floating point ABI cannot be used when compiling Neon intrinsics, so the
intrinsics implementation of the Neon SIMD extensions must be compiled
using -mfloat-abi=softfp if the scalar C source code is compiled using
-mfloat-abi=soft.

This commit modifies the build system so that it detects whether
-mfloat-abi=softfp must be explicitly added to the compiler flags when
building the intrinsics implementation of the Neon SIMD extensions.
This will be necessary if the build is using the 'soft' floating
point ABI along with run-time auto-detection of Neon instructions.

Fixes #523
2021-07-07 14:10:05 -05:00
Peter Kasting
9df5786f05 Fix -Wimplicit-fallthrough warnings with Clang
The existing /*FALLTHROUGH*/ comments work with GCC but not Clang, so
this commit adds a FALLTHROUGH macro that uses the 'fallthrough'
attribute if the compiler supports it.

Refer to https://bugs.chromium.org/p/chromium/issues/detail?id=995993

NOTE: All versions of GCC that support -Wimplicit-fallthrough also
support the 'fallthrough' attribute, but certain other compilers (Oracle
Solaris Studio, for instance) support /*FALLTHROUGH*/ but not the
'fallthrough' attribute.  Thus, this commit retains the /*FALLTHROUGH*/
comments, which have existed in the libjpeg code base in some form since
1994 (libjpeg v5.)

Closes #531
2021-07-06 12:37:34 -05:00
tasty0tomato
323469818c Add building libpng in Windows 2021-06-22 15:47:29 +01:00
DRC
1a1fb615db ChangeLog.md: List CVE ID fixed by c76f4a08
Referring to #527, the security community did not assign this CVE ID
until more than 8 months after the fix for the issue was released.  By
the time they assigned the ID, libjpeg-turbo already had two production
releases containing the fix.  This calls into question the usefulness of
assigning a CVE ID to the issue, particularly given that the buffer
overrun in question was fully contained in the stack, not detectable
with valgrind, and confined to lossless transformation (it did not
affect JPEG compression or decompression.)

https://vuldb.com/?id.176175
says that "the exploitability is told to be easy" but provides no
clarification, and given that the author of that page does not seem to
be aware that a fix for the issue has been available since early
December of 2019, it calls into question the accuracy of everything else
on the page.

It would really be nice if the security community approached me about
these things before wasting my time, but I guess it's my lot in life to
modify a change log entry from 2019 to include a CVE ID from 2020.

So it goes...
2021-06-18 10:29:12 -05:00
DRC
5135c2e25d Build: Use PIC for jsimd_none.o in shared libs
In theory, all objects that will be included in a Un*x shared library
must be built using PIC.  In practice, most compilers don't require PIC
to be explicitly specified for jsimd_none.o, either because the compiler
automatically enables PIC in all cases (Ubuntu) or because the size of
the generated object is too small.  But some rare compilers do require
PIC to be explicitly specified for jsimd_none.o.

Fixes #520
2021-05-28 13:09:43 -05:00
DRC
3932190c2e Fix build w/ non-GCC-compatible Un*x/Arm compilers
Regression introduced by d2c4079959

Closes #519
2021-05-17 13:09:37 -05:00
DRC
a219fd13b0 GitHub bug-report.md: "master" branch --> "main" 2021-05-12 10:58:59 -05:00
DRC
c23672ce52 GitHub Actions: Don't build tags
Our workflow script does not currently work with tags, and there is no
point to building tags anyhow, since we do not use the CI system to spin
official builds.
2021-04-23 13:29:40 -05:00
DRC
4f51f36eb3 Bump version to 2.1.0 to prepare for final release 2021-04-23 11:42:40 -05:00
DRC
e0606dafff TurboJPEG: Update JPEG buf ptrs on comp/xform err
When using the in-memory destination manager, it is necessary to
explicitly call the destination manager's term_destination() method if
an error occurs.  That method is called by jpeg_finish_compress() but
not by jpeg_abort_compress().

This fixes a potential double free() that could occur if tjCompress*()
or tjTransform() returned an error and the calling application tried to
clean up a JPEG buffer that was dynamically re-allocated by one of those
functions.
2021-04-21 15:42:00 -05:00
DRC
ffc1aa9674 Include TJ.FLAG_LIMITSCANS in JNI header
(oversight from c81e91e8ca)

This is purely cosmetic, since the JNI wrapper doesn't actually use that
flag.
2021-04-21 12:33:00 -05:00
DRC
55ec9b3b89 OSS-Fuzz: Code comment tweaks for compr. targets
(oversight from 171b875b27)
2021-04-21 12:33:00 -05:00
DRC
4de8f6922a jdhuff.h: Fix ASan regression caused by 8fa70367
The 0xFF is, in fact, necessary.
2021-04-16 16:34:12 -05:00
DRC
785ec30eb4 cjpeg_fuzzer: Add cov for h2v2 smooth downsampling 2021-04-16 15:59:38 -05:00
DRC
d147be83e9 Huff decs: Fix/suppress more innocuous UBSan errs
- UBSan complained that entropy->restarts_to_go was underflowing an
  unsigned integer when it was decremented while
  cinfo->restart_interval == 0.  That was, of course, completely
  innocuous behavior, since the result of the underflowing computation
  was never used.

- d3a3a73f64 and
  7bc9fca430 silenced a UBSan signed
  integer overflow error, but unfortunately other malformed JPEG images
  have been discovered that cause unsigned integer overflow in the same
  computation.  Since, to the best of our understanding, this behavior
  is innocuous, this commit reverts the commits listed above, suppresses
  the UBSan errors, and adds code comments to document the issue.
2021-04-15 23:46:15 -05:00
DRC
8fa70367ed Huff dec: Fix non-deterministic output w/bad input
Referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1050342,
there are certain very rare circumstances under which a malformed JPEG
image can cause different Huffman decoder output to be produced,
depending on the size of the source manager's I/O buffer.  (More
specifically, the fast Huffman decoder didn't handle invalid codes in
the same manner as the slow decoder, and since the fast decoder requires
all data to be memory-resident, the buffering strategy determines
whether or not the fast decoder can be used on a particular MCU block.)

After extensive experimentation, the Mozilla and Chrome developers and I
determined that this truly was an innocuous issue.  The patch that both
browsers adopted as a workaround caused a performance regression with
32-bit code, which is why it was not accepted into libjpeg-turbo.  This
commit fixes the problem in a less disruptive way with no performance
regression.
2021-04-15 22:55:50 -05:00
DRC
171b875b27 OSS-Fuzz: Check img size b4 readers allocate mem
After the completion of the start_input() method, it's too late to check
the image size, because the image readers may have already tried to
allocate memory for the image.  If the width and height are excessively
large, then attempting to allocate memory for the image could slow
performance or lead to out-of-memory errors prior to the fuzz target
checking the image size.

NOTE: Specifically, the aforementioned OOM errors and slow units were
observed with the compression fuzz targets when using MSan.
2021-04-15 21:20:33 -05:00
DRC
3ab3234875 OSS-Fuzz: More code coverage improvements 2021-04-13 11:58:20 -05:00
DRC
3e68a5ee20 jchuff.c: Fix MSan error
Certain rare malformed input images can cause the Huffman encoder to
generate a value for nbits that corresponds to an uninitialized member
of the DC code table.  The ramifications of this are minimal and would
basically amount to a different bogus JPEG image being generated from a
particular bogus input image.
2021-04-12 14:37:43 -05:00
DRC
4e45161654 compress_yuv_fuzzer: Minor code coverage tweak 2021-04-12 11:53:29 -05:00
DRC
629e96eedc cjpeg.c: Code formatting tweak 2021-04-12 11:52:55 -05:00
DRC
ebaa67ea32 rdbmp.c: Fix more innocuous UBSan errors
- Referring to 3311fc0001, we need to use
  unsigned intermediate math in order to make UBSan happy, even though
  (JDIMENSION)(A * B) is effectively the same as
  (JDIMENSION)A *(JDIMENSION)B, regardless of intermediate overflow.

- Because of the previous commit, it is now possible for bfOffBits to be
  INT_MIN, which would cause the initial computation of bPad to
  underflow a signed integer.  Thus, we need to check for that
  possibility as soon as we know the values of bfOffBits and headerSize.
  The worst case from this regression is that bPad could wrap around to
  a large positive value, which would cause a "Premature end of input
  file" error in the subsequent read_byte() loop.  Thus, this issue was
  effectively innocuous as well, since it resulted in catching the same
  error later and in a different way.  Also, the issue was very
  well-contained, since it was both introduced and fixed as part of the
  ongoing OSS-Fuzz integration project.
2021-04-12 11:48:14 -05:00
DRC
dd830b3ffe rdbmp.c/rdppm.c: Fix more innocuous UBSan errors
- rdbmp.c: Because of 8fb37b8171,
  bfOffBits, biClrUsed, and headerSize were made into unsigned ints.
  Thus, if bPad would eventually be negative due to a malformed header,
  UBSan complained about unsigned math being used in the intermediate
  computations.  It was unnecessary to make those variables unsigned,
  since they are only meant to hold small values, so this commit makes
  them signed again.  The UBSan error was innocuous, because it is
  effectively (if not officially) the case that
  (int)((unsigned int)a - (unsigned int)b) == (int)a - (int)b.

- rdbmp.c: If (biWidth * source->bits_per_pixel / 8) would overflow an
  unsigned int, then UBSan complained at the point at which row_width
  was set in start_input_bmp(), even though the overflow would have been
  detected later in the function.  This commit adds overflow checks
  prior to setting row_width.

- rdppm.c: read_pbm_integer() now bounds-checks the intermediate
  value computations in order to catch integer overflow caused by a
  malformed text PPM.  It's possible, though extremely unlikely, that
  the intermediate value computations could have wrapped around to a
  value smaller than maxval, but the worst case is that this would have
  generated a bogus pixel in the uncompressed image rather than throwing
  an error.
2021-04-09 20:09:04 -05:00
DRC
4ede2ef523 OSS-Fuzz: cjpeg fuzz target 2021-04-09 19:27:22 -05:00
DRC
5cda8c5e31 compress_yuv_fuzzer: Use unique filename template 2021-04-09 13:12:32 -05:00
DRC
47b66d1d1e OSS-Fuzz: Fix UBSan err caused by TJFLAG_FUZZING 2021-04-09 11:26:34 -05:00
DRC
55ab0d396c OSS-Fuzz: YUV encoding/compression fuzz target 2021-04-08 16:13:06 -05:00
DRC
18bc4c6114 compress.cc: Code formatting tweak 2021-04-07 16:08:59 -05:00
DRC
b1079002ad rdppm.c: Fix innocuous MSan error
A fuzzing test case that was effectively a 1-pixel PGM file with a
maximum value of 1 and an actual value of 8 caused an uninitialized
member of the rescale[] array to be accessed in get_gray_rgb_row() or
get_gray_cmyk_row().  Since, for performance reasons, those functions do
not perform bounds checking on the PPM values, we need to ensure that
unused members of the rescale[] array are initialized.
2021-04-07 16:08:48 -05:00
DRC
3311fc0001 rdbmp.c: Fix innocuous UBSan error
A fuzzing test case with an image width of 838860946 triggered a UBSan
error:

rdbmp.c:633:34: runtime error: signed integer overflow:
838860946 * 3 cannot be represented in type 'int'

Because the result is cast to an unsigned int (JDIMENSION), this error
is irrelevant, because

(unsigned int)((int)838860946 * (int)3) ==
(unsigned int)838860946 * (unsigned int)3
2021-04-07 15:23:32 -05:00
DRC
34d264d64e OSS-Fuzz: Private TurboJPEG API flag for fuzzing
This limits the tjLoadImage() behavioral changes to the scope of the
compress_fuzzer target.  Otherwise, TJBench in fuzzer builds would
refuse to load images larger than 1 Mpixel.
2021-04-07 15:09:29 -05:00
DRC
f35fd27ec6 tjLoadImage: Fix issues w/loading 16-bit PPMs/PGMs
- The PPM reader now throws an error rather than segfaulting (due to a
  buffer overrun) if an application attempts to load a 16-bit PPM file
  into a grayscale uncompressed image buffer.  No known applications
  allowed that (not even the test applications in libjpeg-turbo),
  because that mode of operation was never expected to work and did not
  work under any circumstances.  (In fact, it was necessary to modify
  TJBench in order to reproduce the issue outside of a fuzzing
  environment.)  This was purely a matter of making the library bow out
  gracefully rather than crash if an application tries to do something
  really stupid.

- The PPM reader now throws an error rather than generating incorrect
  pixels if an application attempts to load a 16-bit PGM file into an
  RGB uncompressed image buffer.

- The PPM reader now correctly loads 16-bit PPM files into extended
  RGB uncompressed image buffers.  (Previously it generated incorrect
  pixels unless the input colorspace was JCS_RGB or JCS_EXT_RGB.)

The only way that users could have potentially encountered these issues
was through the tjLoadImage() function.  cjpeg and TJBench were
unaffected.
2021-04-06 16:12:29 -05:00
DRC
df17d398ec jcphuff.c: -Wjump-misses-init warning w/GCC 9 -m32
(verified that this commit does not change the generated 64-bit or
32-bit assembly code)
2021-04-06 14:11:32 -05:00
DRC
cd9a318502 Bump TurboJPEG C API version to 2.1
(because of TJFLAG_LIMITSCANS)
2021-04-05 22:20:52 -05:00
DRC
d2d4465548 OSS-Fuzz: Compression fuzz target 2021-04-05 21:59:11 -05:00
DRC
5536ace198 OSS-Fuzz: Fix C++11 compiler warnings in targets 2021-04-05 21:12:29 -05:00
DRC
5dd906beff OSS-Fuzz: Test non-default opts w/ decompress_yuv
The non-default options were not being tested because of a pixel format
comparison buglet.  This commit also changes the code in both
decompression fuzz targets such that non-default options are tested
based on the pixel format index rather than the pixel format value,
which is a bit more idiot-proof.
2021-04-05 17:53:15 -05:00
DRC
c81e91e8ca TurboJPEG: New flag for limiting prog JPEG scans
This also fixes timeouts reported by OSS-Fuzz.
2021-04-05 16:33:44 -05:00
DRC
bff7959e34 OSS-Fuzz: Require static libraries
Refer to
https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies
for the reasons why this is necessary.
2021-04-02 14:58:55 -05:00
DRC
6ad658be17 OSS-Fuzz: Build fuzz targets using C++ compiler
Otherwise, the targets will require libstdc++, the i386 version of which
is not available in the OSS-Fuzz runtime environment.  The OSS-Fuzz
build environment passes -stdlib:libc++ in the CXXFLAGS environment
variable in order to mitigate this issue, since the runtime environment
has the i386 version of libc++, but using that compiler flag requires
using the C++ compiler.
2021-04-02 14:58:31 -05:00
DRC
7b57cba6b4 OSS-Fuzz: Fix uninitialized reads detected by MSan 2021-04-01 11:30:24 -05:00
DRC
2f9e8a1172 OSS-Fuzz integration
This commit integrates OSS-Fuzz targets directly into the libjpeg-turbo
source tree, thus obsoleting and improving code coverage relative to
Google's OSS-Fuzz target for libjpeg-turbo (previously available here:
https://github.com/google/oss-fuzz).

I hope to eventually create fuzz targets for the BMP, GIF, and PPM
readers as well, which would allow for fuzz-testing compression, but
since those readers all require an input file, it is unclear how to
build an efficient fuzzer around them.  It doesn't make sense to
fuzz-test compression in isolation, because compression can't accept
arbitrary input data.
2021-03-30 20:59:41 -05:00
Jonathan Wright
e4ec23d7ae Neon: Use byte-swap builtins instead of inline asm
Define compiler-independent byte-swap macros and use them instead of
executing 'rev' via inline assembly code with GCC-compatible compilers
or a slow shift-store sequence with Visual C++.

* This produces identical assembly code with:

  - 64-bit GCC 8.4.0 (Linux)
  - 64-bit GCC 9.3.0 (Linux)
  - 64-bit Clang 10.0.0 (Linux)
  - 64-bit Clang 10.0.0 (MinGW)
  - 64-bit Clang 12.0.0 (Xcode 12.2, macOS)
  - 64-bit Clang 12.0.0 (Xcode 12.2, iOS)

* This produces different assembly code with:

  - 64-bit GCC 4.9.1 (Linux)
  - 32-bit GCC 4.8.2 (Linux)
  - 32-bit GCC 8.4.0 (Linux)
  - 32-bit GCC 9.3.0 (Linux)
    Since the intrinsics implementation of Huffman encoding is not used
    by default with these compilers, this is not a concern.

  - 32-bit Clang 10.0.0 (Linux)
    Verified performance neutrality

Closes #507
2021-03-26 14:09:10 -05:00
DRC
e795afc330 SSE2: Fix prog Huff enc err if Sl%32==0 && Al!=0
(regression introduced by 16bd984557)

This implements the same fix for
jsimd_encode_mcu_AC_refine_prepare_sse2() that
a81a8c137b implemented for
jsimd_encode_mcu_AC_first_prepare_sse2().

Based on:
1a59587397
eb176a91d8

Fixes #509
Closes #510
2021-03-25 22:46:14 -05:00
Adrian Bunk
2c01200c5d Build: Fix incorrect regexes w/ if(...MATCHES...)
"arm*" as a regex means 'ar' followed by zero or more 'm' characters,
which matches 'parisc' and 'sparc64' as well.
2021-03-15 12:56:53 -05:00
DRC
ed70101da2 ChangeLog.md: List CVE ID fixed by 1719d12e
Referring to https://bugzilla.redhat.com/show_bug.cgi?id=1937385#c2,
it is my opinion that the severity of this bug was grossly overstated
and that a CVE never should have been assigned to it, but since one was
assigned, users need to know which version of libjpeg-turbo contains
the fix.

Dear security community, please learn what "DoS" actually means and stop
misusing that term for dramatic effect.  Thanks.
2021-03-15 12:36:55 -05:00
Kornel
c78b82bbb1 Merge error 2021-03-01 11:31:05 +00:00
Kornel
886ddb1786 Merge commit '8a2cad020171184a49fa8696df0b9e267f1cf2f6'
* commit '8a2cad020171184a49fa8696df0b9e267f1cf2f6': (99 commits)
  Build: Handle CMAKE_OSX_ARCHITECTURES=(i386|ppc)
  Add Sponsor button for GitHub repository
  Build: Support CMAKE_OSX_ARCHITECTURES
  cjpeg: Fix FPE when compressing 0-width GIF
  Fix build with Visual C++ and /std:c11 or /std:c17
  Neon: Fix Huffman enc. error w/Visual Studio+Clang
  Use CLZ compiler intrinsic for Windows/Arm builds
  Build: Use correct SIMD exts w/VStudio IDE + Arm64
  jcphuff.c: Fix compiler warning with clang-cl
  Migrate from Travis CI to GitHub Actions
  tjexample.c: Fix mem leak if tjTransform() fails
  Build: Officially support Ninja
  decompress_smooth_data(): Fix another uninit. read
  LICENSE.md: Remove trailing whitespace
  Build: Test for correct AArch32 RPM/DEBARCH value
  LICENSE.md: Formatting tweak
  Fix uninitialized read in decompress_smooth_data()
  Fix buffer overrun with certain narrow prog JPEGs
  Bump revision to 2.0.91 for post-beta fixes
  Travis: Use Docker tag that matches Git branch
  ...
2021-02-26 21:30:09 +00:00
Ewout ter Hoeven
69bd7ed953 AppVeyor: Update to Visual Studio 2019 image
Updates the AppVeyor build environment, see https://www.appveyor.com/docs/build-environment/#build-worker-images for more information
2021-02-25 23:50:41 +00:00
Kornel
ed21c3ba6f Bump 2021-02-25 22:09:13 +00:00
Kornel
9f01177f72 Default to single-scan DC
People don't like green faces
2021-02-25 21:44:09 +00:00
Kornel
ceb4f8e97c Microsoft's C stdlib continues to be a disappointment 2021-01-24 23:08:26 +00:00
Kornel
44f3f8a544 Fudge incompatible turbo tests 2021-01-22 18:44:39 +00:00
Kornel
fe0e3c7e88 Merge commit '10ba6ed3365615ed5c2995fe2d240cb2d5000173'
* commit '10ba6ed3365615ed5c2995fe2d240cb2d5000173': (32 commits)
  Travis: Install MacPorts without using macports-ci
  Build: Set FLOATTEST more intelligently
  BUILDING.md: Use min. iOS v8 in iOS Armv8 example
  Fix build if WITH_12BIT==1 && WITH_JPEG(7|8)==1
  Travis: Combine PPC/Arm tests with jpeg-7/8 tests
  Build: Fix test failures w/ Arm Neon SIMD exts
  Travis: Regression-test Armv8 and PPC SIMD exts
  Demote "fast" [I]DCT algorithms to legacy status
  jpegtran.c: "subarea" = "region"
  jpegtran.1: Minor formatting tweak
  transupp.c: Code formatting tweaks
  cdjpeg.h: Remove unused function stub
  Consistify formatting to simplify checkstyle
  README.ijg: Update URLs; remove Usenet info
  jversion.h: Update copyrights
  Build: Improve Arm 32-bit cross-comp./packaging
  "ARM"="Arm", "NEON"="Neon"
  Build: Fix permissions
  ChangeLog: Fix minor formatting issue
  ChangeLog.md: jpeg_crop_scanline(), not scanlines
  ...
2021-01-22 16:03:54 +00:00
DRC
8a2cad0201 Build: Handle CMAKE_OSX_ARCHITECTURES=(i386|ppc)
We don't officially support i386 or PowerPC Mac builds of libjpeg-turbo
anymore, but they still work (bearing in mind that PowerPC builds
require GCC v4.0 in Xcode 3.2.6, and i386 builds require Xcode 9.x or
earlier.)  Referring to #495, apparently MacPorts needs this
functionality.
2021-01-21 10:51:49 -06:00
DRC
b6772910d3 Add Sponsor button for GitHub repository 2021-01-19 15:32:32 -06:00
DRC
399aa374bd Build: Support CMAKE_OSX_ARCHITECTURES
... as long as it contains only a singular value, which must equal
"x86_64" or "arm64".

Refer to #495
2021-01-19 12:25:11 -06:00
DRC
1719d12e51 cjpeg: Fix FPE when compressing 0-width GIF
Fixes #493
2021-01-14 18:38:06 -06:00
DRC
486cdcfb9d Fix build with Visual C++ and /std:c11 or /std:c17
Fixes #481
Closes #482
2021-01-12 17:45:55 -06:00
Richard Townsend
74e6ea45e3 Neon: Fix Huffman enc. error w/Visual Studio+Clang
The GNU builtin function __builtin_clzl() accepts an unsigned long
argument, which is 8 bytes wide on LP64 systems (most Un*x systems,
including Mac) but 4 bytes wide on LLP64 systems (Windows.)  This caused
the Neon intrinsics implementation of Huffman encoding to produce
mathematically incorrect results when compiled using Visual Studio with
Clang.

This commit changes all invocations of __builtin_clzl() in the Neon SIMD
extensions to __builtin_clzll(), which accepts an unsigned long long
argument that is guaranteed to be 8 bytes wide on all systems.

Fixes #480
Closes #490
2021-01-11 22:29:11 -06:00
Jonathan Wright
d2c4079959 Use CLZ compiler intrinsic for Windows/Arm builds
The __builtin_clz() compiler intrinsic was already used in the C Huffman
encoders when building libjpeg-turbo for Arm CPUs using a GCC-compatible
compiler.  This commit modifies the C Huffman encoders so that they also
use__builtin_clz() when building for Arm CPUs using Visual Studio +
Clang, as well as the equivalent _CountLeadingZeros() compiler intrinsic
when building for Arm CPUs using Visual C++.

In addition to making the C Huffman encoders faster on Windows/Arm, this
also prevents jpeg_nbits_table from being included in Windows/Arm builds,
thus saving 128 KB of memory.
2021-01-11 17:10:38 -06:00
DRC
3e8911aad5 Build: Use correct SIMD exts w/VStudio IDE + Arm64
When configuring a Visual Studio IDE build and passing -A arm64 to
CMake, CMAKE_SYSTEM_PROCESSOR will be amd64, so we should set CPU_TYPE
based on the value of CMAKE_GENERATOR_PLATFORM rather than the value of
CMAKE_SYSTEM_PROCESSOR.
2021-01-11 14:03:42 -06:00
DRC
4b838c38f9 jcphuff.c: Fix compiler warning with clang-cl
Fixes #492
2021-01-11 13:45:25 -06:00
DRC
944f5915cd Migrate from Travis CI to GitHub Actions
Note that this removes our ability to regression test the Armv8 and
PowerPC SIMD extensions, effectively reverting
a524b9b06b and
02227e48a9, but at the moment, there is no
other way.
2021-01-08 14:20:44 -06:00
DRC
3179f330b2 tjexample.c: Fix mem leak if tjTransform() fails
Fixes #479
2021-01-04 15:39:35 -06:00
DRC
1388ad6757 Build: Officially support Ninja 2020-12-08 21:25:47 -06:00
DRC
110d8d6dca decompress_smooth_data(): Fix another uninit. read
Regression introduced by 42825b68d5

The test case
https://user-images.githubusercontent.com/3491627/101376530-fde56180-38b0-11eb-938d-734119a5b5ba.jpg
is a malformed progressive JPEG image containing an interleaved Y/Cb/Cr
DC scan followed by two non-interleaved Y DC scans.  Thus, the
prev_coef_bits[] array was initialized for the Y component but not the
other components, the uninitialized values for Cb and Cr were
transferred to the prev_coef_bits_latch[] array in smoothing_ok(), and
because cinfo->master->last_good_iMCU_row was 0,
decompress_smooth_data() read those uninitialized values when attempting
to smooth the second iMCU row.

Possibly fixes #478
2020-12-07 12:51:26 -06:00
DRC
7b68764905 LICENSE.md: Remove trailing whitespace
Use <br> to indicate a line break, as we do in README.md, in order to
make checkstyle happy.
2020-12-03 21:20:42 -06:00
DRC
21d056847b Build: Test for correct AArch32 RPM/DEBARCH value
... based on the floating point ABI being used by the compiler (which
do you choose, a hard or soft option?)
2020-12-03 21:20:08 -06:00
DRC
6e4509a3f1 LICENSE.md: Formatting tweak 2020-12-01 09:04:27 -06:00
DRC
c7ca521bc8 Fix uninitialized read in decompress_smooth_data()
Regression introduced by 42825b68d5

Referring to the discussion in #459, the OSS-Fuzz test case
https://github.com/libjpeg-turbo/libjpeg-turbo/files/5597075/clusterfuzz-testcase-minimized-pngsave_buffer_fuzzer-5728375846731776.txt
created a situation in which
  cinfo->output_iMCU_row > cinfo->master->last_good_iMCU_row
but
  cinfo->input_scan_number == 1
thus causing decompress_smooth_data() to read from
prev_coef_bits_latch[], which was uninitialized.  I was unable to create
the same situation with a real JPEG image.
2020-11-28 07:06:08 -06:00
DRC
ccaba5d789 Fix buffer overrun with certain narrow prog JPEGs
Regression introduced by 6d91e950c8

last_block_column in decompress_smooth_data() can be 0 if, for instance,
decompressing a 4:4:4 image of width 8 or less or a 4:2:2 or 4:2:0 image
of width 16 or less.  Since last_block_column is an unsigned int,
subtracting 1 from it produced 0xFFFFFFFF, the test in line 590 passed,
and we attempted to access blocks from a second block column that didn't
actually exist.

Closes #476
2020-11-25 15:08:28 -06:00
DRC
cfc7e6e58e Bump revision to 2.0.91 for post-beta fixes 2020-11-25 14:10:55 -06:00
DRC
4e52b66f34 Travis: Use Docker tag that matches Git branch 2020-11-24 21:56:19 -06:00
DRC
8cf6f716bc Bump revision to 2.0.90 to prepare for beta 2020-11-24 21:32:48 -06:00
Jonathan Wright
eb14189caa Fix Neon SIMD build issues with Visual Studio
- Use the _M_ARM and _M_ARM64 macros provided by Visual Studio for
  compile-time detection of Arm builds, since __arm__ and __aarch64__
  are only present in GNU-compatible compilers.
- Neon/intrinsics: Use the _CountLeadingZeros() and
  _CountLeadingZeros64() intrinsics provided by Visual Studio, since
  __builtin_clz() and __builtin_clzl() are only present in
  GNU-compatible compilers.
- Neon/intrinsics: Since Visual Studio does not support static vector
  initialization, replace static initialization of Neon vectors with the
  appropriate intrinsics.  Compared to the static initialization
  approach, this produces identical assembly code with both GCC and
  Clang.
- Neon/intrinsics: Since Visual Studio does not support inline assembly
  code, provide alternative code paths for Visual Studio whenever inline
  assembly is used.
- Build: Set FLOATTEST appropriately for AArch64 Visual Studio builds
  (Visual Studio does not emit fused multiply-add [FMA] instructions by
  default for such builds.)
- Neon/intrinsics: Move temporary buffer allocation outside of nested
  loops.  Since Visual Studio configures Arm builds with a relatively
  small amount of stack memory, attempting to allocate those buffers
  within the inner loops caused a stack overflow.

Closes #461
Closes #475
2020-11-24 21:13:16 -06:00
DRC
91dd3b23ad ChangeLog: macOS Armv8/x86-64 univ. binary support 2020-11-24 20:31:59 -06:00
DRC
7e0d94d3a7 Merge branch 'master' into dev 2020-11-24 20:31:51 -06:00
DRC
1c839761cf Force Git to treat testorig.ppm as a binary file
Otherwise, because the file begins with an ASCII header, Git will
erroneously treat is as an ASCII file, and if Git for Windows is
configured with default options (specifically, "Checkout windows-style,
commit Unix-style line endings"), it will add carriage return characters
to all of the "linefeed" characters in the PPM file, thus corrupting it
and causing libjpeg-turbo's regression tests to fail.
2020-11-24 18:54:44 -06:00
DRC
6d91e950c8 Use 5x5 win & 9 AC coeffs when smoothing DC scans
... of progressive images.

Based on:
be8d36d13b
9d528f278e
85f36f0765
63a4d39e38
51336a6ad5

Closes #459
Closes #474
2020-11-24 18:21:42 -06:00
Kornel
1a7384c790 Run turbo's tests with turbo's settings
Fixes #384
2020-11-22 20:58:59 +00:00
Kornel
c302c77d17 Mark mozjpeg's output as acceptable 2020-11-22 20:58:59 +00:00
DRC
d523435e18 Travis: Use Xcode 12.2 for all iOS & macOS builds
There doesn't seem to be any performance or compatibility downside to
this, and it has the advantages of simplicity and consistency between
the PR and official builds.
2020-11-19 19:30:51 -06:00
Kornel
3940a92fa8 Readme refresh 2020-11-19 18:30:55 +00:00
DRC
1ac83cd636 Travis: The Mac build log is now log-macos.txt
(oversight from f7a10a61e3)
2020-11-18 18:16:12 -06:00
DRC
0ba70b6a13 Build: Support macOS Armv8/x86-64 univ. binaries
- Rename IOS_ARMV8_BUILD to ARMV8_BUILD.
- Rename install_ios() to install_subbuild() in makemacpkg.
- Wordsmith the build instructions accordingly.
- Use xcode12.2 image in Travis CI.
2020-11-18 17:40:44 -06:00
DRC
e417033d84 Merge branch 'master' into dev 2020-11-18 14:13:54 -06:00
DRC
6d2e8837b4 jpeg_skip_scanlines(): Avoid NULL + 0 UBSan error
This error occurs at the call to (*cinfo->cconvert->color_convert)() in
sep_upsample() whenever cinfo->upsample->need_context_rows == TRUE
(i.e. whenever h2v2 or h1v2 fancy upsampling is used.)  The error is
innocuous, since (*cinfo->cconvert->color_convert)() points to a dummy
function (noop_convert()) in that case.

Fixes #470
2020-11-18 13:33:47 -06:00
DRC
f7c5489244 Travis: Add /opt/local/bin to PATH for Mac build
(oversight from previous commit)

macports-ci does this, and it's necessary in order for the build script
to find md5sum.
2020-11-18 10:11:21 -06:00
DRC
f7a10a61e3 Build: "OS X"/"OSX" = "macOS"/"MACOS"
There are no supported versions of "OS X" anymore.  The operating system
has been named "macOS" since 10.12 Sierra, which was released four years
ago.
2020-11-17 13:53:33 -06:00
DRC
d111d9ff7a Merge branch 'master' into dev 2020-11-17 11:54:20 -06:00
DRC
10ba6ed336 Travis: Install MacPorts without using macports-ci 2020-11-16 17:38:06 -06:00
DRC
292d78e786 Merge branch 'master' into dev 2020-11-16 15:28:02 -06:00
DRC
88bf1d1678 Build: Set FLOATTEST more intelligently
The "32bit" vs. "64bit" floating point test results actually have
nothing to do with the FPU.  That was a fallacious assumption based on
the observation that, with multiple CPU types, 32-bit and 64-bit builds
produce different floating point test results.  It seems that this is,
in fact, due to differing compiler behavior-- more specifically, whether
fused multiply-add (FMA) instructions are used to combine multiple
floating point operations into a single instruction ("floating point
expression contraction".)  GCC does this by default if the target
supports FMA instructions, which PowerPC and AArch64 targets both do.

Fixes #468
2020-11-16 15:19:42 -06:00
DRC
8f8305981b Merge branch 'master' into dev 2020-11-13 15:21:26 -06:00
DRC
42f7c78fe3 BUILDING.md: Use min. iOS v8 in iOS Armv8 example
This is necessary in order to enable thread-local storage.
2020-11-13 15:18:35 -06:00
DRC
33859880e9 Neon: Auto-detect compiler intrinsics completeness
This allows the Neon intrinsics code to be built successfully (albeit
likely with reduced run-time performance) with Xcode 5.0-6.2
(iOS/AArch64) and Android NDK < r19 (AArch32).  Note that Xcode 5.0-6.2
will not build the Armv8 GAS code without gas-preprocessor.pl, and no
version of Xcode will build the Armv7 GAS code without
gas-preprocessor.pl, so we always use the full Neon intrinsics
implementation by default with macOS and iOS builds.

Auto-detecting the completeness of the compiler's set of Neon intrinsics
also allows us to more intelligently set the default value of
NEON_INTRINSICS, based on the values of HAVE_VLD1*.  This is a
reasonable, albeit imperfect, proxy for whether a compiler has a full
and optimal set of Neon intrinsics.  Specific notes:

  - 64-bit RGB-to-YCbCr color conversion
    does not use any of the intrinsics in question, regresses with GCC
  - 64-bit accurate integer forward DCT
    uses vld1_s16_x3(), regresses with GCC
  - 64-bit Huffman encoding
    uses vld1q_u8_x4(), regresses with GCC
  - 64-bit YCbCr-to-RGB color conversion
    does not use any of the intrinsics in question, regresses with GCC
  - 64-bit accurate integer inverse DCT
    uses vld1_s16_x3(), regresses with GCC
  - 64-bit 4x4 inverse DCT
    uses vld1_s16_x3().  I did not test this algorithm in isolation, so
    it may in fact regress with GCC, but the regression may be hidden by
    the speedup from the new SIMD-accelerated upsampling algorithms.

  - 32-bit RGB-to-YCbCr color conversion:
    uses vld1_u16_x2(), regresses with GCC
  - 32-bit accurate integer forward DCT
    uses vld1_s16_x3(), regression irrelevant because there was no
    previous implementation
  - 32-bit accurate integer inverse DCT
    uses vld1_s16_x3(), regresses with GCC
  - 32-bit fast integer inverse DCT
    does not use any of the intrinsics in question, regresses with GCC
  - 32-bit 4x4 inverse DCT
    uses vld1_s16_x3().  I did not test this algorithm in isolation, so
    it may in fact regress with GCC, but the regression may be hidden by
    the speedup from the new SIMD-accelerated upsampling algorithms.

Presumably when GCC includes a full and optimal set of Neon intrinsics,
the HAVE_VLD1* tests will pass, and the full Neon intrinsics
implementation will be enabled automatically.
2020-11-13 15:16:34 -06:00
DRC
3e9e7c7055 Fix build if WITH_12BIT==1 && WITH_JPEG(7|8)==1
Fixes #466
2020-11-11 17:54:06 -06:00
DRC
bbd8089297 Neon: Finalize intrinsics implementation
- Remove gas-preprocessor.pl.  None of the compilers that can build the
  new intrinsics implementation require gas-preprocessor.pl (tested
  with Xcode and with Clang 3.9+ for Linux.)
- Document that Xcode 6.3.x or later is now required for iOS builds
  (older versions of Xcode do not have a full set of Neon intrinsics.)
- Add a change log entry.
- Do not enable the ASM CMake language unless NEON_INTRINSICS is false.
- Add a Clang/Arm64 test to .travis.yml in order to test the new
  intrinsics implementation.

Closes #455
2020-11-10 19:58:28 -06:00
Martyn Jacques
141f26ff6d Neon: Intrinsics impl. of 2x2 and 4x4 scaled IDCTs
The previous AArch32 and AArch64 GAS implementations have been removed,
since the intrinsics implementations provide the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
4574f01f43 Neon: Intrinsics impl. of h2v1 & h2v2 plain upsamp
There was no previous GAS implementation.

NOTE: This doesn't produce much of a speedup when using -O3, because -O3
already enables Neon autovectorization, which works well for the scalar
C implementation of plain upsampling.  However, the Neon SIMD
implementation will benefit other optimization levels.
2020-11-10 19:09:09 -06:00
Jonathan Wright
ba52a3de32 Neon: Intrinsics impl of h2v1 & h2v2 merged upsamp
There was no previous GAS implementation.

This commit also reverts 40557b2301 and
7723d7f7d0.
7723d7f7d0 was only necessary because
there was no Neon implementation of merged upsampling/color conversion,
and 40557b2301 was only necessary because
of 7723d7f7d0.
2020-11-10 19:09:09 -06:00
Jonathan Wright
240ba417aa Neon: Intrinsics impl. of prog. Huffman encoding
The previous AArch64 GAS implementation has been removed, since the
intrinsics implementation provides the same or better performance.
There was no previous AArch32 GAS implementation.
2020-11-10 19:09:09 -06:00
Jonathan Wright
ed581cd935 Neon: Intrinsics impl. of accurate int inverse DCT
The previous AArch32 and AArch64 GAS implementations are retained by
default when using GCC, in order to avoid a performance regression.  The
intrinsics implementation can be forced on or off using the new
NEON_INTRINSICS CMake variable.
2020-11-10 19:09:09 -06:00
Jonathan Wright
2c6b68e283 Neon: Intrinsics impl. of fast integer Inverse DCT
The previous AArch32 GAS implementation is retained by default when
using GCC, in order to avoid a performance regression.  The intrinsics
implementation can be forced on or off using the new NEON_INTRINSICS
CMake variable.  The previous AArch64 GAS implementation has been
removed, since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
2acfb93c94 Neon: Intrinsics impl. of h1v2 fancy upsamling
There was no previous GAS implementation.
2020-11-10 19:09:09 -06:00
Jonathan Wright
975307775c Neon: Intrinsics impl. of h2v1 & h2v2 fancy upsamp
The previous AArch32 GAS implementation of h2v1 fancy upsampling has
been removed, since the intrinsics implementation provides the same or
better performance.  There was no previous GAS implementation of h2v2
fancy upsampling, and there was no previous AArch64 GAS implementation
of h2v1 fancy upsampling.
2020-11-10 19:09:09 -06:00
Jonathan Wright
5dbd39323c Neon: Intrinsics implementation of YCbCr->RGB565
The previous AArch64 GAS implementation is retained by default when
using GCC, in order to avoid a performance regression.  The intrinsics
implementation can be forced on or off using the new NEON_INTRINSICS
CMake variable.  The previous AArch32 GAS implementation has been
removed, since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
0f35cd68f2 Neon: Intrinsics implementation of YCbCr->RGB
The previous AArch64 GAS implementation is retained by default when
using GCC, in order to avoid a performance regression.  The intrinsics
implementation can be forced on or off using the new NEON_INTRINSICS
CMake variable.  The previous AArch32 GAS implementation has been
removed, since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
f3c3f01d23 Neon: Intrinsics impl. of Huffman encoding
The previous AArch64 GAS implementation is retained by default when
using GCC, in order to avoid a performance regression.  The intrinsics
implementation can be forced on or off using the new NEON_INTRINSICS
CMake variable.  The previous AArch32 GAS implementation has been
removed, since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
d0004de5dd Neon: Intrinsics impl. of accurate int forward DCT
The previous AArch64 GAS implementation is retained by default when
using GCC, in order to avoid a performance regression.  The intrinsics
implementation can be forced on or off using the new NEON_INTRINSICS
CMake variable.  There was no previous AArch32 GAS implementation.
2020-11-10 19:09:09 -06:00
Jonathan Wright
3d84668d42 Neon: Intrinsics impl. of fast integer forward DCT
The previous AArch32 and AArch64 GAS implementations have been removed,
since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
951d3677eb Neon: Intrinsics impl. of int sample conv./quant.
The previous AArch32 and AArch64 GAS implementations have been removed,
since the intrinsics implementation provides the same or better
performance.
2020-11-10 19:09:09 -06:00
Jonathan Wright
366168aa7d Neon: Intrinsics impl. of h2v1 & h2v2 downsampling
The previous AArch64 GAS implementation has been removed, since the
intrinsics implementation provides the same or better performance.
There was no previous AArch32 GAS implementation.
2020-11-10 19:09:09 -06:00
Jonathan Wright
f73b1dbc60 Neon: Intrinsics implementation of RGB->Grayscale
There was no previous GAS implementation.
2020-11-10 19:09:09 -06:00
Jonathan Wright
4f2216b435 Neon: Intrinsics implementation of RGB->YCbCr
The previous AArch32 and AArch64 GAS implementations are retained by
default when using GCC, in order to avoid a performance regression.  The
intrinsics implementation can be forced on or off using a new
NEON_INTRINSICS CMake variable.
2020-11-10 19:09:05 -06:00
DRC
0efc4858d4 Merge branch 'master' into dev 2020-11-09 19:02:28 -06:00
DRC
02227e48a9 Travis: Combine PPC/Arm tests with jpeg-7/8 tests
There is no reason not to, since the jpeg-7 and jpeg-8 API/ABI tests do
not exercise the SIMD extensions any differently than the other tests.
2020-11-09 18:20:41 -06:00
DRC
c7dd191271 Merge branch 'master' into dev 2020-11-08 15:15:02 -06:00
DRC
40557b2301 Build: Fix test failures w/ Arm Neon SIMD exts
Regression caused by
a46c111d9f

Because of 7723d7f7d0, which was
introduced in libjpeg-turbo 1.5.1 in response to #81, merged upsampling/
color conversion is disabled on platforms that have SIMD-accelerated
YCbCr -> RGB color conversion but not SIMD-accelerated merged
upsampling/color conversion.  This was intended to improve performance
with the Neon SIMD extensions, since those are the only SIMD extensions
for which those circumstances apply.  Under normal circumstances, the
separate "plain" (non-fancy) upsampling and color conversion routines
will produce bitwise-identical output to the merged upsampling/color
conversion routines, but that is not the case when skipping scanlines
starting at an odd-numbered scanline.  The modified test introduced in
a46c111d9f does precisely that in order to
validate the fixes introduced in
9120a24743 and
a46c111d9f.

Because of 7723d7f7d0, the segfault fixed
in 9120a24743 and
a46c111d9f didn't affect the Neon SIMD
extensions, so this commit effectively reverts the test modifications in
a46c111d9f when using those SIMD
extensions.  We can get rid of this hack, as well as
7723d7f7d0, once a Neon implementation of
merged upsampling/color conversion is available.
2020-11-08 14:57:01 -06:00
DRC
a524b9b06b Travis: Regression-test Armv8 and PPC SIMD exts
Currently this only tests the 64-bit code paths, but it's better than
nothing.
2020-11-06 17:24:16 -06:00
DRC
7c1a1789d2 Merge branch 'master' into dev 2020-11-05 16:04:55 -06:00
DRC
6e632af9f6 Demote "fast" [I]DCT algorithms to legacy status
- Refer to the "slow" [I]DCT algorithms as "accurate" instead, since
  they are not slow under libjpeg-turbo.
- Adjust documentation claims to reflect the fact that the "slow" and
  "fast" algorithms produce about the same performance on AVX2-equipped
  CPUs (because of the dual-lane nature of AVX2, it was not possible to
  accelerate the "fast" algorithm beyond what was achievable with SSE2.)
  Also adjust the claims to reflect the fact that the "fast" algorithm
  tends to be ~5-15% faster than the "slow" algorithm on
  non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo
  SIMD extensions.
- Indicate the legacy status of the "fast" and float algorithms in the
  documentation and cjpeg/djpeg usage info.
- Remove obsolete paragraph in the djpeg man page that suggested that
  the float algorithm could be faster than the "fast" algorithm on some
  CPUs.
2020-11-05 15:59:31 -06:00
DRC
cd342acf7f Merge branch 'master' into dev 2020-10-27 16:45:23 -05:00
DRC
c3bfbde21d jpegtran.c: "subarea" = "region"
It is our convention to use the term "region" when referring to crop
specs, since this is more consistent with the terminology used by the
rest of the image processing community.
2020-10-27 15:45:24 -05:00
DRC
a8656d703d jpegtran.1: Minor formatting tweak 2020-10-27 15:45:24 -05:00
DRC
9ecb67c219 transupp.c: Code formatting tweaks 2020-10-27 15:45:24 -05:00
DRC
53c685b7f4 cdjpeg.h: Remove unused function stub
enable_signal_catcher() was only needed with libjpeg's temp. file memory
manager (jmemname.c), which libjpeg-turbo has never supported.
2020-10-27 15:45:24 -05:00
DRC
d27b935a88 Consistify formatting to simplify checkstyle
The checkstyle script was hastily developed prior to libjpeg-turbo 2.0
beta1, so it has a lot of exceptions and is thus prone to false
negatives.  This commit eliminates some of those exceptions.
2020-10-27 15:45:09 -05:00
DRC
88ae60986e Merge branch 'ijg' into dev
- Restore GIF read/compressed GIF write support from jpeg-6a and
  jpeg-9d.
- Integrate jpegtran -wipe and -drop options from jpeg-9a and jpeg-9d.
- Integrate jpegtran -crop extension (for expanding the image size) from
  jpeg-9a and jpeg-9d.
- Integrate other minor code tweaks from jpeg-9*
2020-10-27 13:32:13 -05:00
DRC
7e4eac7021 Merge branch 'master' into dev 2020-10-26 09:41:32 -05:00
Guido Vollbeding
9fc018fd1a The Independent JPEG Group's JPEG software v9d 2020-10-23 10:00:48 -05:00
Guido Vollbeding
96e4e7eb60 The Independent JPEG Group's JPEG software v9c 2020-10-23 09:56:39 -05:00
DRC
26e3aedbe5 README.ijg: Update URLs; remove Usenet info 2020-10-22 23:06:22 -05:00
DRC
b4525f9f16 jversion.h: Update copyrights 2020-10-19 22:05:09 -05:00
DRC
59352195b2 Merge branch 'master' into dev 2020-10-19 21:17:46 -05:00
DRC
f7ca3c5a3d Build: Improve Arm 32-bit cross-comp./packaging
- Set CPU_TYPE=arm if performing a 32-bit build on an AArch64 system.
  This eliminates the need to use a CMake toolchain file.
- Set RPMARCH=armv7hl if building on a 32-bit Arm system with an FPU.
- Set RPMARCH=armv7hl and DEBARCH=armhf if performing a 32-bit build
  using a gnueabihf toolchain.
- If performing a 32-bit Arm build, generate a 32-bit supplementary DEB
  package for AArch64 systems.
2020-10-19 16:25:11 -05:00
DRC
1ed312eab6 "ARM"="Arm", "NEON"="Neon"
Refer to:
https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark
https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark

NOTE: These changes are only applied to change log entries for 2.0.x and
later, since the change log is a historical record and Arm's new
trademark policy did not go into effect until late 2017.
2020-10-15 17:47:31 -05:00
DRC
b8200c6601 Build: Add CMake package config files
Based on:
d34b89b411

Closes #339
Closes #342
2020-10-15 10:26:54 -05:00
DRC
ea8f643c16 Build: Remove lib32 symlink from official Mac pkg
(oversight from 4c5a15c362)
2020-10-15 10:26:17 -05:00
DRC
460dfe40e1 ChangeLog: Acknowledge 2.0.6 release 2020-10-15 10:26:17 -05:00
DRC
ae08115d4d Merge branch 'master' into dev 2020-10-15 10:25:46 -05:00
DRC
b5a1472781 Build: Fix permissions 2020-10-15 10:22:51 -05:00
DRC
190382b75f ChangeLog: Fix minor formatting issue 2020-10-14 15:14:26 -05:00
DRC
8789a5e255 Merge branch 'master' into dev 2020-10-01 21:27:47 -05:00
DRC
89c88c2509 ChangeLog.md: jpeg_crop_scanline(), not scanlines 2020-10-01 21:26:04 -05:00
DRC
2ec4a5ebe3 Fix dec artifacts w/cropped+smoothed prog DC scans
This commit modifies decompress_smooth_data(), adding missing MCU column
offsets to the prev_block_row and next_block_row indices that are used
for block rows other than the first and last.  Effectively, this
eliminates unexpected visual artifacts when using jpeg_crop_scanline()
along with interblock smoothing while decompressing the DC scan of a
progressive JPEG image.

Based on:
0227d4fb48

Fixes #456
Closes #457
2020-10-01 21:22:58 -05:00
DRC
1d7faf84a0 Merge branch 'master' into dev 2020-10-01 18:17:46 -05:00
DRC
8e895c79e1 Java dox: Fix errors w/ javadoc in Java 8 or later 2020-10-01 18:14:21 -05:00
DRC
2b121d39e7 Merge branch 'master' into dev 2020-10-01 16:20:14 -05:00
DRC
2d14fc2e3b Dox: Re-generate using Doxygen 1.8.20
This fixes a GitHub Dependabot alert regarding jquery.js.

Fixes #421
2020-10-01 14:36:30 -05:00
Kornel
d23e3fc586 Update release token 2020-09-29 11:41:33 +01:00
Kornel Lesiński
f1d512de2f Make test output match turbojpeg tests 2020-09-29 11:41:14 +01:00
dofuuz
751ce7d9f3 Automate Windows build and deploy (with PNG support) (#379) 2020-09-29 11:40:16 +01:00
Kornel
ffea183e55 Response to the rumor mill 2020-09-29 10:32:19 +01:00
dofuuz
3fed7e016b Add PNG support to cjpeg shared build 2020-09-20 23:11:41 +01:00
DRC
6ab61fa1d1 Merge branch 'master' into dev 2020-09-13 17:02:27 -05:00
DRC
fe5b6a1c7c TJPEG: Remove unnecessary setCompDefaults() retval
setCompDefaults() hasn't thrown an error since
aa7459050d was introduced in 2.0.x.
2020-09-13 16:58:08 -05:00
DRC
6ee5d5f568 ARMv8 NEON: Support Windows builds w/AArch64 MinGW
Based on:
c5ef665928

Closes #438
2020-07-28 18:24:41 -05:00
DRC
fe79f56b77 Merge branch 'master' into dev 2020-07-28 15:09:00 -05:00
DRC
c1037f4380 Fix bad return val when skipping past end of image
Fixes #439
2020-07-28 14:59:41 -05:00
DRC
30282a878c README.md, jquant2.c: Use gender-neutral pronouns
Closes #444
2020-07-28 13:08:35 -05:00
DRC
a46c111d9f Further jpeg_skip_scanlines() fixes
- Introduce a partial image decompression regression test script that
  validates the correctness of jpeg_skip_scanlines() and
  jpeg_crop_scanlines() for a variety of cropping regions and libjpeg
  settings.

  This regression test catches the following issues:
  #182, fixed in 5bc43c7821
  #237, fixed in 6e95c08649794f5018608f37250026a45ead2db8
  #244, fixed in 398c1e9acc
  #441, fully fixed in this commit

  It does not catch the following issues:
  #194, fixed in 773040f9d9
  #244 (additional segfault), fixed in
       9120a24743

- Modify the libjpeg-turbo regression test suite (make test) so that it
  checks for the issue reported in #441 (segfault in
  jpeg_skip_scanlines() when used with 4:2:0 merged upsampling/color
  conversion.)

- Fix issues in jpeg_skip_scanlines() that caused incorrect output with
  h2v2 (4:2:0) merged upsampling/color conversion.  The previous commit
  fixed the segfault reported in #441, but that was a symptom of a
  larger problem.  Because merged 4:2:0 upsampling uses a "spare row"
  buffer, it is necessary to allow the upsampler to run when skipping
  rows (fancy 4:2:0 upsampling, which uses context rows, also requires
  this.)  Otherwise, if skipping starts at an odd-numbered row, the
  output image will be incorrect.

- Throw an error if jpeg_skip_scanlines() is called with two-pass color
  quantization enabled.  With two-pass color quantization, the first
  pass occurs within jpeg_start_decompress(), so subsequent calls to
  jpeg_skip_scanlines() interfere with the multipass state and prevent
  the second pass from occurring during subsequent calls to
  jpeg_read_scanlines().
2020-07-28 12:47:53 -05:00
DRC
9120a24743 Fix jpeg_skip_scanlines() segfault w/merged upsamp
The additional segfault mentioned in #244 was due to the fact that
the merged upsamplers use a different private structure than the
non-merged upsamplers.  jpeg_skip_scanlines() was assuming the latter, so
when merged upsampling was enabled, jpeg_skip_scanlines() clobbered one
of the IDCT method pointers in the merged upsampler's private structure.

For reasons unknown, the test image in #441 did not encounter this
segfault (too small?), but it encountered an issue similar to the one
fixed in 5bc43c7821, whereby it was
necessary to set up a dummy postprocessing function in
read_and_discard_scanlines() when merged upsampling was enabled.
Failing to do so caused either a segfault in merged_2v_upsample() (due
to a NULL pointer being passed to jcopy_sample_rows()) or an error
("Corrupt JPEG data: premature end of data segment"), depending on the
number of scanlines skipped and whether the first scanline skipped was
an odd- or even-numbered row.

Fixes #441
Fixes #244 (for real this time)
2020-07-23 23:19:13 -05:00
DRC
c965dc7a79 ChangeLog.md: Add missing sub-header for 2.0.6 2020-07-22 13:59:27 -05:00
DRC
b9142b21f8 Android: Fix "using JNI after critical get" errors
(again.)

Fixes #300
2020-07-22 13:53:21 -05:00
DRC
7d829bfa30 Bump version to 2.0.6 to prepare for new commits 2020-07-07 10:16:29 -05:00
DRC
fb6f5e8b01 Java/Mac:Remove obsolete libturbojpeg.jnilib alias
IIRC, this was only necessary with the version of Java 1.5 that shipped
with OS X 10.4 "Tiger".  Apple's implementation of Java 6 ("Java for
OS X Systems") supported both .jnilib and .dylib extensions for JNI
libraries, but Oracle's implementation of Java has only ever supported
the .dylib extension.
2020-06-25 21:41:30 -05:00
DRC
c77783ed41 BUILDING.md: Undocument 32-bit Mac build/packaging
(oversight from previous commit)
2020-06-25 21:28:33 -05:00
DRC
4c5a15c362 Eliminate 32-bit Mac build/packaging support
The scales have now tilted overwhelmingly in favor of eliminating
support for 32-bit Macs:

- 32-bit applications are only necessary in order to support OS X 10.5
  "Leopard" and OS X 10.6 "Snow Leopard".  OS X 10.7 "Lion" requires a
  64-bit Mac and supports all 64-bit Macs.
- 32-bit applications are no longer allowed in the macOS App Store.
- 32-bit applications no longer run in macOS 10.15 "Catalina".
- 32-bit applications do not support thread-local storage, so the
  TurboJPEG API library's global error handler is not thread-safe with
  such applications.
- libjpeg-turbo 2.1.x no longer supports 32-bit iOS apps, so it makes
  sense to also eliminate support for 32-bit macOS applications.

It's time.
2020-06-25 19:48:18 -05:00
DRC
b797f70012 Build: Eliminate Cygwin packaging support
We haven't provided official Cygwin builds since 1.4.x, since Cygwin
now supplies its own libjpeg-turbo packages (although they apparently
haven't been updated past 1.5.3.)
2020-06-25 19:05:45 -05:00
DRC
80d77720c3 AppVeyor: We no longer build/package JNI JARs
This was done solely to support Java Web Start, which is now obsolete.
2020-06-19 00:22:49 -05:00
DRC
aecee25695 Merge branch 'master' into dev 2020-06-19 00:03:51 -05:00
DRC
70040cb7ee Merge branch 'master' into dev 2020-06-02 15:05:43 -05:00
DRC
219e8e8f65 Merge branch 'master' into dev 2020-04-02 22:26:19 -05:00
DRC
b0f92a1d6c Merge branch 'master' into dev 2020-03-04 11:09:41 -06:00
DRC
77ff3bd66d Merge branch 'master' into dev 2020-02-18 12:56:01 -06:00
DRC
00d48d7e8c Merge branch 'master' into dev 2020-02-17 18:14:10 -06:00
DRC
9a2cf32317 Build: Enable separate iOS pkg/DMG w/ sim support
Refer to #406
2020-02-11 13:56:12 -06:00
DRC
6aabca86d3 Merge branch 'master' into dev 2020-02-11 12:47:12 -06:00
DRC
379edfd815 AppVeyor: Use Visual C++ 2015 instead of 2010
Visual C++ < 2015 is no longer under mainstream support, and Visual C++
2010 will not be supported at all after July of this year.
(https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing)
2020-01-16 20:55:42 -06:00
DRC
ada6ea5105 BUILDING.md: Update Visual C++ recommendations 2020-01-16 20:52:15 -06:00
DRC
167b5a8059 Merge branch 'master' into dev 2020-01-08 15:02:58 -06:00
DRC
4c57ad476c Merge branch 'master' into dev 2020-01-08 14:26:02 -06:00
DRC
04d3143a65 Merge branch 'master' into dev 2020-01-07 16:21:03 -06:00
DRC
b34c85ea4a Merge branch 'master' into dev 2019-12-31 01:20:12 -06:00
DRC
c4675d62e8 Merge branch 'master' into dev 2019-12-31 00:58:42 -06:00
DRC
80acd5c4a7 Remove code for the obsolete RLE image format
libjpeg-turbo never included that code, because it requires an external
library (the Utah Raster Toolkit.)  The RLE image format was supplanted
by GIF in the late 1980s, so it is rarely seen these days.  (It had a
lousy Weissman score, anyhow.)
2019-12-19 10:36:26 -06:00
DRC
5000eaa3a6 cdjpeg.c: Fix Visual C++ compiler warning
(introduced by previous commit)
2019-12-19 10:13:05 -06:00
DRC
e98b061282 Add fault tolerance features to djpeg and jpegtran
- Enable progress reporting at run time using a new -report argument
  (cjpeg now supports that argument as well)
- Limit the allowable number of scans using a new -maxscans argument
- Treat warnings as fatal using a new -strict argument

This mainly demonstrates how to work around the two issues with the
JPEG standard described here:
https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
since those and similar issues continue to be erroneously reported as
libjpeg-turbo bugs.
2019-12-18 15:35:56 -06:00
DRC
54288598bb ChangeLog.md: Document 81b8c0ee 2019-12-17 15:48:10 -06:00
DRC
81b8c0eed5 Loongson MMI: Merge with MIPS64/add auto-detection
Modern Loongson processors are MIPS64-compatible, and MMI instructions
are now supported in the mainline of GCC.  Thus, this commit adds
compile-time and run-time auto-detection of MMI instructions and moves
the MMI SIMD extensions for libjpeg-turbo from simd/loongson/ to
simd/mips64/.  That will allow MMI and MSA instructions to co-exist
in the same build once #377 has been integrated.

Based on:
82953ddd61

Closes #383
2019-12-17 14:35:49 -06:00
DRC
52fef34928 Eliminate internal use of GETJOCTET() macro
Because of 01e3032354 (officially
eliminating support for compilers without unsigned char, since we never
effectively supported those compilers anyhow), GETJOCTET() is now a
no-op.  Since that macro is in jmorecfg.h, it is part of the de facto
libjpeg API and must remain in the public headers.  However, there is no
reason to continue using it internally, and eliminating its internal use
improves code readability.
2019-12-10 19:10:55 -06:00
mayeut
e821464f79 ARM64 NEON SIMD impl. of prog. Huffman encoding
This commit adds ARM64 NEON optimizations for the
encode_mcu_AC_first() and encode_mcu_AC_refine() functions used in
progressive Huffman encoding.

Compression speedups for the typical set of five libjpeg-turbo test
images (https://libjpeg-turbo.org/About/Performance):
Cortex-A53: 23.8-39.2% (avg. 32.2%)
Cortex-A72: 26.8-41.1% (avg. 33.5%)
Apple A7:  29.7-45.9% (avg. 39.6%)

Closes #229
2019-12-10 00:21:57 -06:00
DRC
b8a7680e12 Merge branch 'master' into dev 2019-12-05 22:38:05 -06:00
DRC
f64c5508df Merge branch 'master' into dev 2019-12-05 15:41:28 -06:00
DRC
26b4d62a65 Merge branch 'master' into dev 2019-11-15 13:58:22 -06:00
DRC
9c6f79e919 Fix formatting issues detected by checkstyle 2019-11-14 12:16:38 -06:00
DRC
f60b6dd36f Remove vestigial jpeg_nbits_table.inc
Not needed since 087c29e07f
2019-11-12 17:42:39 -06:00
DRC
c43a5081ce Merge branch 'master' into dev 2019-11-12 17:07:46 -06:00
DRC
713c451f58 Enable SSE2 progressive Huffman encoder for x32
Referring to #289, I'm not sure where I arrived at the conclusion that
the SSE2 progressive Huffman encoder doesn't provide any speedup for
x32.  Upon re-testing, I discovered it to be about 50% faster than the
C encoder.

This commit also re-purposes one of the CI tests (specifically, the
jpeg-7 API/ABI test) so that it tests x32 as well.
2019-11-08 16:03:38 -06:00
DRC
2234deeeed Fix MSan use-of-uninitialized-value error
... introduced by 42825b68d5.  In fact,
fault-tolerant multi-scan block smoothing cannot currently be used with
the arithmetic decoder, because that decoder doesn't have any way of
distinguishing a normal end of scan from an unexpected end of scan.
Thus, this commit also modifies the change log to reset the expectations
regarding the scope of the fault-tolerant multi-scan block smoothing
feature.  If, at some point in the future, the arithmetic decoder can be
modified to detect an unexpected end of scan, then one would need only
set entropy->pub.insufficient_data = TRUE when the arithmetic decoder
encounters an unexpected end of scan in order to make fault-tolerant
block smoothing work properly with that decoder.
2019-11-08 13:51:34 -06:00
DRC
82695cfddf ChangeLog: Acknowledge 2.0.3/de-acknowledge 2.0.4
It is very unlikely that there will be an official 2.0.4 release.
2019-11-07 15:15:36 -06:00
DRC
42825b68d5 Fault-tolerant multi-scan block smoothing
This commit modifies the behavior of the block smoothing algorithm in
the libjpeg API library so that, if a scan in a multi-scan JPEG image is
incomplete (due to premature termination of the image stream), the block
smoothing parameters from the previous (complete) scan are used to
smooth any iMCU rows that the incomplete scan does not contain.

Closes #343
2019-11-07 15:12:54 -06:00
DRC
f2d4b47315 Travis: Use Docker tag that matches Git branch
dcommander/buildljt:dev is a CentOS 6 container with YASM 1.2.0 rather
than NASM 2.10, so it can build the new optimized SSE2 Huffman encoder.
2019-11-07 03:07:17 -06:00
DRC
45dff48c9f Merge branch 'master' into dev 2019-11-06 23:02:03 -06:00
DRC
d70047fcd2 Travis: Use GCC 6 for Mac pre-release builds
The primary impetus for this is to eliminate build warnings, such as

  (32-bit only)
  section "__textcoal_nt" is deprecated

  object file (XXXXXX.o) was built for newer OSX version (10.XX) than
  being linked (10.5)

Upgrading to GCC 6 results in neutral performance for compression,
a measured average overall decompression speedup of 2.5% for 64-bit
code, and a measured average overall decompression speedup of -4.3% for
32-bit code on a 3 GHz Core i7.  The 4.3% slow-down for 32-bit code is
deemed acceptable, given that 32-bit macOS apps are deprecated.
2019-11-05 17:57:59 -06:00
DRC
cbf0fcc8b7 i386 SSE2 Huffman: Fix pointer arithmetic issue
Splitting the pointer arithmetic in GET_SYM() into a separate add and
sub instruction was an attempt to work around an error ("invalid operand
type") that occurred when assembling the file with NASM.  However, this
created a link error on macOS ("ld: illegal text-relocation to
'_jconst_huff_encode_one_block' in
simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o from
'_jsimd_huff_encode_one_block_sse2' in
simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o for architecture i386")
and also changed the alignment of the code in ways that might have
affected the previous benchmark results (which took a great deal of time
to obtain.)  Ultimately, the path of least resistance is just to
require NASM 2.13 or later.
2019-11-05 15:56:28 -06:00
DRC
bbedb4b564 Merge branch 'master' into dev 2019-11-05 15:43:21 -06:00
DRC
087c29e07f Optimize Huffman encoding
This commit improves the C and SSE2 Huffman encoding implementations in
the following ways:

- Avoid using xmm8-xmm15 in the x86-64 SSE2 implementation.  There is no
  actual need to use those registers, and avoiding them produces a
  cleaner WIN64 function entry/exit-- as well as shorter code, since REX
  prefixes can be avoided (this is helpful on certain CPUs, such as
  Intel Atom, for which instruction fetch and decoding can be a
  bottleneck.)
- Optimize register usage so that fewer REX prefixes and
  register-register moves are needed.
- Use the bit counter to store the number of free bits in the bit buffer
  rather than the number of bits in the bit buffer.  This changes the
  method for inserting a code into the bit buffer to:

  (put_buffer |= code << (free_bits -= code_size));

  As a result:
  * Only one bit counter needs to stay in a register (we just keep it in
    cl.)
  * The bit buffer contents are already properly aligned to be written
    out (after a byte swap.)
  * Adjusting the free bits counter and checking if the bit buffer is
    full can be combined into a single operation.
  * We can wait to flush the bit buffer until the buffer is actually
    full and not just in danger of becoming full.  Thus, eight bytes can
    be flushed at a time.

- Speed is quite sensitive to the alignment of branch target labels, so
  insert some padding and remove branches from the flush code.
  (Flushing this way isn't actually faster when compared to using
  branches, but the branchless code doesn't need extra alignment and is
  thus smaller.)
- Speculatively write out the bit buffer as a single 8-byte write,
  falling back to a byte-by-byte write only if there are any 0xFF bytes
  in the bit buffer that need to be encoded as 0xFF 0x00.
- Use MMX registers for the 32-bit implementation (so the bit buffer can
  be 64 bits wide.)
- Slightly reduce overall function code size.
- Eliminate or combine a few SSE instructions.
- Make some minor improvements to instruction scheduling.
- Adjust flush_bits() in jchuff.c to handle cases in which the bit
  buffer has less than 7 free bits (apparently that couldn't happen
  before.)

Based on:
947a09defa
262ebb6b81
6e9a091221

See change log for performance claims.

Closes #292
2019-11-04 19:04:05 -06:00
DRC
d92ae5df0c Merge branch 'master' into dev 2019-11-04 18:50:45 -06:00
DRC
adf9cc942f j*huff.c: Remove crufty ASSIGN_STATE() macro
This macro is a relic of libjpeg's historic need to support a wide
variety of C compilers with varying degrees of compatibility.  Such was
necessary during the open systems era, because C compilers were often
supplied by the system vendor.  Prior to 1989, there was no C standard
per se, and even after ANSI C became a thing, there were still compilers
in use that didn't conform to it (libjpeg was first released in 1991.)

Realistically, only a handful of C compilers are in widespread use these
days, and all modern C compilers should support structure assignment.
2019-10-24 02:13:34 -05:00
DRC
95f4d6ef8b Merge branch 'master' into dev 2019-10-24 02:13:23 -05:00
DRC
2ae2bd66b4 Remove support for Apple's Java implementation
(AKA "Java for OS X systems.")  This implementation of Java 1.6 is long
obsolete and not supported on any version of macOS past High Sierra.
Oracle no longer provides a 32-bit JVM on macOS, so it is no longer
necessary to provide a 32-bit version of the TurboJPEG Java wrapper on
macOS.
2019-10-04 16:31:46 -05:00
DRC
b7523059c1 Merge branch 'master' into dev 2019-10-04 15:53:30 -05:00
DRC
b4110b65fc Merge branch 'master' into dev 2019-09-04 18:58:12 -05:00
DRC
8ef53b102f Merge branch 'master' into dev 2019-08-14 22:08:59 -05:00
DRC
7fbfe29c65 Merge branch 'master' into dev 2019-07-18 15:18:27 -05:00
DRC
051f4862f9 Travis: Fix iOS build
The new libjpeg-turbo 2.1.x official build scripts expect Xcode to be
under /Applications/Xcode83.app.
2019-05-09 20:46:18 -05:00
DRC
c055c88057 Discontinue support for 32-bit iOS builds 2019-05-09 20:36:51 -05:00
DRC
85d96d4478 Merge branch 'master' into dev 2019-05-09 19:13:39 -05:00
DRC
f36d531553 Merge branch 'master' into dev 2019-04-23 14:54:23 -05:00
DRC
8a0e35b212 Merge branch 'master' into dev 2019-04-15 13:41:45 -05:00
DRC
afbe48c290 MMI: Support 32-bit Loongson architectures 2019-02-27 13:36:48 -06:00
DRC
98ff5507d8 MMI: Fix bug in jsimd_h2v1_merged_upsample_mmi()
... that occurred when ((image width) & 1) != 0.
2019-02-27 13:36:48 -06:00
DRC
3ca6dba96e Merge branch 'master' into dev 2019-02-17 09:33:57 -06:00
DRC
aaf58dabb6 Merge branch 'master' into dev 2019-02-13 17:05:26 -06:00
DRC
a9075a17c3 Merge branch 'master' into dev 2019-02-12 13:42:57 -06:00
DRC
bdec995839 MMI: Fix unaligned decomp. perf. for 32-bit PFs
(Oversight from db84125fcb)
2019-02-01 01:16:13 -06:00
DRC
fa905fbf7b MMI: Use unaligned stores w/ merged upsampling
... when necessary.  This was an oversight from
2f9e7c84d1
2019-02-01 01:03:32 -06:00
DRC
9aada25ced Merge branch 'master' into dev 2019-02-01 01:02:55 -06:00
DRC
73fd604161 MMI: Fix formatting issue detected by checkstyle 2019-02-01 00:24:09 -06:00
DRC
2f9e7c84d1 Loongson MMI h2v1 and h2v2 merged upsampling
Based on:
e8f5cee5aa
2019-01-31 23:18:48 -06:00
DRC
3c7199ff06 Loongson MMI h2v1 fancy upsampling
Based on:
e8f5cee5aa
2019-01-31 17:01:01 -06:00
DRC
73b98acd8b Loongson MMI RGB-to-Grayscale conversion
Based on:
e8f5cee5aa
2019-01-31 16:44:55 -06:00
DRC
bb0d170288 Improve readability of Loongson MMI code
We have more than eight registers to work with, as well as three-operand
intrinsics, so there's no need for the implementation to be such a
literal port of the MMX code.
2019-01-31 16:44:48 -06:00
DRC
db84125fcb MMI: Use aligned store instructions when possible
This improves decompression performance by 2-5%.
2019-01-31 15:30:58 -06:00
DRC
ae4221f905 Loongson MMI fast forward/inverse DCT
Based on:
32a9ca222d
2019-01-31 15:30:58 -06:00
DRC
674343ab14 Merge branch 'master' into dev 2019-01-31 15:30:25 -06:00
DRC
6fac90945a wrbmp.c, wrtarga.c: Remove unused variables
(should have been done with the previous commit)
2019-01-23 16:18:41 -06:00
DRC
01e3032354 Eliminate support for compilers w/o unsigned char
libjpeg-turbo has never really supported such compilers, since (AFAIK)
they are non-existent on any modern computing platform and thus
impossible for us to test.  (Also, the TurboJPEG API would break without
unsigned chars.)

Furthermore, the unified CMake-based build system introduced in 2.0
always defines HAVE_UNSIGNED_CHAR, so retaining other code paths is
pointless.  Eliminating support for compilers without unsigned char
eliminates the need for the GETJSAMPLE() macro, which improves the
readability of many parts of the code as well as improving the
performance of writing Targa and Windows BMP files.

Fixes #317
2019-01-23 15:12:26 -06:00
DRC
42d62bf114 Merge branch 'master' into dev 2019-01-23 11:20:11 -06:00
DRC
a39c970d27 Merge branch 'master' into dev 2019-01-01 21:53:19 -06:00
DRC
12f3d0be84 Merge branch 'master' into dev 2019-01-01 21:52:21 -06:00
DRC
2cc4f93c88 Merge branch 'master' into dev 2018-11-12 14:40:19 -06:00
DRC
133e4af070 Add x32 ABI support on Linux
The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers.
(Refer to https://sites.google.com/site/x32abi)

Based on:
8da8fc5213
1e33dfea80
24ffea78da
dedcf76753
d04228a7b5
b4ad38316a

Closes #274
2018-09-05 17:10:06 -05:00
DRC
995eb29dc3 Bump version to 2.1 alpha1
(to prepare for new features)
2018-09-05 09:08:00 -05:00
590 changed files with 82159 additions and 36456 deletions

5
.gitattributes vendored
View File

@@ -1,4 +1,5 @@
/.travis.yml export-ignore
/appveyor.yml export-ignore
/ci export-ignore
/.gitattributes export-ignore
/.github export-ignore
*.ppm binary
/ChangeLog.md conflict-marker-size=8

8
.github/pull_request_template.md vendored Normal file
View File

@@ -0,0 +1,8 @@
**Complete description of the bug fix or feature that this pull request implements**
**Checklist before submitting the pull request, to maximize the chances that the pull request will be accepted**
- [ ] Read CONTRIBUTING.md, a link to which appears under "Helpful resources" below. That document discusses general guidelines for contributing to libjpeg-turbo, as well as the types of contributions that will not be accepted or are unlikely to be accepted.
- [ ] Search the existing issues and pull requests (both open and closed) to ensure that a similar request has not already been submitted and rejected.
- [ ] Discuss the proposed bug fix or feature in a GitHub issue, through direct e-mail with the project maintainer, or on the libjpeg-turbo-devel mailing list.

View File

@@ -8,40 +8,28 @@ Build Requirements
### All Systems
- [CMake](http://www.cmake.org) v2.8.12 or later
- [CMake](https://cmake.org) v2.8.12 or later
- [NASM](http://www.nasm.us) or [YASM](http://yasm.tortall.net)
- [NASM](https://nasm.us) or [Yasm](https://yasm.tortall.net)
(if building x86 or x86-64 SIMD extensions)
* If using NASM, 2.10 or later is required.
* If using NASM, 2.10 or later (except 2.11.08) is required for an x86-64 Mac
build (2.11.08 does not work properly with libjpeg-turbo's x86-64 SIMD code
when building macho64 objects.)
* If using YASM, 1.2.0 or later is required.
* If building on macOS, NASM or YASM can be obtained from
[MacPorts](http://www.macports.org/) or [Homebrew](http://brew.sh/).
* If using NASM, 2.13 or later is required.
* If using Yasm, 1.2.0 or later is required.
* NASM 2.15 or later is required if building libjpeg-turbo with Intel
Control-flow Enforcement Technology (CET) support.
* If building on macOS, NASM or Yasm can be obtained from
[MacPorts](https://macports.org) or [Homebrew](https://brew.sh).
- NOTE: Currently, if it is desirable to hide the SIMD function symbols in
Mac executables or shared libraries that statically link with
libjpeg-turbo, then NASM 2.14 or later or YASM must be used when
libjpeg-turbo, then NASM 2.14 or later or Yasm must be used when
building libjpeg-turbo.
* If building on Windows, **nasm.exe**/**yasm.exe** should be in your `PATH`.
* NASM and YASM are located in the CRB (Code Ready Builder) repository on
Red Hat Enterprise Linux 8 and in the PowerTools repository on CentOS 8,
which is not enabled by default.
The binary RPMs released by the NASM project do not work on older Linux
systems, such as Red Hat Enterprise Linux 5. On such systems, you can easily
build and install NASM from a source RPM by downloading one of the SRPMs from
<http://www.nasm.us/pub/nasm/releasebuilds>
and executing the following as root:
ARCH=`uname -m`
rpmbuild --rebuild nasm-{version}.src.rpm
rpm -Uvh /usr/src/redhat/RPMS/$ARCH/nasm-{version}.$ARCH.rpm
NOTE: the NASM build will fail if texinfo is not installed.
* If NASM or Yasm is not in your `PATH`, then you can specify the full path
to the assembler by using either the `CMAKE_ASM_NASM_COMPILER` CMake
variable or the `ASM_NASM` environment variable. On Windows, use forward
slashes rather than backslashes in the path (for example,
**c:/nasm/nasm.exe**).
* NASM and Yasm are located in the CRB (Code Ready Builder) or PowerTools
repository on Red Hat Enterprise Linux 8+ and derivatives, which is not
enabled by default.
### Un*x Platforms (including Linux, Mac, FreeBSD, Solaris, and Cygwin)
@@ -49,11 +37,9 @@ Build Requirements
- If building the TurboJPEG Java wrapper, JDK or OpenJDK 1.5 or later is
required. Most modern Linux distributions, as well as Solaris 10 and later,
include JDK or OpenJDK. On OS X 10.5 and 10.6, it will be necessary to
install the Java Developer Package, which can be downloaded from
<http://developer.apple.com/downloads> (Apple ID required.) For other
systems, you can obtain the Oracle Java Development Kit from
<http://www.oracle.com/technetwork/java/javase/downloads>.
include JDK or OpenJDK. For other systems, you can obtain the Oracle Java
Development Kit from
<https://oracle.com/java/technologies/downloads>.
* If using JDK 11 or later, CMake 3.10.x or later must also be used.
@@ -62,49 +48,64 @@ Build Requirements
- Microsoft Visual C++ 2005 or later
If you don't already have Visual C++, then the easiest way to get it is by
installing the
[Windows SDK](http://msdn.microsoft.com/en-us/windows/bb980924.aspx).
The Windows SDK includes both 32-bit and 64-bit Visual C++ compilers and
everything necessary to build libjpeg-turbo.
installing
[Visual Studio Community Edition](https://visualstudio.microsoft.com),
which includes everything necessary to build libjpeg-turbo.
* You can also use Microsoft Visual Studio Express/Community Edition, which
is a free download. (NOTE: versions prior to 2012 can only be used to
build 32-bit code.)
* You can also download and install the standalone Windows SDK (for Windows 7
or later), which includes command-line versions of the 32-bit and 64-bit
Visual C++ compilers.
* If you intend to build libjpeg-turbo from the command line, then add the
appropriate compiler and SDK directories to the `INCLUDE`, `LIB`, and
`PATH` environment variables. This is generally accomplished by
executing `vcvars32.bat` or `vcvars64.bat` and `SetEnv.cmd`.
`vcvars32.bat` and `vcvars64.bat` are part of Visual C++ and are located in
the same directory as the compiler. `SetEnv.cmd` is part of the Windows
SDK. You can pass optional arguments to `SetEnv.cmd` to specify a 32-bit
or 64-bit build environment.
executing `vcvars32.bat` or `vcvars64.bat`, which are located in the same
directory as the compiler.
* If built with Visual C++ 2015 or later, the libjpeg-turbo static libraries
cannot be used with earlier versions of Visual C++, and vice versa.
* The libjpeg API DLL (**jpeg{version}.dll**) will depend on the C run-time
DLLs corresponding to the version of Visual C++ that was used to build it.
- Vcpkg
You need to download and install libpng using the [vcpkg](https://github.com/Microsoft/vcpkg) dependency manager:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.bat
./vcpkg integrate install
./vcpkg install libpng:x64-windows
./vcpkg install libpng:x64-windows-static
Actually, you can just download and install MozJPEG using vcpkg dependency manager:
./vcpkg install mozjpeg
The mozjpeg port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please [create an issue or pull request](https://github.com/Microsoft/vcpkg) on the vcpkg repository.
... OR ...
- MinGW
[MSYS2](http://msys2.github.io/) or [tdm-gcc](http://tdm-gcc.tdragon.net/)
[MSYS2](https://msys2.org) or [tdm-gcc](https://jmeubank.github.io/tdm-gcc)
recommended if building on a Windows machine. Both distributions install a
Start Menu link that can be used to launch a command prompt with the
appropriate compiler paths automatically set.
- If building the TurboJPEG Java wrapper, JDK 1.5 or later is required. This
can be downloaded from
<http://www.oracle.com/technetwork/java/javase/downloads>.
<https://oracle.com/java/technologies/downloads>.
* If using JDK 11 or later, CMake 3.10.x or later must also be used.
- Vcpkg
You can download and install mozjpeg using the [vcpkg](https://github.com/Microsoft/vcpkg) dependency manager:
Sub-Project Builds
------------------
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
vcpkg install mozjpeg
The mozjpeg port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please [create an issue or pull request](https://github.com/Microsoft/vcpkg) on the vcpkg repository.
The libjpeg-turbo build system does not support being included as a sub-project
using the CMake `add_subdirectory()` function. Use the CMake
`ExternalProject_Add()` function instead.
Out-of-Tree Builds
@@ -120,6 +121,14 @@ directory, whereas *{source_directory}* refers to the libjpeg-turbo source
directory. For in-tree builds, these directories are the same.
Ninja
-----
If using Ninja, then replace `make` or `nmake` with `ninja`, and replace the
CMake generator (specified with the `-G` option) with `Ninja`, in all of the
procedures and recipes below.
Build Procedure
---------------
@@ -300,15 +309,6 @@ API/ABI-compatible with libjpeg v8. See [README.md](README.md) for more
information about libjpeg v7 and v8 emulation.
### In-Memory Source/Destination Managers
When using libjpeg v6b or v7 API/ABI emulation, add `-DWITH_MEM_SRCDST=0` to
the CMake command line to build a version of libjpeg-turbo that lacks the
`jpeg_mem_src()` and `jpeg_mem_dest()` functions. These functions were not
part of the original libjpeg v6b and v7 APIs, so removing them ensures strict
conformance with those APIs. See [README.md](README.md) for more information.
### Arithmetic Coding Support
Since the patent on arithmetic coding has expired, this functionality has been
@@ -345,7 +345,7 @@ Build Recipes
-------------
### 32-bit Build on 64-bit Linux/Unix/Mac
### 32-bit Build on 64-bit Linux/Unix
Use export/setenv to set the following environment variables before running
CMake:
@@ -384,9 +384,13 @@ located (usually **/usr/bin**.) Next, execute the following commands:
cd {build_directory}
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
-DCMAKE_INSTALL_PREFIX={install_path} \
[additional CMake flags] {source_directory}
make
*{install\_path}* is the path under which the libjpeg-turbo binaries should be
installed.
### 64-bit MinGW Build on Un*x (including Mac and Cygwin)
@@ -403,150 +407,59 @@ located (usually **/usr/bin**.) Next, execute the following commands:
cd {build_directory}
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
-DCMAKE_INSTALL_PREFIX={install_path} \
[additional CMake flags] {source_directory}
make
*{install\_path}* is the path under which the libjpeg-turbo binaries should be
installed.
Building libjpeg-turbo for iOS
------------------------------
iOS platforms, such as the iPhone and iPad, use ARM processors, and all
currently supported models include NEON instructions. Thus, they can take
iOS platforms, such as the iPhone and iPad, use Arm processors, and all
currently supported models include Neon instructions. Thus, they can take
advantage of libjpeg-turbo's SIMD extensions to significantly accelerate JPEG
compression/decompression. This section describes how to build libjpeg-turbo
for these platforms.
### Additional build requirements
### Armv8 (64-bit)
- For configurations that require [gas-preprocessor.pl]
(https://raw.githubusercontent.com/libjpeg-turbo/gas-preprocessor/master/gas-preprocessor.pl),
it should be installed in your `PATH`.
### ARMv7 (32-bit)
**gas-preprocessor.pl required**
The following scripts demonstrate how to build libjpeg-turbo to run on the
iPhone 3GS-4S/iPad 1st-3rd Generation and newer:
#### Xcode 4.2 and earlier (LLVM-GCC)
IOS_PLATFORMDIR=/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=($IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk)
export CFLAGS="-mfloat-abi=softfp -march=armv7 -mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon -miphoneos-version-min=3.0"
cd {build_directory}
cat <<EOF >toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER ${IOS_PLATFORMDIR}/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2)
EOF
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
-DCMAKE_OSX_SYSROOT=${IOS_SYSROOT[0]} \
[additional CMake flags] {source_directory}
make
#### Xcode 4.3-4.6 (LLVM-GCC)
Same as above, but replace the first line with:
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
#### Xcode 5 and later (Clang)
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=($IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk)
export CFLAGS="-mfloat-abi=softfp -arch armv7 -miphoneos-version-min=3.0"
export ASMFLAGS="-no-integrated-as"
cd {build_directory}
cat <<EOF >toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang)
EOF
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
-DCMAKE_OSX_SYSROOT=${IOS_SYSROOT[0]} \
[additional CMake flags] {source_directory}
make
### ARMv7s (32-bit)
**gas-preprocessor.pl required**
The following scripts demonstrate how to build libjpeg-turbo to run on the
iPhone 5/iPad 4th Generation and newer:
#### Xcode 4.5-4.6 (LLVM-GCC)
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=($IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk)
export CFLAGS="-Wall -mfloat-abi=softfp -march=armv7s -mcpu=swift -mtune=swift -mfpu=neon -miphoneos-version-min=6.0"
cd {build_directory}
cat <<EOF >toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER ${IOS_PLATFORMDIR}/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2)
EOF
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
-DCMAKE_OSX_SYSROOT=${IOS_SYSROOT[0]} \
[additional CMake flags] {source_directory}
make
#### Xcode 5 and later (Clang)
Same as the ARMv7 build procedure for Xcode 5 and later, except replace the
compiler flags as follows:
export CFLAGS="-Wall -mfloat-abi=softfp -arch armv7s -miphoneos-version-min=6.0"
### ARMv8 (64-bit)
**gas-preprocessor.pl required if using Xcode < 6**
**Xcode 5 or later required, Xcode 6.3.x or later recommended**
The following script demonstrates how to build libjpeg-turbo to run on the
iPhone 5S/iPad Mini 2/iPad Air and newer.
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=($IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk)
export CFLAGS="-Wall -arch arm64 -miphoneos-version-min=7.0 -funwind-tables"
export CFLAGS="-Wall -miphoneos-version-min=8.0 -funwind-tables"
cd {build_directory}
cat <<EOF >toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_C_COMPILER /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang)
EOF
cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
cmake -G"Unix Makefiles" \
-DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
-DCMAKE_OSX_ARCHITECTURES=arm64 \
-DCMAKE_OSX_SYSROOT=${IOS_SYSROOT[0]} \
[additional CMake flags] {source_directory}
make
Once built, lipo can be used to combine the ARMv7, v7s, and/or v8 variants into
a universal library.
Replace `iPhoneOS` with `iPhoneSimulator` and `-miphoneos-version-min` with
`-miphonesimulator-version-min` to build libjpeg-turbo for the iOS simulator on
Macs with Apple silicon CPUs.
Building libjpeg-turbo for Android
----------------------------------
Building libjpeg-turbo for Android platforms requires v13b or later of the
[Android NDK](https://developer.android.com/tools/sdk/ndk).
[Android NDK](https://developer.android.com/ndk).
### ARMv7 (32-bit)
### Armv7 (32-bit)
**NDK r19 or later with Clang recommended**
The following is a general recipe script that can be modified for your specific
needs.
@@ -571,7 +484,9 @@ needs.
make
### ARMv8 (64-bit)
### Armv8 (64-bit)
**Clang recommended**
The following is a general recipe script that can be modified for your specific
needs.
@@ -707,15 +622,6 @@ brackets, then its final value will depend on the final value of that other
variable. For instance, the default value of `CMAKE_INSTALL_MANDIR` is
**\<CMAKE\_INSTALL\_DATAROOTDIR\>/man**.
NOTE: If setting one of these directory variables to a relative path using the
CMake command line, you must specify that the variable is of type `PATH`.
For example:
cmake -G"{generator type}" -DCMAKE_INSTALL_LIBDIR:PATH=lib {source_directory}
Otherwise, CMake will assume that the path is relative to the build directory
rather than the install directory.
Creating Distribution Packages
==============================
@@ -747,44 +653,24 @@ Mac
make dmg
Create Mac package/disk image. This requires pkgbuild and productbuild, which
are installed by default on OS X 10.7 and later and which can be obtained by
installing Xcode 3.2.6 (with the "Unix Development" option) on OS X 10.6.
Packages built in this manner can be installed on OS X 10.5 and later, but they
must be built on OS X 10.6 or later.
are installed by default on OS X/macOS 10.7 and later.
make udmg
In order to create a Mac package/disk image that contains universal
x86-64/Arm binaries, set the following CMake variable:
This creates a Mac package/disk image that contains universal x86-64/i386/ARM
binaries. The following CMake variables control which architectures are
included in the universal binaries. Setting any of these variables to an empty
string excludes that architecture from the package.
* `SECONDARY_BUILD`: Directory containing a cross-compiled x86-64 or Armv8
(64-bit) iOS or macOS build of libjpeg-turbo to include in the universal
binaries
* `OSX_32BIT_BUILD`: Directory containing an i386 (32-bit) Mac build of
libjpeg-turbo (default: *{source_directory}*/osxx86)
* `IOS_ARMV7_BUILD`: Directory containing an ARMv7 (32-bit) iOS build of
libjpeg-turbo (default: *{source_directory}*/iosarmv7)
* `IOS_ARMV7S_BUILD`: Directory containing an ARMv7s (32-bit) iOS build of
libjpeg-turbo (default: *{source_directory}*/iosarmv7s)
* `IOS_ARMV8_BUILD`: Directory containing an ARMv8 (64-bit) iOS build of
libjpeg-turbo (default: *{source_directory}*/iosarmv8)
You should first use CMake to configure i386, ARMv7, ARMv7s, and/or ARMv8
sub-builds of libjpeg-turbo (see "Build Recipes" and "Building libjpeg-turbo
for iOS" above) in build directories that match those specified in the
aforementioned CMake variables. Next, configure the primary build of
libjpeg-turbo as an out-of-tree build, and build it. Once the primary build
has been built, run `make udmg` from the build directory. The packaging system
will build the sub-builds, use lipo to combine them into a single set of
universal binaries, then package the universal binaries in the same manner as
`make dmg`.
Cygwin
------
make cygwinpkg
Build a Cygwin binary package.
You should first use CMake to configure the cross-compiled x86-64 or Armv8
secondary build of libjpeg-turbo (see "Building libjpeg-turbo for iOS" above,
if applicable) in a build directory that matches the one specified in the
aforementioned CMake variable. Next, configure the primary (native) build of
libjpeg-turbo as an out-of-tree build, specifying the aforementioned CMake
variable, and build it. Once the primary build has been built, run `make dmg`
from the build directory. The packaging system will build the secondary build,
use lipo to combine it with the primary build into a single set of universal
binaries, then package the universal binaries.
Windows
@@ -809,7 +695,7 @@ as the configuration you built (such as *{build_directory}*\Debug\ or
*{build_directory}*\Release\).
Building a Windows installer requires the
[Nullsoft Install System](http://nsis.sourceforge.net/). makensis.exe should
[Nullsoft Install System](https://nsis.sourceforge.io). makensis.exe should
be in your `PATH`.

View File

@@ -1,902 +0,0 @@
*******************************************************************************
** Building on Un*x Platforms (including Cygwin and OS X)
*******************************************************************************
==================
Build Requirements
==================
-- pkg-config
-- autoconf 2.56 or later
-- automake 1.7 or later
-- libtool 1.4 or later
* If using Xcode 4.3 or later on OS X, autoconf and automake are no longer
provided. The easiest way to obtain them is from MacPorts
(http://www.macports.org/).
-- NASM or YASM (if building x86 or x86-64 SIMD extensions)
* NASM 0.98, or 2.01 or later is required for an x86 build (0.99 and 2.00 do
not work properly with libjpeg-turbo's x86 SIMD code.)
* NASM 2.00 or later is required for an x86-64 build.
* NASM 2.07, or 2.11.09 or later is required for an x86-64 Mac build
(2.11.08 does not work properly with libjpeg-turbo's x86-64 SIMD code when
building macho64 objects.) NASM or YASM can be obtained from MacPorts
(http://www.macports.org/).
The binary RPMs released by the NASM project do not work on older Linux
systems, such as Red Hat Enterprise Linux 4. On such systems, you can
easily build and install NASM from a source RPM by downloading one of the
SRPMs from
http://www.nasm.us/pub/nasm/releasebuilds
and executing the following as root:
ARCH=`uname -m`
rpmbuild --rebuild nasm-{version}.src.rpm
rpm -Uvh /usr/src/redhat/RPMS/$ARCH/nasm-{version}.$ARCH.rpm
NOTE: the NASM build will fail if texinfo is not installed.
-- GCC v4.1 or later recommended for best performance
* Beginning with Xcode 4, Apple stopped distributing GCC and switched to
the LLVM compiler. Xcode v4.0 through v4.6 provides a GCC front end
called LLVM-GCC. Unfortunately, as of this writing, neither LLVM-GCC nor
the LLVM (clang) compiler produces optimal performance with libjpeg-turbo.
Building mozjpeg with LLVM-GCC v4.2 results in a 10% performance
degradation when compressing using 64-bit code, relative to building
libjpeg-turbo with GCC v4.2. Building libjpeg-turbo with LLVM (clang)
results in a 20% performance degradation when compressing using 64-bit
code, relative to building libjpeg-turbo with GCC v4.2. If you are
running Snow Leopard or earlier, it is suggested that you continue to use
Xcode v3.2.6, which provides GCC v4.2. If you are using Lion or later, it
is suggested that you install Apple GCC v4.2 or GCC v5 through MacPorts.
-- If building the TurboJPEG Java wrapper, JDK or OpenJDK 1.5 or later is
required. Some systems, such as Solaris 10 and later and Red Hat Enterprise
Linux 5 and later, have this pre-installed. On OS X 10.5 and later, it will
be necessary to install the Java Developer Package, which can be downloaded
from http://developer.apple.com/downloads (Apple ID required.) For systems
that do not have a JDK installed, you can obtain the Oracle Java Development
Kit from http://www.java.com.
==================
Out-of-Tree Builds
==================
Binary objects, libraries, and executables are generated in the same directory
from which configure was executed (the "binary directory"), and this directory
need not necessarily be the same as the mozjpeg source directory. You
can create multiple independent binary directories, in which different versions
of mozjpeg can be built from the same source tree using different
compilers or settings. In the sections below, {build_directory} refers to the
binary directory, whereas {source_directory} refers to the mozjpeg source
directory. For in-tree builds, these directories are the same.
================
Building mozjpeg
================
The following procedure will build mozjpeg on Linux, FreeBSD, Cygwin, and
Solaris/x86 systems (on Solaris, this generates a 32-bit library. See below
for 64-bit build instructions.)
Simple Release tar.gz Source Build
----------------------------------
cd {source_directory}
./configure [additional configure flags]
make
Non-Release Source Build (e.g. GitHub clone)
--------------------------------------------
cd {source_directory}
autoreconf -fiv
cd {build_directory}
sh {source_directory}/configure [additional configure flags]
make
NOTE: Running autoreconf in the source directory is not necessary if building
mozjpeg from one of the official release tarballs.
This will generate the following files under .libs/
libjpeg.a
Static link library for the libjpeg API
libjpeg.so.{version} (Linux, Unix)
libjpeg.{version}.dylib (OS X)
cygjpeg-{version}.dll (Cygwin)
Shared library for the libjpeg API
By default, {version} is 62.2.0, 7.2.0, or 8.1.2, depending on whether
libjpeg v6b (default), v7, or v8 emulation is enabled. If using Cygwin,
{version} is 62, 7, or 8.
libjpeg.so (Linux, Unix)
libjpeg.dylib (OS X)
Development symlink for the libjpeg API
libjpeg.dll.a (Cygwin)
Import library for the libjpeg API
libturbojpeg.a
Static link library for the TurboJPEG API
libturbojpeg.so.0.1.0 (Linux, Unix)
libturbojpeg.0.1.0.dylib (OS X)
cygturbojpeg-0.dll (Cygwin)
Shared library for the TurboJPEG API
libturbojpeg.so (Linux, Unix)
libturbojpeg.dylib (OS X)
Development symlink for the TurboJPEG API
libturbojpeg.dll.a (Cygwin)
Import library for the TurboJPEG API
libjpeg v7 or v8 API/ABI Emulation
----------------------------------
Add --with-jpeg7 to the configure command line to build a version of
mozjpeg that is API/ABI-compatible with libjpeg v7. Add --with-jpeg8 to
the configure command to build a version of mozjpeg that is
API/ABI-compatible with libjpeg v8. See README-turbo.txt for more information
on libjpeg v7 and v8 emulation.
In-Memory Source/Destination Managers
-------------------------------------
When using libjpeg v6b or v7 API/ABI emulation, add --without-mem-srcdst to the
configure command line to build a version of mozjpeg that lacks the
jpeg_mem_src() and jpeg_mem_dest() functions. These functions were not part of
the original libjpeg v6b and v7 APIs, so removing them ensures strict
conformance with those APIs. See README-turbo.txt for more information.
Arithmetic Coding Support
-------------------------
Since the patent on arithmetic coding has expired, this functionality has been
included in this release of mozjpeg. mozjpeg's implementation is
based on the implementation in libjpeg v8, but it works when emulating libjpeg
v7 or v6b as well. The default is to enable both arithmetic encoding and
decoding, but those who have philosophical objections to arithmetic coding can
add --without-arith-enc or --without-arith-dec to the configure command line to
disable encoding or decoding (respectively.)
TurboJPEG Java Wrapper
----------------------
Add --with-java to the configure command line to incorporate an optional Java
Native Interface wrapper into the TurboJPEG shared library and build the Java
front-end classes to support it. This allows the TurboJPEG shared library to
be used directly from Java applications. See java/README for more details.
You can set the JAVAC, JAR, and JAVA configure variables to specify
alternate commands for javac, jar, and java (respectively.) You can also
set the JAVACFLAGS configure variable to specify arguments that should be
passed to the Java compiler when building the front-end classes, and JNI_CFLAGS
to specify arguments that should be passed to the C compiler when building the
JNI wrapper. Run 'configure --help' for more details.
==================
Installing mozjpeg
==================
If you intend to install these libraries and the associated header files, then
replace 'make' in the instructions above with
make install prefix={base dir} libdir={library directory}
For example,
make install prefix=/usr/local libdir=/usr/local/lib64
will install the header files in /usr/local/include and the library files in
/usr/local/lib64. If 'prefix' and 'libdir' are not specified, then the default
is to install the header files in /opt/mozjpeg/include and the library
files in /opt/mozjpeg/lib32 (32-bit) or /opt/mozjpeg/lib64
(64-bit.)
NOTE: You can specify a prefix of /usr and a libdir of, for instance,
/usr/lib64 to overwrite the system's version of libjpeg. If you do this,
however, then be sure to BACK UP YOUR SYSTEM'S INSTALLATION OF LIBJPEG before
overwriting it. It is recommended that you instead install mozjpeg into
a non-system directory and manipulate the LD_LIBRARY_PATH or create symlinks
to force applications to use mozjpeg instead of libjpeg. See
README-turbo.txt for more information.
=============
Build Recipes
=============
32-bit Build on 64-bit Linux
----------------------------
Add
--host i686-pc-linux-gnu CFLAGS='-O3 -m32' LDFLAGS=-m32
to the configure command line.
64-bit Build on 64-bit OS X
---------------------------
Add
--host x86_64-apple-darwin NASM=/opt/local/bin/nasm
to the configure command line. NASM 2.07 or later from MacPorts must be
installed.
32-bit Build on 64-bit OS X
---------------------------
Add
--host i686-apple-darwin CFLAGS='-O3 -m32' LDFLAGS=-m32
to the configure command line.
64-bit Backward-Compatible Build on 64-bit OS X
-----------------------------------------------
Add
--host x86_64-apple-darwin NASM=/opt/local/bin/nasm \
CFLAGS='-isysroot /Developer/SDKs/MacOSX10.5.sdk \
-mmacosx-version-min=10.5 -O3' \
LDFLAGS='-isysroot /Developer/SDKs/MacOSX10.5.sdk \
-mmacosx-version-min=10.5'
to the configure command line. The OS X 10.5 SDK, and NASM 2.07 or later from
MacPorts, must be installed.
32-bit Backward-Compatible Build on OS X
----------------------------------------
Add
--host i686-apple-darwin \
CFLAGS='-isysroot /Developer/SDKs/MacOSX10.5.sdk \
-mmacosx-version-min=10.5 -O3 -m32' \
LDFLAGS='-isysroot /Developer/SDKs/MacOSX10.5.sdk \
-mmacosx-version-min=10.5 -m32'
to the configure command line. The OS X 10.5 SDK must be installed.
64-bit Library Build on 64-bit Solaris
--------------------------------------
Add
--host x86_64-pc-solaris CFLAGS='-O3 -m64' LDFLAGS=-m64
to the configure command line.
32-bit Build on 64-bit FreeBSD
------------------------------
Add
--host i386-unknown-freebsd CC='gcc -B /usr/lib32' CFLAGS='-O3 -m32' \
LDFLAGS='-B/usr/lib32'
to the configure command line. NASM 2.07 or later from FreeBSD ports must be
installed.
Oracle Solaris Studio
---------------------
Add
CC=cc
to the configure command line. mozjpeg will automatically be built with
the maximum optimization level (-xO5) unless you override CFLAGS.
To build a 64-bit version of mozjpeg using Oracle Solaris Studio, add
--host x86_64-pc-solaris CC=cc CFLAGS='-xO5 -m64' LDFLAGS=-m64
to the configure command line.
MinGW Build on Cygwin
---------------------
Use CMake (see recipes below)
===========
ARM Support
===========
This release of mozjpeg can use ARM NEON SIMD instructions to accelerate
JPEG compression/decompression by approximately 2-4x on ARMv7 and later
platforms. If mozjpeg is configured on an ARM Linux platform, then the
build system will automatically include the NEON SIMD routines, if they are
supported. Build instructions for other ARM-based platforms follow.
Building mozjpeg for iOS
------------------------
iOS platforms, such as the iPhone and iPad, use ARM processors, some of which
support NEON instructions. Additional steps are required in order to build
mozjpeg for these platforms.
Additional build requirements:
gas-preprocessor.pl
(https://raw.githubusercontent.com/libjpeg-turbo/gas-preprocessor/master/gas-preprocessor.pl)
should be installed in your PATH.
ARM 32-bit Build (Xcode 4.6.x and earlier, LLVM-GCC):
Set the following shell variables for simplicity:
Xcode 4.2 and earlier:
IOS_PLATFORMDIR=/Developer/Platforms/iPhoneOS.platform
Xcode 4.3 and later:
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=$IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk
IOS_GCC=$IOS_PLATFORMDIR/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2
ARMv6 (code will run on all iOS devices, not SIMD-accelerated):
[NOTE: Requires Xcode 4.4.x or earlier]
IOS_CFLAGS="-march=armv6 -mcpu=arm1176jzf-s -mfpu=vfp"
ARMv7 (code will run on iPhone 3GS-4S/iPad 1st-3rd Generation and newer):
IOS_CFLAGS="-march=armv7 -mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon"
ARMv7s (code will run on iPhone 5/iPad 4th Generation and newer):
[NOTE: Requires Xcode 4.5 or later]
IOS_CFLAGS="-march=armv7s -mcpu=swift -mtune=swift -mfpu=neon"
Follow the procedure under "Building mozjpeg" above, adding
--host arm-apple-darwin10 \
CC="$IOS_GCC" LD="$IOS_GCC" \
CFLAGS="-mfloat-abi=softfp -isysroot $IOS_SYSROOT -O3 $IOS_CFLAGS" \
LDFLAGS="-mfloat-abi=softfp -isysroot $IOS_SYSROOT $IOS_CFLAGS"
to the configure command line.
ARM 32-bit Build (Xcode 5.0.x and later, Clang):
Set the following shell variables for simplicity:
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=$IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk
IOS_GCC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
ARMv7 (code will run on iPhone 3GS-4S/iPad 1st-3rd Generation and newer):
IOS_CFLAGS="-arch armv7"
ARMv7s (code will run on iPhone 5/iPad 4th Generation and newer):
IOS_CFLAGS="-arch armv7s"
Follow the procedure under "Building libjpeg-turbo" above, adding
--host arm-apple-darwin10 \
CC="$IOS_GCC" LD="$IOS_GCC" \
CFLAGS="-mfloat-abi=softfp -isysroot $IOS_SYSROOT -O3 $IOS_CFLAGS" \
LDFLAGS="-mfloat-abi=softfp -isysroot $IOS_SYSROOT $IOS_CFLAGS" \
CCASFLAGS="-no-integrated-as $IOS_CFLAGS"
to the configure command line.
ARMv8 64-bit Build (Xcode 5.0.x and later, Clang):
Code will run on iPhone 5S/iPad Mini 2/iPad Air and newer.
Set the following shell variables for simplicity:
IOS_PLATFORMDIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
IOS_SYSROOT=$IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS*.sdk
IOS_GCC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
IOS_CFLAGS="-arch arm64"
Follow the procedure under "Building libjpeg-turbo" above, adding
--host aarch64-apple-darwin \
CC="$IOS_GCC" LD="$IOS_GCC" \
CFLAGS="-isysroot $IOS_SYSROOT -O3 $IOS_CFLAGS" \
LDFLAGS="-isysroot $IOS_SYSROOT $IOS_CFLAGS"
to the configure command line.
NOTE: You can also add -miphoneos-version-min={version} to $IOS_CFLAGS above
in order to support older versions of iOS than the default version supported by
the SDK.
Once built, lipo can be used to combine the ARMv6, v7, v7s, and/or v8 variants
into a universal library.
Building libjpeg-turbo for Android
----------------------------------
Building libjpeg-turbo for Android platforms requires the Android NDK
(https://developer.android.com/tools/sdk/ndk) and autotools. The following is
a general recipe script that can be modified for your specific needs.
# Set these variables to suit your needs
NDK_PATH={full path to the "ndk" directory-- for example, /opt/android/ndk}
BUILD_PLATFORM={the platform name for the NDK package you installed--
for example, "windows-x86" or "linux-x86_64" or "darwin-x86_64"}
TOOLCHAIN_VERSION={"4.8", "4.9", "clang3.5", etc. This corresponds to a
toolchain directory under ${NDK_PATH}/toolchains/.}
ANDROID_VERSION={The minimum version of Android to support-- for example,
"16", "19", etc. "21" or later is required for a 64-bit build.}
# 32-bit ARMv7 build
HOST=arm-linux-androideabi
SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-arm
ANDROID_CFLAGS="-march=armv7-a -mfloat-abi=softfp -fprefetch-loop-arrays \
--sysroot=${SYSROOT}"
# 64-bit ARMv8 build
HOST=aarch64-linux-android
SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-arm64
ANDROID_CFLAGS="--sysroot=${SYSROOT}"
TOOLCHAIN=${NDK_PATH}/toolchains/${HOST}-${TOOLCHAIN_VERSION}/prebuilt/${BUILD_PLATFORM}
ANDROID_INCLUDES="-I${SYSROOT}/usr/include -I${TOOLCHAIN}/include"
export CPP=${TOOLCHAIN}/bin/${HOST}-cpp
export AR=${TOOLCHAIN}/bin/${HOST}-ar
export AS=${TOOLCHAIN}/bin/${HOST}-as
export NM=${TOOLCHAIN}/bin/${HOST}-nm
export CC=${TOOLCHAIN}/bin/${HOST}-gcc
export LD=${TOOLCHAIN}/bin/${HOST}-ld
export RANLIB=${TOOLCHAIN}/bin/${HOST}-ranlib
export OBJDUMP=${TOOLCHAIN}/bin/${HOST}-objdump
export STRIP=${TOOLCHAIN}/bin/${HOST}-strip
cd {build_directory}
sh {source_directory}/configure --host=${HOST} \
CFLAGS="${ANDROID_INCLUDES} ${ANDROID_CFLAGS} -O3 -fPIE" \
CPPFLAGS="${ANDROID_INCLUDES} ${ANDROID_CFLAGS}" \
LDFLAGS="${ANDROID_CFLAGS} -pie" --with-simd ${1+"$@"}
make
If building for Android 4.0.x (API level < 16) or earlier, remove -fPIE from
CFLAGS and -pie from LDFLAGS.
*******************************************************************************
** Building on Windows (Visual C++ or MinGW)
*******************************************************************************
==================
Build Requirements
==================
-- CMake (http://www.cmake.org) v2.8.8 or later
-- Microsoft Visual C++ 2005 or later
If you don't already have Visual C++, then the easiest way to get it is by
installing the Windows SDK:
http://msdn.microsoft.com/en-us/windows/bb980924.aspx
The Windows SDK includes both 32-bit and 64-bit Visual C++ compilers and
everything necessary to build mozjpeg.
* You can also use Microsoft Visual Studio Express Edition, which is a free
download. (NOTE: versions prior to 2012 can only be used to build 32-bit
code.)
* If you intend to build mozjpeg from the command line, then add the
appropriate compiler and SDK directories to the INCLUDE, LIB, and PATH
environment variables. This is generally accomplished by executing
vcvars32.bat or vcvars64.bat and SetEnv.cmd. vcvars32.bat and
vcvars64.bat are part of Visual C++ and are located in the same directory
as the compiler. SetEnv.cmd is part of the Windows SDK. You can pass
optional arguments to SetEnv.cmd to specify a 32-bit or 64-bit build
environment.
... OR ...
-- MinGW
MinGW-builds (http://sourceforge.net/projects/mingwbuilds/) or
tdm-gcc (http://tdm-gcc.tdragon.net/) recommended if building on a Windows
machine. Both distributions install a Start Menu link that can be used to
launch a command prompt with the appropriate compiler paths automatically
set.
-- NASM (http://www.nasm.us/) 0.98 or later (NASM 2.05 or later is required for
a 64-bit build)
-- If building the TurboJPEG Java wrapper, JDK 1.5 or later is required. This
can be downloaded from http://www.java.com.
==================
Out-of-Tree Builds
==================
Binary objects, libraries, and executables are generated in the same directory
from which cmake was executed (the "binary directory"), and this directory need
not necessarily be the same as the mozjpeg source directory. You can
create multiple independent binary directories, in which different versions of
mozjpeg can be built from the same source tree using different compilers
or settings. In the sections below, {build_directory} refers to the binary
directory, whereas {source_directory} refers to the mozjpeg source
directory. For in-tree builds, these directories are the same.
================
Building mozjpeg
================
Visual C++ (Command Line)
-------------------------
cd {build_directory}
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release {source_directory}
nmake
This will build either a 32-bit or a 64-bit version of mozjpeg, depending
on which version of cl.exe is in the PATH.
The following files will be generated under {build_directory}:
jpeg-static.lib
Static link library for the libjpeg API
sharedlib/jpeg{version}.dll
DLL for the libjpeg API
sharedlib/jpeg.lib
Import library for the libjpeg API
turbojpeg-static.lib
Static link library for the TurboJPEG API
turbojpeg.dll
DLL for the TurboJPEG API
turbojpeg.lib
Import library for the TurboJPEG API
{version} is 62, 7, or 8, depending on whether libjpeg v6b (default), v7, or
v8 emulation is enabled.
Visual C++ (IDE)
----------------
Choose the appropriate CMake generator option for your version of Visual Studio
(run "cmake" with no arguments for a list of available generators.) For
instance:
cd {build_directory}
cmake -G "Visual Studio 10" {source_directory}
NOTE: Add "Win64" to the generator name (for example, "Visual Studio 10
Win64") to build a 64-bit version of libjpeg-turbo. Recent versions of CMake
no longer document that. A separate build directory must be used for 32-bit
and 64-bit builds.
You can then open ALL_BUILD.vcproj in Visual Studio and build one of the
configurations in that project ("Debug", "Release", etc.) to generate a full
build of mozjpeg.
This will generate the following files under {build_directory}:
{configuration}/jpeg-static.lib
Static link library for the libjpeg API
sharedlib/{configuration}/jpeg{version}.dll
DLL for the libjpeg API
sharedlib/{configuration}/jpeg.lib
Import library for the libjpeg API
{configuration}/turbojpeg-static.lib
Static link library for the TurboJPEG API
{configuration}/turbojpeg.dll
DLL for the TurboJPEG API
{configuration}/turbojpeg.lib
Import library for the TurboJPEG API
{configuration} is Debug, Release, RelWithDebInfo, or MinSizeRel, depending on
the configuration you built in the IDE, and {version} is 62, 7, or 8,
depending on whether libjpeg v6b (default), v7, or v8 emulation is enabled.
MinGW
-----
NOTE: This assumes that you are building on a Windows machine. If you are
cross-compiling on a Linux/Unix machine, then see "Build Recipes" below.
cd {build_directory}
cmake -G "MinGW Makefiles" {source_directory}
mingw32-make
This will generate the following files under {build_directory}
libjpeg.a
Static link library for the libjpeg API
sharedlib/libjpeg-{version}.dll
DLL for the libjpeg API
sharedlib/libjpeg.dll.a
Import library for the libjpeg API
libturbojpeg.a
Static link library for the TurboJPEG API
libturbojpeg.dll
DLL for the TurboJPEG API
libturbojpeg.dll.a
Import library for the TurboJPEG API
{version} is 62, 7, or 8, depending on whether libjpeg v6b (default), v7, or
v8 emulation is enabled.
Debug Build
-----------
Add "-DCMAKE_BUILD_TYPE=Debug" to the cmake command line. Or, if building with
NMake, remove "-DCMAKE_BUILD_TYPE=Release" (Debug builds are the default with
NMake.)
libjpeg v7 or v8 API/ABI Emulation
-----------------------------------
Add "-DWITH_JPEG7=1" to the cmake command line to build a version of
mozjpeg that is API/ABI-compatible with libjpeg v7. Add "-DWITH_JPEG8=1"
to the cmake command to build a version of mozjpeg that is
API/ABI-compatible with libjpeg v8. See README-turbo.txt for more information
on libjpeg v7 and v8 emulation.
In-Memory Source/Destination Managers
-------------------------------------
When using libjpeg v6b or v7 API/ABI emulation, add -DWITH_MEM_SRCDST=0 to the
CMake command line to build a version of mozjpeg that lacks the
jpeg_mem_src() and jpeg_mem_dest() functions. These functions were not part of
the original libjpeg v6b and v7 APIs, so removing them ensures strict
conformance with those APIs. See README-turbo.txt for more information.
Arithmetic Coding Support
-------------------------
Since the patent on arithmetic coding has expired, this functionality has been
included in this release of mozjpeg. mozjpeg's implementation is
based on the implementation in libjpeg v8, but it works when emulating libjpeg
v7 or v6b as well. The default is to enable both arithmetic encoding and
decoding, but those who have philosophical objections to arithmetic coding can
add "-DWITH_ARITH_ENC=0" or "-DWITH_ARITH_DEC=0" to the cmake command line to
disable encoding or decoding (respectively.)
TurboJPEG Java Wrapper
----------------------
Add "-DWITH_JAVA=1" to the cmake command line to incorporate an optional Java
Native Interface wrapper into the TurboJPEG shared library and build the Java
front-end classes to support it. This allows the TurboJPEG shared library to
be used directly from Java applications. See java/README for more details.
If you are using CMake 2.8, you can set the Java_JAVAC_EXECUTABLE,
Java_JAVA_EXECUTABLE, and Java_JAR_EXECUTABLE CMake variables to specify
alternate commands or locations for javac, jar, and java (respectively.) If
you are using CMake 2.6, set JAVA_COMPILE, JAVA_RUNTIME, and JAVA_ARCHIVE
instead. You can also set the JAVACFLAGS CMake variable to specify arguments
that should be passed to the Java compiler when building the front-end classes.
==================
Installing mozjpeg
==================
You can use the build system to install mozjpeg into a directory of your
choosing (as opposed to creating an installer.) To do this, add:
-DCMAKE_INSTALL_PREFIX={install_directory}
to the cmake command line.
For example,
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=c:\mozjpeg {source_directory}
nmake install
will install the header files in c:\mozjpeg\include, the library files
in c:\mozjpeg\lib, the DLL's in c:\mozjpeg\bin, and the
documentation in c:\mozjpeg\doc.
=============
Build Recipes
=============
64-bit MinGW Build on Cygwin
----------------------------
cd {build_directory}
CC=/usr/bin/x86_64-w64-mingw32-gcc \
cmake -G "Unix Makefiles" -DCMAKE_SYSTEM_NAME=Windows \
-DCMAKE_RC_COMPILER=/usr/bin/x86_64-w64-mingw32-windres.exe \
{source_directory}
make
This produces a 64-bit build of mozjpeg that does not depend on
cygwin1.dll or other Cygwin DLL's. The mingw64-x86_64-gcc-core and
mingw64-x86_64-gcc-g++ packages (and their dependencies) must be installed.
32-bit MinGW Build on Cygwin
----------------------------
cd {build_directory}
CC=/usr/bin/i686-w64-mingw32-gcc \
cmake -G "Unix Makefiles" -DCMAKE_SYSTEM_NAME=Windows \
-DCMAKE_RC_COMPILER=/usr/bin/i686-w64-mingw32-windres.exe \
{source_directory}
make
This produces a 32-bit build of mozjpeg that does not depend on
cygwin1.dll or other Cygwin DLL's. The mingw64-i686-gcc-core and
mingw64-i686-gcc-g++ packages (and their dependencies) must be installed.
MinGW Build on Linux
--------------------
cd {build_directory}
CC={mingw_binary_path}/i386-mingw32-gcc \
cmake -G "Unix Makefiles" -DCMAKE_SYSTEM_NAME=Windows \
-DCMAKE_AR={mingw_binary_path}/i386-mingw32-ar \
-DCMAKE_RANLIB={mingw_binary_path}/i386-mingw32-ranlib \
{source_directory}
make
*******************************************************************************
** Creating Release Packages
*******************************************************************************
The following commands can be used to create various types of release packages:
Unix/Linux
----------
make rpm
Create Red Hat-style binary RPM package. Requires RPM v4 or later.
make srpm
This runs 'make dist' to create a pristine source tarball, then creates a
Red Hat-style source RPM package from the tarball. Requires RPM v4 or later.
make deb
Create Debian-style binary package. Requires dpkg.
make dmg
Create Macintosh package/disk image. This requires pkgbuild and
productbuild, which are installed by default on OS X 10.7 and later and which
can be obtained by installing Xcode 3.2.6 (with the "Unix Development"
option) on OS X 10.6. Packages built in this manner can be installed on OS X
10.5 and later, but they must be built on OS X 10.6 or later.
make udmg [BUILDDIR32={32-bit build directory}]
On 64-bit OS X systems, this creates a Macintosh package and disk image that
contains universal i386/x86-64 binaries. You should first configure a 32-bit
out-of-tree build of mozjpeg, then configure a 64-bit out-of-tree
build, then run 'make udmg' from the 64-bit build directory. The build
system will look for the 32-bit build under {source_directory}/osxx86 by
default, but you can override this by setting the BUILDDIR32 variable on the
make command line as shown above.
make iosdmg [BUILDDIR32={32-bit build directory}] \
[BUILDDIRARMV6={ARMv6 build directory}] \
[BUILDDIRARMV7={ARMv7 build directory}] \
[BUILDDIRARMV7S={ARMv7s build directory}] \
[BUILDDIRARMV8={ARMv8 build directory}]
On OS X systems, this creates a Macintosh package and disk image in which the
mozjpeg static libraries contain ARM architectures necessary to build
iOS applications. If building on an x86-64 system, the binaries will also
contain the i386 architecture, as with 'make udmg' above. You should first
configure ARMv6, ARMv7, ARMv7s, and/or ARMv8 out-of-tree builds of
mozjpeg (see "Building mozjpeg for iOS" above.) If you are
building an x86-64 version of mozjpeg, you should configure a 32-bit
out-of-tree build as well. Next, build mozjpeg as you would normally,
using an out-of-tree build. When it is built, run 'make iosdmg' from the
build directory. The build system will look for the ARMv6 build under
{source_directory}/iosarmv6 by default, the ARMv7 build under
{source_directory}/iosarmv7 by default, the ARMv7s build under
{source_directory}/iosarmv7s by default, the ARMv8 build under
{source_directory}/iosarmv8 by default, and (if applicable) the 32-bit build
under {source_directory}/osxx86 by default, but you can override this by
setting the BUILDDIR32, BUILDDIRARMV6, BUILDDIRARMV7, BUILDDIRARMV7S, and/or
BUILDDIRARMV8 variables on the make command line as shown above.
NOTE: If including an ARMv8 build in the package, then you may need to use
Xcode's version of lipo instead of the operating system's. To do this, pass
an argument of LIPO="xcrun lipo" on the make command line.
make cygwinpkg
Build a Cygwin binary package.
Windows
-------
If using NMake:
cd {build_directory}
nmake installer
If using MinGW:
cd {build_directory}
make installer
If using the Visual Studio IDE, build the "installer" project.
The installer package (mozjpeg[-gcc][64].exe) will be located under
{build_directory}. If building using the Visual Studio IDE, then the installer
package will be located in a subdirectory with the same name as the
configuration you built (such as {build_directory}\Debug\ or
{build_directory}\Release\).
Building a Windows installer requires the Nullsoft Install System
(http://nsis.sourceforge.net/.) makensis.exe should be in your PATH.
*******************************************************************************
** Regression testing
*******************************************************************************
The most common way to test mozjpeg is by invoking 'make test' on
Unix/Linux platforms or 'ctest' on Windows platforms, once the build has
completed. This runs a series of tests to ensure that mathematical
compatibility has been maintained. This also invokes the TurboJPEG unit tests,
which ensure that the colorspace extensions, YUV encoding, decompression
scaling, and other features of the TurboJPEG C and Java APIs are working
properly (and, by extension, that the equivalent features of the underlying
libjpeg API are also working.)
Invoking 'make testclean' or 'nmake testclean' (if using NMake) or building
the 'testclean' target (if using the Visual Studio IDE) will clean up the
output images generated by 'make test'.
On Unix/Linux platforms, more extensive tests of the TurboJPEG C and Java
wrappers can be run by invoking 'make tjtest'. These extended TurboJPEG tests
essentially iterate through all of the available features of the TurboJPEG APIs
that are not covered by the TurboJPEG unit tests (this includes the lossless
transform options) and compare the images generated by each feature to images
generated using the equivalent feature in the libjpeg API. The extended
TurboJPEG tests are meant to test for regressions in the TurboJPEG wrappers,
not in the underlying libjpeg API library.

File diff suppressed because it is too large Load Diff

View File

@@ -1,3 +1,796 @@
3.0.5
=====
### Significant changes relative to 3.0.4:
1. Fixed an issue in the TurboJPEG API whereby, when generating a
12-bit-per-sample or 16-bit-per-sample lossless JPEG image, specifying a point
transform value greater than 7 resulted in an error ("Parameter value out of
range".)
2. Fixed a regression introduced by 1.4 beta1[3] that prevented
`jpeg_set_defaults()` from resetting the Huffman tables to default (baseline)
values if Huffman table optimization or progressive mode was previously enabled
in the same libjpeg instance.
3. Fixed an issue whereby lossless JPEG compression could not be disabled if it
was previously enabled in a libjpeg or TurboJPEG instance.
`jpeg_set_defaults()` now disables lossless JPEG compression in a libjpeg
instance, and setting `TJPARAM_LOSSLESS`/`TJ.PARAM_LOSSLESS` to `0` now
disables lossless JPEG compression in a TurboJPEG instance.
4. Hardened the libjpeg API against hypothetical calling applications that may
erroneously change the value of the `data_precision` field in
`jpeg_compress_struct` or `jpeg_decompress_struct` after calling
`jpeg_start_compress()` or `jpeg_start_decompress()`.
3.0.4
=====
### Significant changes relative to 3.0.3:
1. Fixed an issue whereby the CPU usage of the default marker processor in the
decompressor grew exponentially with the number of markers. This caused an
unreasonable slow-down in `jpeg_read_header()` if an application called
`jpeg_save_markers()` to save markers of a particular type and then attempted
to decompress a JPEG image containing an excessive number of markers of that
type.
2. Hardened the default marker processor in the decompressor to guard against
an issue (exposed by 3.0 beta2[6]) whereby attempting to decompress a
specially-crafted malformed JPEG image (specifically an image with a complete
12-bit-per-sample Start Of Frame segment followed by an incomplete
8-bit-per-sample Start Of Frame segment) using buffered-image mode and input
prefetching caused a segfault if the `fill_input_buffer()` method in the
calling application's custom source manager incorrectly returned `FALSE` in
response to a prematurely-terminated JPEG data stream.
3. Fixed an issue in cjpeg whereby, when generating a 12-bit-per-sample or
16-bit-per-sample lossless JPEG image, specifying a point transform value
greater than 7 resulted in an error ("Invalid progressive/lossless parameters")
unless the `-precision` option was specified before the `-lossless` option.
4. Fixed a regression introduced by 3.0.3[3] that made it impossible for
calling applications to generate 12-bit-per-sample arithmetic-coded lossy JPEG
images using the TurboJPEG API.
5. Fixed an error ("Destination buffer is not large enough") that occurred when
attempting to generate a full-color lossless JPEG image using the TurboJPEG
Java API's `byte[] TJCompressor.compress()` method if the value of
`TJ.PARAM_SUBSAMP` was not `TJ.SAMP_444`.
6. Fixed a segfault in djpeg that occurred if a negative width was specified
with the `-crop` option. Since the cropping region width was read into an
unsigned 32-bit integer, a negative width was interpreted as a very large
value. With certain negative width and positive left boundary values, the
bounds checks in djpeg and `jpeg_crop_scanline()` overflowed and did not detect
the out-of-bounds width, which caused a buffer overrun in the upsampling or
color conversion routine. Both bounds checks now use 64-bit integers to guard
against overflow, and djpeg now checks for negative numbers when it parses the
crop specification from the command line.
7. Fixed an issue whereby the TurboJPEG lossless transformation function and
methods checked the specified cropping region against the source image
dimensions and level of chrominance subsampling rather than the destination
image dimensions and level of chrominance subsampling, which caused some
cropping regions to be unduly rejected when performing 90-degree rotation,
270-degree rotation, transposition, transverse transposition, or grayscale
conversion.
8. Fixed a regression, introduced by 3.0 beta2[4], that prevented the
`tjTransform()` backward compatibility function from copying extra markers from
the source image to the destination image.
9. Fixed an issue whereby the TurboJPEG lossless transformation function and
methods did not honor `TJXOPT_COPYNONE`/`TJTransform.OPT_COPYNONE` unless it
was specified for all lossless transforms.
3.0.3
=====
### Significant changes relative to 3.0.2:
1. Fixed an issue in the build system, introduced in 3.0.2, that caused all
libjpeg-turbo components to depend on the Visual C++ run-time DLL when built
with Visual C++ and CMake 3.15 or later, regardless of value of the
`WITH_CRT_DLL` CMake variable.
2. The x86-64 SIMD extensions now include support for Intel Control-flow
Enforcement Technology (CET), which is enabled automatically if CET is enabled
in the C compiler.
3. Fixed a regression introduced by 3.0 beta2[6] that made it impossible for
calling applications to supply custom Huffman tables when generating
12-bit-per-component lossy JPEG images using the libjpeg API.
4. Fixed a segfault that occurred when attempting to use the jpegtran `-drop`
option with a specially-crafted malformed input image or drop image
(specifically an image in which all of the scans contain fewer components than
the number of components specified in the Start Of Frame segment.)
3.0.2
=====
### Significant changes relative to 3.0.1:
1. Fixed a signed integer overflow in the `tj3CompressFromYUV8()`,
`tj3DecodeYUV8()`, `tj3DecompressToYUV8()`, and `tj3EncodeYUV8()` functions,
detected by the Clang and GCC undefined behavior sanitizers, that could be
triggered by setting the `align` parameter to an unreasonably large value.
This issue did not pose a security threat, but removing the warning made it
easier to detect actual security issues, should they arise in the future.
2. Introduced a new parameter (`TJPARAM_MAXMEMORY` in the TurboJPEG C API and
`TJ.PARAM_MAXMEMORY` in the TurboJPEG Java API) and a corresponding TJBench
option (`-maxmemory`) for specifying the maximum amount of memory (in
megabytes) that will be allocated for intermediate buffers, which are used with
progressive JPEG compression and decompression, Huffman table optimization,
lossless JPEG compression, and lossless transformation. The new parameter and
option serve the same purpose as the `max_memory_to_use` field in the
`jpeg_memory_mgr` struct in the libjpeg API, the `JPEGMEM` environment
variable, and the cjpeg/djpeg/jpegtran `-maxmemory` option.
3. Introduced a new parameter (`TJPARAM_MAXPIXELS` in the TurboJPEG C API and
`TJ.PARAM_MAXPIXELS` in the TurboJPEG Java API) and a corresponding TJBench
option (`-maxpixels`) for specifying the maximum number of pixels that the
decompression, lossless transformation, and packed-pixel image loading
functions/methods will process.
4. Fixed an error ("Unsupported color conversion request") that occurred when
attempting to decompress a 3-component lossless JPEG image without an Adobe
APP14 marker. The decompressor now assumes that a 3-component lossless JPEG
image without an Adobe APP14 marker uses the RGB colorspace if its component
IDs are 1, 2, and 3.
3.0.1
=====
### Significant changes relative to 3.0.0:
1. The x86-64 SIMD functions now use a standard stack frame, prologue, and
epilogue so that debuggers and profilers can reliably capture backtraces from
within the functions.
2. Fixed two minor issues in the interblock smoothing algorithm that caused
mathematical (but not necessarily perceptible) edge block errors when
decompressing progressive JPEG images exactly two DCT blocks in width or that
use vertical chrominance subsampling.
3. Fixed a regression introduced by 3.0 beta2[6] that, in rare cases, caused
the C Huffman encoder (which is not used by default on x86 and Arm CPUs) to
generate incorrect results if the Neon SIMD extensions were explicitly disabled
at build time (by setting the `WITH_SIMD` CMake variable to `0`) in an AArch64
build of libjpeg-turbo.
3.0.0
=====
### Significant changes relative to 3.0 beta2:
1. The TurboJPEG API now supports 4:4:1 (transposed 4:1:1) chrominance
subsampling, which allows losslessly transposed or rotated 4:1:1 JPEG images to
be losslessly cropped, partially decompressed, or decompressed to planar YUV
images.
2. Fixed various segfaults and buffer overruns (CVE-2023-2804) that occurred
when attempting to decompress various specially-crafted malformed
12-bit-per-component and 16-bit-per-component lossless JPEG images using color
quantization or merged chroma upsampling/color conversion. The underlying
cause of these issues was that the color quantization and merged chroma
upsampling/color conversion algorithms were not designed with lossless
decompression in mind. Since libjpeg-turbo explicitly does not support color
conversion when compressing or decompressing lossless JPEG images, merged
chroma upsampling/color conversion never should have been enabled for such
images. Color quantization is a legacy feature that serves little or no
purpose with lossless JPEG images, so it is also now disabled when
decompressing such images. (As a result, djpeg can no longer decompress a
lossless JPEG image into a GIF image.)
3. Fixed an oversight in 1.4 beta1[8] that caused various segfaults and buffer
overruns when attempting to decompress various specially-crafted malformed
12-bit-per-component JPEG images using djpeg with both color quantization and
RGB565 color conversion enabled.
4. Fixed an issue whereby `jpeg_crop_scanline()` sometimes miscalculated the
downsampled width for components with 4x2 or 2x4 subsampling factors if
decompression scaling was enabled. This caused the components to be upsampled
incompletely, which caused the color converter to read from uninitialized
memory. With 12-bit data precision, this caused a buffer overrun or underrun
and subsequent segfault if the sample value read from uninitialized memory was
outside of the valid sample range.
5. Fixed a long-standing issue whereby the `tj3Transform()` function, when used
with the `TJXOP_TRANSPOSE`, `TJXOP_TRANSVERSE`, `TJXOP_ROT90`, or
`TJXOP_ROT270` transform operation and without automatic JPEG destination
buffer (re)allocation or lossless cropping, computed the worst-case transformed
JPEG image size based on the source image dimensions rather than the
transformed image dimensions. If a calling program allocated the JPEG
destination buffer based on the transformed image dimensions, as the API
documentation instructs, and attempted to transform a specially-crafted 4:2:2,
4:4:0, 4:1:1, or 4:4:1 JPEG source image containing a large amount of metadata,
the issue caused `tj3Transform()` to overflow the JPEG destination buffer
rather than fail gracefully. The issue could be worked around by setting
`TJXOPT_COPYNONE`. Note that, irrespective of this issue, `tj3Transform()`
cannot reliably transform JPEG source images that contain a large amount of
metadata unless automatic JPEG destination buffer (re)allocation is used or
`TJXOPT_COPYNONE` is set.
6. Fixed a regression introduced by 3.0 beta2[6] that prevented the djpeg
`-map` option from working when decompressing 12-bit-per-component lossy JPEG
images.
7. Fixed an issue that caused the C Huffman encoder (which is not used by
default on x86 and Arm CPUs) to read from uninitialized memory when attempting
to transform a specially-crafted malformed arithmetic-coded JPEG source image
into a baseline Huffman-coded JPEG destination image.
2.1.91 (3.0 beta2)
==================
### Significant changes relative to 2.1.5.1:
1. Significantly sped up the computation of optimal Huffman tables. This
speeds up the compression of tiny images by as much as 2x and provides a
noticeable speedup for images as large as 256x256 when using optimal Huffman
tables.
2. All deprecated fields, constructors, and methods in the TurboJPEG Java API
have been removed.
3. Arithmetic entropy coding is now supported with 12-bit-per-component JPEG
images.
4. Overhauled the TurboJPEG API to address long-standing limitations and to
make the API more extensible and intuitive:
- All C function names are now prefixed with `tj3`, and all version
suffixes have been removed from the function names. Future API overhauls will
increment the prefix to `tj4`, etc., thus retaining backward API/ABI
compatibility without versioning each individual function.
- Stateless boolean flags have been replaced with stateful integer API
parameters, the values of which persist between function calls. New
functions/methods (`tj3Set()`/`TJCompressor.set()`/`TJDecompressor.set()` and
`tj3Get()`/`TJCompressor.get()`/`TJDecompressor.get()`) can be used to set and
query the value of a particular API parameter.
- The JPEG quality and subsampling are now implemented using API
parameters rather than stateless function arguments (C) or dedicated set/get
methods (Java.)
- `tj3DecompressHeader()` now stores all relevant information about the
JPEG image, including the width, height, subsampling type, entropy coding
algorithm, etc., in API parameters rather than returning that information
through pointer arguments.
- `TJFLAG_LIMITSCANS`/`TJ.FLAG_LIMITSCANS` has been reimplemented as an
API parameter (`TJPARAM_SCANLIMIT`/`TJ.PARAM_SCANLIMIT`) that allows the number
of scans to be specified.
- Huffman table optimization can now be specified using a new API
parameter (`TJPARAM_OPTIMIZE`/`TJ.PARAM_OPTIMIZE`), a new transform option
(`TJXOPT_OPTIMIZE`/`TJTransform.OPT_OPTIMIZE`), and a new TJBench option
(`-optimize`.)
- Arithmetic entropy coding can now be specified or queried, using a new
API parameter (`TJPARAM_ARITHMETIC`/`TJ.PARAM_ARITHMETIC`), a new transform
option (`TJXOPT_ARITHMETIC`/`TJTransform.OPT_ARITHMETIC`), and a new TJBench
option (`-arithmetic`.)
- The restart marker interval can now be specified, using new API
parameters (`TJPARAM_RESTARTROWS`/`TJ.PARAM_RESTARTROWS` and
`TJPARAM_RESTARTBLOCKS`/`TJ.PARAM_RESTARTBLOCKS`) and a new TJBench option
(`-restart`.)
- Pixel density can now be specified or queried, using new API parameters
(`TJPARAM_XDENSITY`/`TJ.PARAM_XDENSITY`,
`TJPARAM_YDENSITY`/`TJ.PARAM_YDENSITY`, and
`TJPARAM_DENSITYUNITS`/`TJ.PARAM_DENSITYUNITS`.)
- The accurate DCT/IDCT algorithms are now the default for both
compression and decompression, since the "fast" algorithms are considered to be
a legacy feature. (The "fast" algorithms do not pass the ISO compliance tests,
and those algorithms are not any faster than the accurate algorithms on modern
x86 CPUs.)
- All C initialization functions have been combined into a single function
(`tj3Init()`) that accepts an integer argument specifying the subsystems to
initialize.
- All C functions now use the `const` keyword for pointer arguments that
point to unmodified buffers (and for both dimensions of pointer arguments that
point to sets of unmodified buffers.)
- All C functions now use `size_t` rather than `unsigned long` to
represent buffer sizes, for compatibility with `malloc()` and to avoid
disparities in the size of `unsigned long` between LP64 (Un*x) and LLP64
(Windows) operating systems.
- All C buffer size functions now return 0 if an error occurs, rather than
trying to awkwardly return -1 in an unsigned data type (which could easily be
misinterpreted as a very large value.)
- Decompression scaling is now enabled explicitly, using a new
function/method (`tj3SetScalingFactor()`/`TJDecompressor.setScalingFactor()`),
rather than implicitly using awkward "desired width"/"desired height"
arguments.
- Partial image decompression has been implemented, using a new
function/method (`tj3SetCroppingRegion()`/`TJDecompressor.setCroppingRegion()`)
and a new TJBench option (`-crop`.)
- The JPEG colorspace can now be specified explicitly when compressing,
using a new API parameter (`TJPARAM_COLORSPACE`/`TJ.PARAM_COLORSPACE`.) This
allows JPEG images with the RGB and CMYK colorspaces to be created.
- TJBench no longer generates error/difference images, since identical
functionality is already available in ImageMagick.
- JPEG images with unknown subsampling configurations can now be
fully decompressed into packed-pixel images or losslessly transformed (with the
exception of lossless cropping.) They cannot currently be partially
decompressed or decompressed into planar YUV images.
- `tj3Destroy()` now silently accepts a NULL handle.
- `tj3Alloc()` and `tj3Free()` now return/accept void pointers, as
`malloc()` and `free()` do.
- The C image I/O functions now accept a TurboJPEG instance handle, which
is used to transmit/receive API parameter values and to receive error
information.
5. Added support for 8-bit-per-component, 12-bit-per-component, and
16-bit-per-component lossless JPEG images. A new libjpeg API function
(`jpeg_enable_lossless()`), TurboJPEG API parameters
(`TJPARAM_LOSSLESS`/`TJ.PARAM_LOSSLESS`,
`TJPARAM_LOSSLESSPSV`/`TJ.PARAM_LOSSLESSPSV`, and
`TJPARAM_LOSSLESSPT`/`TJ.PARAM_LOSSLESSPT`), and a cjpeg/TJBench option
(`-lossless`) can be used to create a lossless JPEG image. (Decompression of
lossless JPEG images is handled automatically.) Refer to
[libjpeg.txt](libjpeg.txt), [usage.txt](usage.txt), and the TurboJPEG API
documentation for more details.
6. Added support for 12-bit-per-component (lossy and lossless) and
16-bit-per-component (lossless) JPEG images to the libjpeg and TurboJPEG APIs:
- The existing `data_precision` field in `jpeg_compress_struct` and
`jpeg_decompress_struct` has been repurposed to enable the creation of
12-bit-per-component and 16-bit-per-component JPEG images or to detect whether
a 12-bit-per-component or 16-bit-per-component JPEG image is being
decompressed.
- New 12-bit-per-component and 16-bit-per-component versions of
`jpeg_write_scanlines()` and `jpeg_read_scanlines()`, as well as new
12-bit-per-component versions of `jpeg_write_raw_data()`,
`jpeg_skip_scanlines()`, `jpeg_crop_scanline()`, and `jpeg_read_raw_data()`,
provide interfaces for compressing from/decompressing to 12-bit-per-component
and 16-bit-per-component packed-pixel and planar YUV image buffers.
- New 12-bit-per-component and 16-bit-per-component compression,
decompression, and image I/O functions/methods have been added to the TurboJPEG
API, and a new API parameter (`TJPARAM_PRECISION`/`TJ.PARAM_PRECISION`) can be
used to query the data precision of a JPEG image. (YUV functions are currently
limited to 8-bit data precision but can be expanded to accommodate 12-bit data
precision in the future, if such is deemed beneficial.)
- A new cjpeg and TJBench command-line argument (`-precision`) can be used
to create a 12-bit-per-component or 16-bit-per-component JPEG image.
(Decompression and transformation of 12-bit-per-component and
16-bit-per-component JPEG images is handled automatically.)
Refer to [libjpeg.txt](libjpeg.txt), [usage.txt](usage.txt), and the
TurboJPEG API documentation for more details.
2.1.5.1
=======
### Significant changes relative to 2.1.5:
1. The SIMD dispatchers in libjpeg-turbo 2.1.4 and prior stored the list of
supported SIMD instruction sets in a global variable, which caused an innocuous
race condition whereby the variable could have been initialized multiple times
if `jpeg_start_*compress()` was called simultaneously in multiple threads.
libjpeg-turbo 2.1.5 included an undocumented attempt to fix this race condition
by making the SIMD support variable thread-local. However, that caused another
issue whereby, if `jpeg_start_*compress()` was called in one thread and
`jpeg_read_*()` or `jpeg_write_*()` was called in a second thread, the SIMD
support variable was never initialized in the second thread. On x86 systems,
this led the second thread to incorrectly assume that AVX2 instructions were
always available, and when it attempted to use those instructions on older x86
CPUs that do not support them, an illegal instruction error occurred. The SIMD
dispatchers now ensure that the SIMD support variable is initialized before
dispatching based on its value.
2.1.5
=====
### Significant changes relative to 2.1.4:
1. Fixed issues in the build system whereby, when using the Ninja Multi-Config
CMake generator, a static build of libjpeg-turbo (a build in which
`ENABLE_SHARED` is `0`) could not be installed, a Windows installer could not
be built, and the Java regression tests failed.
2. Fixed a regression introduced by 2.0 beta1[15] that caused a buffer overrun
in the progressive Huffman encoder when attempting to transform a
specially-crafted malformed 12-bit-per-component JPEG image into a progressive
12-bit-per-component JPEG image using a 12-bit-per-component build of
libjpeg-turbo (`-DWITH_12BIT=1`.) Given that the buffer overrun was fully
contained within the progressive Huffman encoder structure and did not cause a
segfault or other user-visible errant behavior, given that the lossless
transformer (unlike the decompressor) is not generally exposed to arbitrary
data exploits, and given that 12-bit-per-component builds of libjpeg-turbo are
uncommon, this issue did not likely pose a security risk.
3. Fixed an issue whereby, when using a 12-bit-per-component build of
libjpeg-turbo (`-DWITH_12BIT=1`), passing samples with values greater than 4095
or less than 0 to `jpeg_write_scanlines()` caused a buffer overrun or underrun
in the RGB-to-YCbCr color converter.
4. Fixed a floating point exception that occurred when attempting to use the
jpegtran `-drop` and `-trim` options to losslessly transform a
specially-crafted malformed JPEG image.
5. Fixed an issue in `tjBufSizeYUV2()` whereby it returned a bogus result,
rather than throwing an error, if the `align` parameter was not a power of 2.
Fixed a similar issue in `tjCompressFromYUV()` whereby it generated a corrupt
JPEG image in certain cases, rather than throwing an error, if the `align`
parameter was not a power of 2.
6. Fixed an issue whereby `tjDecompressToYUV2()`, which is a wrapper for
`tjDecompressToYUVPlanes()`, used the desired YUV image dimensions rather than
the actual scaled image dimensions when computing the plane pointers and
strides to pass to `tjDecompressToYUVPlanes()`. This caused a buffer overrun
and subsequent segfault if the desired image dimensions exceeded the scaled
image dimensions.
7. Fixed an issue whereby, when decompressing a 12-bit-per-component JPEG image
(`-DWITH_12BIT=1`) using an alpha-enabled output color space such as
`JCS_EXT_RGBA`, the alpha channel was set to 255 rather than 4095.
8. Fixed an issue whereby the Java version of TJBench did not accept a range of
quality values.
9. Fixed an issue whereby, when `-progressive` was passed to TJBench, the JPEG
input image was not transformed into a progressive JPEG image prior to
decompression.
2.1.4
=====
### Significant changes relative to 2.1.3:
1. Fixed a regression introduced in 2.1.3 that caused build failures with
Visual Studio 2010.
2. The `tjDecompressHeader3()` function in the TurboJPEG C API and the
`TJDecompressor.setSourceImage()` method in the TurboJPEG Java API now accept
"abbreviated table specification" (AKA "tables-only") datastreams, which can be
used to prime the decompressor with quantization and Huffman tables that can be
used when decompressing subsequent "abbreviated image" datastreams.
3. libjpeg-turbo now performs run-time detection of AltiVec instructions on
OS X/PowerPC systems if AltiVec instructions are not enabled at compile time.
This allows both AltiVec-equipped (PowerPC G4 and G5) and non-AltiVec-equipped
(PowerPC G3) CPUs to be supported using the same build of libjpeg-turbo.
4. Fixed an error ("Bogus virtual array access") that occurred when attempting
to decompress a progressive JPEG image with a height less than or equal to one
iMCU (8 * the vertical sampling factor) using buffered-image mode with
interblock smoothing enabled. This was a regression introduced by
2.1 beta1[6(b)].
5. Fixed two issues that prevented partial image decompression from working
properly with buffered-image mode:
- Attempting to call `jpeg_crop_scanline()` after
`jpeg_start_decompress()` but before `jpeg_start_output()` resulted in an error
("Improper call to JPEG library in state 207".)
- Attempting to use `jpeg_skip_scanlines()` resulted in an error ("Bogus
virtual array access") under certain circumstances.
2.1.3
=====
### Significant changes relative to 2.1.2:
1. Fixed a regression introduced by 2.0 beta1[7] whereby cjpeg compressed PGM
input files into full-color JPEG images unless the `-grayscale` option was
used.
2. cjpeg now automatically compresses GIF and 8-bit BMP input files into
grayscale JPEG images if the input files contain only shades of gray.
3. The build system now enables the intrinsics implementation of the AArch64
(Arm 64-bit) Neon SIMD extensions by default when using GCC 12 or later.
4. Fixed a segfault that occurred while decompressing a 4:2:0 JPEG image using
the merged (non-fancy) upsampling algorithms (that is, with
`cinfo.do_fancy_upsampling` set to `FALSE`) along with `jpeg_crop_scanline()`.
Specifically, the segfault occurred if the number of bytes remaining in the
output buffer was less than the number of bytes required to represent one
uncropped scanline of the output image. For that reason, the issue could only
be reproduced using the libjpeg API, not using djpeg.
2.1.2
=====
### Significant changes relative to 2.1.1:
1. Fixed a regression introduced by 2.1 beta1[13] that caused the remaining
GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are used
by default with GCC for performance reasons) to be placed in the `.rodata`
section rather than in the `.text` section. This caused the GNU linker to
automatically place the `.rodata` section in an executable segment, which
prevented libjpeg-turbo from working properly with other linkers and also
represented a potential security risk.
2. Fixed an issue whereby the `tjTransform()` function incorrectly computed the
iMCU size for 4:4:4 JPEG images with non-unary sampling factors and thus unduly
rejected some cropping regions, even though those regions aligned with 8x8 iMCU
boundaries.
3. Fixed a regression introduced by 2.1 beta1[13] that caused the build system
to enable the Arm Neon SIMD extensions when targetting Armv6 and other legacy
architectures that do not support Neon instructions.
4. libjpeg-turbo now performs run-time detection of AltiVec instructions on
FreeBSD/PowerPC systems if AltiVec instructions are not enabled at compile
time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to be
supported using the same build of libjpeg-turbo.
5. cjpeg now accepts a `-strict` argument similar to that of djpeg and
jpegtran, which causes the compressor to abort if an LZW-compressed GIF input
image contains incomplete or corrupt image data.
2.1.1
=====
### Significant changes relative to 2.1.0:
1. Fixed a regression introduced in 2.1.0 that caused build failures with
non-GCC-compatible compilers for Un*x/Arm platforms.
2. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit
(AArch32) Neon SIMD extensions from building unless the C compiler flags
included `-mfloat-abi=softfp` or `-mfloat-abi=hard`.
3. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on
undefined C compiler behavior led to crashes ("SIGBUS: illegal alignment") on
Android systems when running AArch32/Thumb builds of libjpeg-turbo built with
recent versions of Clang.
4. Added a command-line argument (`-copy icc`) to jpegtran that causes it to
copy only the ICC profile markers from the source file and discard any other
metadata.
5. libjpeg-turbo should now build and run on CHERI-enabled architectures, which
use capability pointers that are larger than the size of `size_t`.
6. Fixed a regression (CVE-2021-37972) introduced by 2.1 beta1[5] that caused a
segfault in the 64-bit SSE2 Huffman encoder when attempting to losslessly
transform a specially-crafted malformed JPEG image.
2.1.0
=====
### Significant changes relative to 2.1 beta1:
1. Fixed a regression (CVE-2021-29390) introduced by 2.1 beta1[6(b)] whereby
attempting to decompress certain progressive JPEG images with one or more
component planes of width 8 or less caused a buffer overrun.
2. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to
decompress a specially-crafted malformed progressive JPEG image caused the
block smoothing algorithm to read from uninitialized memory.
3. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the
encoders to generate incorrect results when using the Clang compiler with
Visual Studio.
4. Fixed a floating point exception (CVE-2021-20205) that occurred when
attempting to compress a specially-crafted malformed GIF image with a specified
image width of 0 using cjpeg.
5. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to
generate a progressive JPEG image on an SSE2-capable CPU using a scan script
containing one or more scans with lengths divisible by 32 and non-zero
successive approximation low bit positions would, under certain circumstances,
result in an error ("Missing Huffman code table entry") and an invalid JPEG
image.
6. Introduced a new flag (`TJFLAG_LIMITSCANS` in the TurboJPEG C API and
`TJ.FLAG_LIMIT_SCANS` in the TurboJPEG Java API) and a corresponding TJBench
command-line argument (`-limitscans`) that causes the TurboJPEG decompression
and transform functions/operations to return/throw an error if a progressive
JPEG image contains an unreasonably large number of scans. This allows
applications that use the TurboJPEG API to guard against an exploit of the
progressive JPEG format described in the report
["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
7. The PPM reader now throws an error, rather than segfaulting (due to a buffer
overrun, CVE-2021-46822) or generating incorrect pixels, if an application
attempts to use the `tjLoadImage()` function to load a 16-bit binary PPM file
(a binary PPM file with a maximum value greater than 255) into a grayscale
image buffer or to load a 16-bit binary PGM file into an RGB image buffer.
8. Fixed an issue in the PPM reader that caused incorrect pixels to be
generated when using the `tjLoadImage()` function to load a 16-bit binary PPM
file into an extended RGB image buffer.
9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by
one of the TurboJPEG compression or transform functions and an error
subsequently occurred during compression or transformation, the JPEG buffer
pointer passed by the application was not updated when the function returned.
2.0.90 (2.1 beta1)
==================
### Significant changes relative to 2.0.6:
1. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now
support the x32 ABI on Linux, which allows for using x86-64 instructions with
32-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the
compiler flags.
Caveats:
- CMake 3.9.0 or later is required in order for the build system to
automatically detect an x32 build.
- Java does not support the x32 ABI, and thus the TurboJPEG Java API will
automatically be disabled with x32 builds.
2. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy
chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion,
and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this
speeds up:
- the compression of RGB source images into grayscale JPEG images by
approximately 20%
- the decompression of 4:2:2 JPEG images by approximately 40-60% when
using fancy upsampling
- the decompression of 4:2:2 and 4:2:0 JPEG images by approximately
15-20% when using merged upsampling
- the compression of RGB source images by approximately 30-45% when using
the fast integer DCT
- the decompression of JPEG images into RGB destination images by
approximately 2x when using the fast integer IDCT
The overall decompression speedup for RGB images is now approximately
2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.)
3. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer
supported, and the libjpeg-turbo build system can no longer be used to package
such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store
no longer allows them.
4. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported,
and the libjpeg-turbo build system can no longer be used to package such
builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and
later, and the App Store no longer allows them.
5. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been
significantly optimized, resulting in a measured average overall compression
speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel
and AMD CPUs, as well as a measured average overall compression speedup of
0-23% on platforms that do not have a SIMD-accelerated Huffman encoding
implementation.
6. The block smoothing algorithm that is applied by default when decompressing
progressive Huffman-encoded JPEG images has been improved in the following
ways:
- The algorithm is now more fault-tolerant. Previously, if a particular
scan was incomplete, then the smoothing parameters for the incomplete scan
would be applied to the entire output image, including the parts of the image
that were generated by the prior (complete) scan. Visually, this had the
effect of removing block smoothing from lower-frequency scans if they were
followed by an incomplete higher-frequency scan. libjpeg-turbo now applies
block smoothing parameters to each iMCU row based on which scan generated the
pixels in that row, rather than always using the block smoothing parameters for
the most recent scan.
- When applying block smoothing to DC scans, a Gaussian-like kernel with a
5x5 window is used to reduce the "blocky" appearance.
7. Added SIMD acceleration for progressive Huffman encoding on Arm platforms.
This speeds up the compression of full-color progressive JPEGs by about 30-40%
on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.
8. Added configure-time and run-time auto-detection of Loongson MMI SIMD
instructions, so that the Loongson MMI SIMD extensions can be included in any
MIPS64 libjpeg-turbo build.
9. Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate
methods by which applications can guard against the exploits of the JPEG format
described in the report
["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
- Both programs now accept a `-maxscans` argument, which can be used to
limit the number of allowable scans in the input file.
- Both programs now accept a `-strict` argument, which can be used to
treat all warnings as fatal.
10. CMake package config files are now included for both the libjpeg and
TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's
`find_package()` function. For example:
find_package(libjpeg-turbo CONFIG REQUIRED)
add_executable(libjpeg_program libjpeg_program.c)
target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)
add_executable(libjpeg_program_static libjpeg_program.c)
target_link_libraries(libjpeg_program_static PUBLIC
libjpeg-turbo::jpeg-static)
add_executable(turbojpeg_program turbojpeg_program.c)
target_link_libraries(turbojpeg_program PUBLIC
libjpeg-turbo::turbojpeg)
add_executable(turbojpeg_program_static turbojpeg_program.c)
target_link_libraries(turbojpeg_program_static PUBLIC
libjpeg-turbo::turbojpeg-static)
11. Since the Unisys LZW patent has long expired, cjpeg and djpeg can now
read/write both LZW-compressed and uncompressed GIF files (feature ported from
jpeg-6a and jpeg-9d.)
12. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and
jpeg-9d, as well as the ability to expand the image size using the `-crop`
option. Refer to jpegtran.1 or usage.txt for more details.
13. Added a complete intrinsics implementation of the Arm Neon SIMD extensions,
thus providing SIMD acceleration on Arm platforms for all of the algorithms
that are SIMD-accelerated on x86 platforms. This new implementation is
significantly faster in some cases than the old GAS implementation--
depending on the algorithms used, the type of CPU core, and the compiler. GCC,
as of this writing, does not provide a full or optimal set of Neon intrinsics,
so for performance reasons, the default when building libjpeg-turbo with GCC is
to continue using the GAS implementation of the following algorithms:
- 32-bit RGB-to-YCbCr color conversion
- 32-bit fast and accurate inverse DCT
- 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
- 64-bit accurate forward and inverse DCT
- 64-bit Huffman encoding
A new CMake variable (`NEON_INTRINSICS`) can be used to override this
default.
Since the new intrinsics implementation includes SIMD acceleration
for merged upsampling/color conversion, 1.5.1[5] is no longer necessary and has
been reverted.
14. The Arm Neon SIMD extensions can now be built using Visual Studio.
15. The build system can now be used to generate a universal x86-64 + Armv8
libjpeg-turbo SDK package for both iOS and macOS.
2.0.6
=====
### Significant changes relative to 2.0.5:
1. Fixed "using JNI after critical get" errors that occurred on Android
platforms when using any of the YUV encoding/compression/decompression/decoding
methods in the TurboJPEG Java API.
2. Fixed or worked around multiple issues with `jpeg_skip_scanlines()`:
- Fixed segfaults (CVE-2020-35538) or "Corrupt JPEG data: premature end of
data segment" errors in `jpeg_skip_scanlines()` that occurred when
decompressing 4:2:2 or 4:2:0 JPEG images using merged (non-fancy)
upsampling/color conversion (that is, when setting `cinfo.do_fancy_upsampling`
to `FALSE`.) 2.0.0[6] was a similar fix, but it did not cover all cases.
- `jpeg_skip_scanlines()` now throws an error if two-pass color
quantization is enabled. Two-pass color quantization never worked properly
with `jpeg_skip_scanlines()`, and the issues could not readily be fixed.
- Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when
skipping past the end of an image.
3. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW
toolchains targetting Arm64 (AArch64) Windows binaries.
4. Fixed unexpected visual artifacts that occurred when using
`jpeg_crop_scanline()` and interblock smoothing while decompressing only the DC
scan of a progressive JPEG image.
5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8
API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.)
2.0.5
=====
@@ -54,17 +847,17 @@ JPEG images. This was known to cause a buffer overflow when attempting to
decompress some such images using `tjDecompressToYUV2()` or
`tjDecompressToYUVPlanes()`.
5. Fixed an issue, detected by ASan, whereby attempting to losslessly transform
a specially-crafted malformed JPEG image containing an extremely-high-frequency
coefficient block (junk image data that could never be generated by a
legitimate JPEG compressor) could cause the Huffman encoder's local buffer to
be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that the buffer
overrun was fully contained within the stack and did not cause a segfault or
other user-visible errant behavior, and given that the lossless transformer
(unlike the decompressor) is not generally exposed to arbitrary data exploits,
this issue did not likely pose a security risk.
5. Fixed an issue (CVE-2020-17541), detected by ASan, whereby attempting to
losslessly transform a specially-crafted malformed JPEG image containing an
extremely-high-frequency coefficient block (junk image data that could never be
generated by a legitimate JPEG compressor) could cause the Huffman encoder's
local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that
the buffer overrun was fully contained within the stack and did not cause a
segfault or other user-visible errant behavior, and given that the lossless
transformer (unlike the decompressor) is not generally exposed to arbitrary
data exploits, this issue did not likely pose a security risk.
6. The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a
6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a
separate read-only data section rather than in the text section, to support
execute-only memory layouts.
@@ -246,7 +1039,7 @@ detect actual security issues, should they arise in the future.
1. Added AVX2 SIMD implementations of the colorspace conversion, chroma
downsampling and upsampling, integer quantization and sample conversion, and
slow integer DCT/IDCT algorithms. When using the slow integer DCT/IDCT
accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT
algorithms on AVX2-equipped CPUs, the compression of RGB images is
approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with
64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
@@ -305,16 +1098,15 @@ encounters a warning from the underlying libjpeg API (the default behavior is
to allow the operation to complete unless a fatal error is encountered.)
5. Introduced a new flag in the TurboJPEG C and Java APIs (`TJFLAG_PROGRESSIVE`
and `TJ.FLAG_PROGRESSIVE`, respectively) that causes the library to use
progressive entropy coding in JPEG images generated by compression and
transform operations. Additionally, a new transform option
(`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in the
Java API) has been introduced, allowing progressive entropy coding to be
enabled for selected transforms in a multi-transform operation.
and `TJ.FLAG_PROGRESSIVE`, respectively) that causes compression and transform
operations to generate progressive JPEG images. Additionally, a new transform
option (`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in
the Java API) has been introduced, allowing progressive JPEG images to be
generated by selected transforms in a multi-transform operation.
6. Introduced a new transform option in the TurboJPEG API (`TJXOPT_COPYNONE` in
the C API and `TJTransform.OPT_COPYNONE` in the Java API) that allows the
copying of markers (including EXIF and ICC profile data) to be disabled for a
copying of markers (including Exif and ICC profile data) to be disabled for a
particular transform.
7. Added two functions to the TurboJPEG C API (`tjLoadImage()` and
@@ -350,16 +1142,16 @@ algorithm that caused incorrect dithering in the output image. This algorithm
now produces bitwise-identical results to the unmerged algorithms.
12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if
libjpeg-turbo is built with YASM), and iOS/ARM[64] builds are now private.
libjpeg-turbo is built with Yasm), and iOS/Arm[64] builds are now private.
This prevents those symbols from being exposed in applications or shared
libraries that link statically with libjpeg-turbo.
13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
chroma upsampling, integer quantization, and slow integer DCT/IDCT algorithms.
When using the slow integer DCT/IDCT, this speeds up the compression of RGB
images by approximately 70-100% and the decompression of RGB images by
approximately 2-3.5x.
chroma upsampling, integer quantization, and accurate integer DCT/IDCT
algorithms. When using the accurate integer DCT/IDCT, this speeds up the
compression of RGB images by approximately 70-100% and the decompression of RGB
images by approximately 2-3.5x.
14. Fixed a build error when building with older MinGW releases (regression
caused by 1.5.1[7].)
@@ -409,9 +1201,9 @@ end of a single-scan (non-progressive) image, subsequent calls to
`jpeg_consume_input()` would return `JPEG_SUSPENDED` rather than
`JPEG_REACHED_EOI`.
9. `jpeg_crop_scanlines()` now works correctly when decompressing grayscale
JPEG images that were compressed with a sampling factor other than 1 (for
instance, with `cjpeg -grayscale -sample 2x2`).
9. `jpeg_crop_scanline()` now works correctly when decompressing grayscale JPEG
images that were compressed with a sampling factor other than 1 (for instance,
with `cjpeg -grayscale -sample 2x2`).
1.5.2
@@ -435,7 +1227,7 @@ on PowerPC-based AmigaOS 4 and OpenBSD systems.
5. Fixed build and runtime errors on Windows that occurred when building
libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory
source/destination managers. Due to an oversight, the `jpeg_skip_scanlines()`
and `jpeg_crop_scanlines()` functions were not being included in jpeg7.dll when
and `jpeg_crop_scanline()` functions were not being included in jpeg7.dll when
libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`.
6. Fixed "Bogus virtual array access" error that occurred when using the
@@ -445,13 +1237,13 @@ bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation
in libjpeg-turbo v1.1.
7. The lossless transform features in jpegtran and the TurboJPEG API will now
always attempt to adjust the EXIF image width and height tags if the image size
always attempt to adjust the Exif image width and height tags if the image size
changed as a result of the transform. This behavior has always existed when
using libjpeg v8 API/ABI emulation. It was supposed to be available with
libjpeg v7 API/ABI emulation as well but did not work properly due to a bug.
Furthermore, there was never any good reason not to enable it with libjpeg v6b
API/ABI emulation, since the behavior is entirely internal. Note that
`-copy all` must be passed to jpegtran in order to transfer the EXIF tags from
`-copy all` must be passed to jpegtran in order to transfer the Exif tags from
the source image to the destination image.
8. Fixed several memory leaks in the TurboJPEG API library that could occur
@@ -473,7 +1265,7 @@ for two reasons: it allows testers to more easily work around the 2 GB limit
in libFuzzer, and it allows developers of security-sensitive applications to
more easily defend against one of the progressive JPEG exploits (LJT-01-004)
identified in
[this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
[this report](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
10. TJBench will now run each benchmark for 1 second prior to starting the
timer, in order to improve the consistency of the results. Furthermore, the
@@ -691,8 +1483,8 @@ benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`.
13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
compression algorithms (including the slow integer forward DCT and h2v2 & h2v1
downsampling algorithms, which are not accelerated in the 32-bit NEON
compression algorithms (including the accurate integer forward DCT and h2v2 &
h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON
implementation.) This speeds up the compression of full-color JPEGs by about
75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
Cortex-A53 and Cortex-A57 cores.
@@ -823,8 +1615,8 @@ platforms other than Windows or Linux. Oops.
7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
builds of libjpeg-turbo to incorrectly encode a few specific test images when
quality=98, an optimized Huffman table, and the slow integer forward DCT were
used.
quality=98, an optimized Huffman table, and the accurate integer forward DCT
were used.
8. The Windows (CMake) build system now supports building only static or only
shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or
@@ -983,8 +1775,8 @@ floating point inverse DCT (using code borrowed from libjpeg v8a and later.)
The accuracy of this implementation now matches the accuracy of the SSE/SSE2
implementation. Note, however, that the floating point DCT/IDCT algorithms are
mainly a legacy feature. They generally do not produce significantly better
accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit
slower.
accuracy than the accurate integer DCT/IDCT algorithms, and they are quite a
bit slower.
8. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows
for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
@@ -1014,7 +1806,7 @@ features (such as the colorspace extensions), but in general, it performs no
faster than libjpeg v6b.
14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
and IDCT algorithms (both are used during JPEG decompression.) For unknown
and IDCT algorithms (both are used during JPEG decompression.) For
reasons (probably related to clang), this code cannot currently be compiled for
iOS.
@@ -1235,8 +2027,8 @@ either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
### Significant changes relative to 1.2 beta1:
1. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
was not adding the current directory to the assembler include path, so YASM
1. Fixed build issue with Yasm on Unix systems (the libjpeg-turbo build system
was not adding the current directory to the assembler include path, so Yasm
was not able to find jsimdcfg.inc.)
2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
@@ -1304,7 +2096,7 @@ transposed or rotated 90 degrees.
8. All legacy VirtualGL code has been re-factored, and this has allowed
libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
9. libjpeg-turbo can now be built with YASM.
9. libjpeg-turbo can now be built with Yasm.
10. Added SIMD acceleration for ARM Linux and iOS platforms that support
NEON instructions.
@@ -1394,8 +2186,8 @@ cases.
2. Despite the above, the fast integer forward DCT still degrades somewhat for
JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically
use the slow integer forward DCT when generating JPEG images of quality 96 or
greater. This reduces compression performance by as much as 15% for these
use the accurate integer forward DCT when generating JPEG images of quality 96
or greater. This reduces compression performance by as much as 15% for these
high-quality images but is necessary to ensure that the images are perceptually
lossless. It also ensures that the library can avoid the performance pitfall
created by [1].
@@ -1500,7 +2292,7 @@ and unit tests now work on those architectures.
0.0.93
======
### Significant changes since 0.0.91:
### Significant changes relative to 0.0.91:
1. 2982659: Fixed x86-64 build on FreeBSD systems

View File

@@ -1,30 +1,33 @@
libjpeg-turbo Licenses
======================
libjpeg-turbo is covered by three compatible BSD-style open source licenses:
libjpeg-turbo is covered by two compatible BSD-style open source licenses:
- The IJG (Independent JPEG Group) License, which is listed in
[README.ijg](README.ijg)
This license applies to the libjpeg API library and associated programs
(any code inherited from libjpeg, and any modifications to that code.)
This license applies to the libjpeg API library and associated programs,
including any code inherited from libjpeg and any modifications to that
code. Note that the libjpeg-turbo SIMD source code bears the
[zlib License](https://opensource.org/licenses/Zlib), but in the context of
the overall libjpeg API library, the terms of the zlib License are subsumed
by the terms of the IJG License.
- The Modified (3-clause) BSD License, which is listed below
This license covers the TurboJPEG API library and associated programs, as
well as the build system.
- The [zlib License](https://opensource.org/licenses/Zlib)
This license is a subset of the other two, and it covers the libjpeg-turbo
SIMD extensions.
This license applies to the TurboJPEG API library and associated programs, as
well as the build system. Note that the TurboJPEG API library wraps the
libjpeg API library, so in the context of the overall TurboJPEG API library,
both the terms of the IJG License and the terms of the Modified (3-clause)
BSD License apply.
Complying with the libjpeg-turbo Licenses
=========================================
This section provides a roll-up of the libjpeg-turbo licensing terms, to the
best of our understanding.
best of our understanding. This is not a license in and of itself. It is
intended solely for clarification.
1. If you are distributing a modified version of the libjpeg-turbo source,
then:
@@ -38,7 +41,7 @@ best of our understanding.
- Clauses 1 and 3 of the zlib License
2. You must add your own copyright notice to the header of each source
file you modified, so others can tell that you modified that file (if
file you modified, so others can tell that you modified that file. (If
there is not an existing copyright header in that file, then you can
simply add a notice stating that you modified the file.)
@@ -91,7 +94,7 @@ best of our understanding.
The Modified (3-clause) BSD License
===================================
Copyright (C)2009-2020 D. R. Commander. All Rights Reserved.
Copyright (C)2009-2024 D. R. Commander. All Rights Reserved.<br>
Copyright (C)2015 Viktor Szathmáry. All Rights Reserved.
Redistribution and use in source and binary forms, with or without
@@ -119,8 +122,8 @@ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
Why Three Licenses?
===================
Why Two Licenses?
=================
The zlib License could have been used instead of the Modified (3-clause) BSD
License, and since the IJG License effectively subsumes the distribution

View File

@@ -185,7 +185,7 @@ Integer Extension Parameters Supported by mozjpeg
8 = Table from: An Improved Detection Model for DCT Coefficient Quantization
(1993) Peterson, Ahumada and Watson
* JINT_DC_SCAN_OPT_MODE (default: 1)
* JINT_DC_SCAN_OPT_MODE (default: 0)
Specifies the DC scan optimization mode. The following options are
available:
0 = One scan for all components

View File

@@ -1,14 +1,14 @@
Background
==========
libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
AVX2, NEON, AltiVec) to accelerate baseline JPEG compression and decompression
on x86, x86-64, ARM, and PowerPC systems, as well as progressive JPEG
compression on x86 and x86-64 systems. On such systems, libjpeg-turbo is
generally 2-6x as fast as libjpeg, all else being equal. On other types of
systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by
virtue of its highly-optimized Huffman coding routines. In many cases, the
performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.
libjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate
baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and
MIPS systems, as well as progressive JPEG compression on x86, x86-64, and Arm
systems. On such systems, libjpeg-turbo is generally 2-6x as fast as libjpeg,
all else being equal. On other types of systems, libjpeg-turbo can still
outperform libjpeg by a significant amount, by virtue of its highly-optimized
Huffman coding routines. In many cases, the performance of libjpeg-turbo
rivals that of proprietary high-speed JPEG codecs.
libjpeg-turbo implements both the traditional libjpeg API as well as the less
powerful but more straightforward TurboJPEG API. libjpeg-turbo also features
@@ -21,7 +21,26 @@ derivative of libjpeg v6b developed by Miyasaka Masaru. The TigerVNC and
VirtualGL projects made numerous enhancements to the codec in 2009, and in
early 2010, libjpeg-turbo spun off into an independent project, with the goal
of making high-speed JPEG compression/decompression technology available to a
broader range of users and developers.
broader range of users and developers. libjpeg-turbo is an ISO/IEC and ITU-T
reference implementation of the JPEG standard.
More information about libjpeg-turbo can be found at
<https://libjpeg-turbo.org>.
Funding
=======
libjpeg-turbo is an independent open source project, but we rely on patronage
and funded development in order to maintain that independence. The easiest way
to ensure that libjpeg-turbo remains community-focused and free of any one
organization's agenda is to
[sponsor our project through GitHub](https://github.com/sponsors/libjpeg-turbo).
All sponsorship money goes directly toward funding the labor necessary to
maintain libjpeg-turbo, support the user community, and implement bug fixes and
strategically important features.
[![Sponsor libjpeg-turbo](https://img.shields.io/github/sponsors/libjpeg-turbo?label=Sponsor&logo=GitHub)](https://github.com/sponsors/libjpeg-turbo)
License
@@ -52,7 +71,8 @@ JPEG images:
top of the TurboJPEG API. The TurboJPEG API is recommended for first-time
users of libjpeg-turbo. Refer to [tjexample.c](tjexample.c) and
[TJExample.java](java/TJExample.java) for examples of its usage and to
<http://libjpeg-turbo.org/Documentation/Documentation> for API documentation.
<https://libjpeg-turbo.org/Documentation/Documentation> for API
documentation.
- **libjpeg API**<br>
This is the de facto industry-standard API for compressing and decompressing
@@ -135,25 +155,24 @@ without recompiling. libjpeg-turbo does not claim to support all of the
libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
cases (see below.)
By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, or
an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build a
version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that
programs that are built against libjpeg v7 or v8 can be run with libjpeg-turbo.
The following section describes which libjpeg v7+ features are supported and
which aren't.
By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you
can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so
that programs that are built against libjpeg v7 or v8 can be run with
libjpeg-turbo. The following section describes which libjpeg v7+ features are
supported and which aren't.
### Support for libjpeg v7 and v8 Features
#### Fully supported
- **libjpeg: IDCT scaling extensions in decompressor**<br>
- **libjpeg API: IDCT scaling extensions in decompressor**<br>
libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4
and 1/2 are SIMD-accelerated.)
- **libjpeg: Arithmetic coding**
- **libjpeg API: Arithmetic coding**
- **libjpeg: In-memory source and destination managers**<br>
- **libjpeg API: In-memory source and destination managers**<br>
See notes below.
- **cjpeg: Separate quality settings for luminance and chrominance**<br>
@@ -180,19 +199,19 @@ which aren't.
NOTE: As of this writing, extensive research has been conducted into the
usefulness of DCT scaling as a means of data reduction and SmartScale as a
means of quality improvement. The reader is invited to peruse the research at
<http://www.libjpeg-turbo.org/About/SmartScale> and draw his/her own conclusions,
means of quality improvement. Readers are invited to peruse the research at
<https://libjpeg-turbo.org/About/SmartScale> and draw their own conclusions,
but it is the general belief of our project that these features have not
demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
- **libjpeg: DCT scaling in compressor**<br>
- **libjpeg API: DCT scaling in compressor**<br>
`cinfo.scale_num` and `cinfo.scale_denom` are silently ignored.
There is no technical reason why DCT scaling could not be supported when
emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
8/9 would be available, which is of limited usefulness.
- **libjpeg: SmartScale**<br>
- **libjpeg API: SmartScale**<br>
`cinfo.block_size` is silently ignored.
SmartScale is an extension to the JPEG format that allows for DCT block
sizes other than 8x8. Providing support for this new format would be
@@ -205,7 +224,7 @@ demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
interest in providing this feature would be as a means of supporting
additional DCT scaling factors.
- **libjpeg: Fancy downsampling in compressor**<br>
- **libjpeg API: Fancy downsampling in compressor**<br>
`cinfo.do_fancy_downsampling` is silently ignored.
This requires the DCT scaling feature, which is not supported.
@@ -246,17 +265,6 @@ programs that need them, without breaking ABI compatibility for programs that
don't, and it allows those functions to be provided in the "official"
libjpeg-turbo binaries.
Those who are concerned about maintaining strict conformance with the libjpeg
v6b or v7 API can pass an argument of `--without-mem-srcdst` to `configure` or
an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to building
libjpeg-turbo. This will restore the pre-1.3 behavior, in which
`jpeg_mem_src()` and `jpeg_mem_dest()` are only included when emulating the
libjpeg v8 API/ABI.
On Un*x systems, including the in-memory source/destination managers changes
the dynamic library version from 62.1.0 to 62.2.0 if using libjpeg v6b API/ABI
emulation and from 7.1.0 to 7.2.0 if using libjpeg v7 API/ABI emulation.
Note that, on most Un*x systems, the dynamic linker will not look for a
function in a library until that function is actually used. Thus, if a program
is built against libjpeg-turbo 1.3+ and uses `jpeg_mem_src()` or
@@ -276,29 +284,35 @@ Mathematical Compatibility
==========================
For the most part, libjpeg-turbo should produce identical output to libjpeg
v6b. The one exception to this is when using the floating point DCT/IDCT, in
which case the outputs of libjpeg v6b and libjpeg-turbo can differ for the
following reasons:
v6b. There are two exceptions:
- The SSE/SSE2 floating point DCT implementation in libjpeg-turbo is ever so
slightly more accurate than the implementation in libjpeg v6b, but not by
any amount perceptible to human vision (generally in the range of 0.01 to
0.08 dB gain in PNSR.)
1. When decompressing a JPEG image that uses 4:4:0 chrominance subsampling, the
outputs of libjpeg v6b and libjpeg-turbo can differ because libjpeg-turbo
implements a "fancy" (smooth) 4:4:0 upsampling algorithm and libjpeg did not.
2. When using the floating point DCT/IDCT, the outputs of libjpeg v6b and
libjpeg-turbo can differ for the following reasons:
- The SSE/SSE2 floating point DCT implementation in libjpeg-turbo is ever
so slightly more accurate than the implementation in libjpeg v6b, but not
by any amount perceptible to human vision (generally in the range of 0.01
to 0.08 dB gain in PNSR.)
- When not using the SIMD extensions, libjpeg-turbo uses the more accurate
(and slightly faster) floating point IDCT algorithm introduced in libjpeg
v8a as opposed to the algorithm used in libjpeg v6b. It should be noted,
however, that this algorithm basically brings the accuracy of the floating
point IDCT in line with the accuracy of the slow integer IDCT. The floating
point DCT/IDCT algorithms are mainly a legacy feature, and they do not
produce significantly more accuracy than the slow integer algorithms (to put
numbers on this, the typical difference in PNSR between the two algorithms
is less than 0.10 dB, whereas changing the quality level by 1 in the upper
range of the quality scale is typically more like a 1.0 dB difference.)
however, that this algorithm basically brings the accuracy of the
floating point IDCT in line with the accuracy of the accurate integer
IDCT. The floating point DCT/IDCT algorithms are mainly a legacy
feature, and they do not produce significantly more accuracy than the
accurate integer algorithms. (To put numbers on this, the typical
difference in PNSR between the two algorithms is less than 0.10 dB,
whereas changing the quality level by 1 in the upper range of the quality
scale is typically more like a 1.0 dB difference.)
- If the floating point algorithms in libjpeg-turbo are not implemented using
SIMD instructions on a particular platform, then the accuracy of the
floating point DCT/IDCT can depend on the compiler settings.
- If the floating point algorithms in libjpeg-turbo are not implemented
using SIMD instructions on a particular platform, then the accuracy of
the floating point DCT/IDCT can depend on the compiler settings.
While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood it is
still using the same algorithms as libjpeg v6b, so there are several specific
@@ -331,7 +345,7 @@ in a way that makes the rest of the libjpeg infrastructure happy, so it is
necessary to use the slow Huffman decoder when decompressing a JPEG image that
has restart markers. This can cause the decompression performance to drop by
as much as 20%, but the performance will still be much greater than that of
libjpeg. Many consumer packages, such as PhotoShop, use restart markers when
libjpeg. Many consumer packages, such as Photoshop, use restart markers when
generating JPEG images, so images generated by those programs will experience
this issue.
@@ -342,5 +356,17 @@ The algorithm used by the SIMD-accelerated quantization function cannot produce
correct results whenever the fast integer forward DCT is used along with a JPEG
quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization
function in those cases. This causes performance to drop by as much as 40%.
It is therefore strongly advised that you use the slow integer forward DCT
It is therefore strongly advised that you use the accurate integer forward DCT
whenever encoding images with a JPEG quality of 98 or higher.
Memory Debugger Pitfalls
========================
Valgrind and Memory Sanitizer (MSan) can generate false positives
(specifically, incorrect reports of uninitialized memory accesses) when used
with libjpeg-turbo's SIMD extensions. It is generally recommended that the
SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0`
to `cmake` when configuring the build or by setting the environment variable
`JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind,
MSan, or other memory debuggers.

View File

@@ -43,7 +43,7 @@ User documentation:
change.log Version-to-version change highlights.
Programmer and internal documentation:
libjpeg.txt How to use the JPEG library in your own programs.
example.txt Sample code for calling the JPEG library.
example.c Sample code for calling the JPEG library.
structure.txt Overview of the JPEG library's internal structure.
coderules.txt Coding style rules --- please read if you contribute code.
@@ -68,17 +68,17 @@ other abrupt features may not compress well with JPEG, and a higher JPEG
quality may have to be used to avoid visible compression artifacts with such
images.
JPEG is lossy, meaning that the output pixels are not necessarily identical to
the input pixels. However, on photographic content and other "smooth" images,
very good compression ratios can be obtained with no visible compression
artifacts, and extremely high compression ratios are possible if you are
willing to sacrifice image quality (by reducing the "quality" setting in the
compressor.)
JPEG is normally lossy, meaning that the output pixels are not necessarily
identical to the input pixels. However, on photographic content and other
"smooth" images, very good compression ratios can be obtained with no visible
compression artifacts, and extremely high compression ratios are possible if
you are willing to sacrifice image quality (by reducing the "quality" setting
in the compressor.)
This software implements JPEG baseline, extended-sequential, and progressive
compression processes. Provision is made for supporting all variants of these
processes, although some uncommon parameter settings aren't implemented yet.
We have made no provision for supporting the hierarchical or lossless
This software implements JPEG baseline, extended-sequential, progressive, and
lossless compression processes. Provision is made for supporting all variants
of these processes, although some uncommon parameter settings aren't
implemented yet. We have made no provision for supporting the hierarchical
processes defined in the standard.
We provide a set of library routines for reading and writing JPEG image files,
@@ -89,9 +89,9 @@ The library is intended to be reused in other applications.
In order to support file conversion and viewing software, we have included
considerable functionality beyond the bare JPEG coding/decoding capability;
for example, the color quantization modules are not strictly part of JPEG
decoding, but they are essential for output to colormapped file formats or
colormapped displays. These extra functions can be compiled out of the
library if not required for a particular application.
decoding, but they are essential for output to colormapped file formats. These
extra functions can be compiled out of the library if not required for a
particular application.
We have also included "jpegtran", a utility for lossless transcoding between
different JPEG processes, and "rdjpgcom" and "wrjpgcom", two simple
@@ -128,7 +128,7 @@ with respect to this software, its quality, accuracy, merchantability, or
fitness for a particular purpose. This software is provided "AS IS", and you,
its user, assume the entire risk as to its quality and accuracy.
This software is copyright (C) 1991-2016, Thomas G. Lane, Guido Vollbeding.
This software is copyright (C) 1991-2020, Thomas G. Lane, Guido Vollbeding.
All Rights Reserved except as specified below.
Permission is hereby granted to use, copy, modify, and distribute this
@@ -159,19 +159,6 @@ commercial products, provided that all warranty or liability claims are
assumed by the product vendor.
The IJG distribution formerly included code to read and write GIF files.
To avoid entanglement with the Unisys LZW patent (now expired), GIF reading
support has been removed altogether, and the GIF writer has been simplified
to produce "uncompressed GIFs". This technique does not use the LZW
algorithm; the resulting GIF files are larger than usual, but are readable
by all standard GIF decoders.
We are required to state that
"The Graphics Interchange Format(c) is the Copyright property of
CompuServe Incorporated. GIF(sm) is a Service Mark property of
CompuServe Incorporated."
REFERENCES
==========
@@ -223,12 +210,12 @@ https://www.iso.org/standard/54989.html and http://www.itu.int/rec/T-REC-T.871.
A PDF file of the older JFIF 1.02 specification is available at
http://www.w3.org/Graphics/JPEG/jfif3.pdf.
The TIFF 6.0 file format specification can be obtained by FTP from
ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation scheme
found in the TIFF 6.0 spec of 3-June-92 has a number of serious problems.
IJG does not recommend use of the TIFF 6.0 design (TIFF Compression tag 6).
Instead, we recommend the JPEG design proposed by TIFF Technical Note #2
(Compression tag 7). Copies of this Note can be obtained from
The TIFF 6.0 file format specification can be obtained from
http://mirrors.ctan.org/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation
scheme found in the TIFF 6.0 spec of 3-June-92 has a number of serious
problems. IJG does not recommend use of the TIFF 6.0 design (TIFF Compression
tag 6). Instead, we recommend the JPEG design proposed by TIFF Technical Note
#2 (Compression tag 7). Copies of this Note can be obtained from
http://www.ijg.org/files/. It is expected that the next revision
of the TIFF spec will replace the 6.0 JPEG design with the Note's design.
Although IJG's own code does not support TIFF/JPEG, the free libtiff library
@@ -243,14 +230,8 @@ The most recent released version can always be found there in
directory "files".
The JPEG FAQ (Frequently Asked Questions) article is a source of some
general information about JPEG.
It is available on the World Wide Web at http://www.faqs.org/faqs/jpeg-faq/
and other news.answers archive sites, including the official news.answers
archive at rtfm.mit.edu: ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/.
If you don't have Web or FTP access, send e-mail to mail-server@rtfm.mit.edu
with body
send usenet/news.answers/jpeg-faq/part1
send usenet/news.answers/jpeg-faq/part2
general information about JPEG. It is available at
http://www.faqs.org/faqs/jpeg-faq.
FILE FORMAT COMPATIBILITY
@@ -260,7 +241,7 @@ This software implements ITU T.81 | ISO/IEC 10918 with some extensions from
ITU T.871 | ISO/IEC 10918-5 (JPEG File Interchange Format-- see REFERENCES).
Informally, the term "JPEG image" or "JPEG file" most often refers to JFIF or
a subset thereof, but there are other formats containing the name "JPEG" that
are incompatible with the DCT-based JPEG standard or with JFIF (for instance,
are incompatible with the original JPEG standard or with JFIF (for instance,
JPEG 2000 and JPEG XR). This software therefore does not support these
formats. Indeed, one of the original reasons for developing this free software
was to help force convergence on a common, interoperable format standard for

View File

@@ -1,13 +1,13 @@
Mozilla JPEG Encoder Project [![Build Status](https://ci.appveyor.com/api/projects/status/github/mozilla/mozjpeg?branch=master&svg=true)](https://ci.appveyor.com/project/kornel/mozjpeg-4ekrx)
============================
MozJPEG reduces file sizes of JPEG images while retaining quality and compatibility with the vast majority of the world's deployed decoders.
MozJPEG improves JPEG compression efficiency achieving higher visual quality and smaller file sizes at the same time. It is compatible with the JPEG standard, and the vast majority of the world's deployed JPEG decoders.
MozJPEG is based on [libjpeg-turbo](https://github.com/libjpeg-turbo/libjpeg-turbo). **Please send pull requests to libjpeg-turbo** if the changes aren't specific to newly-added MozJPEG-only compression code. This project aims to keep differences with libjpeg-turbo minimal, so whenever possible, improvements and bug fixes should go there first.
MozJPEG is a patch for [libjpeg-turbo](https://github.com/libjpeg-turbo/libjpeg-turbo). **Please send pull requests to libjpeg-turbo** if the changes aren't specific to newly-added MozJPEG-only compression code. This project aims to keep differences with libjpeg-turbo minimal, so whenever possible, improvements and bug fixes should go there first.
It's compatible with libjpeg API and ABI, and can be used as a drop-in replacement for libjpeg. MozJPEG makes tradeoffs that are intended to benefit Web use cases and focuses solely on improving encoding, so it's best used as part of a Web encoding workflow.
MozJPEG is compatible with the libjpeg API and ABI. It is intended to be a drop-in replacement for libjpeg. MozJPEG is a strict superset of libjpeg-turbo's functionality. All MozJPEG's improvements can be disabled at run time, and in that case it behaves exactly like libjpeg-turbo.
MozJPEG is meant to be used as a library in graphics programs and image processing tools. We include a demo `cjpeg` tool, but it's not intended for serious use. We encourage authors of graphics programs to use MozJPEG's [C API](libjpeg.txt) instead.
MozJPEG is meant to be used as a library in graphics programs and image processing tools. We include a demo `cjpeg` command-line tool, but it's not intended for serious use. We encourage authors of graphics programs to use libjpeg's [C API](libjpeg.txt) and link with MozJPEG library instead.
## Features
@@ -15,7 +15,7 @@ MozJPEG is meant to be used as a library in graphics programs and image processi
* Trellis quantization. When converting other formats to JPEG it maximizes quality/filesize ratio.
* Comes with new quantization table presets, e.g. tuned for high-resolution displays.
* Fully compatible with all web browsers.
* Can be seamlessly integrated into any program using libjpeg.
* Can be seamlessly integrated into any program that uses the industry-standard libjpeg API. There's no need to write any MozJPEG-specific integration code.
## Releases
@@ -26,4 +26,4 @@ MozJPEG is meant to be used as a library in graphics programs and image processi
## Compiling
See [BUILDING](BUILDING.md).
See [BUILDING](BUILDING.md). MozJPEG is built exactly the same way as libjpeg-turbo, so if you need additional help please consult [libjpeg-turbo documentation](https://libjpeg-turbo.org/).

View File

@@ -1,26 +1,62 @@
image: Visual Studio 2017
image: Visual Studio 2019
configuration: Release
platform:
- Win32
- x64
install:
## Download nasm
- mkdir nasm
- cd nasm
- appveyor DownloadFile https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/win64/nasm-2.14.02-win64.zip -FileName nasm.zip
- 7z e -y nasm.zip
- set PATH=%PATH%;%CD%
## Prepare cmake
- cd %APPVEYOR_BUILD_FOLDER%
- mkdir cmake_build
- if %PLATFORM% == Win32 (set ARCH=x86)
- if %PLATFORM% == x64 (set ARCH=x64)
## Set up nasm
- choco install nasm
- set PATH=%PATH%;C:\Program Files\NASM
## Set up libpng
- cd C:\Tools\vcpkg
- vcpkg install libpng:%ARCH%-windows
- vcpkg install libpng:%ARCH%-windows-static
before_build:
- cd %APPVEYOR_BUILD_FOLDER%
- nasm -v
- cmake --version
- cd cmake_build
- cmake .. -G "Visual Studio 15 2017" -DPNG_SUPPORTED=NO
- git describe --always --tags --dirty
- FOR /F %%a in ('git describe --always --tags --dirty') do set GIT_VERSION=%%a
build_script:
- cd %APPVEYOR_BUILD_FOLDER%
- msbuild cmake_build\mozjpeg.sln
## Build shared
- cmake -B shared -A %PLATFORM%
-DENABLE_SHARED=1 -DENABLE_STATIC=0
-DREQUIRE_SIMD=1
-DCMAKE_TOOLCHAIN_FILE=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake
- cmake --build shared --config Release
## Build static
- cmake -B static -A %PLATFORM%
-DENABLE_SHARED=0 -DENABLE_STATIC=1
-DREQUIRE_SIMD=1
-DCMAKE_TOOLCHAIN_FILE=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake
-DVCPKG_TARGET_TRIPLET=%ARCH%-windows-static
- cmake --build static --config Release
after_build:
- 7z a mozjpeg-%GIT_VERSION%-win-%ARCH%.zip shared/Release static/Release
artifacts:
- path: cmake_build\**\Release\**\*.exe
- path: cmake_build\**\Release\**\*.lib
- path: '*.zip'
cache:
- C:\ProgramData\chocolatey\bin
- C:\ProgramData\chocolatey\lib
- C:\Program Files\NASM
- C:\tools\vcpkg\installed
deploy:
description: 'Automated build using Appveyor'
provider: GitHub
auth_token:
secure: 2Jj47Q5HnaPob9U4yX2t4q4TYTw4JWU6cS56mM12aoRLgfYkZ4gRZPySIzfmTPqC
artifact: /.*\.zip/
on:
APPVEYOR_REPO_TAG: true # deploy on tag push only

View File

@@ -1,9 +1,11 @@
/*
* cderror.h
*
* This file was part of the Independent JPEG Group's software:
* Copyright (C) 1994-1997, Thomas G. Lane.
* Modified 2009-2017 by Guido Vollbeding.
* This file is part of the Independent JPEG Group's software.
* libjpeg-turbo Modifications:
* Copyright (C) 2021, 2024, D. R. Commander.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
@@ -40,9 +42,8 @@ typedef enum {
JMESSAGE(JMSG_FIRSTADDONCODE = 1000, NULL) /* Must be first entry! */
#ifdef BMP_SUPPORTED
JMESSAGE(JERR_BMP_BADCMAP, "Unsupported BMP colormap format")
JMESSAGE(JERR_BMP_BADDEPTH, "Only 8- and 24-bit BMP files are supported")
JMESSAGE(JERR_BMP_BADDEPTH, "Only 8-, 24-, and 32-bit BMP files are supported")
JMESSAGE(JERR_BMP_BADHEADER, "Invalid BMP file: bad header length")
JMESSAGE(JERR_BMP_BADPLANES, "Invalid BMP file: biPlanes not equal to 1")
JMESSAGE(JERR_BMP_COLORSPACE, "BMP output must be grayscale or RGB")
@@ -50,16 +51,15 @@ JMESSAGE(JERR_BMP_COMPRESSED, "Sorry, compressed BMPs not yet supported")
JMESSAGE(JERR_BMP_EMPTY, "Empty BMP image")
JMESSAGE(JERR_BMP_NOT, "Not a BMP file - does not start with BM")
JMESSAGE(JERR_BMP_OUTOFRANGE, "Numeric value out of range in BMP file")
JMESSAGE(JTRC_BMP, "%ux%u 24-bit BMP image")
JMESSAGE(JTRC_BMP, "%ux%u %d-bit BMP image")
JMESSAGE(JTRC_BMP_MAPPED, "%ux%u 8-bit colormapped BMP image")
JMESSAGE(JTRC_BMP_OS2, "%ux%u 24-bit OS2 BMP image")
JMESSAGE(JTRC_BMP_OS2, "%ux%u %d-bit OS2 BMP image")
JMESSAGE(JTRC_BMP_OS2_MAPPED, "%ux%u 8-bit colormapped OS2 BMP image")
#endif /* BMP_SUPPORTED */
#ifdef GIF_SUPPORTED
JMESSAGE(JERR_GIF_BUG, "GIF output got confused")
JMESSAGE(JERR_GIF_CODESIZE, "Bogus GIF codesize %d")
JMESSAGE(JERR_GIF_COLORSPACE, "GIF output must be grayscale or RGB")
JMESSAGE(JERR_GIF_EMPTY, "Empty GIF image")
JMESSAGE(JERR_GIF_IMAGENOTFOUND, "Too few images in GIF file")
JMESSAGE(JERR_GIF_NOT, "Not a GIF file")
JMESSAGE(JTRC_GIF, "%ux%ux%d GIF image")
@@ -71,46 +71,23 @@ JMESSAGE(JWRN_GIF_BADDATA, "Corrupt data in GIF file")
JMESSAGE(JWRN_GIF_CHAR, "Bogus char 0x%02x in GIF file, ignoring")
JMESSAGE(JWRN_GIF_ENDCODE, "Premature end of GIF image")
JMESSAGE(JWRN_GIF_NOMOREDATA, "Ran out of GIF bits")
#endif /* GIF_SUPPORTED */
#ifdef PPM_SUPPORTED
JMESSAGE(JERR_PPM_COLORSPACE, "PPM output must be grayscale or RGB")
JMESSAGE(JERR_PPM_NONNUMERIC, "Nonnumeric data in PPM file")
JMESSAGE(JERR_PPM_NOT, "Not a PPM/PGM file")
JMESSAGE(JERR_PPM_OUTOFRANGE, "Numeric value out of range in PPM file")
JMESSAGE(JTRC_PGM, "%ux%u PGM image")
JMESSAGE(JTRC_PGM_TEXT, "%ux%u text PGM image")
JMESSAGE(JTRC_PPM, "%ux%u PPM image")
JMESSAGE(JTRC_PPM_TEXT, "%ux%u text PPM image")
#endif /* PPM_SUPPORTED */
JMESSAGE(JTRC_PGM, "%ux%u PGM image (maximum color value = %u)")
JMESSAGE(JTRC_PGM_TEXT, "%ux%u text PGM image (maximum color value = %u)")
JMESSAGE(JTRC_PPM, "%ux%u PPM image (maximum color value = %u)")
JMESSAGE(JTRC_PPM_TEXT, "%ux%u text PPM image (maximum color value = %u)")
#ifdef RLE_SUPPORTED
JMESSAGE(JERR_RLE_BADERROR, "Bogus error code from RLE library")
JMESSAGE(JERR_RLE_COLORSPACE, "RLE output must be grayscale or RGB")
JMESSAGE(JERR_RLE_DIMENSIONS, "Image dimensions (%ux%u) too large for RLE")
JMESSAGE(JERR_RLE_EMPTY, "Empty RLE file")
JMESSAGE(JERR_RLE_EOF, "Premature EOF in RLE header")
JMESSAGE(JERR_RLE_MEM, "Insufficient memory for RLE header")
JMESSAGE(JERR_RLE_NOT, "Not an RLE file")
JMESSAGE(JERR_RLE_TOOMANYCHANNELS, "Cannot handle %d output channels for RLE")
JMESSAGE(JERR_RLE_UNSUPPORTED, "Cannot handle this RLE setup")
JMESSAGE(JTRC_RLE, "%ux%u full-color RLE file")
JMESSAGE(JTRC_RLE_FULLMAP, "%ux%u full-color RLE file with map of length %d")
JMESSAGE(JTRC_RLE_GRAY, "%ux%u grayscale RLE file")
JMESSAGE(JTRC_RLE_MAPGRAY, "%ux%u grayscale RLE file with map of length %d")
JMESSAGE(JTRC_RLE_MAPPED, "%ux%u colormapped RLE file with map of length %d")
#endif /* RLE_SUPPORTED */
#ifdef TARGA_SUPPORTED
JMESSAGE(JERR_TGA_BADCMAP, "Unsupported Targa colormap format")
JMESSAGE(JERR_TGA_BADPARMS, "Invalid or unsupported Targa file")
JMESSAGE(JERR_TGA_COLORSPACE, "Targa output must be grayscale or RGB")
JMESSAGE(JTRC_TGA, "%ux%u RGB Targa image")
JMESSAGE(JTRC_TGA_GRAY, "%ux%u grayscale Targa image")
JMESSAGE(JTRC_TGA_MAPPED, "%ux%u colormapped Targa image")
#else
JMESSAGE(JERR_TGA_NOTCOMP, "Targa support was not compiled")
#endif /* TARGA_SUPPORTED */
JMESSAGE(JERR_BAD_CMAP_FILE,
"Color map file is invalid or of unsupported format")

View File

@@ -3,8 +3,8 @@
*
* This file was part of the Independent JPEG Group's software:
* Copyright (C) 1991-1997, Thomas G. Lane.
* It was modified by The libjpeg-turbo Project to include only code relevant
* to libjpeg-turbo.
* libjpeg-turbo Modifications:
* Copyright (C) 2019, 2022, D. R. Commander.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
@@ -25,12 +25,22 @@
* Optional progress monitor: display a percent-done figure on stderr.
*/
#ifdef PROGRESS_REPORT
METHODDEF(void)
progress_monitor(j_common_ptr cinfo)
{
cd_progress_ptr prog = (cd_progress_ptr)cinfo->progress;
if (prog->max_scans != 0 && cinfo->is_decompressor) {
int scan_no = ((j_decompress_ptr)cinfo)->input_scan_number;
if (scan_no > (int)prog->max_scans) {
fprintf(stderr, "Scan number %d exceeds maximum scans (%u)\n", scan_no,
prog->max_scans);
exit(EXIT_FAILURE);
}
}
if (prog->report) {
int total_passes = prog->pub.total_passes + prog->total_extra_passes;
int percent_done =
(int)(prog->pub.pass_counter * 100L / prog->pub.pass_limit);
@@ -47,6 +57,7 @@ progress_monitor(j_common_ptr cinfo)
fflush(stderr);
}
}
}
GLOBAL(void)
@@ -57,6 +68,8 @@ start_progress_monitor(j_common_ptr cinfo, cd_progress_ptr progress)
progress->pub.progress_monitor = progress_monitor;
progress->completed_extra_passes = 0;
progress->total_extra_passes = 0;
progress->max_scans = 0;
progress->report = FALSE;
progress->percent_done = -1;
cinfo->progress = &progress->pub;
}
@@ -73,8 +86,6 @@ end_progress_monitor(j_common_ptr cinfo)
}
}
#endif
/*
* Case-insensitive matching of possibly-abbreviated keyword switches.

View File

@@ -3,11 +3,12 @@
*
* This file was part of the Independent JPEG Group's software:
* Copyright (C) 1994-1997, Thomas G. Lane.
* Modified 2019 by Guido Vollbeding.
* libjpeg-turbo Modifications:
* Copyright (C) 2017, D. R. Commander.
* mozjpeg Modifications:
* Copyright (C) 2017, 2019, 2021-2022, D. R. Commander.
* Copyright (C) 2014, Mozilla Corporation.
* For conditions of distribution and use, see the accompanying README.ijg file.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
* This file contains common declarations for the sample applications
* cjpeg and djpeg. It is NOT used by the core JPEG library.
@@ -36,8 +37,12 @@ struct cjpeg_source_struct {
FILE *input_file;
JSAMPARRAY buffer;
J12SAMPARRAY buffer12;
#ifdef C_LOSSLESS_SUPPORTED
J16SAMPARRAY buffer16;
#endif
JDIMENSION buffer_height;
JDIMENSION max_pixels;
#if JPEG_RAW_READER
// For reading JPEG
JSAMPARRAY plane_pointer[4];
@@ -65,9 +70,9 @@ struct djpeg_dest_struct {
void (*finish_output) (j_decompress_ptr cinfo, djpeg_dest_ptr dinfo);
/* Re-calculate buffer dimensions based on output dimensions (for use with
partial image decompression.) If this is NULL, then the output format
does not support partial image decompression (BMP and RLE, in particular,
cannot support partial decompression because they use an inversion buffer
to write the image in bottom-up order.) */
does not support partial image decompression (BMP, in particular, cannot
support partial decompression because it uses an inversion buffer to write
the image in bottom-up order.) */
void (*calc_buffer_dimensions) (j_decompress_ptr cinfo,
djpeg_dest_ptr dinfo);
@@ -80,6 +85,10 @@ struct djpeg_dest_struct {
* height is buffer_height.
*/
JSAMPARRAY buffer;
J12SAMPARRAY buffer12;
#ifdef D_LOSSLESS_SUPPORTED
J16SAMPARRAY buffer16;
#endif
JDIMENSION buffer_height;
};
@@ -96,6 +105,9 @@ struct cdjpeg_progress_mgr {
struct jpeg_progress_mgr pub; /* fields known to JPEG library */
int completed_extra_passes; /* extra passes completed */
int total_extra_passes; /* total extra */
JDIMENSION max_scans; /* abort if the number of scans exceeds this
value and the value is non-zero */
boolean report; /* whether or not to report progress */
/* last printed percentage stored here to avoid multiple printouts */
int percent_done;
};
@@ -112,11 +124,23 @@ EXTERN(cjpeg_source_ptr) jinit_read_bmp(j_compress_ptr cinfo,
EXTERN(djpeg_dest_ptr) jinit_write_bmp(j_decompress_ptr cinfo, boolean is_os2,
boolean use_inversion_array);
EXTERN(cjpeg_source_ptr) jinit_read_gif(j_compress_ptr cinfo);
EXTERN(djpeg_dest_ptr) jinit_write_gif(j_decompress_ptr cinfo);
EXTERN(cjpeg_source_ptr) j12init_read_gif(j_compress_ptr cinfo);
#ifdef C_LOSSLESS_SUPPORTED
EXTERN(cjpeg_source_ptr) j16init_read_gif(j_compress_ptr cinfo);
#endif
EXTERN(djpeg_dest_ptr) jinit_write_gif(j_decompress_ptr cinfo, boolean is_lzw);
EXTERN(djpeg_dest_ptr) j12init_write_gif(j_decompress_ptr cinfo,
boolean is_lzw);
EXTERN(cjpeg_source_ptr) jinit_read_ppm(j_compress_ptr cinfo);
EXTERN(cjpeg_source_ptr) j12init_read_ppm(j_compress_ptr cinfo);
#ifdef C_LOSSLESS_SUPPORTED
EXTERN(cjpeg_source_ptr) j16init_read_ppm(j_compress_ptr cinfo);
#endif
EXTERN(djpeg_dest_ptr) jinit_write_ppm(j_decompress_ptr cinfo);
EXTERN(cjpeg_source_ptr) jinit_read_rle(j_compress_ptr cinfo);
EXTERN(djpeg_dest_ptr) jinit_write_rle(j_decompress_ptr cinfo);
EXTERN(djpeg_dest_ptr) j12init_write_ppm(j_decompress_ptr cinfo);
#ifdef D_LOSSLESS_SUPPORTED
EXTERN(djpeg_dest_ptr) j16init_write_ppm(j_decompress_ptr cinfo);
#endif
EXTERN(cjpeg_source_ptr) jinit_read_targa(j_compress_ptr cinfo);
EXTERN(djpeg_dest_ptr) jinit_write_targa(j_decompress_ptr cinfo);
@@ -133,10 +157,10 @@ EXTERN(boolean) set_sample_factors(j_compress_ptr cinfo, char *arg);
/* djpeg support routines (in rdcolmap.c) */
EXTERN(void) read_color_map(j_decompress_ptr cinfo, FILE *infile);
EXTERN(void) read_color_map_12(j_decompress_ptr cinfo, FILE *infile);
/* common support routines (in cdjpeg.c) */
EXTERN(void) enable_signal_catcher(j_common_ptr cinfo);
EXTERN(void) start_progress_monitor(j_common_ptr cinfo,
cd_progress_ptr progress);
EXTERN(void) end_progress_monitor(j_common_ptr cinfo);
@@ -163,6 +187,3 @@ EXTERN(FILE *) write_stdout(void);
#ifndef EXIT_WARNING
#define EXIT_WARNING 2
#endif
#define IsExtRGB(cs) \
(cs == JCS_RGB || (cs >= JCS_EXT_RGB && cs <= JCS_EXT_ARGB))

View File

@@ -6,6 +6,25 @@ reference. Please see ChangeLog.md for information specific to libjpeg-turbo.
CHANGE LOG for Independent JPEG Group's JPEG software
Version 9d 12-Jan-2020
-----------------------
Restore GIF read and write support from libjpeg version 6a.
Thank to Wolfgang Werner (W.W.) Heinz for suggestion.
Add jpegtran -drop option; add options to the crop extension and wipe
to fill the extra area with content from the source image region,
instead of gray out.
Version 9c 14-Jan-2018
-----------------------
jpegtran: add an option to the -wipe switch to fill the region
with the average of adjacent blocks, instead of gray out.
Thank to Caitlyn Feddock and Maddie Ziegler for inspiration.
Version 9b 17-Jan-2016
-----------------------
@@ -13,6 +32,13 @@ Document 'f' specifier for jpegtran -crop specification.
Thank to Michele Martone for suggestion.
Version 9a 19-Jan-2014
-----------------------
Add jpegtran -wipe option and extension for -crop.
Thank to Andrew Senior, David Clunie, and Josef Schmid for suggestion.
Version 9 13-Jan-2013
----------------------
@@ -138,11 +164,6 @@ Huffman tables being used.
Huffman tables are checked for validity much more carefully than before.
To avoid the Unisys LZW patent, djpeg's GIF output capability has been
changed to produce "uncompressed GIFs", and cjpeg's GIF input capability
has been removed altogether. We're not happy about it either, but there
seems to be no good alternative.
The configure script now supports building libjpeg as a shared library
on many flavors of Unix (all the ones that GNU libtool knows how to
build shared libraries for). Use "./configure --enable-shared" to

199
cjpeg.1
View File

@@ -1,4 +1,4 @@
.TH CJPEG 1 "18 March 2017"
.TH CJPEG 1 "30 August 2024"
.SH NAME
cjpeg \- compress an image file to a JPEG file
.SH SYNOPSIS
@@ -16,8 +16,8 @@ cjpeg \- compress an image file to a JPEG file
compresses the named image file, or the standard input if no file is
named, and produces a JPEG/JFIF file on the standard output.
The currently supported input file formats are: PPM (PBMPLUS color
format), PGM (PBMPLUS grayscale format), BMP, Targa, and RLE (Utah Raster
Toolkit format). (RLE is supported only if the URT library is available.)
format), PGM (PBMPLUS grayscale format), BMP, GIF [legacy feature], and Targa
[legacy feature].
.SH OPTIONS
All switch names may be abbreviated; for example,
.B \-grayscale
@@ -30,7 +30,7 @@ Upper and lower case are equivalent (thus
.B \-BMP
is the same as
.BR \-bmp ).
British spellings are also accepted (e.g.,
British spellings are also accepted (e.g.
.BR \-greyscale ),
though for brevity these are not mentioned below.
.PP
@@ -41,17 +41,12 @@ Scale quantization tables to adjust image quality. Quality is 0 (worst) to
100 (best); default is 75. (See below for more info.)
.TP
.B \-grayscale
Create monochrome JPEG file from color input. Be sure to use this switch when
compressing a grayscale BMP file, because
.B cjpeg
isn't bright enough to notice whether a BMP file uses only shades of gray.
By saying
Create monochrome JPEG file from color input. By specifying
.BR \-grayscale,
you'll get a smaller JPEG file that takes less time to process.
.TP
.B \-rgb
Create RGB JPEG file.
Using this switch suppresses the conversion from RGB
Create RGB JPEG file. Using this switch suppresses the conversion from RGB
colorspace input to the default YCbCr JPEG colorspace.
.TP
.B \-optimize
@@ -65,18 +60,22 @@ decompression are unaffected by
.BR \-optimize .
.TP
.B \-progressive
Create progressive JPEG file (see below).
Create progressive JPEG file (see below). Implies
.B \-optimize
unless
.B \-arithmetic
is also specified.
.TP
.B \-targa
Input file is Targa format. Targa files that contain an "identification"
field will not be automatically recognized by
.BR cjpeg ;
for such files you must specify
Input file is Targa format [legacy feature]. Targa files that contain an
"identification" field will not be automatically recognized by
.BR cjpeg .
For such files, you must specify
.B \-targa
to make
.B cjpeg
treat the input as Targa format.
For most Targa files, you won't need this switch.
treat the input as Targa format. For most Targa files, you won't need this
switch.
.PP
The
.B \-quality
@@ -154,45 +153,135 @@ about the same --- often a little smaller.
.PP
Switches for advanced users:
.TP
.BI \-precision " N"
Create JPEG file with N-bit data precision. N is 8, 12, or 16; default is 8.
If N is 16, then
.B -lossless
must also be specified. Note that only the PBMPLUS input file format supports
data precisions other than 8. (For historical reasons,
.B cjpeg
allows GIF input files to be converted into 12-bit-per-sample JPEG files, but
this is not a useful conversion.) Note also that PBMPLUS input files are
silently scaled to the target data precision, even if it is lower than the
precision of the input file. Passing an argument of
.B \-verbose
to
.B cjpeg
will cause it to print information about the precision of the input file.
.B Caution:
12-bit and 16-bit data precision is not yet widely implemented, so many
decoders will be unable to handle a 12-bit-per-sample or 16-bit-per-sample JPEG
file at all.
.IP
.B \-precision\ 12
implies
.B \-optimize
unless
.B \-arithmetic
is also specified.
.TP
.BI \-lossless " psv[,Pt]"
Create a lossless JPEG file using the specified predictor selection value
(1 through 7) and optional point transform (0 through
.nh
.I precision
.hy
- 1, where
.nh
.I precision
.hy
is the JPEG data precision in bits). A point transform value of 0 (the
default) is necessary in order to create a fully lossless JPEG file. (A
non-zero point transform value right-shifts the input samples by the specified
number of bits, which is effectively a form of lossy color quantization.)
.B Caution:
lossless JPEG is not yet widely implemented, so many decoders will be unable to
handle a lossless JPEG file at all. In most cases, compressing and
decompressing a lossless JPEG file is considerably slower than compressing and
decompressing a lossy JPEG file, and lossless JPEG files are much larger than
lossy JPEG files. Also note that the following features will be unavailable
when compressing or decompressing a lossless JPEG file:
.IP
- Quality/quantization table selection
.IP
- Color space conversion (the JPEG image will use the same color space as the
input image)
.IP
- Color quantization
.IP
- DCT/IDCT algorithm selection
.IP
- Smoothing
.IP
- Downsampling/upsampling
.IP
- IDCT scaling
.IP
- Partial image decompression
.IP
- Transformations using
.B jpegtran
.IP
Any switches used to enable or configure those features will be ignored.
.TP
.B \-arithmetic
Use arithmetic coding.
.B Caution:
arithmetic coded JPEG is not yet widely implemented, so many decoders will be
unable to view an arithmetic coded JPEG file at all.
arithmetic-coded JPEG is not yet widely implemented, so many decoders will be
unable to handle an arithmetic-coded JPEG file at all.
.TP
.B \-dct int
Use integer DCT method (default).
Use accurate integer DCT method (default).
.TP
.B \-dct fast
Use fast integer DCT (less accurate).
In libjpeg-turbo, the fast method is generally about 5-15% faster than the int
method when using the x86/x86-64 SIMD extensions (results may vary with other
SIMD implementations, or when using libjpeg-turbo without SIMD extensions.)
Use less accurate integer DCT method [legacy feature].
When the Independent JPEG Group's software was first released in 1991, the
compression time for a 1-megapixel JPEG image on a mainstream PC was measured
in minutes. Thus, the \fBfast\fR integer DCT algorithm provided noticeable
performance benefits. On modern CPUs running libjpeg-turbo, however, the
compression time for a 1-megapixel JPEG image is measured in milliseconds, and
thus the performance benefits of the \fBfast\fR algorithm are much less
noticeable. On modern x86/x86-64 CPUs that support AVX2 instructions, the
\fBfast\fR and \fBint\fR methods have similar performance. On other types of
CPUs, the \fBfast\fR method is generally about 5-15% faster than the \fBint\fR
method.
For quality levels of 90 and below, there should be little or no perceptible
difference between the two algorithms. For quality levels above 90, however,
the difference between the fast and the int methods becomes more pronounced.
With quality=97, for instance, the fast method incurs generally about a 1-3 dB
loss (in PSNR) relative to the int method, but this can be larger for some
images. Do not use the fast method with quality levels above 97. The
algorithm often degenerates at quality=98 and above and can actually produce a
more lossy image than if lower quality levels had been used. Also, in
libjpeg-turbo, the fast method is not fully accelerated for quality levels
above 97, so it will be slower than the int method.
quality difference between the two algorithms. For quality levels above 90,
however, the difference between the \fBfast\fR and \fBint\fR methods becomes
more pronounced. With quality=97, for instance, the \fBfast\fR method incurs
generally about a 1-3 dB loss in PSNR relative to the \fBint\fR method, but
this can be larger for some images. Do not use the \fBfast\fR method with
quality levels above 97. The algorithm often degenerates at quality=98 and
above and can actually produce a more lossy image than if lower quality levels
had been used. Also, in libjpeg-turbo, the \fBfast\fR method is not fully
accelerated for quality levels above 97, so it will be slower than the
\fBint\fR method.
.TP
.B \-dct float
Use floating-point DCT method.
The float method is mainly a legacy feature. It does not produce significantly
more accurate results than the int method, and it is much slower. The float
method may also give different results on different machines due to varying
roundoff behavior, whereas the integer methods should give the same results on
all machines.
Use floating-point DCT method [legacy feature].
The \fBfloat\fR method does not produce significantly more accurate results
than the \fBint\fR method, and it is much slower. The \fBfloat\fR method may
also give different results on different machines due to varying roundoff
behavior, whereas the integer methods should give the same results on all
machines.
.TP
.BI \-icc " file"
Embed ICC color management profile contained in the specified file.
.TP
.BI \-restart " N"
Emit a JPEG restart marker every N MCU rows, or every N MCU blocks if "B" is
attached to the number.
Emit a JPEG restart marker every N MCU rows, or every N MCUs if "B" is attached
to the number.
.IP
In typical JPEG images, an MCU (Minimum Coded Unit) is the minimum set of
interleaved "data units" (8x8 DCT blocks if the image is lossy or samples if
the image is lossless) necessary to represent at least one data unit per
component. (For example, an MCU in an interleaved lossy JPEG image that uses
4:2:2 subsampling consists of two luminance blocks followed by one block for
each chrominance component.) In single-component or non-interleaved JPEG
images, an MCU is the same as a data unit. An MCU row is a row of MCUs
spanning the entire width of the image.
.IP
.B \-restart 0
(the default) means no restart markers.
.TP
@@ -215,6 +304,14 @@ Compress to memory instead of a file. This feature was implemented mainly as a
way of testing the in-memory destination manager (jpeg_mem_dest()), but it is
also useful for benchmarking, since it reduces the I/O overhead.
.TP
.BI \-report
Report compression progress.
.TP
.BI \-strict
Treat all warnings as fatal. Enabling this option will cause the compressor to
abort if an LZW-compressed GIF input image contains incomplete or corrupt image
data.
.TP
.B \-verbose
Enable debug printout. More
.BR \-v 's
@@ -284,10 +381,10 @@ This example compresses the PPM file foo.ppm with a quality factor of
.I foo.jpg
.SH HINTS
Color GIF files are not the ideal input for JPEG; JPEG is really intended for
compressing full-color (24-bit) images. In particular, don't try to convert
cartoons, line drawings, and other images that have only a few distinct
colors. GIF works great on these, JPEG does not. If you want to convert a
GIF to JPEG, you should experiment with
compressing full-color (24-bit through 48-bit) images. In particular, don't
try to convert cartoons, line drawings, and other images that have only a few
distinct colors. GIF works great on these; JPEG does not. If you want to
convert a GIF to JPEG, you should experiment with
.BR cjpeg 's
.B \-quality
and
@@ -341,14 +438,4 @@ This file was modified by The libjpeg-turbo Project to include only information
relevant to libjpeg-turbo, to wordsmith certain sections, and to describe
features not present in libjpeg.
.SH ISSUES
Support for GIF input files was removed in cjpeg v6b due to concerns over
the Unisys LZW patent. Although this patent expired in 2006, cjpeg still
lacks GIF support, for these historical reasons. (Conversion of GIF files to
JPEG is usually a bad idea anyway, since GIF is a 256-color format.)
.PP
Not all variants of BMP and Targa file formats are supported.
.PP
The
.B \-targa
switch is not a bug, it's a feature. (It would be a bug if the Targa format
designers had not been clueless.)

274
cjpeg.c
View File

@@ -4,11 +4,13 @@
* This file was part of the Independent JPEG Group's software:
* Copyright (C) 1991-1998, Thomas G. Lane.
* Modified 2003-2011 by Guido Vollbeding.
* Lossless JPEG Modifications:
* Copyright (C) 1999, Ken Murchison.
* libjpeg-turbo Modifications:
* Copyright (C) 2010, 2013-2014, 2017, D. R. Commander.
* mozjpeg Modifications:
* Copyright (C) 2010, 2013-2014, 2017, 2019-2022, 2024, D. R. Commander.
* Copyright (C) 2014, Mozilla Corporation.
* For conditions of distribution and use, see the accompanying README file.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
* This file contains a command-line user interface for the JPEG compressor.
* It should work on any system with Unix- or MS-DOS-style command lines.
@@ -28,25 +30,17 @@
* works regardless of which command line style is used.
*/
#ifdef _MSC_VER
#define _CRT_SECURE_NO_DEPRECATE
#endif
#ifdef CJPEG_FUZZER
#define JPEG_INTERNALS
#endif
#include "cdjpeg.h" /* Common decls for cjpeg/djpeg applications */
#include "jversion.h" /* for version message */
#include "jconfigint.h"
#ifndef HAVE_STDLIB_H /* <stdlib.h> should declare malloc(),free() */
extern void *malloc(size_t size);
extern void free(void *ptr);
#endif
#ifdef USE_CCOMMAND /* command-line reader for Macintosh */
#ifdef __MWERKS__
#include <SIOUX.h> /* Metrowerks needs this */
#include <console.h> /* ... and this */
#endif
#ifdef THINK_C
#include <console.h> /* Think declares it here */
#endif
#endif
/* Create the add-on message string table. */
@@ -70,9 +64,9 @@ static const char * const cdjpeg_message_table[] = {
* 2) assume we can push back more than one character (works in
* some C implementations, but unportable);
* 3) provide our own buffering (breaks input readers that want to use
* stdio directly, such as the RLE library);
* stdio directly);
* or 4) don't put back the data, and modify the input_init methods to assume
* they start reading after the start of file (also breaks RLE library).
* they start reading after the start of file.
* #1 is attractive for MS-DOS but is untenable on Unix.
*
* The most portable solution for file types that can't be identified by their
@@ -113,10 +107,30 @@ select_file_type(j_compress_ptr cinfo, FILE *infile)
#endif
#ifdef GIF_SUPPORTED
case 'G':
if (cinfo->data_precision == 16) {
#ifdef C_LOSSLESS_SUPPORTED
return j16init_read_gif(cinfo);
#else
ERREXIT1(cinfo, JERR_BAD_PRECISION, cinfo->data_precision);
break;
#endif
} else if (cinfo->data_precision == 12)
return j12init_read_gif(cinfo);
else
return jinit_read_gif(cinfo);
#endif
#ifdef PPM_SUPPORTED
case 'P':
if (cinfo->data_precision == 16) {
#ifdef C_LOSSLESS_SUPPORTED
return j16init_read_ppm(cinfo);
#else
ERREXIT1(cinfo, JERR_BAD_PRECISION, cinfo->data_precision);
break;
#endif
} else if (cinfo->data_precision == 12)
return j12init_read_ppm(cinfo);
else
return jinit_read_ppm(cinfo);
#endif
#ifdef PNG_SUPPORTED
@@ -124,10 +138,6 @@ select_file_type(j_compress_ptr cinfo, FILE *infile)
copy_markers = TRUE;
return jinit_read_png(cinfo);
#endif
#ifdef RLE_SUPPORTED
case 'R':
return jinit_read_rle(cinfo);
#endif
#ifdef TARGA_SUPPORTED
case 0x00:
return jinit_read_targa(cinfo);
@@ -157,7 +167,48 @@ select_file_type(j_compress_ptr cinfo, FILE *infile)
static const char *progname; /* program name for error messages */
static char *icc_filename; /* for -icc switch */
static char *outfilename; /* for -outfile switch */
boolean memdst; /* for -memdst switch */
static boolean memdst; /* for -memdst switch */
static boolean report; /* for -report switch */
static boolean strict; /* for -strict switch */
#ifdef CJPEG_FUZZER
#include <setjmp.h>
struct my_error_mgr {
struct jpeg_error_mgr pub;
jmp_buf setjmp_buffer;
};
void my_error_exit(j_common_ptr cinfo)
{
struct my_error_mgr *myerr = (struct my_error_mgr *)cinfo->err;
longjmp(myerr->setjmp_buffer, 1);
}
static void my_emit_message_fuzzer(j_common_ptr cinfo, int msg_level)
{
if (msg_level < 0)
cinfo->err->num_warnings++;
}
#define HANDLE_ERROR() { \
if (cinfo.global_state > CSTATE_START) { \
if (memdst && outbuffer) \
(*cinfo.dest->term_destination) (&cinfo); \
jpeg_abort_compress(&cinfo); \
} \
jpeg_destroy_compress(&cinfo); \
if (input_file != stdin && input_file != NULL) \
fclose(input_file); \
if (memdst) \
free(outbuffer); \
return EXIT_FAILURE; \
}
#endif
LOCAL(void)
@@ -177,10 +228,10 @@ usage(void)
fprintf(stderr, " -grayscale Create monochrome JPEG file\n");
fprintf(stderr, " -rgb Create RGB JPEG file\n");
#ifdef ENTROPY_OPT_SUPPORTED
fprintf(stderr, " -optimize Optimize Huffman table (smaller file, but slow compression, enabled by default)\n");
fprintf(stderr, " -optimize Optimize Huffman table (smaller file, but slow compression)\n");
#endif
#ifdef C_PROGRESSIVE_SUPPORTED
fprintf(stderr, " -progressive Create progressive JPEG file (enabled by default)\n");
fprintf(stderr, " -progressive Create progressive JPEG file\n");
#endif
fprintf(stderr, " -baseline Create baseline JPEG file (disable progressive coding)\n");
#ifdef TARGA_SUPPORTED
@@ -203,29 +254,42 @@ usage(void)
fprintf(stderr, "Switches for advanced users:\n");
fprintf(stderr, " -noovershoot Disable black-on-white deringing via overshoot\n");
fprintf(stderr, " -nojfif Do not write JFIF (reduces size by 18 bytes but breaks standards; no known problems in Web browsers)\n");
fprintf(stderr, " -precision N Create JPEG file with N-bit data precision\n");
#ifdef C_LOSSLESS_SUPPORTED
fprintf(stderr, " (N is 8, 12, or 16; default is 8; if N is 16, then -lossless\n");
fprintf(stderr, " must also be specified)\n");
#else
fprintf(stderr, " (N is 8 or 12; default is 8)\n");
#endif
#ifdef C_LOSSLESS_SUPPORTED
fprintf(stderr, " -lossless psv[,Pt] Create lossless JPEG file\n");
#endif
#ifdef C_ARITH_CODING_SUPPORTED
fprintf(stderr, " -arithmetic Use arithmetic coding\n");
#endif
#ifdef DCT_ISLOW_SUPPORTED
fprintf(stderr, " -dct int Use integer DCT method%s\n",
fprintf(stderr, " -dct int Use accurate integer DCT method%s\n",
(JDCT_DEFAULT == JDCT_ISLOW ? " (default)" : ""));
#endif
#ifdef DCT_IFAST_SUPPORTED
fprintf(stderr, " -dct fast Use fast integer DCT (less accurate)%s\n",
fprintf(stderr, " -dct fast Use less accurate integer DCT method [legacy feature]%s\n",
(JDCT_DEFAULT == JDCT_IFAST ? " (default)" : ""));
#endif
#ifdef DCT_FLOAT_SUPPORTED
fprintf(stderr, " -dct float Use floating-point DCT method%s\n",
fprintf(stderr, " -dct float Use floating-point DCT method [legacy feature]%s\n",
(JDCT_DEFAULT == JDCT_FLOAT ? " (default)" : ""));
#endif
fprintf(stderr, " -quant-baseline Use 8-bit quantization table entries for baseline JPEG compatibility\n");
fprintf(stderr, " -quant-table N Use predefined quantization table N:\n");
fprintf(stderr, " - 0 JPEG Annex K\n");
fprintf(stderr, " - 1 Flat\n");
fprintf(stderr, " - 2 Custom, tuned for MS-SSIM\n");
fprintf(stderr, " - 3 ImageMagick table by N. Robidoux\n");
fprintf(stderr, " - 4 Custom, tuned for PSNR-HVS\n");
fprintf(stderr, " - 2 Tuned for MS-SSIM on Kodak image set\n");
fprintf(stderr, " - 3 ImageMagick table by N. Robidoux (default)\n");
fprintf(stderr, " - 4 Tuned for PSNR-HVS on Kodak image set\n");
fprintf(stderr, " - 5 Table from paper by Klein, Silverstein and Carney\n");
fprintf(stderr, " - 6 Table from paper by Watson, Taylor and Borthwick\n");
fprintf(stderr, " - 7 Table from paper by Ahumada, Watson, Peterson\n");
fprintf(stderr, " - 8 Table from paper by Peterson, Ahumada and Watson\n");
fprintf(stderr, " -icc FILE Embed ICC profile contained in FILE\n");
fprintf(stderr, " -restart N Set restart interval in rows, or in blocks with B\n");
#ifdef INPUT_SMOOTHING_SUPPORTED
@@ -233,9 +297,9 @@ usage(void)
#endif
fprintf(stderr, " -maxmemory N Maximum memory to use (in kbytes)\n");
fprintf(stderr, " -outfile name Specify name for output file\n");
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
fprintf(stderr, " -memdst Compress to memory instead of file (useful for benchmarking)\n");
#endif
fprintf(stderr, " -report Report compression progress\n");
fprintf(stderr, " -strict Treat all warnings as fatal\n");
fprintf(stderr, " -verbose or -debug Emit debug output\n");
fprintf(stderr, " -version Print version information and exit\n");
fprintf(stderr, "Switches for wizards:\n");
@@ -263,6 +327,9 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
{
int argn;
char *arg;
#ifdef C_LOSSLESS_SUPPORTED
int psv = 0, pt = 0;
#endif
boolean force_baseline;
boolean simple_progressive;
char *qualityarg = NULL; /* saves -quality parm if any */
@@ -283,6 +350,8 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
icc_filename = NULL;
outfilename = NULL;
memdst = FALSE;
report = FALSE;
strict = FALSE;
cinfo->err->trace_level = 0;
/* Scan command line options, adjust parameters */
@@ -345,7 +414,8 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
if (!printed_version) {
fprintf(stderr, "%s version %s (build %s)\n",
PACKAGE_NAME, VERSION, BUILD);
fprintf(stderr, "%s\n\n", JCOPYRIGHT);
fprintf(stderr, JCOPYRIGHT1);
fprintf(stderr, JCOPYRIGHT2 "\n");
fprintf(stderr, "Emulating The Independent JPEG Group's software, version %s\n\n",
JVERSION);
printed_version = TRUE;
@@ -386,6 +456,28 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
usage();
icc_filename = argv[argn];
} else if (keymatch(arg, "lossless", 1)) {
/* Enable lossless mode. */
#ifdef C_LOSSLESS_SUPPORTED
char ch = ',', *ptr;
if (++argn >= argc) /* advance to next argument */
usage();
if (sscanf(argv[argn], "%d%c", &psv, &ch) < 1 || ch != ',')
usage();
ptr = argv[argn];
while (*ptr && *ptr++ != ','); /* advance to next segment of arg
string */
if (*ptr)
sscanf(ptr, "%d", &pt);
/* We must postpone execution until data_precision is known. */
#else
fprintf(stderr, "%s: sorry, lossless output was not compiled\n",
progname);
exit(EXIT_FAILURE);
#endif
} else if (keymatch(arg, "maxmemory", 3)) {
/* Maximum memory in Kb (or Mb with 'm'). */
long lval;
@@ -424,6 +516,22 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
}
outfilename = argv[argn]; /* save it away for later use */
} else if (keymatch(arg, "precision", 3)) {
/* Set data precision. */
int val;
if (++argn >= argc) /* advance to next argument */
usage();
if (sscanf(argv[argn], "%d", &val) != 1)
usage();
#ifdef C_LOSSLESS_SUPPORTED
if (val != 8 && val != 12 && val != 16)
#else
if (val != 8 && val != 12)
#endif
usage();
cinfo->data_precision = val;
} else if (keymatch(arg, "progressive", 1)) {
/* Select simple progressive mode. */
#ifdef C_PROGRESSIVE_SUPPORTED
@@ -437,13 +545,7 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
} else if (keymatch(arg, "memdst", 2)) {
/* Use in-memory destination manager */
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
memdst = TRUE;
#else
fprintf(stderr, "%s: sorry, in-memory destination manager was not compiled in\n",
progname);
exit(EXIT_FAILURE);
#endif
} else if (keymatch(arg, "quality", 1)) {
/* Quality ratings (quantization table scaling factors). */
@@ -470,6 +572,8 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
qtablefile = argv[argn];
/* We postpone actually reading the file in case -quality comes later. */
} else if (keymatch(arg, "report", 3)) {
report = TRUE;
} else if (keymatch(arg, "quant-table", 7)) {
int val;
if (++argn >= argc) /* advance to next argument */
@@ -520,7 +624,7 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
* default sampling factors.
*/
} else if (keymatch(arg, "scans", 4)) {
} else if (keymatch(arg, "scans", 2)) {
/* Set scan script. */
#ifdef C_MULTISCAN_FILES_SUPPORTED
if (++argn >= argc) /* advance to next argument */
@@ -545,6 +649,9 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
usage();
cinfo->smoothing_factor = val;
} else if (keymatch(arg, "strict", 2)) {
strict = TRUE;
} else if (keymatch(arg, "targa", 1)) {
/* Input file is Targa format. */
is_targa = TRUE;
@@ -642,6 +749,11 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
jpeg_simple_progression(cinfo);
#endif
#ifdef C_LOSSLESS_SUPPORTED
if (psv != 0) /* process -lossless */
jpeg_enable_lossless(cinfo, psv, pt);
#endif
#ifdef C_MULTISCAN_FILES_SUPPORTED
if (scansarg != NULL) /* process -scans if it was present */
if (!read_scan_script(cinfo, scansarg))
@@ -653,6 +765,19 @@ parse_switches(j_compress_ptr cinfo, int argc, char **argv,
}
METHODDEF(void)
my_emit_message(j_common_ptr cinfo, int msg_level)
{
if (msg_level < 0) {
/* Treat warning as fatal */
cinfo->err->error_exit(cinfo);
} else {
if (cinfo->err->trace_level >= msg_level)
cinfo->err->output_message(cinfo);
}
}
/*
* The main program.
*/
@@ -661,13 +786,16 @@ int
main(int argc, char **argv)
{
struct jpeg_compress_struct cinfo;
#ifdef CJPEG_FUZZER
struct my_error_mgr myerr;
struct jpeg_error_mgr &jerr = myerr.pub;
#else
struct jpeg_error_mgr jerr;
#ifdef PROGRESS_REPORT
struct cdjpeg_progress_mgr progress;
#endif
struct cdjpeg_progress_mgr progress;
int file_index;
cjpeg_source_ptr src_mgr;
FILE *input_file;
FILE *input_file = NULL;
FILE *icc_file;
JOCTET *icc_profile = NULL;
long icc_len = 0;
@@ -676,11 +804,6 @@ main(int argc, char **argv)
unsigned long outsize = 0;
JDIMENSION num_scanlines;
/* On Mac, fetch a command line. */
#ifdef USE_CCOMMAND
argc = ccommand(&argv);
#endif
progname = argv[0];
if (progname == NULL || progname[0] == 0)
progname = "cjpeg"; /* in case C library doesn't provide it */
@@ -710,6 +833,9 @@ main(int argc, char **argv)
file_index = parse_switches(&cinfo, argc, argv, 0, FALSE);
if (strict)
jerr.emit_message = my_emit_message;
#ifdef TWO_FILE_COMMANDLINE
if (!memdst) {
/* Must have either -outfile switch or explicit output file name */
@@ -785,13 +911,24 @@ main(int argc, char **argv)
fclose(icc_file);
}
#ifdef PROGRESS_REPORT
start_progress_monitor((j_common_ptr)&cinfo, &progress);
#ifdef CJPEG_FUZZER
jerr.error_exit = my_error_exit;
jerr.emit_message = my_emit_message_fuzzer;
if (setjmp(myerr.setjmp_buffer))
HANDLE_ERROR()
#endif
if (report) {
start_progress_monitor((j_common_ptr)&cinfo, &progress);
progress.report = report;
}
/* Figure out the input file format, and set up to read it. */
src_mgr = select_file_type(&cinfo, input_file);
src_mgr->input_file = input_file;
#ifdef CJPEG_FUZZER
src_mgr->max_pixels = 1048576;
#endif
/* Read the input file header to obtain file size & colorspace. */
(*src_mgr->start_input) (&cinfo, src_mgr);
@@ -806,13 +943,16 @@ main(int argc, char **argv)
file_index = parse_switches(&cinfo, argc, argv, 0, TRUE);
/* Specify data destination for compression */
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
if (memdst)
jpeg_mem_dest(&cinfo, &outbuffer, &outsize);
else
#endif
jpeg_stdio_dest(&cinfo, output_file);
#ifdef CJPEG_FUZZER
if (setjmp(myerr.setjmp_buffer))
HANDLE_ERROR()
#endif
/* Start compressor */
jpeg_start_compress(&cinfo, TRUE);
@@ -852,6 +992,21 @@ main(int argc, char **argv)
jpeg_write_icc_profile(&cinfo, icc_profile, (unsigned int)icc_len);
/* Process data */
if (cinfo.data_precision == 16) {
#ifdef C_LOSSLESS_SUPPORTED
while (cinfo.next_scanline < cinfo.image_height) {
num_scanlines = (*src_mgr->get_pixel_rows) (&cinfo, src_mgr);
(void)jpeg16_write_scanlines(&cinfo, src_mgr->buffer16, num_scanlines);
}
#else
ERREXIT1(&cinfo, JERR_BAD_PRECISION, cinfo.data_precision);
#endif
} else if (cinfo.data_precision == 12) {
while (cinfo.next_scanline < cinfo.image_height) {
num_scanlines = (*src_mgr->get_pixel_rows) (&cinfo, src_mgr);
(void)jpeg12_write_scanlines(&cinfo, src_mgr->buffer12, num_scanlines);
}
} else {
while (cinfo.next_scanline < cinfo.image_height) {
num_scanlines = (*src_mgr->get_pixel_rows) (&cinfo, src_mgr);
#if JPEG_RAW_READER
@@ -861,6 +1016,7 @@ main(int argc, char **argv)
#endif
(void)jpeg_write_scanlines(&cinfo, src_mgr->buffer, num_scanlines);
}
}
/* Finish compression and release memory */
(*src_mgr->finish_input) (&cinfo, src_mgr);
@@ -873,18 +1029,18 @@ main(int argc, char **argv)
if (output_file != stdout && output_file != NULL)
fclose(output_file);
#ifdef PROGRESS_REPORT
if (report)
end_progress_monitor((j_common_ptr)&cinfo);
#endif
if (memdst) {
#ifndef CJPEG_FUZZER
fprintf(stderr, "Compressed size: %lu bytes\n", outsize);
#endif
free(outbuffer);
}
free(icc_profile);
/* All done. */
exit(jerr.num_warnings ? EXIT_WARNING : EXIT_SUCCESS);
return 0; /* suppress no-return-value warnings */
return (jerr.num_warnings ? EXIT_WARNING : EXIT_SUCCESS);
}

View File

@@ -1,18 +1,6 @@
# This file is included from the top-level CMakeLists.txt. We just store it
# here to avoid cluttering up that file.
set(PKGNAME ${CMAKE_PROJECT_NAME} CACHE STRING
"Distribution package name (default: ${CMAKE_PROJECT_NAME})")
set(PKGVENDOR "The ${CMAKE_PROJECT_NAME} Project" CACHE STRING
"Vendor name to be included in distribution package descriptions (default: The ${CMAKE_PROJECT_NAME} Project)")
set(PKGURL "http://www.${CMAKE_PROJECT_NAME}.org" CACHE STRING
"URL of project web site to be included in distribution package descriptions (default: http://www.${CMAKE_PROJECT_NAME}.org)")
set(PKGEMAIL "information@${CMAKE_PROJECT_NAME}.org" CACHE STRING
"E-mail of project maintainer to be included in distribution package descriptions (default: information@${CMAKE_PROJECT_NAME}.org")
set(PKGID "com.${CMAKE_PROJECT_NAME}.${PKGNAME}" CACHE STRING
"Globally unique package identifier (reverse DNS notation) (default: com.${CMAKE_PROJECT_NAME}.${PKGNAME})")
###############################################################################
# Linux RPM and DEB
###############################################################################
@@ -22,12 +10,21 @@ if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
set(RPMARCH ${CMAKE_SYSTEM_PROCESSOR})
if(CPU_TYPE STREQUAL "x86_64")
set(DEBARCH amd64)
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "armv7*")
set(DEBARCH armhf)
elseif(CPU_TYPE STREQUAL "arm64")
set(DEBARCH ${CPU_TYPE})
elseif(CPU_TYPE STREQUAL "arm")
check_c_source_compiles("
#if __ARM_PCS_VFP != 1
#error \"float ABI != hard\"
#endif
int main(void) { return 0; }" HAVE_HARD_FLOAT)
if(HAVE_HARD_FLOAT)
set(RPMARCH armv7hl)
set(DEBARCH armhf)
else()
set(RPMARCH armel)
set(DEBARCH armel)
endif()
elseif(CMAKE_SYSTEM_PROCESSOR_LC STREQUAL "ppc64le")
set(DEBARCH ppc64el)
elseif(CPU_TYPE STREQUAL "powerpc" AND BITS EQUAL 32)
@@ -45,19 +42,19 @@ boolean_number(CMAKE_POSITION_INDEPENDENT_CODE)
configure_file(release/makerpm.in pkgscripts/makerpm)
configure_file(release/rpm.spec.in pkgscripts/rpm.spec @ONLY)
add_custom_target(rpm sh pkgscripts/makerpm
add_custom_target(rpm pkgscripts/makerpm
SOURCES pkgscripts/makerpm)
configure_file(release/makesrpm.in pkgscripts/makesrpm)
add_custom_target(srpm sh pkgscripts/makesrpm
add_custom_target(srpm pkgscripts/makesrpm
SOURCES pkgscripts/makesrpm
DEPENDS dist)
configure_file(release/makedpkg.in pkgscripts/makedpkg)
configure_file(release/deb-control.in pkgscripts/deb-control)
add_custom_target(deb sh pkgscripts/makedpkg
add_custom_target(deb pkgscripts/makedpkg
SOURCES pkgscripts/makedpkg)
endif() # Linux
@@ -69,14 +66,16 @@ endif() # Linux
if(WIN32)
if(MSVC)
if(MSVC_LIKE)
set(INST_PLATFORM "Visual C++")
set(INST_NAME ${CMAKE_PROJECT_NAME}-${VERSION}-vc)
set(INST_ID vc)
set(INST_NAME ${CMAKE_PROJECT_NAME}-${VERSION}-${INST_ID})
set(INST_REG_NAME ${CMAKE_PROJECT_NAME})
elseif(MINGW)
set(INST_PLATFORM GCC)
set(INST_NAME ${CMAKE_PROJECT_NAME}-${VERSION}-gcc)
set(INST_REG_NAME ${CMAKE_PROJECT_NAME}-gcc)
set(INST_ID gcc)
set(INST_NAME ${CMAKE_PROJECT_NAME}-${VERSION}-${INST_ID})
set(INST_REG_NAME ${CMAKE_PROJECT_NAME}-${INST_ID})
set(INST_DEFS -DGCC)
endif()
@@ -91,7 +90,7 @@ if(WITH_JAVA)
set(INST_DEFS ${INST_DEFS} -DJAVA)
endif()
if(MSVC_IDE)
if(GENERATOR_IS_MULTI_CONFIG)
set(INST_DEFS ${INST_DEFS} "-DBUILDDIR=${CMAKE_CFG_INTDIR}\\")
else()
set(INST_DEFS ${INST_DEFS} "-DBUILDDIR=")
@@ -100,64 +99,48 @@ endif()
string(REGEX REPLACE "/" "\\\\" INST_DIR ${CMAKE_INSTALL_PREFIX})
configure_file(release/installer.nsi.in installer.nsi @ONLY)
# TODO: It would be nice to eventually switch to CPack and eliminate this mess,
# but not today.
configure_file(win/projectTargets.cmake.in
win/${CMAKE_PROJECT_NAME}Targets.cmake @ONLY)
configure_file(win/${INST_ID}/projectTargets-release.cmake.in
win/${CMAKE_PROJECT_NAME}Targets-release.cmake @ONLY)
if(WITH_JAVA)
set(JAVA_DEPEND turbojpeg-java)
endif()
if(WITH_TURBOJPEG)
set(TURBOJPEG_DEPEND turbojpeg turbojpeg-static tjbench)
endif()
add_custom_target(installer
makensis -nocd ${INST_DEFS} installer.nsi
DEPENDS jpeg jpeg-static turbojpeg turbojpeg-static rdjpgcom wrjpgcom
cjpeg djpeg jpegtran tjbench ${JAVA_DEPEND}
DEPENDS jpeg jpeg-static rdjpgcom wrjpgcom cjpeg djpeg jpegtran
${JAVA_DEPEND} ${TURBOJPEG_DEPEND}
SOURCES installer.nsi)
endif() # WIN32
###############################################################################
# Cygwin Package
###############################################################################
if(CYGWIN)
configure_file(release/makecygwinpkg.in pkgscripts/makecygwinpkg)
add_custom_target(cygwinpkg sh pkgscripts/makecygwinpkg)
endif() # CYGWIN
###############################################################################
# Mac DMG
###############################################################################
if(APPLE)
set(DEFAULT_OSX_32BIT_BUILD ${CMAKE_SOURCE_DIR}/osxx86)
set(OSX_32BIT_BUILD ${DEFAULT_OSX_32BIT_BUILD} CACHE PATH
"Directory containing 32-bit (i386) Mac build to include in universal binaries (default: ${DEFAULT_OSX_32BIT_BUILD})")
set(DEFAULT_IOS_ARMV7_BUILD ${CMAKE_SOURCE_DIR}/iosarmv7)
set(IOS_ARMV7_BUILD ${DEFAULT_IOS_ARMV7_BUILD} CACHE PATH
"Directory containing ARMv7 iOS build to include in universal binaries (default: ${DEFAULT_IOS_ARMV7_BUILD})")
set(DEFAULT_IOS_ARMV7S_BUILD ${CMAKE_SOURCE_DIR}/iosarmv7s)
set(IOS_ARMV7S_BUILD ${DEFAULT_IOS_ARMV7S_BUILD} CACHE PATH
"Directory containing ARMv7s iOS build to include in universal binaries (default: ${DEFAULT_IOS_ARMV7S_BUILD})")
set(DEFAULT_IOS_ARMV8_BUILD ${CMAKE_SOURCE_DIR}/iosarmv8)
set(IOS_ARMV8_BUILD ${DEFAULT_IOS_ARMV8_BUILD} CACHE PATH
"Directory containing ARMv8 iOS build to include in universal binaries (default: ${DEFAULT_IOS_ARMV8_BUILD})")
set(SECONDARY_BUILD "" CACHE PATH
"Directory containing cross-compiled x86-64 or Armv8 (64-bit) iOS or macOS build to include in universal binaries")
set(OSX_APP_CERT_NAME "" CACHE STRING
set(MACOS_APP_CERT_NAME "" CACHE STRING
"Name of the Developer ID Application certificate (in the macOS keychain) that should be used to sign the libjpeg-turbo DMG. Leave this blank to generate an unsigned DMG.")
set(OSX_INST_CERT_NAME "" CACHE STRING
set(MACOS_INST_CERT_NAME "" CACHE STRING
"Name of the Developer ID Installer certificate (in the macOS keychain) that should be used to sign the libjpeg-turbo installer package. Leave this blank to generate an unsigned package.")
configure_file(release/makemacpkg.in pkgscripts/makemacpkg)
configure_file(release/Distribution.xml.in pkgscripts/Distribution.xml)
configure_file(release/Welcome.rtf.in pkgscripts/Welcome.rtf)
configure_file(release/uninstall.in pkgscripts/uninstall)
add_custom_target(dmg sh pkgscripts/makemacpkg
SOURCES pkgscripts/makemacpkg)
add_custom_target(udmg sh pkgscripts/makemacpkg universal
add_custom_target(dmg pkgscripts/makemacpkg
SOURCES pkgscripts/makemacpkg)
endif() # APPLE
@@ -174,9 +157,20 @@ add_custom_target(dist
configure_file(release/maketarball.in pkgscripts/maketarball)
add_custom_target(tarball sh pkgscripts/maketarball
add_custom_target(tarball pkgscripts/maketarball
SOURCES pkgscripts/maketarball)
configure_file(release/libjpeg.pc.in pkgscripts/libjpeg.pc @ONLY)
if(WITH_TURBOJPEG)
configure_file(release/libturbojpeg.pc.in pkgscripts/libturbojpeg.pc @ONLY)
endif()
include(CMakePackageConfigHelpers)
write_basic_package_version_file(
pkgscripts/${CMAKE_PROJECT_NAME}ConfigVersion.cmake
VERSION ${VERSION} COMPATIBILITY AnyNewerVersion)
configure_package_config_file(release/Config.cmake.in
pkgscripts/${CMAKE_PROJECT_NAME}Config.cmake
INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${CMAKE_PROJECT_NAME})

View File

@@ -118,8 +118,10 @@
# absolute paths where necessary, using the same logic.
#=============================================================================
# Copyright 2016, 2019 D. R. Commander
# Copyright 2016 Dmitry Marakasov
# Copyright 2018 Tobias C. Berner
# Copyright 2018 Matthias Räncker
# Copyright 2016, 2019, 2024 D. R. Commander
# Copyright 2016, 2021 Dmitry Marakasov
# Copyright 2016 Roger Leigh
# Copyright 2015 Alex Turbov
# Copyright 2014 Rolf Eike Beer
@@ -180,6 +182,10 @@ macro(GNUInstallDirs_set_install_dir var docstring)
set(_GNUInstallDirs_CMAKE_INSTALL_FORCE_${var} "FORCE")
endif()
if(DEFINED CMAKE_INSTALL_${var} AND NOT CMAKE_INSTALL_${var} MATCHES "^/")
set_property(CACHE CMAKE_INSTALL_${var} PROPERTY TYPE PATH)
endif()
set(CMAKE_INSTALL_${var} "${CMAKE_INSTALL_DEFAULT_${var}}" CACHE PATH
"${docstring} (Default: ${CMAKE_INSTALL_DEFAULT_${var}})"
${_GNUInstallDirs_CMAKE_INSTALL_FORCE_${var}})
@@ -259,6 +265,8 @@ if(NOT DEFINED CMAKE_INSTALL_DEFAULT_LIBDIR)
else()
if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
set(CMAKE_INSTALL_DEFAULT_LIBDIR "lib64")
elseif(CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
set(CMAKE_INSTALL_DEFAULT_LIBDIR "libx32")
endif()
endif()
endif()
@@ -297,7 +305,7 @@ GNUInstallDirs_set_install_dir(DATADIR
"The directory under which read-only architecture-independent data files should be installed")
if(NOT DEFINED CMAKE_INSTALL_DEFAULT_INFODIR)
if(CMAKE_SYSTEM_NAME MATCHES "^(.*BSD|DragonFly)$")
if(CMAKE_SYSTEM_NAME MATCHES "^(([^kF].*)?BSD|DragonFly)$")
set(CMAKE_INSTALL_DEFAULT_INFODIR "info")
else()
set(CMAKE_INSTALL_DEFAULT_INFODIR "<CMAKE_INSTALL_DATAROOTDIR>/info")
@@ -307,7 +315,7 @@ GNUInstallDirs_set_install_dir(INFODIR
"The directory into which info documentation files should be installed")
if(NOT DEFINED CMAKE_INSTALL_DEFAULT_MANDIR)
if(CMAKE_SYSTEM_NAME MATCHES "^(.*BSD|DragonFly)$")
if(CMAKE_SYSTEM_NAME MATCHES "^(([^k].*)?BSD|DragonFly)$" AND NOT CMAKE_SYSTEM_NAME MATCHES "^(FreeBSD)$")
set(CMAKE_INSTALL_DEFAULT_MANDIR "man")
else()
set(CMAKE_INSTALL_DEFAULT_MANDIR "<CMAKE_INSTALL_DATAROOTDIR>/man")

View File

@@ -0,0 +1,13 @@
# This file is included from the top-level CMakeLists.txt. We just store it
# here to avoid cluttering up that file.
set(PKGNAME ${CMAKE_PROJECT_NAME} CACHE STRING
"Distribution package name (default: ${CMAKE_PROJECT_NAME})")
set(PKGVENDOR "The ${CMAKE_PROJECT_NAME} Project" CACHE STRING
"Vendor name to be included in distribution package descriptions (default: The ${CMAKE_PROJECT_NAME} Project)")
set(PKGURL "https://${CMAKE_PROJECT_NAME}.org" CACHE STRING
"URL of project web site to be included in distribution package descriptions (default: https://${CMAKE_PROJECT_NAME}.org)")
set(PKGEMAIL "information@${CMAKE_PROJECT_NAME}.org" CACHE STRING
"E-mail of project maintainer to be included in distribution package descriptions (default: information@${CMAKE_PROJECT_NAME}.org")
set(PKGID "com.${CMAKE_PROJECT_NAME}.${PKGNAME}" CACHE STRING
"Globally unique package identifier (reverse DNS notation) (default: com.${CMAKE_PROJECT_NAME}.${PKGNAME})")

View File

@@ -30,6 +30,15 @@ file(GLOB FILES
*_411_*.ppm
*_411_*.jpg
*_411.yuv
*_441_*.bmp
*_441_*.png
*_441_*.ppm
*_441_*.jpg
*_441.yuv
*_LOSSL*S_*.bmp
*_LOSSL*S_*.ppm
*_LOSSL*S_*.jpg
croptest.log
tjbenchtest*.log
tjexampletest*.log)

View File

@@ -0,0 +1,77 @@
if(NOT DEFINED PRECISION)
message(FATAL_ERROR "PRECISION must be specified")
endif()
if(NOT DEFINED WITH_JAVA)
message(FATAL_ERROR "WITH_JAVA must be specified")
endif()
macro(check_error program)
if(NOT RESULT EQUAL 0)
message(FATAL_ERROR "${program} failed.")
endif()
endmacro()
macro(run_test PROG ARGS)
string(REPLACE ";" " " SPACED_ARGS "${ARGS}")
message(STATUS "${PROG} ${SPACED_ARGS}")
execute_process(COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${PROG} ${ARGS}
RESULT_VARIABLE RESULT)
check_error("${PROG} ${SPACED_ARGS}")
endmacro()
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-precision;${PRECISION}")
run_test(tjbenchtest "-precision;${PRECISION};-alloc")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-precision;${PRECISION};-yuv")
run_test(tjbenchtest "-precision;${PRECISION};-yuv;-alloc")
run_test(tjbenchtest "-precision;${PRECISION};-optimize")
run_test(tjbenchtest "-precision;${PRECISION};-optimize;-yuv")
endif()
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-precision;${PRECISION};-progressive")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-precision;${PRECISION};-progressive;-yuv")
endif()
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-precision;${PRECISION};-arithmetic")
run_test(tjbenchtest "-precision;${PRECISION};-progressive;-arithmetic")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-precision;${PRECISION};-arithmetic;-yuv")
endif()
run_test(tjbenchtest "-precision;${PRECISION};-lossless")
run_test(tjbenchtest "-precision;${PRECISION};-lossless;-alloc")
if(PRECISION EQUAL 8)
run_test(tjexampletest "")
endif()
if(WITH_JAVA)
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-java;-precision;${PRECISION}")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-java;-precision;${PRECISION};-yuv")
run_test(tjbenchtest "-java;-precision;${PRECISION};-optimize")
run_test(tjbenchtest "-java;-precision;${PRECISION};-optimize;-yuv")
endif()
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-java;-precision;${PRECISION};-progressive")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-java;-precision;${PRECISION};-progressive;-yuv")
endif()
if(NOT PRECISION EQUAL 16)
run_test(tjbenchtest "-java;-precision;${PRECISION};-arithmetic")
run_test(tjbenchtest "-java;-precision;${PRECISION};-progressive;-arithmetic")
endif()
if(PRECISION EQUAL 8)
run_test(tjbenchtest "-java;-precision;${PRECISION};-arithmetic;-yuv")
endif()
run_test(tjbenchtest "-java;-precision;${PRECISION};-lossless")
if(PRECISION EQUAL 8)
run_test(tjexampletest "-java")
endif()
endif()

32
cmyk.h
View File

@@ -1,7 +1,7 @@
/*
* cmyk.h
*
* Copyright (C) 2017-2018, D. R. Commander.
* Copyright (C) 2017-2018, 2022, D. R. Commander.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
@@ -17,19 +17,19 @@
#include <jinclude.h>
#define JPEG_INTERNALS
#include <jpeglib.h>
#include "jconfigint.h"
#include "jsamplecomp.h"
/* Fully reversible */
INLINE
LOCAL(void)
rgb_to_cmyk(JSAMPLE r, JSAMPLE g, JSAMPLE b, JSAMPLE *c, JSAMPLE *m,
JSAMPLE *y, JSAMPLE *k)
rgb_to_cmyk(_JSAMPLE r, _JSAMPLE g, _JSAMPLE b,
_JSAMPLE *c, _JSAMPLE *m, _JSAMPLE *y, _JSAMPLE *k)
{
double ctmp = 1.0 - ((double)r / 255.0);
double mtmp = 1.0 - ((double)g / 255.0);
double ytmp = 1.0 - ((double)b / 255.0);
double ctmp = 1.0 - ((double)r / (double)_MAXJSAMPLE);
double mtmp = 1.0 - ((double)g / (double)_MAXJSAMPLE);
double ytmp = 1.0 - ((double)b / (double)_MAXJSAMPLE);
double ktmp = MIN(MIN(ctmp, mtmp), ytmp);
if (ktmp == 1.0) ctmp = mtmp = ytmp = 0.0;
@@ -38,10 +38,10 @@ rgb_to_cmyk(JSAMPLE r, JSAMPLE g, JSAMPLE b, JSAMPLE *c, JSAMPLE *m,
mtmp = (mtmp - ktmp) / (1.0 - ktmp);
ytmp = (ytmp - ktmp) / (1.0 - ktmp);
}
*c = (JSAMPLE)(255.0 - ctmp * 255.0 + 0.5);
*m = (JSAMPLE)(255.0 - mtmp * 255.0 + 0.5);
*y = (JSAMPLE)(255.0 - ytmp * 255.0 + 0.5);
*k = (JSAMPLE)(255.0 - ktmp * 255.0 + 0.5);
*c = (_JSAMPLE)((double)_MAXJSAMPLE - ctmp * (double)_MAXJSAMPLE + 0.5);
*m = (_JSAMPLE)((double)_MAXJSAMPLE - mtmp * (double)_MAXJSAMPLE + 0.5);
*y = (_JSAMPLE)((double)_MAXJSAMPLE - ytmp * (double)_MAXJSAMPLE + 0.5);
*k = (_JSAMPLE)((double)_MAXJSAMPLE - ktmp * (double)_MAXJSAMPLE + 0.5);
}
@@ -49,12 +49,12 @@ rgb_to_cmyk(JSAMPLE r, JSAMPLE g, JSAMPLE b, JSAMPLE *c, JSAMPLE *m,
INLINE
LOCAL(void)
cmyk_to_rgb(JSAMPLE c, JSAMPLE m, JSAMPLE y, JSAMPLE k, JSAMPLE *r, JSAMPLE *g,
JSAMPLE *b)
cmyk_to_rgb(_JSAMPLE c, _JSAMPLE m, _JSAMPLE y, _JSAMPLE k,
_JSAMPLE *r, _JSAMPLE *g, _JSAMPLE *b)
{
*r = (JSAMPLE)((double)c * (double)k / 255.0 + 0.5);
*g = (JSAMPLE)((double)m * (double)k / 255.0 + 0.5);
*b = (JSAMPLE)((double)y * (double)k / 255.0 + 0.5);
*r = (_JSAMPLE)((double)c * (double)k / (double)_MAXJSAMPLE + 0.5);
*g = (_JSAMPLE)((double)m * (double)k / (double)_MAXJSAMPLE + 0.5);
*b = (_JSAMPLE)((double)y * (double)k / (double)_MAXJSAMPLE + 0.5);
}

95
croptest.in Executable file
View File

@@ -0,0 +1,95 @@
#!/bin/bash
set -u
set -e
trap onexit INT
trap onexit TERM
trap onexit EXIT
onexit()
{
if [ -d $OUTDIR ]; then
rm -rf $OUTDIR
fi
}
runme()
{
echo \*\*\* $*
$*
}
IMAGE=vgl_6548_0026a.bmp
WIDTH=128
HEIGHT=95
IMGDIR=@CMAKE_CURRENT_SOURCE_DIR@/testimages
OUTDIR=`mktemp -d /tmp/__croptest_output.XXXXXX`
EXEDIR=@CMAKE_CURRENT_BINARY_DIR@
if [ -d $OUTDIR ]; then
rm -rf $OUTDIR
fi
mkdir -p $OUTDIR
exec >$EXEDIR/croptest.log
echo "============================================================"
echo "$IMAGE ($WIDTH x $HEIGHT)"
echo "============================================================"
echo
for PROGARG in "" -progressive; do
cp $IMGDIR/$IMAGE $OUTDIR
basename=`basename $IMAGE .bmp`
echo "------------------------------------------------------------"
echo "Generating test images"
echo "------------------------------------------------------------"
echo
runme $EXEDIR/cjpeg $PROGARG -grayscale -outfile $OUTDIR/${basename}_GRAY.jpg $IMGDIR/${basename}.bmp
runme $EXEDIR/cjpeg $PROGARG -sample 2x2 -outfile $OUTDIR/${basename}_420.jpg $IMGDIR/${basename}.bmp
runme $EXEDIR/cjpeg $PROGARG -sample 2x1 -outfile $OUTDIR/${basename}_422.jpg $IMGDIR/${basename}.bmp
runme $EXEDIR/cjpeg $PROGARG -sample 1x2 -outfile $OUTDIR/${basename}_440.jpg $IMGDIR/${basename}.bmp
runme $EXEDIR/cjpeg $PROGARG -sample 1x1 -outfile $OUTDIR/${basename}_444.jpg $IMGDIR/${basename}.bmp
echo
for NSARG in "" -nosmooth; do
for COLORSARG in "" "-colors 256 -dither none -onepass"; do
for Y in {0..16}; do
for H in {1..16}; do
X=$(( (Y*16)%128 ))
W=$(( WIDTH-X-7 ))
if [ $Y -le 15 ]; then
CROPSPEC="${W}x${H}+${X}+${Y}"
else
Y2=$(( HEIGHT-H ));
CROPSPEC="${W}x${H}+${X}+${Y2}"
fi
echo "------------------------------------------------------------"
echo $PROGARG $NSARG $COLORSARG -crop $CROPSPEC
echo "------------------------------------------------------------"
echo
for samp in GRAY 420 422 440 444; do
$EXEDIR/djpeg $NSARG $COLORSARG -rgb -outfile $OUTDIR/${basename}_${samp}_full.ppm $OUTDIR/${basename}_${samp}.jpg
convert -crop $CROPSPEC $OUTDIR/${basename}_${samp}_full.ppm $OUTDIR/${basename}_${samp}_ref.ppm
runme $EXEDIR/djpeg $NSARG $COLORSARG -crop $CROPSPEC -rgb -outfile $OUTDIR/${basename}_${samp}.ppm $OUTDIR/${basename}_${samp}.jpg
runme cmp $OUTDIR/${basename}_${samp}.ppm $OUTDIR/${basename}_${samp}_ref.ppm
done
echo
done
done
done
done
done
echo SUCCESS!

225
djpeg.1
View File

@@ -1,4 +1,4 @@
.TH DJPEG 1 "13 November 2017"
.TH DJPEG 1 "17 June 2024"
.SH NAME
djpeg \- decompress a JPEG file to an image file
.SH SYNOPSIS
@@ -15,8 +15,7 @@ djpeg \- decompress a JPEG file to an image file
.B djpeg
decompresses the named JPEG file, or the standard input if no file is named,
and produces an image file on the standard output. PBMPLUS (PPM/PGM), BMP,
GIF, Targa, or RLE (Utah Raster Toolkit) output format can be selected.
(RLE is supported only if the URT library is available.)
GIF, or Targa output format can be selected.
.SH OPTIONS
All switch names may be abbreviated; for example,
.B \-grayscale
@@ -29,47 +28,46 @@ Upper and lower case are equivalent (thus
.B \-BMP
is the same as
.BR \-bmp ).
British spellings are also accepted (e.g.,
British spellings are also accepted (e.g.
.BR \-greyscale ),
though for brevity these are not mentioned below.
.PP
The basic switches are:
.TP
.BI \-colors " N"
Reduce image to at most N colors. This reduces the number of colors used in
the output image, so that it can be displayed on a colormapped display or
stored in a colormapped file format. For example, if you have an 8-bit
display, you'd need to reduce to 256 or fewer colors.
Reduce image to at most N colors [legacy feature]. This reduces the number of
colors used in the output image so that it can be stored in a colormapped file
format. This feature cannot be used when decompressing lossless JPEG images.
.TP
.BI \-quantize " N"
Same as
.BR \-colors .
.B \-colors
is the recommended name,
is the recommended name.
.B \-quantize
is provided only for backwards compatibility.
is provided only for backward compatibility.
.TP
.B \-fast
Select recommended processing options for fast, low quality output. (The
default options are chosen for highest quality output.) Currently, this is
equivalent to \fB\-dct fast \-nosmooth \-onepass \-dither ordered\fR.
Select recommended processing options for low-quality output [legacy feature].
(The default options are chosen for highest-quality output.) Currently, this
is equivalent to \fB\-dct fast \-nosmooth \-onepass \-dither ordered\fR. On
modern CPUs, these settings have little or no performance benefit and are
retained solely for backward compatibility.
.TP
.B \-grayscale
Force grayscale output even if JPEG file is color. Useful for viewing on
monochrome displays; also,
.B djpeg
runs noticeably faster in this mode.
Force grayscale output even if JPEG file is full-color. This feature cannot be
used when decompressing full-color lossless JPEG images.
.TP
.B \-rgb
Force RGB output even if JPEG file is grayscale.
Force RGB output even if JPEG file is grayscale. This feature cannot be used
when decompressing grayscale lossless JPEG images.
.TP
.BI \-scale " M/N"
Scale the output image by a factor M/N. Currently the scale factor must be
M/8, where M is an integer between 1 and 16 inclusive, or any reduced fraction
thereof (such as 1/2, 3/4, etc.) Scaling is handy if the image is larger than
your screen; also,
.B djpeg
runs much faster when scaling down the output.
your screen. This feature cannot be used when decompressing lossless JPEG
images.
.TP
.B \-bmp
Select BMP output format (Windows flavor). 8-bit colormapped format is
@@ -78,21 +76,36 @@ emitted if
or
.B \-grayscale
is specified, or if the JPEG file is grayscale; otherwise, 24-bit full-color
format is emitted.
format is emitted. This format can only be used when decompressing
8-bit-per-sample JPEG images.
.TP
.B \-gif
Select GIF output format. Since GIF does not support more than 256 colors,
Select GIF output format (LZW-compressed) [legacy feature]. Since GIF does not
support more than 256 colors,
.B \-colors 256
is assumed (unless you specify a smaller number of colors).
is assumed (unless you specify a smaller number of colors). If you specify
.BR \-fast,
the default number of colors is 216. This format can only be used when
decompressing 8-bit-per-sample or 12-bit-per-sample lossy JPEG images.
.TP
.B \-gif0
Select GIF output format (uncompressed) [legacy feature]. Since GIF does not
support more than 256 colors,
.B \-colors 256
is assumed (unless you specify a smaller number of colors). If you specify
.BR \-fast,
the default number of colors is 216. This format can only be used when
decompressing 8-bit-per-sample or 12-bit-per-sample lossy JPEG images.
.TP
.B \-os2
Select BMP output format (OS/2 1.x flavor). 8-bit colormapped format is
emitted if
Select BMP output format (OS/2 1.x flavor) [legacy feature]. 8-bit colormapped
format is emitted if
.B \-colors
or
.B \-grayscale
is specified, or if the JPEG file is grayscale; otherwise, 24-bit full-color
format is emitted.
format is emitted. This format can only be used when decompressing
8-bit-per-sample JPEG images.
.TP
.B \-pnm
Select PBMPLUS (PPM/PGM) output format (this is the default format).
@@ -100,60 +113,66 @@ PGM is emitted if the JPEG file is grayscale or if
.B \-grayscale
is specified; otherwise PPM is emitted.
.TP
.B \-rle
Select RLE output format. (Requires URT library.)
.TP
.B \-targa
Select Targa output format. Grayscale format is emitted if the JPEG file is
grayscale or if
Select Targa output format [legacy feature]. Grayscale format is emitted if
the JPEG file is grayscale or if
.B \-grayscale
is specified; otherwise, colormapped format is emitted if
.B \-colors
is specified; otherwise, 24-bit full-color format is emitted.
is specified; otherwise, 24-bit full-color format is emitted. This format can
only be used when decompressing 8-bit-per-sample JPEG images.
.PP
Switches for advanced users:
.TP
.B \-dct int
Use integer DCT method (default).
Use accurate integer DCT method (default).
.TP
.B \-dct fast
Use fast integer DCT (less accurate).
In libjpeg-turbo, the fast method is generally about 5-15% faster than the int
method when using the x86/x86-64 SIMD extensions (results may vary with other
SIMD implementations, or when using libjpeg-turbo without SIMD extensions.) If
the JPEG image was compressed using a quality level of 85 or below, then there
should be little or no perceptible difference between the two algorithms. When
decompressing images that were compressed using quality levels above 85,
however, the difference between the fast and int methods becomes more
pronounced. With images compressed using quality=97, for instance, the fast
method incurs generally about a 4-6 dB loss (in PSNR) relative to the int
method, but this can be larger for some images. If you can avoid it, do not
use the fast method when decompressing images that were compressed using
quality levels above 97. The algorithm often degenerates for such images and
can actually produce a more lossy output image than if the JPEG image had been
compressed using lower quality levels.
Use less accurate integer DCT method [legacy feature].
When the Independent JPEG Group's software was first released in 1991, the
decompression time for a 1-megapixel JPEG image on a mainstream PC was measured
in minutes. Thus, the \fBfast\fR integer DCT algorithm provided noticeable
performance benefits. On modern CPUs running libjpeg-turbo, however, the
decompression time for a 1-megapixel JPEG image is measured in milliseconds,
and thus the performance benefits of the \fBfast\fR algorithm are much less
noticeable. On modern x86/x86-64 CPUs that support AVX2 instructions, the
\fBfast\fR and \fBint\fR methods have similar performance. On other types of
CPUs, the \fBfast\fR method is generally about 5-15% faster than the \fBint\fR
method.
If the JPEG image was compressed using a quality level of 85 or below, then
there should be little or no perceptible quality difference between the two
algorithms. When decompressing images that were compressed using quality
levels above 85, however, the difference between the \fBfast\fR and \fBint\fR
methods becomes more pronounced. With images compressed using quality=97, for
instance, the \fBfast\fR method incurs generally about a 4-6 dB loss in PSNR
relative to the \fBint\fR method, but this can be larger for some images. If
you can avoid it, do not use the \fBfast\fR method when decompressing images
that were compressed using quality levels above 97. The algorithm often
degenerates for such images and can actually produce a more lossy output image
than if the JPEG image had been compressed using lower quality levels.
.TP
.B \-dct float
Use floating-point DCT method.
The float method is mainly a legacy feature. It does not produce significantly
more accurate results than the int method, and it is much slower. The float
method may also give different results on different machines due to varying
roundoff behavior, whereas the integer methods should give the same results on
all machines.
Use floating-point DCT method [legacy feature].
The \fBfloat\fR method does not produce significantly more accurate results
than the \fBint\fR method, and it is much slower. The \fBfloat\fR method may
also give different results on different machines due to varying roundoff
behavior, whereas the integer methods should give the same results on all
machines.
.TP
.B \-dither fs
Use Floyd-Steinberg dithering in color quantization.
Use Floyd-Steinberg dithering when quantizing colors [legacy feature].
.TP
.B \-dither ordered
Use ordered dithering in color quantization.
Use ordered dithering when quantizing colors [legacy feature].
.TP
.B \-dither none
Do not use dithering in color quantization.
By default, Floyd-Steinberg dithering is applied when quantizing colors; this
is slow but usually produces the best results. Ordered dither is a compromise
between speed and quality; no dithering is fast but usually looks awful. Note
that these switches have no effect unless color quantization is being done.
Ordered dither is only available in
Do not use dithering when quantizing colors [legacy feature]. By default,
Floyd-Steinberg dithering is applied when quantizing colors. This is slower
but usually produces the best results. Ordered dithering is a compromise
between speed and quality. No dithering is faster but usually looks awful.
Note that these switches have no effect unless color quantization is being
done. Ordered dithering is only available in
.B \-onepass
mode.
.TP
@@ -161,9 +180,9 @@ mode.
Extract ICC color management profile to the specified file.
.TP
.BI \-map " file"
Quantize to the colors used in the specified image file. This is useful for
producing multiple files with identical color maps, or for forcing a
predefined set of colors to be used. The
Quantize to the colors used in the specified image file [legacy feature]. This
is useful for producing multiple files with identical color maps, or for
forcing a predefined set of colors to be used. The
.I file
must be a GIF or PPM file. This option overrides
.B \-colors
@@ -174,14 +193,14 @@ and
Use a faster, lower-quality upsampling routine.
.TP
.B \-onepass
Use one-pass instead of two-pass color quantization. The one-pass method is
faster and needs less memory, but it produces a lower-quality image.
Use one-pass instead of two-pass color quantization [legacy feature]. The
one-pass method needs less memory, but it produces a lower-quality image.
.B \-onepass
is ignored unless you also say
is ignored unless you also specify
.B \-colors
.IR N .
Also, the one-pass method is always used for grayscale output (the two-pass
method is no improvement then).
Also, the one-pass method is always used for grayscale output. (The two-pass
method has no improvement in that case.)
.TP
.BI \-maxmemory " N"
Set limit for amount of memory to use in processing large images. Value is
@@ -190,6 +209,19 @@ number. For example,
.B \-max 4m
selects 4000000 bytes. If more space is needed, an error will occur.
.TP
.BI \-maxscans " N"
Abort if the JPEG image contains more than
.I N
scans. This feature demonstrates a method by which applications can guard
against denial-of-service attacks instigated by specially-crafted malformed
JPEG images containing numerous scans with missing image data or image data
consisting only of "EOB runs" (a feature of progressive JPEG images that allows
potentially hundreds of thousands of adjoining zero-value pixels to be
represented using only a few bytes.) Attempting to decompress such malformed
JPEG images can cause excessive CPU activity, since the decompressor must fully
process each scan (even if the scan is corrupt) before it can proceed to the
next scan.
.TP
.BI \-outfile " name"
Send output image to the named file, not to standard output.
.TP
@@ -197,6 +229,9 @@ Send output image to the named file, not to standard output.
Load input file into memory before decompressing. This feature was implemented
mainly as a way of testing the in-memory source manager (jpeg_mem_src().)
.TP
.BI \-report
Report decompression progress.
.TP
.BI \-skip " Y0,Y1"
Decompress all rows of the JPEG image except those between Y0 and Y1
(inclusive.) Note that if decompression scaling is being used, then Y0 and Y1
@@ -210,6 +245,12 @@ decompression scaling is being used, then X, Y, W, and H are relative to the
scaled image dimensions. Currently this option only works with the
PBMPLUS (PPM/PGM), GIF, and Targa output formats.
.TP
.BI \-strict
Treat all warnings as fatal. This feature also demonstrates a method by which
applications can guard against attacks instigated by specially-crafted
malformed JPEG images. Enabling this option will cause the decompressor to
abort if the JPEG image contains incomplete or corrupt image data.
.TP
.B \-verbose
Enable debug printout. More
.BR \-v 's
@@ -223,42 +264,13 @@ Same as
Print version information and exit.
.SH EXAMPLES
.LP
This example decompresses the JPEG file foo.jpg, quantizes it to
256 colors, and saves the output in 8-bit BMP format in foo.bmp:
This example decompresses the JPEG file foo.jpg and saves the output in 8-bit
BMP format in foo.bmp:
.IP
.B djpeg \-colors 256 \-bmp
.B djpeg \-bmp
.I foo.jpg
.B >
.I foo.bmp
.SH HINTS
To get a quick preview of an image, use the
.B \-grayscale
and/or
.B \-scale
switches.
.B \-grayscale \-scale 1/8
is the fastest case.
.PP
Several options are available that trade off image quality to gain speed.
.B \-fast
turns on the recommended settings.
.PP
.B \-dct fast
and/or
.B \-nosmooth
gain speed at a small sacrifice in quality.
When producing a color-quantized image,
.B \-onepass \-dither ordered
is fast but much lower quality than the default behavior.
.B \-dither none
may give acceptable results in two-pass mode, but is seldom tolerable in
one-pass mode.
.PP
If you are fortunate enough to have very fast floating point hardware,
\fB\-dct float\fR may be even faster than \fB\-dct fast\fR. But on most
machines \fB\-dct float\fR is slower than \fB\-dct int\fR; in this case it is
not worth using, because its theoretical accuracy advantage is too small to be
significant in practice.
.SH ENVIRONMENT
.TP
.B JPEGMEM
@@ -287,10 +299,3 @@ Independent JPEG Group
This file was modified by The libjpeg-turbo Project to include only information
relevant to libjpeg-turbo, to wordsmith certain sections, and to describe
features not present in libjpeg.
.SH ISSUES
Support for compressed GIF output files was removed in djpeg v6b due to
concerns over the Unisys LZW patent. Although this patent expired in 2006,
djpeg still lacks compressed GIF support, for these historical reasons.
(Conversion of JPEG files to GIF is usually a bad idea anyway, since GIF is a
256-color format.) The uncompressed GIF files that djpeg generates are larger
than they should be, but they are readable by standard GIF decoders.

307
djpeg.c
View File

@@ -3,9 +3,9 @@
*
* This file was part of the Independent JPEG Group's software:
* Copyright (C) 1991-1997, Thomas G. Lane.
* Modified 2013 by Guido Vollbeding.
* Modified 2013-2019 by Guido Vollbeding.
* libjpeg-turbo Modifications:
* Copyright (C) 2010-2011, 2013-2017, D. R. Commander.
* Copyright (C) 2010-2011, 2013-2017, 2019-2020, 2022-2024, D. R. Commander.
* Copyright (C) 2015, Google, Inc.
* For conditions of distribution and use, see the accompanying README.ijg
* file.
@@ -28,26 +28,16 @@
* works regardless of which command line style is used.
*/
#ifdef _MSC_VER
#define _CRT_SECURE_NO_DEPRECATE
#endif
#include "cdjpeg.h" /* Common decls for cjpeg/djpeg applications */
#include "jversion.h" /* for version message */
#include "jconfigint.h"
#ifndef HAVE_STDLIB_H /* <stdlib.h> should declare free() */
extern void free(void *ptr);
#endif
#include <ctype.h> /* to declare isprint() */
#ifdef USE_CCOMMAND /* command-line reader for Macintosh */
#ifdef __MWERKS__
#include <SIOUX.h> /* Metrowerks needs this */
#include <console.h> /* ... and this */
#endif
#ifdef THINK_C
#include <console.h> /* Think declares it here */
#endif
#endif
/* Create the add-on message string table. */
@@ -68,10 +58,10 @@ static const char * const cdjpeg_message_table[] = {
typedef enum {
FMT_BMP, /* BMP format (Windows flavor) */
FMT_GIF, /* GIF format */
FMT_GIF, /* GIF format (LZW-compressed) */
FMT_GIF0, /* GIF format (uncompressed) */
FMT_OS2, /* BMP format (OS/2 flavor) */
FMT_PPM, /* PPM/PGM (PBMPLUS formats) */
FMT_RLE, /* RLE format */
FMT_TARGA, /* Targa format */
FMT_TIFF /* TIFF format */
} IMAGE_FORMATS;
@@ -94,11 +84,14 @@ static IMAGE_FORMATS requested_fmt;
static const char *progname; /* program name for error messages */
static char *icc_filename; /* for -icc switch */
static JDIMENSION max_scans; /* for -maxscans switch */
static char *outfilename; /* for -outfile switch */
boolean memsrc; /* for -memsrc switch */
boolean skip, crop;
JDIMENSION skip_start, skip_end;
JDIMENSION crop_x, crop_y, crop_width, crop_height;
static boolean memsrc; /* for -memsrc switch */
static boolean report; /* for -report switch */
static boolean skip, crop;
static JDIMENSION skip_start, skip_end;
static JDIMENSION crop_x, crop_y, crop_width, crop_height;
static boolean strict; /* for -strict switch */
#define INPUT_BUF_SIZE 4096
@@ -114,8 +107,8 @@ usage(void)
#endif
fprintf(stderr, "Switches (names may be abbreviated):\n");
fprintf(stderr, " -colors N Reduce image to no more than N colors\n");
fprintf(stderr, " -fast Fast, low-quality processing\n");
fprintf(stderr, " -colors N Reduce image to no more than N colors [legacy feature]\n");
fprintf(stderr, " -fast Low-quality processing [legacy feature]\n");
fprintf(stderr, " -grayscale Force grayscale output\n");
fprintf(stderr, " -rgb Force RGB output\n");
fprintf(stderr, " -rgb565 Force RGB565 output\n");
@@ -127,58 +120,58 @@ usage(void)
(DEFAULT_FMT == FMT_BMP ? " (default)" : ""));
#endif
#ifdef GIF_SUPPORTED
fprintf(stderr, " -gif Select GIF output format%s\n",
fprintf(stderr, " -gif Select GIF output format (LZW-compressed)%s [legacy feature]\n",
(DEFAULT_FMT == FMT_GIF ? " (default)" : ""));
fprintf(stderr, " -gif0 Select GIF output format (uncompressed)%s [legacy feature]\n",
(DEFAULT_FMT == FMT_GIF0 ? " (default)" : ""));
#endif
#ifdef BMP_SUPPORTED
fprintf(stderr, " -os2 Select BMP output format (OS/2 style)%s\n",
fprintf(stderr, " -os2 Select BMP output format (OS/2 style)%s [legacy feature]\n",
(DEFAULT_FMT == FMT_OS2 ? " (default)" : ""));
#endif
#ifdef PPM_SUPPORTED
fprintf(stderr, " -pnm Select PBMPLUS (PPM/PGM) output format%s\n",
(DEFAULT_FMT == FMT_PPM ? " (default)" : ""));
#endif
#ifdef RLE_SUPPORTED
fprintf(stderr, " -rle Select Utah RLE output format%s\n",
(DEFAULT_FMT == FMT_RLE ? " (default)" : ""));
#endif
#ifdef TARGA_SUPPORTED
fprintf(stderr, " -targa Select Targa output format%s\n",
fprintf(stderr, " -targa Select Targa output format%s [legacy feature]\n",
(DEFAULT_FMT == FMT_TARGA ? " (default)" : ""));
#endif
fprintf(stderr, "Switches for advanced users:\n");
#ifdef DCT_ISLOW_SUPPORTED
fprintf(stderr, " -dct int Use integer DCT method%s\n",
fprintf(stderr, " -dct int Use accurate integer DCT method%s\n",
(JDCT_DEFAULT == JDCT_ISLOW ? " (default)" : ""));
#endif
#ifdef DCT_IFAST_SUPPORTED
fprintf(stderr, " -dct fast Use fast integer DCT (less accurate)%s\n",
fprintf(stderr, " -dct fast Use less accurate integer DCT method [legacy feature]%s\n",
(JDCT_DEFAULT == JDCT_IFAST ? " (default)" : ""));
#endif
#ifdef DCT_FLOAT_SUPPORTED
fprintf(stderr, " -dct float Use floating-point DCT method%s\n",
fprintf(stderr, " -dct float Use floating-point DCT method [legacy feature]%s\n",
(JDCT_DEFAULT == JDCT_FLOAT ? " (default)" : ""));
#endif
fprintf(stderr, " -dither fs Use F-S dithering (default)\n");
fprintf(stderr, " -dither none Don't use dithering in quantization\n");
fprintf(stderr, " -dither ordered Use ordered dither (medium speed, quality)\n");
fprintf(stderr, " -dither fs Use Floyd-Steinberg dithering when quantizing colors (default)\n");
fprintf(stderr, " [legacy feature]\n");
fprintf(stderr, " -dither none Don't use dithering when quantizing colors [legacy feature]\n");
fprintf(stderr, " -dither ordered Use ordered dithering when quantizing colors\n");
fprintf(stderr, " [legacy feature]\n");
fprintf(stderr, " -icc FILE Extract ICC profile to FILE\n");
#ifdef QUANT_2PASS_SUPPORTED
fprintf(stderr, " -map FILE Map to colors used in named image file\n");
fprintf(stderr, " -map FILE Quantize to colors used in named image file [legacy feature]\n");
#endif
fprintf(stderr, " -nosmooth Don't use high-quality upsampling\n");
fprintf(stderr, " -nosmooth Use faster, lower-quality upsampling\n");
#ifdef QUANT_1PASS_SUPPORTED
fprintf(stderr, " -onepass Use 1-pass quantization (fast, low quality)\n");
fprintf(stderr, " -onepass Use 1-pass color quantization (low quality) [legacy feature]\n");
#endif
fprintf(stderr, " -maxmemory N Maximum memory to use (in kbytes)\n");
fprintf(stderr, " -maxscans N Maximum number of scans to allow in input file\n");
fprintf(stderr, " -outfile name Specify name for output file\n");
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
fprintf(stderr, " -memsrc Load input file into memory before decompressing\n");
#endif
fprintf(stderr, " -report Report decompression progress\n");
fprintf(stderr, " -skip Y0,Y1 Decompress all rows except those between Y0 and Y1 (inclusive)\n");
fprintf(stderr, " -crop WxH+X+Y Decompress only a rectangular subregion of the image\n");
fprintf(stderr, " [requires PBMPLUS (PPM/PGM), GIF, or Targa output format]\n");
fprintf(stderr, " -strict Treat all warnings as fatal\n");
fprintf(stderr, " -verbose or -debug Emit debug output\n");
fprintf(stderr, " -version Print version information and exit\n");
exit(EXIT_FAILURE);
@@ -203,10 +196,13 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
/* Set up default JPEG parameters. */
requested_fmt = DEFAULT_FMT; /* set default output file format */
icc_filename = NULL;
max_scans = 0;
outfilename = NULL;
memsrc = FALSE;
report = FALSE;
skip = FALSE;
crop = FALSE;
strict = FALSE;
cinfo->err->trace_level = 0;
/* Scan command line options, adjust parameters */
@@ -224,7 +220,7 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
arg++; /* advance past switch marker character */
if (keymatch(arg, "bmp", 1)) {
/* BMP output format. */
/* BMP output format (Windows flavor). */
requested_fmt = FMT_BMP;
} else if (keymatch(arg, "colors", 1) || keymatch(arg, "colours", 1) ||
@@ -273,7 +269,8 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
if (!printed_version) {
fprintf(stderr, "%s version %s (build %s)\n",
PACKAGE_NAME, VERSION, BUILD);
fprintf(stderr, "%s\n\n", JCOPYRIGHT);
fprintf(stderr, JCOPYRIGHT1);
fprintf(stderr, JCOPYRIGHT2 "\n");
fprintf(stderr, "Emulating The Independent JPEG Group's software, version %s\n\n",
JVERSION);
printed_version = TRUE;
@@ -295,9 +292,13 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
cinfo->do_fancy_upsampling = FALSE;
} else if (keymatch(arg, "gif", 1)) {
/* GIF output format. */
/* GIF output format (LZW-compressed). */
requested_fmt = FMT_GIF;
} else if (keymatch(arg, "gif0", 4)) {
/* GIF output format (uncompressed). */
requested_fmt = FMT_GIF0;
} else if (keymatch(arg, "grayscale", 2) ||
keymatch(arg, "greyscale", 2)) {
/* Force monochrome output. */
@@ -316,7 +317,9 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
if (++argn >= argc) /* advance to next argument */
usage();
icc_filename = argv[argn];
#ifdef SAVE_MARKERS_SUPPORTED
jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF);
#endif
} else if (keymatch(arg, "map", 3)) {
/* Quantize to a color map taken from an input file. */
@@ -330,6 +333,9 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
fprintf(stderr, "%s: can't open %s\n", progname, argv[argn]);
exit(EXIT_FAILURE);
}
if (cinfo->data_precision == 12)
read_color_map_12(cinfo, mapfile);
else
read_color_map(cinfo, mapfile);
fclose(mapfile);
cinfo->quantize_colors = TRUE;
@@ -351,6 +357,12 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
lval *= 1000L;
cinfo->mem->max_memory_to_use = lval * 1000L;
} else if (keymatch(arg, "maxscans", 4)) {
if (++argn >= argc) /* advance to next argument */
usage();
if (sscanf(argv[argn], "%u", &max_scans) != 1)
usage();
} else if (keymatch(arg, "nosmooth", 3)) {
/* Suppress fancy upsampling */
cinfo->do_fancy_upsampling = FALSE;
@@ -371,23 +383,16 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
} else if (keymatch(arg, "memsrc", 2)) {
/* Use in-memory source manager */
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
memsrc = TRUE;
#else
fprintf(stderr, "%s: sorry, in-memory source manager was not compiled in\n",
progname);
exit(EXIT_FAILURE);
#endif
} else if (keymatch(arg, "pnm", 1) || keymatch(arg, "ppm", 1)) {
/* PPM/PGM output format. */
requested_fmt = FMT_PPM;
} else if (keymatch(arg, "rle", 1)) {
/* RLE output format. */
requested_fmt = FMT_RLE;
} else if (keymatch(arg, "report", 2)) {
report = TRUE;
} else if (keymatch(arg, "scale", 2)) {
} else if (keymatch(arg, "scale", 1)) {
/* Scale the output image by a fraction M/N. */
if (++argn >= argc) /* advance to next argument */
usage();
@@ -396,22 +401,34 @@ parse_switches(j_decompress_ptr cinfo, int argc, char **argv,
usage();
} else if (keymatch(arg, "skip", 2)) {
int temp_start = -1, temp_end = -1;
if (++argn >= argc)
usage();
if (sscanf(argv[argn], "%u,%u", &skip_start, &skip_end) != 2 ||
skip_start > skip_end)
if (sscanf(argv[argn], "%d,%d", &temp_start, &temp_end) != 2 ||
temp_start < 0 || temp_end < 0 || temp_start > temp_end)
usage();
skip = TRUE;
skip_start = temp_start;
skip_end = temp_end;
} else if (keymatch(arg, "crop", 2)) {
int temp_width = -1, temp_height = -1, temp_x = -1, temp_y = -1;
char c;
if (++argn >= argc)
usage();
if (sscanf(argv[argn], "%u%c%u+%u+%u", &crop_width, &c, &crop_height,
&crop_x, &crop_y) != 5 ||
(c != 'X' && c != 'x') || crop_width < 1 || crop_height < 1)
if (sscanf(argv[argn], "%d%c%d+%d+%d", &temp_width, &c, &temp_height,
&temp_x, &temp_y) != 5 ||
(c != 'X' && c != 'x') || temp_width < 1 || temp_height < 1 ||
temp_x < 0 || temp_y < 0)
usage();
crop = TRUE;
crop_width = temp_width;
crop_height = temp_height;
crop_x = temp_x;
crop_y = temp_y;
} else if (keymatch(arg, "strict", 2)) {
strict = TRUE;
} else if (keymatch(arg, "targa", 1)) {
/* Targa output format. */
@@ -444,7 +461,7 @@ jpeg_getc(j_decompress_ptr cinfo)
ERREXIT(cinfo, JERR_CANT_SUSPEND);
}
datasrc->bytes_in_buffer--;
return GETJOCTET(*datasrc->next_input_byte++);
return *datasrc->next_input_byte++;
}
@@ -499,6 +516,19 @@ print_text_marker(j_decompress_ptr cinfo)
}
METHODDEF(void)
my_emit_message(j_common_ptr cinfo, int msg_level)
{
if (msg_level < 0) {
/* Treat warning as fatal */
cinfo->err->error_exit(cinfo);
} else {
if (cinfo->err->trace_level >= msg_level)
cinfo->err->output_message(cinfo);
}
}
/*
* The main program.
*/
@@ -508,24 +538,15 @@ main(int argc, char **argv)
{
struct jpeg_decompress_struct cinfo;
struct jpeg_error_mgr jerr;
#ifdef PROGRESS_REPORT
struct cdjpeg_progress_mgr progress;
#endif
int file_index;
djpeg_dest_ptr dest_mgr = NULL;
FILE *input_file;
FILE *output_file;
unsigned char *inbuffer = NULL;
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
unsigned long insize = 0;
#endif
JDIMENSION num_scanlines;
/* On Mac, fetch a command line. */
#ifdef USE_CCOMMAND
argc = ccommand(&argv);
#endif
progname = argv[0];
if (progname == NULL || progname[0] == 0)
progname = "djpeg"; /* in case C library doesn't provide it */
@@ -557,6 +578,9 @@ main(int argc, char **argv)
file_index = parse_switches(&cinfo, argc, argv, 0, FALSE);
if (strict)
jerr.emit_message = my_emit_message;
#ifdef TWO_FILE_COMMANDLINE
/* Must have either -outfile switch or explicit output file name */
if (outfilename == NULL) {
@@ -603,12 +627,13 @@ main(int argc, char **argv)
output_file = write_stdout();
}
#ifdef PROGRESS_REPORT
if (report || max_scans != 0) {
start_progress_monitor((j_common_ptr)&cinfo, &progress);
#endif
progress.report = report;
progress.max_scans = max_scans;
}
/* Specify data source for decompression */
#if JPEG_LIB_VERSION >= 80 || defined(MEM_SRCDST_SUPPORTED)
if (memsrc) {
size_t nbytes;
do {
@@ -617,7 +642,7 @@ main(int argc, char **argv)
fprintf(stderr, "%s: memory allocation failure\n", progname);
exit(EXIT_FAILURE);
}
nbytes = JFREAD(input_file, &inbuffer[insize], INPUT_BUF_SIZE);
nbytes = fread(&inbuffer[insize], 1, INPUT_BUF_SIZE, input_file);
if (nbytes < INPUT_BUF_SIZE && ferror(input_file)) {
if (file_index < argc)
fprintf(stderr, "%s: can't read from %s\n", progname,
@@ -630,7 +655,6 @@ main(int argc, char **argv)
fprintf(stderr, "Compressed size: %lu bytes\n", insize);
jpeg_mem_src(&cinfo, inbuffer, insize);
} else
#endif
jpeg_stdio_src(&cinfo, input_file);
/* Read file header, set default decompression parameters */
@@ -653,17 +677,29 @@ main(int argc, char **argv)
#endif
#ifdef GIF_SUPPORTED
case FMT_GIF:
dest_mgr = jinit_write_gif(&cinfo);
if (cinfo.data_precision == 16)
ERREXIT1(&cinfo, JERR_BAD_PRECISION, cinfo.data_precision);
else if (cinfo.data_precision == 12)
dest_mgr = j12init_write_gif(&cinfo, TRUE);
else
dest_mgr = jinit_write_gif(&cinfo, TRUE);
break;
case FMT_GIF0:
dest_mgr = jinit_write_gif(&cinfo, FALSE);
break;
#endif
#ifdef PPM_SUPPORTED
case FMT_PPM:
dest_mgr = jinit_write_ppm(&cinfo);
break;
if (cinfo.data_precision == 16)
#ifdef D_LOSSLESS_SUPPORTED
dest_mgr = j16init_write_ppm(&cinfo);
#else
ERREXIT1(&cinfo, JERR_BAD_PRECISION, cinfo.data_precision);
#endif
#ifdef RLE_SUPPORTED
case FMT_RLE:
dest_mgr = jinit_write_rle(&cinfo);
else if (cinfo.data_precision == 12)
dest_mgr = j12init_write_ppm(&cinfo);
else
dest_mgr = jinit_write_ppm(&cinfo);
break;
#endif
#ifdef TARGA_SUPPORTED
@@ -689,7 +725,7 @@ main(int argc, char **argv)
* that skip_start <= skip_end.
*/
if (skip_end > cinfo.output_height - 1) {
fprintf(stderr, "%s: skip region exceeds image height %d\n", progname,
fprintf(stderr, "%s: skip region exceeds image height %u\n", progname,
cinfo.output_height);
exit(EXIT_FAILURE);
}
@@ -702,18 +738,45 @@ main(int argc, char **argv)
(*dest_mgr->start_output) (&cinfo, dest_mgr);
cinfo.output_height = tmp;
if (cinfo.data_precision == 16)
ERREXIT(&cinfo, JERR_NOTIMPL);
else if (cinfo.data_precision == 12) {
/* Process data */
while (cinfo.output_scanline < skip_start) {
num_scanlines = jpeg12_read_scanlines(&cinfo, dest_mgr->buffer12,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
if ((tmp = jpeg12_skip_scanlines(&cinfo, skip_end - skip_start + 1)) !=
skip_end - skip_start + 1) {
fprintf(stderr, "%s: jpeg12_skip_scanlines() returned %u rather than %u\n",
progname, tmp, skip_end - skip_start + 1);
exit(EXIT_FAILURE);
}
while (cinfo.output_scanline < cinfo.output_height) {
num_scanlines = jpeg12_read_scanlines(&cinfo, dest_mgr->buffer12,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
} else {
/* Process data */
while (cinfo.output_scanline < skip_start) {
num_scanlines = jpeg_read_scanlines(&cinfo, dest_mgr->buffer,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
jpeg_skip_scanlines(&cinfo, skip_end - skip_start + 1);
if ((tmp = jpeg_skip_scanlines(&cinfo, skip_end - skip_start + 1)) !=
skip_end - skip_start + 1) {
fprintf(stderr, "%s: jpeg_skip_scanlines() returned %u rather than %u\n",
progname, tmp, skip_end - skip_start + 1);
exit(EXIT_FAILURE);
}
while (cinfo.output_scanline < cinfo.output_height) {
num_scanlines = jpeg_read_scanlines(&cinfo, dest_mgr->buffer,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
}
/* Decompress a subregion */
} else if (crop) {
@@ -722,13 +785,18 @@ main(int argc, char **argv)
/* Check for valid crop dimensions. We cannot check these values until
* after jpeg_start_decompress() is called.
*/
if (crop_x + crop_width > cinfo.output_width ||
crop_y + crop_height > cinfo.output_height) {
fprintf(stderr, "%s: crop dimensions exceed image dimensions %d x %d\n",
if ((unsigned long long)crop_x + crop_width > cinfo.output_width ||
(unsigned long long)crop_y + crop_height > cinfo.output_height) {
fprintf(stderr, "%s: crop dimensions exceed image dimensions %u x %u\n",
progname, cinfo.output_width, cinfo.output_height);
exit(EXIT_FAILURE);
}
if (cinfo.data_precision == 16)
ERREXIT(&cinfo, JERR_NOTIMPL);
else if (cinfo.data_precision == 12)
jpeg12_crop_scanline(&cinfo, &crop_x, &crop_width);
else
jpeg_crop_scanline(&cinfo, &crop_x, &crop_width);
if (dest_mgr->calc_buffer_dimensions)
(*dest_mgr->calc_buffer_dimensions) (&cinfo, dest_mgr);
@@ -743,20 +811,74 @@ main(int argc, char **argv)
(*dest_mgr->start_output) (&cinfo, dest_mgr);
cinfo.output_height = tmp;
if (cinfo.data_precision == 16)
ERREXIT(&cinfo, JERR_NOTIMPL);
else if (cinfo.data_precision == 12) {
/* Process data */
jpeg_skip_scanlines(&cinfo, crop_y);
if ((tmp = jpeg12_skip_scanlines(&cinfo, crop_y)) != crop_y) {
fprintf(stderr, "%s: jpeg12_skip_scanlines() returned %u rather than %u\n",
progname, tmp, crop_y);
exit(EXIT_FAILURE);
}
while (cinfo.output_scanline < crop_y + crop_height) {
num_scanlines = jpeg12_read_scanlines(&cinfo, dest_mgr->buffer12,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
if ((tmp =
jpeg12_skip_scanlines(&cinfo, cinfo.output_height - crop_y -
crop_height)) !=
cinfo.output_height - crop_y - crop_height) {
fprintf(stderr, "%s: jpeg12_skip_scanlines() returned %u rather than %u\n",
progname, tmp, cinfo.output_height - crop_y - crop_height);
exit(EXIT_FAILURE);
}
} else {
/* Process data */
if ((tmp = jpeg_skip_scanlines(&cinfo, crop_y)) != crop_y) {
fprintf(stderr, "%s: jpeg_skip_scanlines() returned %u rather than %u\n",
progname, tmp, crop_y);
exit(EXIT_FAILURE);
}
while (cinfo.output_scanline < crop_y + crop_height) {
num_scanlines = jpeg_read_scanlines(&cinfo, dest_mgr->buffer,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
jpeg_skip_scanlines(&cinfo, cinfo.output_height - crop_y - crop_height);
if ((tmp =
jpeg_skip_scanlines(&cinfo,
cinfo.output_height - crop_y - crop_height)) !=
cinfo.output_height - crop_y - crop_height) {
fprintf(stderr, "%s: jpeg_skip_scanlines() returned %u rather than %u\n",
progname, tmp, cinfo.output_height - crop_y - crop_height);
exit(EXIT_FAILURE);
}
}
/* Normal full-image decompress */
} else {
/* Write output file header */
(*dest_mgr->start_output) (&cinfo, dest_mgr);
if (cinfo.data_precision == 16) {
#ifdef D_LOSSLESS_SUPPORTED
/* Process data */
while (cinfo.output_scanline < cinfo.output_height) {
num_scanlines = jpeg16_read_scanlines(&cinfo, dest_mgr->buffer16,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
#else
ERREXIT1(&cinfo, JERR_BAD_PRECISION, cinfo.data_precision);
#endif
} else if (cinfo.data_precision == 12) {
/* Process data */
while (cinfo.output_scanline < cinfo.output_height) {
num_scanlines = jpeg12_read_scanlines(&cinfo, dest_mgr->buffer12,
dest_mgr->buffer_height);
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
} else {
/* Process data */
while (cinfo.output_scanline < cinfo.output_height) {
num_scanlines = jpeg_read_scanlines(&cinfo, dest_mgr->buffer,
@@ -764,13 +886,13 @@ main(int argc, char **argv)
(*dest_mgr->put_pixel_rows) (&cinfo, dest_mgr, num_scanlines);
}
}
}
#ifdef PROGRESS_REPORT
/* Hack: count final pass as done in case finish_output does an extra pass.
* The library won't have updated completed_passes.
*/
if (report || max_scans != 0)
progress.pub.completed_passes = progress.pub.total_passes;
#endif
if (icc_filename != NULL) {
FILE *icc_file;
@@ -809,9 +931,8 @@ main(int argc, char **argv)
if (output_file != stdout)
fclose(output_file);
#ifdef PROGRESS_REPORT
if (report || max_scans != 0)
end_progress_monitor((j_common_ptr)&cinfo);
#endif
if (memsrc)
free(inbuffer);

View File

@@ -1,18 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TurboJPEG: Data Structures</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
@@ -21,10 +20,9 @@
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
<tr id="projectrow">
<td id="projectalign">
<div id="projectname">TurboJPEG<span id="projectnumber">&#160;3.0.1</span>
</div>
</td>
</tr>
@@ -32,73 +30,60 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<!-- Generated by Doxygen 1.9.8 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li class="current"><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<div id="navrow2" class="tabs2">
<ul class="tablist">
<li class="current"><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li><a href="classes.html"><span>Data&#160;Structure&#160;Index</span></a></li>
<li><a href="functions.html"><span>Data&#160;Fields</span></a></li>
</ul>
</div>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
initMenu('',true,false,'search.php','Search');
$(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Data Structures</div> </div>
<div class="headertitle"><div class="title">Data Structures</div></div>
</div><!--header-->
<div class="contents">
<div class="textblock">Here are the data structures with brief descriptions:</div><div class="directory">
<table class="directory">
<tr id="row_0_" class="even"><td class="entry"><img src="ftv2node.png" alt="o" width="16" height="22" /><img src="ftv2cl.png" alt="C" width="24" height="22" /><a class="el" href="structtjregion.html" target="_self">tjregion</a></td><td class="desc">Cropping region</td></tr>
<tr id="row_1_"><td class="entry"><img src="ftv2node.png" alt="o" width="16" height="22" /><img src="ftv2cl.png" alt="C" width="24" height="22" /><a class="el" href="structtjscalingfactor.html" target="_self">tjscalingfactor</a></td><td class="desc">Scaling factor</td></tr>
<tr id="row_2_" class="even"><td class="entry"><img src="ftv2lastnode.png" alt="\" width="16" height="22" /><img src="ftv2cl.png" alt="C" width="24" height="22" /><a class="el" href="structtjtransform.html" target="_self">tjtransform</a></td><td class="desc">Lossless transform</td></tr>
<tr id="row_0_" class="even"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><span class="icona"><span class="icon">C</span></span><a class="el" href="structtjregion.html" target="_self">tjregion</a></td><td class="desc">Cropping region </td></tr>
<tr id="row_1_" class="odd"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><span class="icona"><span class="icon">C</span></span><a class="el" href="structtjscalingfactor.html" target="_self">tjscalingfactor</a></td><td class="desc">Scaling factor </td></tr>
<tr id="row_2_" class="even"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><span class="icona"><span class="icon">C</span></span><a class="el" href="structtjtransform.html" target="_self">tjtransform</a></td><td class="desc">Lossless transform </td></tr>
</table>
</div><!-- directory -->
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.8
</small></address>
</body>
</html>

BIN
doc/html/bc_sd.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 635 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 147 B

View File

@@ -1,18 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TurboJPEG: Data Structure Index</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
@@ -21,10 +20,9 @@
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
<tr id="projectrow">
<td id="projectalign">
<div id="projectname">TurboJPEG<span id="projectnumber">&#160;3.0.1</span>
</div>
</td>
</tr>
@@ -32,75 +30,59 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<!-- Generated by Doxygen 1.9.8 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li class="current"><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<div id="navrow2" class="tabs2">
<ul class="tablist">
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li class="current"><a href="classes.html"><span>Data&#160;Structure&#160;Index</span></a></li>
<li><a href="functions.html"><span>Data&#160;Fields</span></a></li>
</ul>
</div>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
initMenu('',true,false,'search.php','Search');
$(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Data Structure Index</div> </div>
<div class="headertitle"><div class="title">Data Structure Index</div></div>
</div><!--header-->
<div class="contents">
<div class="qindex"><a class="qindex" href="#letter_T">T</a></div>
<table style="margin: 10px; white-space: nowrap;" align="center" width="95%" border="0" cellspacing="0" cellpadding="0">
<tr><td rowspan="2" valign="bottom"><a name="letter_T"></a><table border="0" cellspacing="0" cellpadding="0"><tr><td><div class="ah">&#160;&#160;T&#160;&#160;</div></td></tr></table>
</td><td valign="top"><a class="el" href="structtjscalingfactor.html">tjscalingfactor</a>&#160;&#160;&#160;</td><td valign="top"><a class="el" href="structtjtransform.html">tjtransform</a>&#160;&#160;&#160;</td><td></td></tr>
<tr><td></td><td></td><td></td></tr>
<tr><td valign="top"><a class="el" href="structtjregion.html">tjregion</a>&#160;&#160;&#160;</td><td></td><td></td><td></td></tr>
<tr><td></td><td></td><td></td><td></td></tr>
</table>
<div class="qindex"><a class="qindex" href="#letter_T">T</a></div>
<div class="classindex">
<dl class="classindex even">
<dt class="alphachar"><a id="letter_T" name="letter_T">T</a></dt>
<dd><a class="el" href="structtjregion.html">tjregion</a></dd><dd><a class="el" href="structtjscalingfactor.html">tjscalingfactor</a></dd><dd><a class="el" href="structtjtransform.html">tjtransform</a></dd></dl>
</div>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.8
</small></address>
</body>
</html>

12
doc/html/doc.svg Normal file
View File

@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 80 60" id="doc" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#4665A2">
<path d="m 14,-1.1445312 c -2.824372,0 -5.1445313,2.320159 -5.1445312,5.1445312 v 72 c 0,2.824372 2.3201592,5.144531 5.1445312,5.144531 h 52 c 2.824372,0 5.144531,-2.320159 5.144531,-5.144531 V 23.699219 a 1.1447968,1.1447968 0 0 0 -0.01563,-0.1875 C 70.977847,22.605363 70.406495,21.99048 70.007812,21.591797 L 48.208984,-0.20898438 C 47.606104,-0.81186474 46.804652,-1.1445313 46,-1.1445312 Z m 1.144531,6.2890624 H 42.855469 V 24 c 0,1.724372 1.420159,3.144531 3.144531,3.144531 H 64.855469 V 74.855469 H 15.144531 Z m 34,4.4179688 L 60.4375,20.855469 H 49.144531 Z"/>
</g>
<g style="fill:#D8DFEE;stroke-width:0">
<path d="M 3.0307167,13.993174 V 7.0307167 h 2.7576792 2.7576792 v 1.8826151 c 0,1.2578262 0.0099,1.9287572 0.029818,2.0216512 0.03884,0.181105 0.168631,0.348218 0.33827,0.43554 l 0.1355017,0.06975 1.9598092,0.0079 1.959809,0.0078 v 4.749829 4.749829 H 8 3.0307167 Z" transform="matrix(5,0,0,5,0,-30)" />
<path d="M 9.8293515,9.0581469 V 7.9456453 l 1.1058025,1.1055492 c 0.608191,0.6080521 1.105802,1.1086775 1.105802,1.1125015 0,0.0038 -0.497611,0.007 -1.105802,0.007 H 9.8293515 Z" transform="matrix(5,0,0,5,0,-30)" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 1.5 KiB

12
doc/html/docd.svg Normal file
View File

@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 80 60" id="doc" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#C4CFE5">
<path d="m 14,-1.1445312 c -2.824372,0 -5.1445313,2.320159 -5.1445312,5.1445312 v 72 c 0,2.824372 2.3201592,5.144531 5.1445312,5.144531 h 52 c 2.824372,0 5.144531,-2.320159 5.144531,-5.144531 V 23.699219 a 1.1447968,1.1447968 0 0 0 -0.01563,-0.1875 C 70.977847,22.605363 70.406495,21.99048 70.007812,21.591797 L 48.208984,-0.20898438 C 47.606104,-0.81186474 46.804652,-1.1445313 46,-1.1445312 Z m 1.144531,6.2890624 H 42.855469 V 24 c 0,1.724372 1.420159,3.144531 3.144531,3.144531 H 64.855469 V 74.855469 H 15.144531 Z m 34,4.4179688 L 60.4375,20.855469 H 49.144531 Z"/>
</g>
<g style="fill:#4665A2;stroke-width:0">
<path d="M 3.0307167,13.993174 V 7.0307167 h 2.7576792 2.7576792 v 1.8826151 c 0,1.2578262 0.0099,1.9287572 0.029818,2.0216512 0.03884,0.181105 0.168631,0.348218 0.33827,0.43554 l 0.1355017,0.06975 1.9598092,0.0079 1.959809,0.0078 v 4.749829 4.749829 H 8 3.0307167 Z" transform="matrix(5,0,0,5,0,-30)" />
<path d="M 9.8293515,9.0581469 V 7.9456453 l 1.1058025,1.1055492 c 0.608191,0.6080521 1.105802,1.1086775 1.105802,1.1125015 0,0.0038 -0.497611,0.007 -1.105802,0.007 H 9.8293515 Z" transform="matrix(5,0,0,5,0,-30)" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 1.5 KiB

View File

@@ -1,3 +1,7 @@
code {
color: #4665A2;
}
th.markdownTableHeadNone {
color: black;
}

File diff suppressed because it is too large Load Diff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.7 KiB

28
doc/html/doxygen.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 15 KiB

View File

@@ -1,3 +1,27 @@
/*
@licstart The following is the entire license notice for the JavaScript code in this file.
The MIT License (MIT)
Copyright (C) 1997-2020 by Dimitri van Heesch
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@licend The above is the entire license notice for the JavaScript code in this file
*/
function toggleVisibility(linkObj)
{
var base = $(linkObj).attr('id');
@@ -23,7 +47,10 @@ function updateStripes()
{
$('table.directory tr').
removeClass('even').filter(':visible:even').addClass('even');
$('table.directory tr').
removeClass('odd').filter(':visible:odd').addClass('odd');
}
function toggleLevel(level)
{
$('table.directory tr').each(function() {
@@ -31,12 +58,12 @@ function toggleLevel(level)
var i = $('#img'+this.id.substring(3));
var a = $('#arr'+this.id.substring(3));
if (l<level+1) {
i.attr('src','ftv2folderopen.png');
a.attr('src','ftv2mnode.png');
i.removeClass('iconfopen iconfclosed').addClass('iconfopen');
a.html('&#9660;');
$(this).show();
} else if (l==level+1) {
i.attr('src','ftv2folderclosed.png');
a.attr('src','ftv2pnode.png');
i.removeClass('iconfclosed iconfopen').addClass('iconfclosed');
a.html('&#9658;');
$(this).show();
} else {
$(this).hide();
@@ -47,34 +74,33 @@ function toggleLevel(level)
function toggleFolder(id)
{
//The clicked row
// the clicked row
var currentRow = $('#row_'+id);
var currentRowImages = currentRow.find("img");
//All rows after the clicked row
// all rows after the clicked row
var rows = currentRow.nextAll("tr");
//Only match elements AFTER this one (can't hide elements before)
var childRows = rows.filter(function() {
var re = new RegExp('^row_'+id+'\\d+_$', "i"); //only one sub
return this.id.match(re);
});
//First row is visible we are HIDING
// only match elements AFTER this one (can't hide elements before)
var childRows = rows.filter(function() { return this.id.match(re); });
// first row is visible we are HIDING
if (childRows.filter(':first').is(':visible')===true) {
currentRowImages.filter("[id^=arr]").attr('src', 'ftv2pnode.png');
currentRowImages.filter("[id^=img]").attr('src', 'ftv2folderclosed.png');
rows.filter("[id^=row_"+id+"]").hide();
} else { //We are SHOWING
//All sub images
var childImages = childRows.find("img");
var childImg = childImages.filter("[id^=img]");
var childArr = childImages.filter("[id^=arr]");
currentRow.find("[id^=arr]").attr('src', 'ftv2mnode.png'); //open row
currentRow.find("[id^=img]").attr('src', 'ftv2folderopen.png'); //open row
childImg.attr('src','ftv2folderclosed.png'); //children closed
childArr.attr('src','ftv2pnode.png'); //children closed
// replace down arrow by right arrow for current row
var currentRowSpans = currentRow.find("span");
currentRowSpans.filter(".iconfopen").removeClass("iconfopen").addClass("iconfclosed");
currentRowSpans.filter(".arrow").html('&#9658;');
rows.filter("[id^=row_"+id+"]").hide(); // hide all children
} else { // we are SHOWING
// replace right arrow by down arrow for current row
var currentRowSpans = currentRow.find("span");
currentRowSpans.filter(".iconfclosed").removeClass("iconfclosed").addClass("iconfopen");
currentRowSpans.filter(".arrow").html('&#9660;');
// replace down arrows by right arrows for child rows
var childRowsSpans = childRows.find("span");
childRowsSpans.filter(".iconfopen").removeClass("iconfopen").addClass("iconfclosed");
childRowsSpans.filter(".arrow").html('&#9658;');
childRows.show(); //show all children
}
updateStripes();
@@ -95,3 +121,72 @@ function toggleInherit(id)
}
}
var opened=true;
// in case HTML_COLORSTYLE is LIGHT or DARK the vars will be replaced, so we write them out explicitly and use double quotes
var plusImg = [ "var(--fold-plus-image)", "var(--fold-plus-image-relpath)" ];
var minusImg = [ "var(--fold-minus-image)", "var(--fold-minus-image-relpath)" ];
// toggle all folding blocks
function codefold_toggle_all(relPath) {
if (opened) {
$('#fold_all').css('background-image',plusImg[relPath]);
$('div[id^=foldopen]').hide();
$('div[id^=foldclosed]').show();
} else {
$('#fold_all').css('background-image',minusImg[relPath]);
$('div[id^=foldopen]').show();
$('div[id^=foldclosed]').hide();
}
opened=!opened;
}
// toggle single folding block
function codefold_toggle(id) {
$('#foldopen'+id).toggle();
$('#foldclosed'+id).toggle();
}
function init_codefold(relPath) {
$('span[class=lineno]').css(
{'padding-right':'4px',
'margin-right':'2px',
'display':'inline-block',
'width':'54px',
'background':'linear-gradient(var(--fold-line-color),var(--fold-line-color)) no-repeat 46px/2px 100%'
});
// add global toggle to first line
$('span[class=lineno]:first').append('<span class="fold" id="fold_all" '+
'onclick="javascript:codefold_toggle_all('+relPath+');" '+
'style="background-image:'+minusImg[relPath]+';"></span>');
// add vertical lines to other rows
$('span[class=lineno]').not(':eq(0)').append('<span class="fold"></span>');
// add toggle controls to lines with fold divs
$('div[class=foldopen]').each(function() {
// extract specific id to use
var id = $(this).attr('id').replace('foldopen','');
// extract start and end foldable fragment attributes
var start = $(this).attr('data-start');
var end = $(this).attr('data-end');
// replace normal fold span with controls for the first line of a foldable fragment
$(this).find('span[class=fold]:first').replaceWith('<span class="fold" '+
'onclick="javascript:codefold_toggle(\''+id+'\');" '+
'style="background-image:'+minusImg[relPath]+';"></span>');
// append div for folded (closed) representation
$(this).after('<div id="foldclosed'+id+'" class="foldclosed" style="display:none;"></div>');
// extract the first line from the "open" section to represent closed content
var line = $(this).children().first().clone();
// remove any glow that might still be active on the original line
$(line).removeClass('glow');
if (start) {
// if line already ends with a start marker (e.g. trailing {), remove it
$(line).html($(line).html().replace(new RegExp('\\s*'+start+'\\s*$','g'),''));
}
// replace minus with plus symbol
$(line).find('span[class=fold]').css('background-image',plusImg[relPath]);
// append ellipsis
$(line).append(' '+start+'<a href="javascript:codefold_toggle(\''+id+'\')">&#8230;</a>'+end);
// insert constructed line into closed div
$('#foldclosed'+id).html(line);
});
}
/* @license-end */

11
doc/html/folderclosed.svg Normal file
View File

@@ -0,0 +1,11 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#4665A2;">
<path d="M1,5.998l-0,16.002c-0,1.326 0.527,2.598 1.464,3.536c0.938,0.937 2.21,1.464 3.536,1.464c5.322,0 14.678,-0 20,0c1.326,0 2.598,-0.527 3.536,-1.464c0.937,-0.938 1.464,-2.21 1.464,-3.536c0,-3.486 0,-8.514 0,-12c0,-1.326 -0.527,-2.598 -1.464,-3.536c-0.938,-0.937 -2.21,-1.464 -3.536,-1.464c-0,0 -10.586,0 -10.586,0c0,-0 -3.707,-3.707 -3.707,-3.707c-0.187,-0.188 -0.442,-0.293 -0.707,-0.293l-5.002,0c-2.76,0 -4.998,2.238 -4.998,4.998Zm2,-0l-0,16.002c-0,0.796 0.316,1.559 0.879,2.121c0.562,0.563 1.325,0.879 2.121,0.879l20,0c0.796,0 1.559,-0.316 2.121,-0.879c0.563,-0.562 0.879,-1.325 0.879,-2.121c0,-3.486 0,-8.514 0,-12c0,-0.796 -0.316,-1.559 -0.879,-2.121c-0.562,-0.563 -1.325,-0.879 -2.121,-0.879c-7.738,0 -11,0 -11,0c-0.265,0 -0.52,-0.105 -0.707,-0.293c-0,0 -3.707,-3.707 -3.707,-3.707c-0,0 -4.588,0 -4.588,0c-1.656,0 -2.998,1.342 -2.998,2.998Z"/>
</g>
<g style="fill:#D8DFEE;stroke-width:0;">
<path d="M 5.6063709,24.951908 C 4.3924646,24.775461 3.4197129,23.899792 3.1031586,22.698521 L 3.0216155,22.389078 V 13.997725 5.6063709 L 3.1037477,5.2982247 C 3.3956682,4.2029881 4.1802788,3.412126 5.2787258,3.105917 5.5646428,3.0262132 5.6154982,3.0244963 8.0611641,3.0119829 l 2.4911989,-0.012746 1.932009,1.9300342 c 1.344142,1.3427669 1.976319,1.9498819 2.07763,1.9952626 0.137456,0.061571 0.474218,0.066269 6.006826,0.083795 l 5.861206,0.018568 0.29124,0.081916 c 1.094895,0.3079569 1.890116,1.109428 2.175567,2.192667 l 0.08154,0.3094425 V 16 22.389078 l -0.08154,0.309443 c -0.28446,1.079482 -1.086411,1.888085 -2.175567,2.193614 l -0.29124,0.0817 -10.302616,0.0049 c -5.700217,0.0027 -10.4001945,-0.0093 -10.5210471,-0.02684 z"/>
</g>
</svg>

After

Width:  |  Height:  |  Size: 1.9 KiB

View File

@@ -0,0 +1,11 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#C4CFE5;">
<path d="M1,5.998l-0,16.002c-0,1.326 0.527,2.598 1.464,3.536c0.938,0.937 2.21,1.464 3.536,1.464c5.322,0 14.678,-0 20,0c1.326,0 2.598,-0.527 3.536,-1.464c0.937,-0.938 1.464,-2.21 1.464,-3.536c0,-3.486 0,-8.514 0,-12c0,-1.326 -0.527,-2.598 -1.464,-3.536c-0.938,-0.937 -2.21,-1.464 -3.536,-1.464c-0,0 -10.586,0 -10.586,0c0,-0 -3.707,-3.707 -3.707,-3.707c-0.187,-0.188 -0.442,-0.293 -0.707,-0.293l-5.002,0c-2.76,0 -4.998,2.238 -4.998,4.998Zm2,-0l-0,16.002c-0,0.796 0.316,1.559 0.879,2.121c0.562,0.563 1.325,0.879 2.121,0.879l20,0c0.796,0 1.559,-0.316 2.121,-0.879c0.563,-0.562 0.879,-1.325 0.879,-2.121c0,-3.486 0,-8.514 0,-12c0,-0.796 -0.316,-1.559 -0.879,-2.121c-0.562,-0.563 -1.325,-0.879 -2.121,-0.879c-7.738,0 -11,0 -11,0c-0.265,0 -0.52,-0.105 -0.707,-0.293c-0,0 -3.707,-3.707 -3.707,-3.707c-0,0 -4.588,0 -4.588,0c-1.656,0 -2.998,1.342 -2.998,2.998Z"/>
</g>
<g style="fill:#4665A2;stroke-width:0;">
<path d="M 5.6063709,24.951908 C 4.3924646,24.775461 3.4197129,23.899792 3.1031586,22.698521 L 3.0216155,22.389078 V 13.997725 5.6063709 L 3.1037477,5.2982247 C 3.3956682,4.2029881 4.1802788,3.412126 5.2787258,3.105917 5.5646428,3.0262132 5.6154982,3.0244963 8.0611641,3.0119829 l 2.4911989,-0.012746 1.932009,1.9300342 c 1.344142,1.3427669 1.976319,1.9498819 2.07763,1.9952626 0.137456,0.061571 0.474218,0.066269 6.006826,0.083795 l 5.861206,0.018568 0.29124,0.081916 c 1.094895,0.3079569 1.890116,1.109428 2.175567,2.192667 l 0.08154,0.3094425 V 16 22.389078 l -0.08154,0.309443 c -0.28446,1.079482 -1.086411,1.888085 -2.175567,2.193614 l -0.29124,0.0817 -10.302616,0.0049 c -5.700217,0.0027 -10.4001945,-0.0093 -10.5210471,-0.02684 z"/>
</g>
</svg>

After

Width:  |  Height:  |  Size: 1.9 KiB

17
doc/html/folderopen.svg Normal file
View File

@@ -0,0 +1,17 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#4665A2;">
<path
d="M1,5.998l0,16.002c-0,1.326 0.527,2.598 1.464,3.536c0.938,0.937 2.21,1.464 3.536,1.464c5.322,0 14.678,-0 20,0c1.326,0 2.598,-0.527 3.536,-1.464c0.937,-0.938 1.464,-2.21 1.464,-3.536c0,-3.486 0,-8.514 0,-12c0,-1.326 -0.527,-2.598 -1.464,-3.536c-0.938,-0.937 -2.21,-1.464 -3.536,-1.464c-0,0 -10.586,0 -10.586,0c0,-0 -3.707,-3.707 -3.707,-3.707c-0.187,-0.188 -0.442,-0.293 -0.707,-0.293l-5.002,0c-2.76,0 -4.998,2.238 -4.998,4.998Zm28,14.415l-3.456,-5.925c-0.538,-0.921 -1.524,-1.488 -2.591,-1.488c-0,0 -12.905,0 -12.906,0c-1.067,0 -2.053,0.567 -2.591,1.488l-4.453,7.635c0.03,0.751 0.342,1.465 0.876,1.998c0.562,0.563 1.325,0.879 2.121,0.879l20,0c0.796,0 1.559,-0.316 2.121,-0.879c0.563,-0.562 0.879,-1.325 0.879,-2.121l0,-1.587Zm0,-3.969l0,-6.444c0,-0.796 -0.316,-1.559 -0.879,-2.121c-0.562,-0.563 -1.325,-0.879 -2.121,-0.879c-7.738,0 -11,0 -11,0c-0.265,0 -0.52,-0.105 -0.707,-0.293c-0,0 -3.707,-3.707 -3.707,-3.707c-0,0 -4.588,0 -4.588,0c-1.656,0 -2.998,1.342 -2.998,2.998l0,12.16l2.729,-4.677c0.896,-1.536 2.54,-2.481 4.318,-2.481c3.354,0 9.552,0 12.906,0c1.778,0 3.422,0.945 4.318,2.481l1.729,2.963Z"
id="path2" />
</g>
<g style="fill:#D8DFEE;stroke-width:0;">
<path
d="M 5.3879408,24.913408 C 4.1598821,24.650818 3.1571088,23.558656 3.053503,22.370876 L 3.0312746,22.116041 5.2606813,18.293515 C 6.486855,16.191126 7.5598351,14.372696 7.6450818,14.25256 8.0043056,13.746312 8.5423079,13.363007 9.2104664,13.137285 l 0.2548351,-0.08609 6.9294785,-0.0097 c 6.805096,-0.0095 6.934944,-0.0084 7.234011,0.06267 0.695577,0.165199 1.290483,0.557253 1.714887,1.130141 0.08158,0.110125 0.938747,1.556711 1.90481,3.214634 l 1.756479,3.014406 -0.0186,0.971942 c -0.01387,0.724723 -0.03365,1.032131 -0.07778,1.208575 -0.242792,0.970733 -0.88732,1.735415 -1.772382,2.102793 -0.58835,0.244217 0.247209,0.227436 -11.161974,0.224159 -9.0281537,-0.0026 -10.3636023,-0.0098 -10.5862902,-0.05746 z"
id="path199" /><path
d="M 3.0126385,11.849829 3.0235061,5.5881684 3.1020974,5.2969283 C 3.3478146,4.3863605 3.93576,3.6757372 4.756668,3.2971229 5.3293315,3.0330025 5.1813272,3.0450949 8.0130385,3.0310668 l 2.5522875,-0.012644 1.918693,1.9107086 c 1.404146,1.3983023 1.964459,1.9332518 2.089351,1.9947704 l 0.170657,0.084062 5.897611,0.019367 c 5.553257,0.018236 5.910365,0.023213 6.116041,0.085231 1.102257,0.3323708 1.857042,1.1184422 2.154229,2.2435244 0.05645,0.2137228 0.06373,0.5643981 0.07519,3.6220748 0.0076,2.032169 -5.42e-4,3.370979 -0.02041,3.349261 -0.0182,-0.0199 -0.414296,-0.691472 -0.880217,-1.492382 -0.46592,-0.80091 -0.93093,-1.577954 -1.033354,-1.726764 -0.735716,-1.0689 -1.983568,-1.844244 -3.315972,-2.060353 -0.280375,-0.04548 -1.345158,-0.05334 -7.238708,-0.05347 -4.713933,-1.09e-4 -6.9931825,0.01221 -7.1717862,0.03874 -1.3002273,0.193134 -2.4770512,0.889916 -3.283628,1.944192 -0.1076466,0.140705 -0.8359664,1.353438 -1.6184885,2.694963 L 3.0017709,18.11149 Z"
id="path201" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 3.2 KiB

12
doc/html/folderopend.svg Normal file
View File

@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="16" height="24" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve">
<g style="fill:#C4CFE5;">
<path d="M1,5.998l0,16.002c-0,1.326 0.527,2.598 1.464,3.536c0.938,0.937 2.21,1.464 3.536,1.464c5.322,0 14.678,-0 20,0c1.326,0 2.598,-0.527 3.536,-1.464c0.937,-0.938 1.464,-2.21 1.464,-3.536c0,-3.486 0,-8.514 0,-12c0,-1.326 -0.527,-2.598 -1.464,-3.536c-0.938,-0.937 -2.21,-1.464 -3.536,-1.464c-0,0 -10.586,0 -10.586,0c0,-0 -3.707,-3.707 -3.707,-3.707c-0.187,-0.188 -0.442,-0.293 -0.707,-0.293l-5.002,0c-2.76,0 -4.998,2.238 -4.998,4.998Zm28,14.415l-3.456,-5.925c-0.538,-0.921 -1.524,-1.488 -2.591,-1.488c-0,0 -12.905,0 -12.906,0c-1.067,0 -2.053,0.567 -2.591,1.488l-4.453,7.635c0.03,0.751 0.342,1.465 0.876,1.998c0.562,0.563 1.325,0.879 2.121,0.879l20,0c0.796,0 1.559,-0.316 2.121,-0.879c0.563,-0.562 0.879,-1.325 0.879,-2.121l0,-1.587Zm0,-3.969l0,-6.444c0,-0.796 -0.316,-1.559 -0.879,-2.121c-0.562,-0.563 -1.325,-0.879 -2.121,-0.879c-7.738,0 -11,0 -11,0c-0.265,0 -0.52,-0.105 -0.707,-0.293c-0,0 -3.707,-3.707 -3.707,-3.707c-0,0 -4.588,0 -4.588,0c-1.656,0 -2.998,1.342 -2.998,2.998l0,12.16l2.729,-4.677c0.896,-1.536 2.54,-2.481 4.318,-2.481c3.354,0 9.552,0 12.906,0c1.778,0 3.422,0.945 4.318,2.481l1.729,2.963Z"/>
</g>
<g style="fill:#4665A2;stroke-width:0;">
<path d="M 5.3879408,24.913408 C 4.1598821,24.650818 3.1571088,23.558656 3.053503,22.370876 L 3.0312746,22.116041 5.2606813,18.293515 C 6.486855,16.191126 7.5598351,14.372696 7.6450818,14.25256 8.0043056,13.746312 8.5423079,13.363007 9.2104664,13.137285 l 0.2548351,-0.08609 6.9294785,-0.0097 c 6.805096,-0.0095 6.934944,-0.0084 7.234011,0.06267 0.695577,0.165199 1.290483,0.557253 1.714887,1.130141 0.08158,0.110125 0.938747,1.556711 1.90481,3.214634 l 1.756479,3.014406 -0.0186,0.971942 c -0.01387,0.724723 -0.03365,1.032131 -0.07778,1.208575 -0.242792,0.970733 -0.88732,1.735415 -1.772382,2.102793 -0.58835,0.244217 0.247209,0.227436 -11.161974,0.224159 -9.0281537,-0.0026 -10.3636023,-0.0098 -10.5862902,-0.05746 z" />
<path d="M 3.0126385,11.849829 3.0235061,5.5881684 3.1020974,5.2969283 C 3.3478146,4.3863605 3.93576,3.6757372 4.756668,3.2971229 5.3293315,3.0330025 5.1813272,3.0450949 8.0130385,3.0310668 l 2.5522875,-0.012644 1.918693,1.9107086 c 1.404146,1.3983023 1.964459,1.9332518 2.089351,1.9947704 l 0.170657,0.084062 5.897611,0.019367 c 5.553257,0.018236 5.910365,0.023213 6.116041,0.085231 1.102257,0.3323708 1.857042,1.1184422 2.154229,2.2435244 0.05645,0.2137228 0.06373,0.5643981 0.07519,3.6220748 0.0076,2.032169 -5.42e-4,3.370979 -0.02041,3.349261 -0.0182,-0.0199 -0.414296,-0.691472 -0.880217,-1.492382 -0.46592,-0.80091 -0.93093,-1.577954 -1.033354,-1.726764 -0.735716,-1.0689 -1.983568,-1.844244 -3.315972,-2.060353 -0.280375,-0.04548 -1.345158,-0.05334 -7.238708,-0.05347 -4.713933,-1.09e-4 -6.9931825,0.01221 -7.1717862,0.03874 -1.3002273,0.193134 -2.4770512,0.889916 -3.283628,1.944192 -0.1076466,0.140705 -0.8359664,1.353438 -1.6184885,2.694963 L 3.0017709,18.11149 Z" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 3.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 453 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 746 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 616 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 597 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 746 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 246 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 246 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 403 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 388 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 229 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 229 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 B

View File

@@ -1,18 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TurboJPEG: Data Fields</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
@@ -21,10 +20,9 @@
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
<tr id="projectrow">
<td id="projectalign">
<div id="projectname">TurboJPEG<span id="projectnumber">&#160;3.0.1</span>
</div>
</td>
</tr>
@@ -32,103 +30,63 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<!-- Generated by Doxygen 1.9.8 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li class="current"><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<div id="navrow2" class="tabs2">
<ul class="tablist">
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li><a href="classes.html"><span>Data&#160;Structure&#160;Index</span></a></li>
<li class="current"><a href="functions.html"><span>Data&#160;Fields</span></a></li>
</ul>
</div>
<div id="navrow3" class="tabs2">
<ul class="tablist">
<li class="current"><a href="functions.html"><span>All</span></a></li>
<li><a href="functions_vars.html"><span>Variables</span></a></li>
</ul>
</div>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
initMenu('',true,false,'search.php','Search');
$(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div class="contents">
<div class="textblock">Here is a list of all documented struct and union fields with links to the struct/union documentation for each field:</div><ul>
<li>customFilter
: <a class="el" href="structtjtransform.html#a43ee1bcdd2a8d7249a756774f78793c1">tjtransform</a>
</li>
<li>data
: <a class="el" href="structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3">tjtransform</a>
</li>
<li>denom
: <a class="el" href="structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3">tjscalingfactor</a>
</li>
<li>h
: <a class="el" href="structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115">tjregion</a>
</li>
<li>num
: <a class="el" href="structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec">tjscalingfactor</a>
</li>
<li>op
: <a class="el" href="structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498">tjtransform</a>
</li>
<li>options
: <a class="el" href="structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6">tjtransform</a>
</li>
<li>r
: <a class="el" href="structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf">tjtransform</a>
</li>
<li>w
: <a class="el" href="structtjregion.html#ab6eb73ceef584fc23c8c8097926dce42">tjregion</a>
</li>
<li>x
: <a class="el" href="structtjregion.html#a4b6a37a93997091b26a75831fa291ad9">tjregion</a>
</li>
<li>y
: <a class="el" href="structtjregion.html#a7b3e0c24cfe87acc80e334cafdcf22c2">tjregion</a>
</li>
<li>customFilter&#160;:&#160;<a class="el" href="structtjtransform.html#a0dc7697d59a7abe48afc629e96cbc1d2">tjtransform</a></li>
<li>data&#160;:&#160;<a class="el" href="structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3">tjtransform</a></li>
<li>denom&#160;:&#160;<a class="el" href="structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3">tjscalingfactor</a></li>
<li>h&#160;:&#160;<a class="el" href="structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115">tjregion</a></li>
<li>num&#160;:&#160;<a class="el" href="structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec">tjscalingfactor</a></li>
<li>op&#160;:&#160;<a class="el" href="structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498">tjtransform</a></li>
<li>options&#160;:&#160;<a class="el" href="structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6">tjtransform</a></li>
<li>r&#160;:&#160;<a class="el" href="structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf">tjtransform</a></li>
<li>w&#160;:&#160;<a class="el" href="structtjregion.html#ab6eb73ceef584fc23c8c8097926dce42">tjregion</a></li>
<li>x&#160;:&#160;<a class="el" href="structtjregion.html#a4b6a37a93997091b26a75831fa291ad9">tjregion</a></li>
<li>y&#160;:&#160;<a class="el" href="structtjregion.html#a7b3e0c24cfe87acc80e334cafdcf22c2">tjregion</a></li>
</ul>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.8
</small></address>
</body>
</html>

View File

@@ -1,18 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TurboJPEG: Data Fields - Variables</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
@@ -21,10 +20,9 @@
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
<tr id="projectrow">
<td id="projectalign">
<div id="projectname">TurboJPEG<span id="projectnumber">&#160;3.0.1</span>
</div>
</td>
</tr>
@@ -32,103 +30,63 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<!-- Generated by Doxygen 1.9.8 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li class="current"><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<div id="navrow2" class="tabs2">
<ul class="tablist">
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li><a href="classes.html"><span>Data&#160;Structure&#160;Index</span></a></li>
<li class="current"><a href="functions.html"><span>Data&#160;Fields</span></a></li>
</ul>
</div>
<div id="navrow3" class="tabs2">
<ul class="tablist">
<li><a href="functions.html"><span>All</span></a></li>
<li class="current"><a href="functions_vars.html"><span>Variables</span></a></li>
</ul>
</div>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
initMenu('',true,false,'search.php','Search');
$(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div class="contents">
&#160;<ul>
<li>customFilter
: <a class="el" href="structtjtransform.html#a43ee1bcdd2a8d7249a756774f78793c1">tjtransform</a>
</li>
<li>data
: <a class="el" href="structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3">tjtransform</a>
</li>
<li>denom
: <a class="el" href="structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3">tjscalingfactor</a>
</li>
<li>h
: <a class="el" href="structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115">tjregion</a>
</li>
<li>num
: <a class="el" href="structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec">tjscalingfactor</a>
</li>
<li>op
: <a class="el" href="structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498">tjtransform</a>
</li>
<li>options
: <a class="el" href="structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6">tjtransform</a>
</li>
<li>r
: <a class="el" href="structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf">tjtransform</a>
</li>
<li>w
: <a class="el" href="structtjregion.html#ab6eb73ceef584fc23c8c8097926dce42">tjregion</a>
</li>
<li>x
: <a class="el" href="structtjregion.html#a4b6a37a93997091b26a75831fa291ad9">tjregion</a>
</li>
<li>y
: <a class="el" href="structtjregion.html#a7b3e0c24cfe87acc80e334cafdcf22c2">tjregion</a>
</li>
<div class="textblock">Here is a list of all documented variables with links to the struct/union documentation for each field:</div><ul>
<li>customFilter&#160;:&#160;<a class="el" href="structtjtransform.html#a0dc7697d59a7abe48afc629e96cbc1d2">tjtransform</a></li>
<li>data&#160;:&#160;<a class="el" href="structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3">tjtransform</a></li>
<li>denom&#160;:&#160;<a class="el" href="structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3">tjscalingfactor</a></li>
<li>h&#160;:&#160;<a class="el" href="structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115">tjregion</a></li>
<li>num&#160;:&#160;<a class="el" href="structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec">tjscalingfactor</a></li>
<li>op&#160;:&#160;<a class="el" href="structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498">tjtransform</a></li>
<li>options&#160;:&#160;<a class="el" href="structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6">tjtransform</a></li>
<li>r&#160;:&#160;<a class="el" href="structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf">tjtransform</a></li>
<li>w&#160;:&#160;<a class="el" href="structtjregion.html#ab6eb73ceef584fc23c8c8097926dce42">tjregion</a></li>
<li>x&#160;:&#160;<a class="el" href="structtjregion.html#a4b6a37a93997091b26a75831fa291ad9">tjregion</a></li>
<li>y&#160;:&#160;<a class="el" href="structtjregion.html#a7b3e0c24cfe87acc80e334cafdcf22c2">tjregion</a></li>
</ul>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.8
</small></address>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@@ -1,18 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TurboJPEG: Main Page</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
@@ -21,10 +20,9 @@
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
<tr id="projectrow">
<td id="projectalign">
<div id="projectname">TurboJPEG<span id="projectnumber">&#160;3.0.1</span>
</div>
</td>
</tr>
@@ -32,59 +30,53 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<!-- Generated by Doxygen 1.9.8 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li class="current"><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
initMenu('',true,false,'search.php','Search');
$(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div class="header">
<div class="headertitle">
<div class="title">TurboJPEG Documentation</div> </div>
<div class="headertitle"><div class="title">TurboJPEG Documentation</div></div>
</div><!--header-->
<div class="contents">
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.8
</small></address>
</body>
</html>

42
doc/html/jquery.js vendored

File diff suppressed because one or more lines are too long

136
doc/html/menu.js Normal file
View File

@@ -0,0 +1,136 @@
/*
@licstart The following is the entire license notice for the JavaScript code in this file.
The MIT License (MIT)
Copyright (C) 1997-2020 by Dimitri van Heesch
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@licend The above is the entire license notice for the JavaScript code in this file
*/
function initMenu(relPath,searchEnabled,serverSide,searchPage,search) {
function makeTree(data,relPath) {
var result='';
if ('children' in data) {
result+='<ul>';
for (var i in data.children) {
var url;
var link;
link = data.children[i].url;
if (link.substring(0,1)=='^') {
url = link.substring(1);
} else {
url = relPath+link;
}
result+='<li><a href="'+url+'">'+
data.children[i].text+'</a>'+
makeTree(data.children[i],relPath)+'</li>';
}
result+='</ul>';
}
return result;
}
var searchBoxHtml;
if (searchEnabled) {
if (serverSide) {
searchBoxHtml='<div id="MSearchBox" class="MSearchBoxInactive">'+
'<div class="left">'+
'<form id="FSearchBox" action="'+relPath+searchPage+
'" method="get"><span id="MSearchSelectExt">&#160;</span>'+
'<input type="text" id="MSearchField" name="query" value="" placeholder="'+search+
'" size="20" accesskey="S" onfocus="searchBox.OnSearchFieldFocus(true)"'+
' onblur="searchBox.OnSearchFieldFocus(false)"/>'+
'</form>'+
'</div>'+
'<div class="right"></div>'+
'</div>';
} else {
searchBoxHtml='<div id="MSearchBox" class="MSearchBoxInactive">'+
'<span class="left">'+
'<span id="MSearchSelect" onmouseover="return searchBox.OnSearchSelectShow()"'+
' onmouseout="return searchBox.OnSearchSelectHide()">&#160;</span>'+
'<input type="text" id="MSearchField" value="" placeholder="'+search+
'" accesskey="S" onfocus="searchBox.OnSearchFieldFocus(true)" '+
'onblur="searchBox.OnSearchFieldFocus(false)" '+
'onkeyup="searchBox.OnSearchFieldChange(event)"/>'+
'</span>'+
'<span class="right"><a id="MSearchClose" '+
'href="javascript:searchBox.CloseResultsWindow()">'+
'<img id="MSearchCloseImg" border="0" src="'+relPath+
'search/close.svg" alt=""/></a>'+
'</span>'+
'</div>';
}
}
$('#main-nav').before('<div class="sm sm-dox"><input id="main-menu-state" type="checkbox"/>'+
'<label class="main-menu-btn" for="main-menu-state">'+
'<span class="main-menu-btn-icon"></span> '+
'Toggle main menu visibility</label>'+
'<span id="searchBoxPos1" style="position:absolute;right:8px;top:8px;height:36px;"></span>'+
'</div>');
$('#main-nav').append(makeTree(menudata,relPath));
$('#main-nav').children(':first').addClass('sm sm-dox').attr('id','main-menu');
if (searchBoxHtml) {
$('#main-menu').append('<li id="searchBoxPos2" style="float:right"></li>');
}
var $mainMenuState = $('#main-menu-state');
var prevWidth = 0;
if ($mainMenuState.length) {
function initResizableIfExists() {
if (typeof initResizable==='function') initResizable();
}
// animate mobile menu
$mainMenuState.change(function(e) {
var $menu = $('#main-menu');
var options = { duration: 250, step: initResizableIfExists };
if (this.checked) {
options['complete'] = function() { $menu.css('display', 'block') };
$menu.hide().slideDown(options);
} else {
options['complete'] = function() { $menu.css('display', 'none') };
$menu.show().slideUp(options);
}
});
// set default menu visibility
function resetState() {
var $menu = $('#main-menu');
var $mainMenuState = $('#main-menu-state');
var newWidth = $(window).outerWidth();
if (newWidth!=prevWidth) {
if ($(window).outerWidth()<768) {
$mainMenuState.prop('checked',false); $menu.hide();
$('#searchBoxPos1').html(searchBoxHtml);
$('#searchBoxPos2').hide();
} else {
$menu.show();
$('#searchBoxPos1').empty();
$('#searchBoxPos2').html(searchBoxHtml);
$('#searchBoxPos2').show();
}
if (typeof searchBox!=='undefined') {
searchBox.CloseResultsWindow();
}
prevWidth = newWidth;
}
}
$(window).ready(function() { resetState(); initResizableIfExists(); });
$(window).resize(resetState);
}
$('#main-menu').smartmenus();
}
/* @license-end */

33
doc/html/menudata.js Normal file
View File

@@ -0,0 +1,33 @@
/*
@licstart The following is the entire license notice for the JavaScript code in this file.
The MIT License (MIT)
Copyright (C) 1997-2020 by Dimitri van Heesch
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@licend The above is the entire license notice for the JavaScript code in this file
*/
var menudata={children:[
{text:"Main Page",url:"index.html"},
{text:"Topics",url:"topics.html"},
{text:"Data Structures",url:"annotated.html",children:[
{text:"Data Structures",url:"annotated.html"},
{text:"Data Structure Index",url:"classes.html"},
{text:"Data Fields",url:"functions.html",children:[
{text:"All",url:"functions.html"},
{text:"Variables",url:"functions_vars.html"}]}]}]}

8
doc/html/minus.svg Normal file
View File

@@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="12px" height="12px" viewBox="0 0 105.83333 105.83333" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
<g>
<rect style="fill:#808080;stroke-width:0" width="105.83333" height="105.83334" x="4.2409692e-08" y="-1.2701158e-06" ry="0" />
<rect style="fill:#fcfcfc;stroke-width:0" width="79.375" height="79.375" x="13.229166" y="13.229166" />
<rect style="fill:#808080;stroke-width:0" width="52.916668" height="15.874998" x="26.458332" y="44.979168" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 582 B

8
doc/html/minusd.svg Normal file
View File

@@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="12px" height="12px" viewBox="0 0 105.83333 105.83333" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
<g>
<rect style="fill:#808080;stroke-width:0" width="105.83333" height="105.83334" x="4.2409692e-08" y="-1.2701158e-06" ry="0" />
<rect style="fill:#000000;stroke-width:0" width="79.375" height="79.375" x="13.229166" y="13.229166" />
<rect style="fill:#808080;stroke-width:0" width="52.916668" height="15.874998" x="26.458332" y="44.979168" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 582 B

View File

@@ -1,95 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.3.1"/>
<title>TurboJPEG: Modules</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="doxygen-extra.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">TurboJPEG
&#160;<span id="projectnumber">2.0</span>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.3.1 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main&#160;Page</span></a></li>
<li class="current"><a href="modules.html"><span>Modules</span></a></li>
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Groups</a></div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Modules</div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock">Here is a list of all modules:</div><div class="directory">
<table class="directory">
<tr id="row_0_" class="even"><td class="entry"><img src="ftv2lastnode.png" alt="\" width="16" height="22" /><a class="el" href="group___turbo_j_p_e_g.html" target="_self">TurboJPEG</a></td><td class="desc">TurboJPEG API</td></tr>
</table>
</div><!-- directory -->
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.3.1
</small></address>
</body>
</html>

BIN
doc/html/nav_fd.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 169 B

BIN
doc/html/nav_hd.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 114 B

9
doc/html/plus.svg Normal file
View File

@@ -0,0 +1,9 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="12px" height="12px" viewBox="0 0 105.83333 105.83333" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
<g>
<rect style="fill:#808080;stroke-width:0" width="105.83333" height="105.83334" x="4.2409692e-08" y="-1.2701158e-06" ry="0" />
<rect style="fill:#fcfcfc;stroke-width:0" width="79.375" height="79.375" x="13.229166" y="13.229166" />
<rect style="fill:#808080;stroke-width:0" width="52.916668" height="15.874998" x="26.458332" y="44.979168" />
<rect style="fill:#808080;stroke-width:0" width="15.874998" height="52.916668" x="44.979168" y="26.458332" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 696 B

9
doc/html/plusd.svg Normal file
View File

@@ -0,0 +1,9 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="12px" height="12px" viewBox="0 0 105.83333 105.83333" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
<g>
<rect style="fill:#808080;stroke-width:0" width="105.83333" height="105.83334" x="4.2409692e-08" y="-1.2701158e-06" ry="0" />
<rect style="fill:#000000;stroke-width:0" width="79.375" height="79.375" x="13.229166" y="13.229166" />
<rect style="fill:#808080;stroke-width:0" width="52.916668" height="15.874998" x="26.458332" y="44.979168" />
<rect style="fill:#808080;stroke-width:0" width="15.874998" height="52.916668" x="44.979168" y="26.458332" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 696 B

4
doc/html/search/all_0.js Normal file
View File

@@ -0,0 +1,4 @@
var searchData=
[
['customfilter_0',['customFilter',['../structtjtransform.html#a0dc7697d59a7abe48afc629e96cbc1d2',1,'tjtransform']]]
];

5
doc/html/search/all_1.js Normal file
View File

@@ -0,0 +1,5 @@
var searchData=
[
['data_0',['data',['../structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3',1,'tjtransform']]],
['denom_1',['denom',['../structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3',1,'tjscalingfactor']]]
];

4
doc/html/search/all_2.js Normal file
View File

@@ -0,0 +1,4 @@
var searchData=
[
['format_20notes_0',['YUV Image Format Notes',['../group___turbo_j_p_e_g.html#autotoc_md0',1,'']]]
];

4
doc/html/search/all_3.js Normal file
View File

@@ -0,0 +1,4 @@
var searchData=
[
['h_0',['h',['../structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115',1,'tjregion']]]
];

4
doc/html/search/all_4.js Normal file
View File

@@ -0,0 +1,4 @@
var searchData=
[
['image_20format_20notes_0',['YUV Image Format Notes',['../group___turbo_j_p_e_g.html#autotoc_md0',1,'']]]
];

5
doc/html/search/all_5.js Normal file
View File

@@ -0,0 +1,5 @@
var searchData=
[
['notes_0',['YUV Image Format Notes',['../group___turbo_j_p_e_g.html#autotoc_md0',1,'']]],
['num_1',['num',['../structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec',1,'tjscalingfactor']]]
];

5
doc/html/search/all_6.js Normal file
View File

@@ -0,0 +1,5 @@
var searchData=
[
['op_0',['op',['../structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498',1,'tjtransform']]],
['options_1',['options',['../structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6',1,'tjtransform']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_63.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['customfilter',['customFilter',['../structtjtransform.html#a43ee1bcdd2a8d7249a756774f78793c1',1,'tjtransform']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_64.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,5 +0,0 @@
var searchData=
[
['data',['data',['../structtjtransform.html#a688fe8f1a8ecc12a538d9e561cf338e3',1,'tjtransform']]],
['denom',['denom',['../structtjscalingfactor.html#aefbcdf3e9e62274b2d312c695f133ce3',1,'tjscalingfactor']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_68.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['h',['h',['../structtjregion.html#aecefc45a26f4d8b60dd4d825c1710115',1,'tjregion']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_6e.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['num',['num',['../structtjscalingfactor.html#a9b011e57f981ee23083e2c1aa5e640ec',1,'tjscalingfactor']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_6f.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,5 +0,0 @@
var searchData=
[
['op',['op',['../structtjtransform.html#a2525aab4ba6978a1c273f74fef50e498',1,'tjtransform']]],
['options',['options',['../structtjtransform.html#ac0e74655baa4402209a21e1ae481c8f6',1,'tjtransform']]]
];

4
doc/html/search/all_7.js Normal file
View File

@@ -0,0 +1,4 @@
var searchData=
[
['r_0',['r',['../structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf',1,'tjtransform']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_72.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['r',['r',['../structtjtransform.html#ac324e5e442abec8a961e5bf219db12cf',1,'tjtransform']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_74.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,102 +0,0 @@
var searchData=
[
['tj_5fnumcs',['TJ_NUMCS',['../group___turbo_j_p_e_g.html#ga39f57a6fb02d9cf32e7b6890099b5a71',1,'turbojpeg.h']]],
['tj_5fnumerr',['TJ_NUMERR',['../group___turbo_j_p_e_g.html#ga79bde1b4a3e2351e00887e47781b966e',1,'turbojpeg.h']]],
['tj_5fnumpf',['TJ_NUMPF',['../group___turbo_j_p_e_g.html#ga7010a4402f54a45ba822ad8675a4655e',1,'turbojpeg.h']]],
['tj_5fnumsamp',['TJ_NUMSAMP',['../group___turbo_j_p_e_g.html#ga5ef3d169162ce77ce348e292a0b7477c',1,'turbojpeg.h']]],
['tj_5fnumxop',['TJ_NUMXOP',['../group___turbo_j_p_e_g.html#ga0f6dbd18adf38b7d46ac547f0f4d562c',1,'turbojpeg.h']]],
['tjalloc',['tjAlloc',['../group___turbo_j_p_e_g.html#gaec627dd4c5f30b7a775a7aea3bec5d83',1,'turbojpeg.h']]],
['tjalphaoffset',['tjAlphaOffset',['../group___turbo_j_p_e_g.html#ga5af0ab065feefd526debf1e20c43e837',1,'turbojpeg.h']]],
['tjblueoffset',['tjBlueOffset',['../group___turbo_j_p_e_g.html#ga84e2e35d3f08025f976ec1ec53693dea',1,'turbojpeg.h']]],
['tjbufsize',['tjBufSize',['../group___turbo_j_p_e_g.html#ga67ac12fee79073242cb216e07c9f1f90',1,'turbojpeg.h']]],
['tjbufsizeyuv2',['tjBufSizeYUV2',['../group___turbo_j_p_e_g.html#ga2be2b9969d4df9ecce9b05deed273194',1,'turbojpeg.h']]],
['tjcompress2',['tjCompress2',['../group___turbo_j_p_e_g.html#gafbdce0112fd78fd38efae841443a9bcf',1,'turbojpeg.h']]],
['tjcompressfromyuv',['tjCompressFromYUV',['../group___turbo_j_p_e_g.html#ga7622a459b79aa1007e005b58783f875b',1,'turbojpeg.h']]],
['tjcompressfromyuvplanes',['tjCompressFromYUVPlanes',['../group___turbo_j_p_e_g.html#ga29ec5dfbd2d84b8724e951d6fa0d5d9e',1,'turbojpeg.h']]],
['tjcs',['TJCS',['../group___turbo_j_p_e_g.html#ga4f83ad3368e0e29d1957be0efa7c3720',1,'turbojpeg.h']]],
['tjcs_5fcmyk',['TJCS_CMYK',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a6c8b636152ac8195b869587db315ee53',1,'turbojpeg.h']]],
['tjcs_5fgray',['TJCS_GRAY',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720ab3e7d6a87f695e45b81c1b5262b5a50a',1,'turbojpeg.h']]],
['tjcs_5frgb',['TJCS_RGB',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a677cb7ccb85c4038ac41964a2e09e555',1,'turbojpeg.h']]],
['tjcs_5fycbcr',['TJCS_YCbCr',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a7389b8f65bb387ffedce3efd0d78ec75',1,'turbojpeg.h']]],
['tjcs_5fycck',['TJCS_YCCK',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a53839e0fe867b76b58d16b0a1a7c598e',1,'turbojpeg.h']]],
['tjdecodeyuv',['tjDecodeYUV',['../group___turbo_j_p_e_g.html#ga70abbf38f77a26fd6da8813bef96f695',1,'turbojpeg.h']]],
['tjdecodeyuvplanes',['tjDecodeYUVPlanes',['../group___turbo_j_p_e_g.html#ga10e837c07fa9d25770565b237d3898d9',1,'turbojpeg.h']]],
['tjdecompress2',['tjDecompress2',['../group___turbo_j_p_e_g.html#gae9eccef8b682a48f43a9117c231ed013',1,'turbojpeg.h']]],
['tjdecompressheader3',['tjDecompressHeader3',['../group___turbo_j_p_e_g.html#ga0595681096bba7199cc6f3533cb25f77',1,'turbojpeg.h']]],
['tjdecompresstoyuv2',['tjDecompressToYUV2',['../group___turbo_j_p_e_g.html#ga04d1e839ff9a0860dd1475cff78d3364',1,'turbojpeg.h']]],
['tjdecompresstoyuvplanes',['tjDecompressToYUVPlanes',['../group___turbo_j_p_e_g.html#gaa59f901a5258ada5bd0185ad59368540',1,'turbojpeg.h']]],
['tjdestroy',['tjDestroy',['../group___turbo_j_p_e_g.html#ga75f355fa27225ba1a4ee392c852394d2',1,'turbojpeg.h']]],
['tjencodeyuv3',['tjEncodeYUV3',['../group___turbo_j_p_e_g.html#gac519b922cdf446e97d0cdcba513636bf',1,'turbojpeg.h']]],
['tjencodeyuvplanes',['tjEncodeYUVPlanes',['../group___turbo_j_p_e_g.html#gae2d04c72457fe7f4d60cf78ab1b1feb1',1,'turbojpeg.h']]],
['tjerr',['TJERR',['../group___turbo_j_p_e_g.html#gafbc17cfa57d0d5d11fea35ac025950fe',1,'turbojpeg.h']]],
['tjerr_5ffatal',['TJERR_FATAL',['../group___turbo_j_p_e_g.html#ggafbc17cfa57d0d5d11fea35ac025950feafc9cceeada13122b09e4851e3788039a',1,'turbojpeg.h']]],
['tjerr_5fwarning',['TJERR_WARNING',['../group___turbo_j_p_e_g.html#ggafbc17cfa57d0d5d11fea35ac025950fea342dd6e2aedb47bb257b4e7568329b59',1,'turbojpeg.h']]],
['tjflag_5faccuratedct',['TJFLAG_ACCURATEDCT',['../group___turbo_j_p_e_g.html#gacb233cfd722d66d1ccbf48a7de81f0e0',1,'turbojpeg.h']]],
['tjflag_5fbottomup',['TJFLAG_BOTTOMUP',['../group___turbo_j_p_e_g.html#ga72ecf4ebe6eb702d3c6f5ca27455e1ec',1,'turbojpeg.h']]],
['tjflag_5ffastdct',['TJFLAG_FASTDCT',['../group___turbo_j_p_e_g.html#gaabce235db80d3f698b27f36cbd453da2',1,'turbojpeg.h']]],
['tjflag_5ffastupsample',['TJFLAG_FASTUPSAMPLE',['../group___turbo_j_p_e_g.html#ga4ee4506c81177a06f77e2504a22efd2d',1,'turbojpeg.h']]],
['tjflag_5fnorealloc',['TJFLAG_NOREALLOC',['../group___turbo_j_p_e_g.html#ga8808d403c68b62aaa58a4c1e58e98963',1,'turbojpeg.h']]],
['tjflag_5fprogressive',['TJFLAG_PROGRESSIVE',['../group___turbo_j_p_e_g.html#ga43b426750b46190a25d34a67ef76df1b',1,'turbojpeg.h']]],
['tjflag_5fstoponwarning',['TJFLAG_STOPONWARNING',['../group___turbo_j_p_e_g.html#ga519cfa4ef6c18d9e5b455fdf59306a3a',1,'turbojpeg.h']]],
['tjfree',['tjFree',['../group___turbo_j_p_e_g.html#gaea863d2da0cdb609563aabdf9196514b',1,'turbojpeg.h']]],
['tjgeterrorcode',['tjGetErrorCode',['../group___turbo_j_p_e_g.html#ga414feeffbf860ebd31c745df203de410',1,'turbojpeg.h']]],
['tjgeterrorstr2',['tjGetErrorStr2',['../group___turbo_j_p_e_g.html#ga1ead8574f9f39fbafc6b497124e7aafa',1,'turbojpeg.h']]],
['tjgetscalingfactors',['tjGetScalingFactors',['../group___turbo_j_p_e_g.html#gac3854476006b10787bd128f7ede48057',1,'turbojpeg.h']]],
['tjgreenoffset',['tjGreenOffset',['../group___turbo_j_p_e_g.html#ga82d6e35da441112a411da41923c0ba2f',1,'turbojpeg.h']]],
['tjhandle',['tjhandle',['../group___turbo_j_p_e_g.html#ga758d2634ecb4949de7815cba621f5763',1,'turbojpeg.h']]],
['tjinitcompress',['tjInitCompress',['../group___turbo_j_p_e_g.html#ga9d63a05fc6d813f4aae06107041a37e8',1,'turbojpeg.h']]],
['tjinitdecompress',['tjInitDecompress',['../group___turbo_j_p_e_g.html#ga52300eac3f3d9ef4bab303bc244f62d3',1,'turbojpeg.h']]],
['tjinittransform',['tjInitTransform',['../group___turbo_j_p_e_g.html#ga928beff6ac248ceadf01089fc6b41957',1,'turbojpeg.h']]],
['tjloadimage',['tjLoadImage',['../group___turbo_j_p_e_g.html#gaffbd83c375e79f5db4b5c5d8ad4466e7',1,'turbojpeg.h']]],
['tjmcuheight',['tjMCUHeight',['../group___turbo_j_p_e_g.html#gabd247bb9fecb393eca57366feb8327bf',1,'turbojpeg.h']]],
['tjmcuwidth',['tjMCUWidth',['../group___turbo_j_p_e_g.html#ga9e61e7cd47a15a173283ba94e781308c',1,'turbojpeg.h']]],
['tjpad',['TJPAD',['../group___turbo_j_p_e_g.html#ga0aba955473315e405295d978f0c16511',1,'turbojpeg.h']]],
['tjpf',['TJPF',['../group___turbo_j_p_e_g.html#gac916144e26c3817ac514e64ae5d12e2a',1,'turbojpeg.h']]],
['tjpf_5fabgr',['TJPF_ABGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa1ba1a7f1631dbeaa49a0a85fc4a40081',1,'turbojpeg.h']]],
['tjpf_5fargb',['TJPF_ARGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aae8f846ed9d9de99b6e1dfe448848765c',1,'turbojpeg.h']]],
['tjpf_5fbgr',['TJPF_BGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aab10624437fb8ef495a0b153e65749839',1,'turbojpeg.h']]],
['tjpf_5fbgra',['TJPF_BGRA',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aac037ff1845cf9b74bb81a3659c2b9fb4',1,'turbojpeg.h']]],
['tjpf_5fbgrx',['TJPF_BGRX',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa2a1fbf569ca79897eae886e3376ca4c8',1,'turbojpeg.h']]],
['tjpf_5fcmyk',['TJPF_CMYK',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa7f5100ec44c91994e243f1cf55553f8b',1,'turbojpeg.h']]],
['tjpf_5fgray',['TJPF_GRAY',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa5431b54b015337705f13118073711a1a',1,'turbojpeg.h']]],
['tjpf_5frgb',['TJPF_RGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa7ce93230bff449518ce387c17e6ed37c',1,'turbojpeg.h']]],
['tjpf_5frgba',['TJPF_RGBA',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa88d2e88fab67f6503cf972e14851cc12',1,'turbojpeg.h']]],
['tjpf_5frgbx',['TJPF_RGBX',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa83973bebb7e2dc6fa8bae89ff3f42e01',1,'turbojpeg.h']]],
['tjpf_5funknown',['TJPF_UNKNOWN',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa84c1a6cead7952998e2fb895844a21ed',1,'turbojpeg.h']]],
['tjpf_5fxbgr',['TJPF_XBGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aaf6603b27147de47e212e75dac027b2af',1,'turbojpeg.h']]],
['tjpf_5fxrgb',['TJPF_XRGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aadae996905efcfa3b42a0bb3bea7f9d84',1,'turbojpeg.h']]],
['tjpixelsize',['tjPixelSize',['../group___turbo_j_p_e_g.html#gad77cf8fe5b2bfd3cb3f53098146abb4c',1,'turbojpeg.h']]],
['tjplaneheight',['tjPlaneHeight',['../group___turbo_j_p_e_g.html#ga1a209696c6a80748f20e134b3c64789f',1,'turbojpeg.h']]],
['tjplanesizeyuv',['tjPlaneSizeYUV',['../group___turbo_j_p_e_g.html#gab4ab7b24f6e797d79abaaa670373961d',1,'turbojpeg.h']]],
['tjplanewidth',['tjPlaneWidth',['../group___turbo_j_p_e_g.html#ga63fb66bb1e36c74008c4634360becbb1',1,'turbojpeg.h']]],
['tjredoffset',['tjRedOffset',['../group___turbo_j_p_e_g.html#gadd9b446742ac8a3923f7992c7988fea8',1,'turbojpeg.h']]],
['tjregion',['tjregion',['../structtjregion.html',1,'']]],
['tjsamp',['TJSAMP',['../group___turbo_j_p_e_g.html#ga1d047060ea80bb9820d540bb928e9074',1,'turbojpeg.h']]],
['tjsamp_5f411',['TJSAMP_411',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a28ec62575e5ea295c3fde3001dc628e2',1,'turbojpeg.h']]],
['tjsamp_5f420',['TJSAMP_420',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a63085dbf683cfe39e513cdb6343e3737',1,'turbojpeg.h']]],
['tjsamp_5f422',['TJSAMP_422',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a136130902cc578f11f32429b59368404',1,'turbojpeg.h']]],
['tjsamp_5f440',['TJSAMP_440',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074accf740e6f3aa6ba20ba922cad13cb974',1,'turbojpeg.h']]],
['tjsamp_5f444',['TJSAMP_444',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074afb8da4f44197837bdec0a4f593dacae3',1,'turbojpeg.h']]],
['tjsamp_5fgray',['TJSAMP_GRAY',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a3f1c9504842ddc7a48d0f690754b6248',1,'turbojpeg.h']]],
['tjsaveimage',['tjSaveImage',['../group___turbo_j_p_e_g.html#ga6f445b22d8933ae4815b3370a538d879',1,'turbojpeg.h']]],
['tjscaled',['TJSCALED',['../group___turbo_j_p_e_g.html#ga84878bb65404204743aa18cac02781df',1,'turbojpeg.h']]],
['tjscalingfactor',['tjscalingfactor',['../structtjscalingfactor.html',1,'']]],
['tjtransform',['tjtransform',['../structtjtransform.html',1,'tjtransform'],['../group___turbo_j_p_e_g.html#gaa29f3189c41be12ec5dee7caec318a31',1,'tjtransform():&#160;turbojpeg.h'],['../group___turbo_j_p_e_g.html#ga9cb8abf4cc91881e04a0329b2270be25',1,'tjTransform(tjhandle handle, const unsigned char *jpegBuf, unsigned long jpegSize, int n, unsigned char **dstBufs, unsigned long *dstSizes, tjtransform *transforms, int flags):&#160;turbojpeg.h']]],
['tjxop',['TJXOP',['../group___turbo_j_p_e_g.html#ga2de531af4e7e6c4f124908376b354866',1,'turbojpeg.h']]],
['tjxop_5fhflip',['TJXOP_HFLIP',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866aa0df69776caa30f0fa28e26332d311ce',1,'turbojpeg.h']]],
['tjxop_5fnone',['TJXOP_NONE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866aad88c0366cd3f7d0eac9d7a3fa1c2c27',1,'turbojpeg.h']]],
['tjxop_5frot180',['TJXOP_ROT180',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a140952eb8dd0300accfcc22726d69692',1,'turbojpeg.h']]],
['tjxop_5frot270',['TJXOP_ROT270',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a3064ee5dfb7f032df332818587567a08',1,'turbojpeg.h']]],
['tjxop_5frot90',['TJXOP_ROT90',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a43b2bbb23bc4bd548422d43fbe9af128',1,'turbojpeg.h']]],
['tjxop_5ftranspose',['TJXOP_TRANSPOSE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a31060aed199f886afdd417f80499c32d',1,'turbojpeg.h']]],
['tjxop_5ftransverse',['TJXOP_TRANSVERSE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866af3b14d488aea6ece9e5b3df73a74d6a4',1,'turbojpeg.h']]],
['tjxop_5fvflip',['TJXOP_VFLIP',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a324eddfbec53b7e691f61e56929d0d5d',1,'turbojpeg.h']]],
['tjxopt_5fcopynone',['TJXOPT_COPYNONE',['../group___turbo_j_p_e_g.html#ga153b468cfb905d0de61706c838986fe8',1,'turbojpeg.h']]],
['tjxopt_5fcrop',['TJXOPT_CROP',['../group___turbo_j_p_e_g.html#ga9c771a757fc1294add611906b89ab2d2',1,'turbojpeg.h']]],
['tjxopt_5fgray',['TJXOPT_GRAY',['../group___turbo_j_p_e_g.html#ga3acee7b48ade1b99e5588736007c2589',1,'turbojpeg.h']]],
['tjxopt_5fnooutput',['TJXOPT_NOOUTPUT',['../group___turbo_j_p_e_g.html#gafbf992bbf6e006705886333703ffab31',1,'turbojpeg.h']]],
['tjxopt_5fperfect',['TJXOPT_PERFECT',['../group___turbo_j_p_e_g.html#ga50e03cb5ed115330e212417429600b00',1,'turbojpeg.h']]],
['tjxopt_5fprogressive',['TJXOPT_PROGRESSIVE',['../group___turbo_j_p_e_g.html#gad2371c80674584ecc1a7d75e564cf026',1,'turbojpeg.h']]],
['tjxopt_5ftrim',['TJXOPT_TRIM',['../group___turbo_j_p_e_g.html#ga319826b7eb1583c0595bbe7b95428709',1,'turbojpeg.h']]],
['turbojpeg',['TurboJPEG',['../group___turbo_j_p_e_g.html',1,'']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_77.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['w',['w',['../structtjregion.html#ab6eb73ceef584fc23c8c8097926dce42',1,'tjregion']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_78.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['x',['x',['../structtjregion.html#a4b6a37a93997091b26a75831fa291ad9',1,'tjregion']]]
];

View File

@@ -1,26 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta name="generator" content="Doxygen 1.8.3.1">
<link rel="stylesheet" type="text/css" href="search.css"/>
<script type="text/javascript" src="all_79.js"></script>
<script type="text/javascript" src="search.js"></script>
</head>
<body class="SRPage">
<div id="SRIndex">
<div class="SRStatus" id="Loading">Loading...</div>
<div id="SRResults"></div>
<script type="text/javascript"><!--
createResults();
--></script>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
<script type="text/javascript"><!--
document.getElementById("Loading").style.display="none";
document.getElementById("NoMatches").style.display="none";
var searchResults = new SearchResults("searchResults");
searchResults.Search();
--></script>
</div>
</body>
</html>

View File

@@ -1,4 +0,0 @@
var searchData=
[
['y',['y',['../structtjregion.html#a7b3e0c24cfe87acc80e334cafdcf22c2',1,'tjregion']]]
];

142
doc/html/search/all_8.js Normal file
View File

@@ -0,0 +1,142 @@
var searchData=
[
['tj3alloc_0',['tj3Alloc',['../group___turbo_j_p_e_g.html#ga1a2c96d8b47530b6e6050ba6f10b7c57',1,'turbojpeg.h']]],
['tj3compress12_1',['tj3Compress12',['../group___turbo_j_p_e_g.html#ga9a1968c384ec7abb6122830253ebf570',1,'turbojpeg.h']]],
['tj3compress16_2',['tj3Compress16',['../group___turbo_j_p_e_g.html#ga77901b71d0471784f318ada31ff4e7bd',1,'turbojpeg.h']]],
['tj3compress8_3',['tj3Compress8',['../group___turbo_j_p_e_g.html#ga2cc418a2dab709ad7f30f5b25905f138',1,'turbojpeg.h']]],
['tj3compressfromyuv8_4',['tj3CompressFromYUV8',['../group___turbo_j_p_e_g.html#ga041c870d9c669eb3f385c78f4346c43f',1,'turbojpeg.h']]],
['tj3compressfromyuvplanes8_5',['tj3CompressFromYUVPlanes8',['../group___turbo_j_p_e_g.html#gac9f5ace3e73805b476c95dda9f8d0cd0',1,'turbojpeg.h']]],
['tj3decodeyuv8_6',['tj3DecodeYUV8',['../group___turbo_j_p_e_g.html#gaa1eb574f38b1c1de43a6c7aafcf68d8c',1,'turbojpeg.h']]],
['tj3decodeyuvplanes8_7',['tj3DecodeYUVPlanes8',['../group___turbo_j_p_e_g.html#gad366f1915f82c1ad4e7e37ebe073ca89',1,'turbojpeg.h']]],
['tj3decompress12_8',['tj3Decompress12',['../group___turbo_j_p_e_g.html#ga39b848f01781ad74a5b3941c012b6199',1,'turbojpeg.h']]],
['tj3decompress16_9',['tj3Decompress16',['../group___turbo_j_p_e_g.html#gaa074e63f9beb0b3ff42b833a4049df6e',1,'turbojpeg.h']]],
['tj3decompress8_10',['tj3Decompress8',['../group___turbo_j_p_e_g.html#ga1169c7c1a26ec18c9e6122cb8ae64013',1,'turbojpeg.h']]],
['tj3decompressheader_11',['tj3DecompressHeader',['../group___turbo_j_p_e_g.html#ga96d2c4b3432f9d88ad14758ae240b8d1',1,'turbojpeg.h']]],
['tj3decompresstoyuv8_12',['tj3DecompressToYUV8',['../group___turbo_j_p_e_g.html#ga1e6bf6a19fec3f9fa7534348879d8320',1,'turbojpeg.h']]],
['tj3decompresstoyuvplanes8_13',['tj3DecompressToYUVPlanes8',['../group___turbo_j_p_e_g.html#ga934373482dbbf257f2280505b6ff4fb5',1,'turbojpeg.h']]],
['tj3destroy_14',['tj3Destroy',['../group___turbo_j_p_e_g.html#ga53fbadf4560e95a65b8f5ab81703fe82',1,'turbojpeg.h']]],
['tj3encodeyuv8_15',['tj3EncodeYUV8',['../group___turbo_j_p_e_g.html#ga2a8d50f130bde10f0a04030f8cc59936',1,'turbojpeg.h']]],
['tj3encodeyuvplanes8_16',['tj3EncodeYUVPlanes8',['../group___turbo_j_p_e_g.html#gae2e9df38790e9bddc249d04cb158a4cf',1,'turbojpeg.h']]],
['tj3free_17',['tj3Free',['../group___turbo_j_p_e_g.html#gaddb84fb6c81769e9faa0f5a63b296606',1,'turbojpeg.h']]],
['tj3get_18',['tj3Get',['../group___turbo_j_p_e_g.html#ga34af9ba3183bdf0ec7c8f47bb9a4c84f',1,'turbojpeg.h']]],
['tj3geterrorcode_19',['tj3GetErrorCode',['../group___turbo_j_p_e_g.html#gab8c8279f1415fe425ff30dbbc56013bd',1,'turbojpeg.h']]],
['tj3geterrorstr_20',['tj3GetErrorStr',['../group___turbo_j_p_e_g.html#ga5a23ad0776c5333cda0d7c6d826e9d29',1,'turbojpeg.h']]],
['tj3getscalingfactors_21',['tj3GetScalingFactors',['../group___turbo_j_p_e_g.html#gaf9253e0c2e9f464142d389673da085fa',1,'turbojpeg.h']]],
['tj3init_22',['tj3Init',['../group___turbo_j_p_e_g.html#ga69c09d39f97ec30250ad3605ace7e5df',1,'turbojpeg.h']]],
['tj3jpegbufsize_23',['tj3JPEGBufSize',['../group___turbo_j_p_e_g.html#gac6285e58e35a35d871d7162ec5a929c4',1,'turbojpeg.h']]],
['tj3loadimage12_24',['tj3LoadImage12',['../group___turbo_j_p_e_g.html#gaa1d3772cfdb53afa21aae3c606238d44',1,'turbojpeg.h']]],
['tj3loadimage16_25',['tj3LoadImage16',['../group___turbo_j_p_e_g.html#gace4240b665dc47742cbb3b76b03dfd69',1,'turbojpeg.h']]],
['tj3loadimage8_26',['tj3LoadImage8',['../group___turbo_j_p_e_g.html#ga884023536e70985616126a073f662001',1,'turbojpeg.h']]],
['tj3saveimage12_27',['tj3SaveImage12',['../group___turbo_j_p_e_g.html#ga7c64b5106d04267a46aad85f9714ad90',1,'turbojpeg.h']]],
['tj3saveimage16_28',['tj3SaveImage16',['../group___turbo_j_p_e_g.html#ga0fd87851f4266aca24bf4594dd0c0e71',1,'turbojpeg.h']]],
['tj3saveimage8_29',['tj3SaveImage8',['../group___turbo_j_p_e_g.html#gaa4ec838988e469cc15618e4690cc8722',1,'turbojpeg.h']]],
['tj3set_30',['tj3Set',['../group___turbo_j_p_e_g.html#gaddf92640bfee3e8622218c713e77e7db',1,'turbojpeg.h']]],
['tj3setcroppingregion_31',['tj3SetCroppingRegion',['../group___turbo_j_p_e_g.html#gaa49c7bd4c9431667a043cfc93388ba1c',1,'turbojpeg.h']]],
['tj3setscalingfactor_32',['tj3SetScalingFactor',['../group___turbo_j_p_e_g.html#ga89da17ee1e43ff423382cbc145803c75',1,'turbojpeg.h']]],
['tj3transform_33',['tj3Transform',['../group___turbo_j_p_e_g.html#gaff23ba1dcabed456794b844791613920',1,'turbojpeg.h']]],
['tj3yuvbufsize_34',['tj3YUVBufSize',['../group___turbo_j_p_e_g.html#gaaebaa16973a0f550a66eca5765ed0546',1,'turbojpeg.h']]],
['tj3yuvplaneheight_35',['tj3YUVPlaneHeight',['../group___turbo_j_p_e_g.html#ga969767ec8180cc3edd99cf507f87299b',1,'turbojpeg.h']]],
['tj3yuvplanesize_36',['tj3YUVPlaneSize',['../group___turbo_j_p_e_g.html#gacc19d265edce76b46146f59579f9438d',1,'turbojpeg.h']]],
['tj3yuvplanewidth_37',['tj3YUVPlaneWidth',['../group___turbo_j_p_e_g.html#gac99d1933ede1d59fcada9a826e88eb2d',1,'turbojpeg.h']]],
['tj_5fnumcs_38',['TJ_NUMCS',['../group___turbo_j_p_e_g.html#ga39f57a6fb02d9cf32e7b6890099b5a71',1,'turbojpeg.h']]],
['tj_5fnumerr_39',['TJ_NUMERR',['../group___turbo_j_p_e_g.html#ga79bde1b4a3e2351e00887e47781b966e',1,'turbojpeg.h']]],
['tj_5fnuminit_40',['TJ_NUMINIT',['../group___turbo_j_p_e_g.html#ga5e0e8c784295c636f0bf8dab93c4bddf',1,'turbojpeg.h']]],
['tj_5fnumpf_41',['TJ_NUMPF',['../group___turbo_j_p_e_g.html#ga7010a4402f54a45ba822ad8675a4655e',1,'turbojpeg.h']]],
['tj_5fnumsamp_42',['TJ_NUMSAMP',['../group___turbo_j_p_e_g.html#ga5ef3d169162ce77ce348e292a0b7477c',1,'turbojpeg.h']]],
['tj_5fnumxop_43',['TJ_NUMXOP',['../group___turbo_j_p_e_g.html#ga0f6dbd18adf38b7d46ac547f0f4d562c',1,'turbojpeg.h']]],
['tjalphaoffset_44',['tjAlphaOffset',['../group___turbo_j_p_e_g.html#ga5af0ab065feefd526debf1e20c43e837',1,'turbojpeg.h']]],
['tjblueoffset_45',['tjBlueOffset',['../group___turbo_j_p_e_g.html#ga84e2e35d3f08025f976ec1ec53693dea',1,'turbojpeg.h']]],
['tjcs_46',['TJCS',['../group___turbo_j_p_e_g.html#ga4f83ad3368e0e29d1957be0efa7c3720',1,'turbojpeg.h']]],
['tjcs_5fcmyk_47',['TJCS_CMYK',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a6c8b636152ac8195b869587db315ee53',1,'turbojpeg.h']]],
['tjcs_5fgray_48',['TJCS_GRAY',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720ab3e7d6a87f695e45b81c1b5262b5a50a',1,'turbojpeg.h']]],
['tjcs_5frgb_49',['TJCS_RGB',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a677cb7ccb85c4038ac41964a2e09e555',1,'turbojpeg.h']]],
['tjcs_5fycbcr_50',['TJCS_YCbCr',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a7389b8f65bb387ffedce3efd0d78ec75',1,'turbojpeg.h']]],
['tjcs_5fycck_51',['TJCS_YCCK',['../group___turbo_j_p_e_g.html#gga4f83ad3368e0e29d1957be0efa7c3720a53839e0fe867b76b58d16b0a1a7c598e',1,'turbojpeg.h']]],
['tjerr_52',['TJERR',['../group___turbo_j_p_e_g.html#gafbc17cfa57d0d5d11fea35ac025950fe',1,'turbojpeg.h']]],
['tjerr_5ffatal_53',['TJERR_FATAL',['../group___turbo_j_p_e_g.html#ggafbc17cfa57d0d5d11fea35ac025950feafc9cceeada13122b09e4851e3788039a',1,'turbojpeg.h']]],
['tjerr_5fwarning_54',['TJERR_WARNING',['../group___turbo_j_p_e_g.html#ggafbc17cfa57d0d5d11fea35ac025950fea342dd6e2aedb47bb257b4e7568329b59',1,'turbojpeg.h']]],
['tjgreenoffset_55',['tjGreenOffset',['../group___turbo_j_p_e_g.html#ga82d6e35da441112a411da41923c0ba2f',1,'turbojpeg.h']]],
['tjhandle_56',['tjhandle',['../group___turbo_j_p_e_g.html#ga758d2634ecb4949de7815cba621f5763',1,'turbojpeg.h']]],
['tjinit_57',['TJINIT',['../group___turbo_j_p_e_g.html#ga3850bbee1313e752e667b4eb08b1e086',1,'turbojpeg.h']]],
['tjinit_5fcompress_58',['TJINIT_COMPRESS',['../group___turbo_j_p_e_g.html#gga3850bbee1313e752e667b4eb08b1e086aa45ac279e3dc6ffabc4b0f45864da796',1,'turbojpeg.h']]],
['tjinit_5fdecompress_59',['TJINIT_DECOMPRESS',['../group___turbo_j_p_e_g.html#gga3850bbee1313e752e667b4eb08b1e086a4b8ca1ef700699b71350700bf95c2167',1,'turbojpeg.h']]],
['tjinit_5ftransform_60',['TJINIT_TRANSFORM',['../group___turbo_j_p_e_g.html#gga3850bbee1313e752e667b4eb08b1e086a8d58a2a4c45b3e0cd349746544a6e0c2',1,'turbojpeg.h']]],
['tjmcuheight_61',['tjMCUHeight',['../group___turbo_j_p_e_g.html#gabd247bb9fecb393eca57366feb8327bf',1,'turbojpeg.h']]],
['tjmcuwidth_62',['tjMCUWidth',['../group___turbo_j_p_e_g.html#ga9e61e7cd47a15a173283ba94e781308c',1,'turbojpeg.h']]],
['tjparam_63',['TJPARAM',['../group___turbo_j_p_e_g.html#gaa0f6be63ba78278299c9f5c12031fe82',1,'turbojpeg.h']]],
['tjparam_5farithmetic_64',['TJPARAM_ARITHMETIC',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a1c756757384308145602c040524aebf7',1,'turbojpeg.h']]],
['tjparam_5fbottomup_65',['TJPARAM_BOTTOMUP',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a924657172695ed6cb0b128219546fcce',1,'turbojpeg.h']]],
['tjparam_5fcolorspace_66',['TJPARAM_COLORSPACE',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a46a10d46309514907d0c39fcd86c324c',1,'turbojpeg.h']]],
['tjparam_5fdensityunits_67',['TJPARAM_DENSITYUNITS',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a4c045981bd8a303521a401dbbe1df208',1,'turbojpeg.h']]],
['tjparam_5ffastdct_68',['TJPARAM_FASTDCT',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a6914692ac6ec5567787d592b7563f627',1,'turbojpeg.h']]],
['tjparam_5ffastupsample_69',['TJPARAM_FASTUPSAMPLE',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a0e051ac106f7b7402b690a5daf4869c0',1,'turbojpeg.h']]],
['tjparam_5fjpegheight_70',['TJPARAM_JPEGHEIGHT',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a8f76673be73f2b659440a9572a65a95f',1,'turbojpeg.h']]],
['tjparam_5fjpegwidth_71',['TJPARAM_JPEGWIDTH',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a02ab77fb294a0c9061a78cd424c82dd8',1,'turbojpeg.h']]],
['tjparam_5flossless_72',['TJPARAM_LOSSLESS',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a249f35f0770792b19f995e603bb17c6f',1,'turbojpeg.h']]],
['tjparam_5flosslesspsv_73',['TJPARAM_LOSSLESSPSV',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82abcc997d40e5bec84817c12b76ef84159',1,'turbojpeg.h']]],
['tjparam_5flosslesspt_74',['TJPARAM_LOSSLESSPT',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a4a6c6f25764ecaf4231a36bff844e46a',1,'turbojpeg.h']]],
['tjparam_5fmaxmemory_75',['TJPARAM_MAXMEMORY',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a0de0a8281da45d1fc984edc8918f7dd2',1,'turbojpeg.h']]],
['tjparam_5fmaxpixels_76',['TJPARAM_MAXPIXELS',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82ac4e95dd2ecd766854feee579406eae68',1,'turbojpeg.h']]],
['tjparam_5fnorealloc_77',['TJPARAM_NOREALLOC',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82ae64ffb358bc7b194fd48e0f27750b29b',1,'turbojpeg.h']]],
['tjparam_5foptimize_78',['TJPARAM_OPTIMIZE',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a8f0af9afc0b36443751f9ee82b760aa6',1,'turbojpeg.h']]],
['tjparam_5fprecision_79',['TJPARAM_PRECISION',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a781db82741934e8cd008d308597c59d8',1,'turbojpeg.h']]],
['tjparam_5fprogressive_80',['TJPARAM_PROGRESSIVE',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a1716f242b3859905b4a317dae8cfb75f',1,'turbojpeg.h']]],
['tjparam_5fquality_81',['TJPARAM_QUALITY',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a0467e8792621f2d817dc2af563d3186c',1,'turbojpeg.h']]],
['tjparam_5frestartblocks_82',['TJPARAM_RESTARTBLOCKS',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a343c72883b7160f23f3ef46fc548a0ec',1,'turbojpeg.h']]],
['tjparam_5frestartrows_83',['TJPARAM_RESTARTROWS',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a714367585952fe5c863f0dba5bd37e5c',1,'turbojpeg.h']]],
['tjparam_5fscanlimit_84',['TJPARAM_SCANLIMIT',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82ac478910e20ecf61b914f9824d80f8167',1,'turbojpeg.h']]],
['tjparam_5fstoponwarning_85',['TJPARAM_STOPONWARNING',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a555e2212079fa49b30bcd2879c6c8ddb',1,'turbojpeg.h']]],
['tjparam_5fsubsamp_86',['TJPARAM_SUBSAMP',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a2a3494a8215d3de4fdbaeb2ba6f6b03a',1,'turbojpeg.h']]],
['tjparam_5fxdensity_87',['TJPARAM_XDENSITY',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82a4de5c9d7cab5be806143a43c3b0e0877',1,'turbojpeg.h']]],
['tjparam_5fydensity_88',['TJPARAM_YDENSITY',['../group___turbo_j_p_e_g.html#ggaa0f6be63ba78278299c9f5c12031fe82abda48f2df7eb9b88e2b7621efb017eba',1,'turbojpeg.h']]],
['tjpf_89',['TJPF',['../group___turbo_j_p_e_g.html#gac916144e26c3817ac514e64ae5d12e2a',1,'turbojpeg.h']]],
['tjpf_5fabgr_90',['TJPF_ABGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa1ba1a7f1631dbeaa49a0a85fc4a40081',1,'turbojpeg.h']]],
['tjpf_5fargb_91',['TJPF_ARGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aae8f846ed9d9de99b6e1dfe448848765c',1,'turbojpeg.h']]],
['tjpf_5fbgr_92',['TJPF_BGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aab10624437fb8ef495a0b153e65749839',1,'turbojpeg.h']]],
['tjpf_5fbgra_93',['TJPF_BGRA',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aac037ff1845cf9b74bb81a3659c2b9fb4',1,'turbojpeg.h']]],
['tjpf_5fbgrx_94',['TJPF_BGRX',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa2a1fbf569ca79897eae886e3376ca4c8',1,'turbojpeg.h']]],
['tjpf_5fcmyk_95',['TJPF_CMYK',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa7f5100ec44c91994e243f1cf55553f8b',1,'turbojpeg.h']]],
['tjpf_5fgray_96',['TJPF_GRAY',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa5431b54b015337705f13118073711a1a',1,'turbojpeg.h']]],
['tjpf_5frgb_97',['TJPF_RGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa7ce93230bff449518ce387c17e6ed37c',1,'turbojpeg.h']]],
['tjpf_5frgba_98',['TJPF_RGBA',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa88d2e88fab67f6503cf972e14851cc12',1,'turbojpeg.h']]],
['tjpf_5frgbx_99',['TJPF_RGBX',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa83973bebb7e2dc6fa8bae89ff3f42e01',1,'turbojpeg.h']]],
['tjpf_5funknown_100',['TJPF_UNKNOWN',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aa84c1a6cead7952998e2fb895844a21ed',1,'turbojpeg.h']]],
['tjpf_5fxbgr_101',['TJPF_XBGR',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aaf6603b27147de47e212e75dac027b2af',1,'turbojpeg.h']]],
['tjpf_5fxrgb_102',['TJPF_XRGB',['../group___turbo_j_p_e_g.html#ggac916144e26c3817ac514e64ae5d12e2aadae996905efcfa3b42a0bb3bea7f9d84',1,'turbojpeg.h']]],
['tjpixelsize_103',['tjPixelSize',['../group___turbo_j_p_e_g.html#gad77cf8fe5b2bfd3cb3f53098146abb4c',1,'turbojpeg.h']]],
['tjredoffset_104',['tjRedOffset',['../group___turbo_j_p_e_g.html#gadd9b446742ac8a3923f7992c7988fea8',1,'turbojpeg.h']]],
['tjregion_105',['tjregion',['../structtjregion.html',1,'']]],
['tjsamp_106',['TJSAMP',['../group___turbo_j_p_e_g.html#ga1d047060ea80bb9820d540bb928e9074',1,'turbojpeg.h']]],
['tjsamp_5f411_107',['TJSAMP_411',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a28ec62575e5ea295c3fde3001dc628e2',1,'turbojpeg.h']]],
['tjsamp_5f420_108',['TJSAMP_420',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a63085dbf683cfe39e513cdb6343e3737',1,'turbojpeg.h']]],
['tjsamp_5f422_109',['TJSAMP_422',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a136130902cc578f11f32429b59368404',1,'turbojpeg.h']]],
['tjsamp_5f440_110',['TJSAMP_440',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074accf740e6f3aa6ba20ba922cad13cb974',1,'turbojpeg.h']]],
['tjsamp_5f441_111',['TJSAMP_441',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a3351696e1dd34a083a35b6be8b90122d',1,'turbojpeg.h']]],
['tjsamp_5f444_112',['TJSAMP_444',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074afb8da4f44197837bdec0a4f593dacae3',1,'turbojpeg.h']]],
['tjsamp_5fgray_113',['TJSAMP_GRAY',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074a3f1c9504842ddc7a48d0f690754b6248',1,'turbojpeg.h']]],
['tjsamp_5funknown_114',['TJSAMP_UNKNOWN',['../group___turbo_j_p_e_g.html#gga1d047060ea80bb9820d540bb928e9074ac124fa8f6cb41147e3d670dfbdfb7173',1,'turbojpeg.h']]],
['tjscaled_115',['TJSCALED',['../group___turbo_j_p_e_g.html#ga84878bb65404204743aa18cac02781df',1,'turbojpeg.h']]],
['tjscalingfactor_116',['tjscalingfactor',['../structtjscalingfactor.html',1,'']]],
['tjtransform_117',['tjtransform',['../structtjtransform.html',1,'tjtransform'],['../group___turbo_j_p_e_g.html#ga504805ec0161f1b505397ca0118bf8fd',1,'tjtransform:&#160;turbojpeg.h']]],
['tjuncropped_118',['TJUNCROPPED',['../group___turbo_j_p_e_g.html#ga6f192ad58a5a5802e145149d83c643bf',1,'turbojpeg.h']]],
['tjunscaled_119',['TJUNSCALED',['../group___turbo_j_p_e_g.html#ga7880644a0849161ad20933536169ee19',1,'turbojpeg.h']]],
['tjxop_120',['TJXOP',['../group___turbo_j_p_e_g.html#ga2de531af4e7e6c4f124908376b354866',1,'turbojpeg.h']]],
['tjxop_5fhflip_121',['TJXOP_HFLIP',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866aa0df69776caa30f0fa28e26332d311ce',1,'turbojpeg.h']]],
['tjxop_5fnone_122',['TJXOP_NONE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866aad88c0366cd3f7d0eac9d7a3fa1c2c27',1,'turbojpeg.h']]],
['tjxop_5frot180_123',['TJXOP_ROT180',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a140952eb8dd0300accfcc22726d69692',1,'turbojpeg.h']]],
['tjxop_5frot270_124',['TJXOP_ROT270',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a3064ee5dfb7f032df332818587567a08',1,'turbojpeg.h']]],
['tjxop_5frot90_125',['TJXOP_ROT90',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a43b2bbb23bc4bd548422d43fbe9af128',1,'turbojpeg.h']]],
['tjxop_5ftranspose_126',['TJXOP_TRANSPOSE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a31060aed199f886afdd417f80499c32d',1,'turbojpeg.h']]],
['tjxop_5ftransverse_127',['TJXOP_TRANSVERSE',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866af3b14d488aea6ece9e5b3df73a74d6a4',1,'turbojpeg.h']]],
['tjxop_5fvflip_128',['TJXOP_VFLIP',['../group___turbo_j_p_e_g.html#gga2de531af4e7e6c4f124908376b354866a324eddfbec53b7e691f61e56929d0d5d',1,'turbojpeg.h']]],
['tjxopt_5farithmetic_129',['TJXOPT_ARITHMETIC',['../group___turbo_j_p_e_g.html#gaecaaa3b7e2af812592c015d83207f010',1,'turbojpeg.h']]],
['tjxopt_5fcopynone_130',['TJXOPT_COPYNONE',['../group___turbo_j_p_e_g.html#ga153b468cfb905d0de61706c838986fe8',1,'turbojpeg.h']]],
['tjxopt_5fcrop_131',['TJXOPT_CROP',['../group___turbo_j_p_e_g.html#ga9c771a757fc1294add611906b89ab2d2',1,'turbojpeg.h']]],
['tjxopt_5fgray_132',['TJXOPT_GRAY',['../group___turbo_j_p_e_g.html#ga3acee7b48ade1b99e5588736007c2589',1,'turbojpeg.h']]],
['tjxopt_5fnooutput_133',['TJXOPT_NOOUTPUT',['../group___turbo_j_p_e_g.html#gafbf992bbf6e006705886333703ffab31',1,'turbojpeg.h']]],
['tjxopt_5foptimize_134',['TJXOPT_OPTIMIZE',['../group___turbo_j_p_e_g.html#ga6bedf37aa9e1122f3ec9f7302ca59117',1,'turbojpeg.h']]],
['tjxopt_5fperfect_135',['TJXOPT_PERFECT',['../group___turbo_j_p_e_g.html#ga50e03cb5ed115330e212417429600b00',1,'turbojpeg.h']]],
['tjxopt_5fprogressive_136',['TJXOPT_PROGRESSIVE',['../group___turbo_j_p_e_g.html#gad2371c80674584ecc1a7d75e564cf026',1,'turbojpeg.h']]],
['tjxopt_5ftrim_137',['TJXOPT_TRIM',['../group___turbo_j_p_e_g.html#ga319826b7eb1583c0595bbe7b95428709',1,'turbojpeg.h']]],
['turbojpeg_138',['TurboJPEG',['../group___turbo_j_p_e_g.html',1,'']]]
];

Some files were not shown because too many files have changed in this diff Show More