kc3-lang/libjpeg-turbo/jcicc.c

• Show log

  Commit

• Hash : e8b40f3c
  Author :
  Date : 2022-11-01T21:45:39
  

  Vastly improve 12-bit JPEG integration
  
  The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac 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.
  

Download

• jcicc.c

• /*
   * jcicc.c
   *
   * Copyright (C) 1997-1998, Thomas G. Lane, Todd Newman.
   * Copyright (C) 2017, D. R. Commander.
   * For conditions of distribution and use, see the accompanying README.ijg
   * file.
   *
   * This file provides code to write International Color Consortium (ICC) device
   * profiles embedded in JFIF JPEG image files.  The ICC has defined a standard
   * for including such data in JPEG "APP2" markers.  The code given here does
   * not know anything about the internal structure of the ICC profile data; it
   * just knows how to embed the profile data in a JPEG file while writing it.
   */
  
  #define JPEG_INTERNALS
  #include "jinclude.h"
  #include "jpeglib.h"
  #include "jerror.h"
  
  
  /*
   * Since an ICC profile can be larger than the maximum size of a JPEG marker
   * (64K), we need provisions to split it into multiple markers.  The format
   * defined by the ICC specifies one or more APP2 markers containing the
   * following data:
   *      Identifying string      ASCII "ICC_PROFILE\0"  (12 bytes)
   *      Marker sequence number  1 for first APP2, 2 for next, etc (1 byte)
   *      Number of markers       Total number of APP2's used (1 byte)
   *      Profile data            (remainder of APP2 data)
   * Decoders should use the marker sequence numbers to reassemble the profile,
   * rather than assuming that the APP2 markers appear in the correct sequence.
   */
  
  #define ICC_MARKER  (JPEG_APP0 + 2)     /* JPEG marker code for ICC */
  #define ICC_OVERHEAD_LEN  14            /* size of non-profile data in APP2 */
  #define MAX_BYTES_IN_MARKER  65533      /* maximum data len of a JPEG marker */
  #define MAX_DATA_BYTES_IN_MARKER  (MAX_BYTES_IN_MARKER - ICC_OVERHEAD_LEN)
  
  
  /*
   * This routine writes the given ICC profile data into a JPEG file.  It *must*
   * be called AFTER calling jpeg_start_compress() and BEFORE the first call to
   * jpeg_write_scanlines().  (This ordering ensures that the APP2 marker(s) will
   * appear after the SOI and JFIF or Adobe markers, but before all else.)
   */
  
  GLOBAL(void)
  jpeg_write_icc_profile(j_compress_ptr cinfo, const JOCTET *icc_data_ptr,
                         unsigned int icc_data_len)
  {
    unsigned int num_markers;     /* total number of markers we'll write */
    int cur_marker = 1;           /* per spec, counting starts at 1 */
    unsigned int length;          /* number of bytes to write in this marker */
  
    if (icc_data_ptr == NULL || icc_data_len == 0)
      ERREXIT(cinfo, JERR_BUFFER_SIZE);
    if (cinfo->global_state < CSTATE_SCANNING)
      ERREXIT1(cinfo, JERR_BAD_STATE, cinfo->global_state);
  
    /* Calculate the number of markers we'll need, rounding up of course */
    num_markers = icc_data_len / MAX_DATA_BYTES_IN_MARKER;
    if (num_markers * MAX_DATA_BYTES_IN_MARKER != icc_data_len)
      num_markers++;
  
    while (icc_data_len > 0) {
      /* length of profile to put in this marker */
      length = icc_data_len;
      if (length > MAX_DATA_BYTES_IN_MARKER)
        length = MAX_DATA_BYTES_IN_MARKER;
      icc_data_len -= length;
  
      /* Write the JPEG marker header (APP2 code and marker length) */
      jpeg_write_m_header(cinfo, ICC_MARKER,
                          (unsigned int)(length + ICC_OVERHEAD_LEN));
  
      /* Write the marker identifying string "ICC_PROFILE" (null-terminated).  We
       * code it in this less-than-transparent way so that the code works even if
       * the local character set is not ASCII.
       */
      jpeg_write_m_byte(cinfo, 0x49);
      jpeg_write_m_byte(cinfo, 0x43);
      jpeg_write_m_byte(cinfo, 0x43);
      jpeg_write_m_byte(cinfo, 0x5F);
      jpeg_write_m_byte(cinfo, 0x50);
      jpeg_write_m_byte(cinfo, 0x52);
      jpeg_write_m_byte(cinfo, 0x4F);
      jpeg_write_m_byte(cinfo, 0x46);
      jpeg_write_m_byte(cinfo, 0x49);
      jpeg_write_m_byte(cinfo, 0x4C);
      jpeg_write_m_byte(cinfo, 0x45);
      jpeg_write_m_byte(cinfo, 0x0);
  
      /* Add the sequencing info */
      jpeg_write_m_byte(cinfo, cur_marker);
      jpeg_write_m_byte(cinfo, (int)num_markers);
  
      /* Add the profile data */
      while (length--) {
        jpeg_write_m_byte(cinfo, *icc_data_ptr);
        icc_data_ptr++;
      }
      cur_marker++;
    }
  }
  

Download