28 Commits

Author SHA1 Message Date
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
DRC
13377e6b38 MSVC: Eliminate int conversion warnings (C4244) 2022-02-23 15:57:05 -06: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
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
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
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
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
a62895265f Fix JPEG spec references per ISO/ITU-T suggestions
- When referring to specific clauses, annexes, tables, and figures, a
  "timed reference" (a reference that includes the year) must be used in
  order to avoid confusion.
- "CCITT" = "ITU-T"
- Replace ambiguous "JPEG spec" with the specific document number.
2018-07-24 18:43:49 -05:00
Even Rouault
9ab569e616 Fix int overflow when decompr. corrupt prog. JPEG
No discernible performance regression

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9447
Credit to OSS Fuzz
Closes #259
2018-07-23 22:11:38 -05:00
DRC
293263c352 Format preprocessor macros more consistently
Within the libjpeg API code, it seems to be more the convention than not
to separate the macro name and value by two or more spaces, which
improves general readability.  Making this consistent across all of
libjpeg-turbo is less about my individual preferences and more about
making it easy to automatically detect variations from our chosen
formatting convention.  I intend to release the script I'm using to
validate this stuff, once it matures and stabilizes a bit.
2018-03-17 15:19:41 -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
DRC
a1dd35680d Silence additional UBSan warnings
NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced
by 8e9cef2e6f, but apparently I need to
be REALLY clear that I'm trying to do pointer arithmetic rather than
dereference an array.  Grrr...

Refer to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301250
https://bugzilla.mozilla.org/show_bug.cgi?id=1301256
2016-09-08 21:29:58 -05: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
DRC
8e9cef2e6f Fix various issues reported by the UB sanitizers
Most of these involved left shifting a negative number, which is
technically undefined (although every modern compiler I'm aware of
will implement this by treating the signed integer as a 2's complement
unsigned integer-- the LEFT_SHIFT() macro just makes this behavior
explicit in order to shut up ubsan.)  This also fixes a couple of
non-issues in the entropy codecs, whereby the sanitizer reported an
out-of-bounds index in the 4th argument of jpeg_make_d_derived_tbl().
In those cases, the index was actually out of bounds (caused by a
malformed JPEG image), but jpeg_make_d_derived_tbl() would have caught
the error and aborted prior to actually using the invalid address.  Here
again, the fix was to make our intentions explicit so as to shut up
ubsan.
2015-09-21 13:12:04 -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
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
5033f3e19a Remove MS-DOS code and information, and adjust copyright headers to reflect the removal of features in r1307 and r1308. libjpeg-turbo has never supported MS-DOS, nor is it even possible for us to do so.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1312 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-18 18:33:44 +00:00
DRC
bc56b754e1 Get rid of the HAVE_PROTOTYPES configuration option, as well as the related JMETHOD and JPP macros. libjpeg-turbo has never supported compilers that don't handle prototypes. Doing so requires ansi2knr, which isn't even supported in the IJG code anymore.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1308 632fc199-4ca6-4c93-a231-07263d6284db
2014-05-16 10:43:44 +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
d4ab63d191 Fix several potential overflow issues identified by the community.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1114 632fc199-4ca6-4c93-a231-07263d6284db
2014-02-06 19:31:50 +00:00