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.
This commit is contained in:
DRC
2024-06-24 12:17:22 -04:00
parent bb3ab53157
commit 51d021bf01
8 changed files with 53 additions and 25 deletions

View File

@@ -24,6 +24,10 @@ response to a prematurely-terminated JPEG data stream.
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.
3.0.3
=====