57 Commits

Author SHA1 Message Date
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
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
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
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
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
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
Kornel
8217fd5478 Merge tag '2.0.0'
* tag '2.0.0': (160 commits)
  Clarify Android Windows build instructions
  Bump revision to 2.0.0
  Build: Don't use @rpath with OS X 10.4 builds
  Fix JPEG spec references per ISO/ITU-T suggestions
  Fix int overflow when decompr. corrupt prog. JPEG
  cjpeg: Fix OOB read caused by malformed 8-bit BMP
  Build: Preserve CMake exe suffix from cmd line
  Honor CMake exe suffix when inst. static builds
  README.ijg: Clarification regarding JPEG 2000/XR
  BUILDING.md: Correct iOS/Android examples
  Build: Detect whether compiler supports DSPr2
  Fix jpeg_skip_scanlines() segfault w/merged upsamp
  Fix infinite loop in partial image decompression
  tjLoadImage(): Fix FPE triggered by malformed BMP
  TurboJPEG: Handle JERR_BMP*,JERR_PPM* error codes
  Fix CVE-2018-11813
  Travis: Use SKS keyserver pool
  Additional code formatting tweaks
  Java: Further style refinements
  Java: Reformat code per checkstyle recommendations
  ...
2018-11-11 16:13:59 +00:00
DRC
09497c1a73 Additional code formatting tweaks
Missed by previous analysis
2018-03-17 00:28:17 -05:00
DRC
19c791cdac Improve code formatting consistency
With rare exceptions ...
- Always separate line continuation characters by one space from
  preceding code.
- Always use two-space indentation.  Never use tabs.
- Always use K&R-style conditional blocks.
- Always surround operators with spaces, except in raw assembly code.
- Always put a space after, but not before, a comma.
- Never put a space between type casts and variables/function calls.
- Never put a space between the function name and the argument list in
  function declarations and prototypes.
- Always surround braces ('{' and '}') with spaces.
- Always surround statements (if, for, else, catch, while, do, switch)
  with spaces.
- Always attach pointer symbols ('*' and '**') to the variable or
  function name.
- Always precede pointer symbols ('*' and '**') by a space in type
  casts.
- Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG
  API libraries (using min() from tjutil.h is still necessary for
  TJBench.)
- Where it makes sense (particularly in the TurboJPEG code), put a blank
  line after variable declaration blocks.
- Always separate statements in one-liners by two spaces.

The purpose of this was to ease maintenance on my part and also to make
it easier for contributors to figure out how to format patch
submissions.  This was admittedly confusing (even to me sometimes) when
we had 3 or 4 different style conventions in the same source tree.  The
new convention is more consistent with the formatting of other OSS code
bases.

This commit corrects deviations from the chosen formatting style in the
libjpeg API code and reformats the TurboJPEG API code such that it
conforms to the same standard.

NOTES:
- Although it is no longer necessary for the function name in function
  declarations to begin in Column 1 (this was historically necessary
  because of the ansi2knr utility, which allowed libjpeg to be built
  with non-ANSI compilers), we retain that formatting for the libjpeg
  code because it improves readability when using libjpeg's function
  attribute macros (GLOBAL(), etc.)
- This reformatting project was accomplished with the help of AStyle and
  Uncrustify, although neither was completely up to the task, and thus
  a great deal of manual tweaking was required.  Note to developers of
  code formatting utilities:  the libjpeg-turbo code base is an
  excellent test bed, because AFAICT, it breaks every single one of the
  utilities that are currently available.
- The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been
  formatted to match the SSE2 code (refer to
  ff5685d5344273df321eb63a005eaae19d2496e3.)  I hadn't intended to
  bother with this, but the Loongson MMI implementation demonstrated
  that there is still academic value to the MMX implementation, as an
  algorithmic model for other 64-bit vector implementations.  Thus, it
  is desirable to improve its readability in the same manner as that of
  the SSE2 implementation.
2018-03-16 02:14:34 -05:00
Kornel Lesiński
ec333d5bbd Merge remote-tracking branch 'libjpeg-turbo/master' into libjpeg-turbo
* libjpeg-turbo/master: (140 commits)
  Increase severity of tjDecompressToYUV2() bug desc
  Catch libjpeg errors in tjDecompressToYUV2()
  BUILDING.md: Fix "... OR ..." indentation again
  BUILDING.md: Fix confusing Windows build reqs
  ChangeLog.md: Improve readability of plain text
  change.log: Refer users to ChangeLog.md
  Markdown version of ChangeLog.txt
  Rename ChangeLog.txt
  README.md: Link to BUILDING.md
  BUILDING.md and README.md: Cosmetic tweaks
  ChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)"
  Java: Fix parallel make with autotools
  Win/x64: Fix improper callee save of xmm8-xmm11
  Bump TurboJPEG C API revision to 1.5
  ChangeLog: Mention jpeg_crop_scanline() function
  1.5 beta1
  Fix v7/v8-compatible build
  libjpeg API: Partial scanline decompression
  Build: Make the NASM autoconf variable persistent
  Use consistent/modern code formatting for dbl ptrs
  ...
2016-04-28 01:08:01 +01:00
Kornel Lesiński
667fb53e3f Merge tag '1.4.1' into libjpeg-turbo
Tag 1.4.1 release

* tag '1.4.1': (427 commits)
  Now that the TurboJPEG API is reporting libjpeg warnings as errors, an "Invalid SOS parameters for sequential JPEG" warning surfaced in tjDecodeYUV*().  This was caused by the Se member of jpeg_decompress_struct being set to 0 (it is normally set to a non-zero value when the start-of-scan markers are read, but there are no SOS markers in this case, because we're not actually decompressing a JPEG file.)
  Fix a segfault that occured in the MIPS DSPr2 fancy upsampling routine when downsampled_width==3.  Because the DSPr2 code unrolls the loop for the middle columns (refer to jdsample.c), it has the effect of performing two column iterations, and that only works properly if the number of columns (minus the first and last) is >= 2.  For the specific case of downsampled_width==3, this patch skips to the second iteration of the unrolled column loop.
  If a warning (such as "Premature end of JPEG file") is triggered in the underlying libjpeg API, make sure that the TurboJPEG API function returns -1.  Unlike errors, however, libjpeg warnings do not make the TurboJPEG functions abort.
  Back out r1555 and r1548.  Using setenv() didn't fix the iOS simulator issue.  It just replaced an undefined _putenv$UNIX2003 symbol with an undefined _setenv$UNIX2003 symbol.  The correct solution seems to be to use -D_NONSTD_SOURCE when generating our official builds.
  Fix the Windows build.  I remember now why I used putenv() originally-- because Windows doesn't have setenv().  We could use _putenv_s(), but older versions of MinGW don't have that either.  Fortunately, since all of the environment values we're setting in turbojpeg.c are static, we can just map setenv() to putenv() using a macro.  NOTE: we still have to use _putenv_s() in turbojpeg-jni.c, but at least people who may need to build with an older version of MinGW can still do so by disabling the Java build.
  Allow building only static or only shared libraries on Windows
  __WORDSIZE doesn't seem to be available on platforms other than Mac or Linux, and best practices are for user-level code not to rely on it anyhow, since it's meant to be an internal macro.  Fortunately, autoconf already has a way of determining the word size at configure time, so it can be passed into the compiler.  This should work on any platform and has been tested on all of the Un*x platforms we support (Linux, Mac, FreeBSD, Solaris.)
  Unless you define _ANSI_SOURCE, then putenv() on Mac is renamed to putenv$UNIX2003(), and this causes problems when trying to link an i386 iOS application (for the simulator) against the TurboJPEG static library.  It's easiest to just use setenv() instead.
  Fix a bug in the 64-bit Huffman encoder that Google discovered when encoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT.  These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS().  Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it.  This issue appears to have existed in all versions of libjpeg-turbo.
  Restore backward compatibility with MSVC < 2010 (broken by r1541)
  Oops.  OS X doesn't define __WORDSIZE unless you include stdint.h, so apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X.
  Allow the executables and libraries outside of the sharedlib/ directory to be linked against msvcr*.dll instead of libcmt*.lib.  This is reported to be necessary when building libjpeg-turbo for use with C#.
  Surround the usage of getenv() in the TurboJPEG API with #ifndef NO_GETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv().  Currently this is known to be necessary when building for Windows Phone.
  If libjpeg-turbo is configured with a non-default prefix, such as /usr, then use the docdir variable defined by autoconf 2.60 and later, if available.  This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden.  When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been.
  Enable silent build rules for the NASM objects, if the source is configured with automake 1.11 or later.  NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.")
  Set the RPM and deb architecture properly on non-x86 platforms.
  Come on, Cohaagen, you got what you want.  Give these people air!
  Oops.  Need to set the alpha channel when using TYPE_4BYTE_ABGR*.  This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank.
  Oops.  The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error.
  Introduce fast paths to speed up NULL color conversion somewhat, particularly when using 64-bit code;  on the decompression side, the "slow path" also now use an approach similar to that of the compression side (with the component loop outside of the column loop rather than inside.)  This is faster when using 32-bit code.
  ...
2016-04-28 00:45:08 +01:00
DRC
bd49803f92 Use consistent/modern code formatting for pointers
The convention used by libjpeg:

    type * variable;

is not very common anymore, because it looks too much like
multiplication.  Some (particularly C++ programmers) prefer to tuck the
pointer symbol against the type:

    type* variable;

to emphasize that a pointer to a type is effectively a new type.
However, this can also be confusing, since defining multiple variables
on the same line would not work properly:

    type* variable1, variable2;  /* Only variable1 is actually a
                                    pointer. */

This commit reformats the entirety of the libjpeg-turbo code base so
that it uses the same code formatting convention for pointers that the
TurboJPEG API code uses:

    type *variable1, *variable2;

This seems to be the most common convention among C programmers, and
it is the convention used by other codec libraries, such as libpng and
libtiff.
2016-02-19 09:10:07 -06:00
DRC
7e3acc0e0a Rename README, LICENSE, BUILDING text files
The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.
2015-10-10 10:31:33 -05:00
Thomas G. Lane
5ead57a34a The Independent JPEG Group's JPEG software v6b 2015-07-27 13:43:00 -05:00
Thomas G. Lane
489583f516 The Independent JPEG Group's JPEG software v6a 2015-07-29 15:32:35 -05:00
Thomas G. Lane
bc79e0680a The Independent JPEG Group's JPEG software v6 2015-07-29 15:31:30 -05:00
Thomas G. Lane
36a4ccccd3 The Independent JPEG Group's JPEG software v5 2015-07-29 15:28:00 -05:00
DRC
3bc0839d7f Restore full bitwise compatibility with libjpeg-turbo when -revert is used
mozjpeg should produce identical output to libjpeg-turbo when the JCP_FASTEST
compression profile is used.  That means that that profile needs to revert to
the default libjpeg quantization/Huffman tables as well as disable mozjpeg's
duplicate table checking feature.  This patch also adds -revert to any instance
of cjpeg and jpegtran called by 'make test' (or ctest on Windows), so that
those tests actually work again.  The tests aren't useful for regression
testing the mozjpeg extensions, but at least they can now be used to regression
test the underlying code.
2014-12-14 05:31:57 -06:00
DRC
ebc7c3a760 Reconcile indentation, whitespace, and other code formatting with libjpeg-turbo.
For whatever reason, some of these files didn't get fully merged from
libjpeg-turbo 1.4.  They still contained tab characters and other formatting
conventions from libjpeg-turbo 1.3.  This patch also fixes some obvious
indentation errors in the mozjpeg-specific code.  There is more formatting work
that needs to be done to the mozjpeg-specific code, to fix line overruns,
incorrect operator whitespace, and other issues that make it not consistent
with the libjpeg/libjpeg-turbo code.
2014-11-06 01:14:11 -06:00
DRC
29165500c9 Fix build error encountered when using MS Visual C++ (it doesn't support C99) -- at least not the version of MSVC++ I'm using.) 2014-11-04 01:59:19 -06:00
Kornel Lesiński
a7eb278df1 Merge mozjpeg into libjpeg-turbo
* origin/master: (23 commits)
  Update .gitignore
  .func/.endfunc are only necessary when generating STABS debug info, which basically went out of style with parachute pants and Rick Astley.  At any rate, none of the platforms for which we're building the ARM code use it (DWARF is the common format these days), and the .func/.endfunc directives cause the clang integrated assembler to fail (http://llvm.org/bugs/show_bug.cgi?id=20424).
  Enable DC trellis by default
  Avoid double inline attribute
  Detect libpng
  Implement DHT Merging
  Add .gitignore for autotools files
  Check memory alloc success
  Update cjpeg usage text
  Implement DQT merging
  Fix issue with scan printout
  Get rid of unnecessary and obsolete platform configuration instructions.
  Add error checks for malloc calls that don't already have them. Issue #87.
  yuvjpeg: fix trivial leak
  Parse quality as float
  PNG reading support
  Fix issue with DC trellis
  Add option to split DC scans
  Add trellis for DC
  Bump version to 2.1.
  ...

Conflicts:
	BUILDING.txt
	cdjpeg.h
	jcdctmgr.c
	jchuff.h
	jcmarker.c
	jcmaster.c
	jconfig.txt
	jpeglib.h
	rdswitch.c
2014-09-07 18:20:38 +01:00
Derek Buitenhuis
873a32e8d0 Implement DHT Merging
The current way multipass works, write_scan_header() seems to be called
multiple times, so only DC tables get merged, however, this will still
merge AC tables if possible.

Implements the second half of #30.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
2014-08-14 18:19:29 +01:00
Derek Buitenhuis
d3a58a33cd Implement DQT merging
See #30.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
2014-08-13 15:07:08 +01:00
DRC
46611eb0ee libjpeg-turbo has never supported non-ANSI compilers, so get rid of the crufty SIZEOF() macro. It was not being used consistently anyhow, so it would not have been possible to build prior releases of libjpeg-turbo using the broken compilers for which that macro was designed. 2014-05-18 19:04:03 +00:00
DRC
5de454b291 libjpeg-turbo has never supported non-ANSI compilers, so get rid of the crufty SIZEOF() macro. It was not being used consistently anyhow, so it would not have been possible to build prior releases of libjpeg-turbo using the broken compilers for which that macro was designed.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1313 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-18 19:04:03 +00:00
DRC
66245aa735 libjpeg-turbo has never supported non-ANSI compilers, so get rid of the crufty SIZEOF() macro. It was not being used consistently anyhow, so it would not have been possible to build prior releases of libjpeg-turbo using the broken compilers for which that macro was designed.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1313 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-18 19:04:03 +00:00
DRC
e45363d7c2 Convert tabs to spaces in the libjpeg code and the SIMD code (TurboJPEG retains the use of tabs for historical reasons. They were annoying in the libjpeg code primarily because they were not consistently used and because they were used to format as well as indent the code. In the case of TurboJPEG, tabs are used just to indent the code, so even if the editor assumes a different tab width, the code will still be readable.) 2014-05-09 18:00:32 +00:00
DRC
e5eaf37440 Convert tabs to spaces in the libjpeg code and the SIMD code (TurboJPEG retains the use of tabs for historical reasons. They were annoying in the libjpeg code primarily because they were not consistently used and because they were used to format as well as indent the code. In the case of TurboJPEG, tabs are used just to indent the code, so even if the editor assumes a different tab width, the code will still be readable.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1278 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-09 18:00:32 +00:00
DRC
16d7eeb944 Convert tabs to spaces in the libjpeg code and the SIMD code (TurboJPEG retains the use of tabs for historical reasons. They were annoying in the libjpeg code primarily because they were not consistently used and because they were used to format as well as indent the code. In the case of TurboJPEG, tabs are used just to indent the code, so even if the editor assumes a different tab width, the code will still be readable.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1278 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-09 18:00:32 +00:00
Josh Aas
72b66f9c77 Initial commit of libjpeg-turbo plus readme edits. 2014-01-13 18:28:20 -06:00
DRC
db6e007c44 Back-port code from jpeg-8 that removes unpopulated (and unneeded) tables for AC and DC coefficients when generating progressive JPEG files with arithmetic coding. This should make such files bitwise compatible with jpeg-8, barring any other mathematical differences listed in README-turbo.txt. Add regression tests for progressive+arithmetic JPEG files. 2013-11-06 06:50:38 +00:00
DRC
4b509280ce Back-port code from jpeg-8 that removes unpopulated (and unneeded) tables for AC and DC coefficients when generating progressive JPEG files with arithmetic coding. This should make such files bitwise compatible with jpeg-8, barring any other mathematical differences listed in README-turbo.txt. Add regression tests for progressive+arithmetic JPEG files.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1080 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 06:55:28 +00:00
Guido Vollbeding
c39ec149e8 The Independent JPEG Group's JPEG software v8c 2015-07-27 13:49:31 -05:00
Guido Vollbeding
989630f70c The Independent JPEG Group's JPEG software v8 2015-07-27 13:45:31 -05:00
Guido Vollbeding
5996a25e2f The Independent JPEG Group's JPEG software v7 2015-07-27 13:44:25 -05:00
Guido Vollbeding
1e247ac854 The Independent JPEG Group's JPEG software v6b with arithmetic coding support 2015-07-27 14:40:46 -05:00
DRC
97fbe04323 Back-port code from jpeg-8 that removes unpopulated (and unneeded) tables for AC and DC coefficients when generating progressive JPEG files with arithmetic coding. This should make such files bitwise compatible with jpeg-8, barring any other mathematical differences listed in README-turbo.txt. Add regression tests for progressive+arithmetic JPEG files.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1080 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 06:55:28 +00:00
DRC
4ac8700537 Remove unnecessary whitespace
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1078 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 06:02:26 +00:00
DRC
bff45dffc1 Remove unnecessary whitespace
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1078 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 06:02:26 +00:00
DRC
5aa6c9a553 Remove unnecessary whitespace
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1077 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 05:58:38 +00:00
DRC
2d4ca5d710 Remove unnecessary whitespace 2013-11-06 05:51:03 +00:00
DRC
a6ef282a49 Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1053 632fc199-4ca6-4c93-a231-07263d6284db
2013-09-28 03:23:49 +00:00
DRC
472ecea71e Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1053 632fc199-4ca6-4c93-a231-07263d6284db
2013-09-28 03:23:49 +00:00
DRC
e2563adb2e Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these. 2013-09-28 03:22:53 +00:00
DRC
e8be2c612a Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1049 632fc199-4ca6-4c93-a231-07263d6284db
2013-09-28 03:04:01 +00:00
DRC
c44750e50e Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1081 632fc199-4ca6-4c93-a231-07263d6284db
2013-11-06 07:37:01 +00:00
DRC
dc0f3c179e Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1049 632fc199-4ca6-4c93-a231-07263d6284db
2013-09-28 03:04:01 +00:00
DRC
0ccc581b8c Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo. 2013-09-28 03:03:04 +00:00
DRC
a73e870ad0 Change the copyright notices to make it clear that our modified files are not part of the IJG's software.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@873 632fc199-4ca6-4c93-a231-07263d6284db
2012-12-31 02:52:30 +00:00