From 723f507c11ddceaef974691ae302c14b50516903 Mon Sep 17 00:00:00 2001 From: beaglejoe Date: Mon, 17 Jan 2022 17:16:37 +0000 Subject: [PATCH] Update libjpeg to version 9e git-svn-id: https://svn.code.sf.net/p/speed-dreams/code/trunk@7914 30fe4595-0a0c-4342-8851-515496e4dcbd Former-commit-id: 84212601fc00a0fd1a3e18b497eda648639a1832 Former-commit-id: 30f71f24986b6308c274faf23e644d5d34f4b1af --- packaging/3rdParty-devel/Licenses/jpeg/README | 33 +++--- .../3rdParty-devel/Licenses/jpeg/libjpeg.txt | 51 ++++----- .../patches/jpeg-9e.CMakeLists.txt | 108 ++++++++++++++++++ .../thirdpartydefinitions.cmake | 4 +- 4 files changed, 153 insertions(+), 43 deletions(-) create mode 100644 packaging/3rdParty-devel/patches/jpeg-9e.CMakeLists.txt diff --git a/packaging/3rdParty-devel/Licenses/jpeg/README b/packaging/3rdParty-devel/Licenses/jpeg/README index 13b245c5c..d288f41b8 100644 --- a/packaging/3rdParty-devel/Licenses/jpeg/README +++ b/packaging/3rdParty-devel/Licenses/jpeg/README @@ -1,7 +1,7 @@ The Independent JPEG Group's JPEG software ========================================== -README for release 9d of 12-Jan-2020 +README for release 9e of 16-Jan-2022 ==================================== This distribution contains the ninth public release of the Independent JPEG @@ -38,6 +38,7 @@ User documentation: rdjpgcom, and wrjpgcom. *.1 Unix-style man pages for programs (same info as usage.txt). wizard.txt Advanced usage instructions for JPEG wizards only. + cdaltui.txt Description of alternate user interface for cjpeg/djpeg. change.log Version-to-version change highlights. Programmer and internal documentation: libjpeg.txt How to use the JPEG library in your own programs. @@ -115,7 +116,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-2020, Thomas G. Lane, Guido Vollbeding. +This software is copyright (C) 1991-2022, Thomas G. Lane, Guido Vollbeding. All Rights Reserved except as specified below. Permission is hereby granted to use, copy, modify, and distribute this @@ -165,7 +166,7 @@ The best short technical introduction to the JPEG compression algorithm is (Adjacent articles in that issue discuss MPEG motion picture compression, applications of JPEG, and related topics.) If you don't have the CACM issue handy, a PDF file containing a revised version of Wallace's article is -available at http://www.ijg.org/files/Wallace.JPEG.pdf. The file (actually +available at https://www.ijg.org/files/Wallace.JPEG.pdf. The file (actually a preprint for an article that appeared in IEEE Trans. Consumer Electronics) omits the sample images that appeared in CACM, but it includes corrections and some added material. Note: the Wallace article is copyright ACM and IEEE, @@ -209,17 +210,16 @@ document is Revision 3. And a contributed document ISO/IEC JTC1/SC29/WG1 N 5799 with title "Evolution of JPEG", June/July 2011, Berlin, Germany. IJG JPEG 9 introduces a reversible color transform for improved lossless compression which is described in a contributed document ISO/IEC JTC1/SC29/ -WG1 N 6080 with title "JPEG 9 Lossless Coding", June/July 2012, Paris, -France. +WG1 N 6080 with title "JPEG 9 Lossless Coding", June/July 2012, Paris, France. The JPEG standard does not specify all details of an interchangeable file format. For the omitted details we follow the "JFIF" conventions, version 2. JFIF version 1 has been adopted as Recommendation ITU-T T.871 (05/2011) : Information technology - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF). It is available as a -free download in PDF file format from http://www.itu.int/rec/T-REC-T.871. +free download in PDF file format from https://www.itu.int/rec/T-REC-T.871. A PDF file of the older JFIF document is available at -http://www.w3.org/Graphics/JPEG/jfif3.pdf. +https://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 @@ -227,7 +227,7 @@ 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 +https://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 uses our library to implement TIFF/JPEG per the Note. @@ -238,9 +238,11 @@ ARCHIVE LOCATIONS The "official" archive site for this software is www.ijg.org. The most recent released version can always be found there in -directory "files". This particular version will be archived as -http://www.ijg.org/files/jpegsrc.v9d.tar.gz, and in Windows-compatible -"zip" archive format as http://www.ijg.org/files/jpegsr9d.zip. +directory "files". This particular version will be archived +in Windows-compatible "zip" archive format as +https://www.ijg.org/files/jpegsr9e.zip, and +in Unix-compatible "tar.gz" archive format as +https://www.ijg.org/files/jpegsrc.v9e.tar.gz. The JPEG FAQ (Frequently Asked Questions) article is a source of some general information about JPEG. @@ -286,11 +288,12 @@ communication about JPEG configuration in Sigma Photo Pro software. Thank to Andrew Finkenstadt for hosting the ijg.org site. -Thank to Thomas G. Lane for the original design and development of -this singular software package. +Thank to Thomas G. Lane for the original design and development +of this singular software package. -Thank to Lars Goehler, Andreas Heinecke, Sebastian Fuss, Yvonne Roebert, -Andrej Werner, and Ulf-Dietrich Braumann for support and public relations. +Thank to Lars Goehler, Andreas Heinecke, Sebastian Fuss, +Yvonne Roebert, Andrej Werner, Ulf-Dietrich Braumann, +and Nina Ssymank for support and public relations. FILE FORMAT WARS diff --git a/packaging/3rdParty-devel/Licenses/jpeg/libjpeg.txt b/packaging/3rdParty-devel/Licenses/jpeg/libjpeg.txt index 4243c2463..546a86e2d 100644 --- a/packaging/3rdParty-devel/Licenses/jpeg/libjpeg.txt +++ b/packaging/3rdParty-devel/Licenses/jpeg/libjpeg.txt @@ -1,6 +1,6 @@ USING THE IJG JPEG LIBRARY -Copyright (C) 1994-2013, Thomas G. Lane, Guido Vollbeding. +Copyright (C) 1994-2019, Thomas G. Lane, Guido Vollbeding. This file is part of the Independent JPEG Group's software. For conditions of distribution and use, see the accompanying README file. @@ -2591,8 +2591,8 @@ different sizes. If the image dimensions are not a multiple of the MCU size, you must also pad the data correctly (usually, this is done by replicating the last column and/or row). The data must be padded to a multiple of a DCT block in each component: that is, each downsampled row must contain a -multiple of block_size valid samples, and there must be a multiple of -block_size sample rows for each component. (For applications such as +multiple of DCT_h_scaled_size valid samples, and there must be a multiple of +DCT_v_scaled_size sample rows for each component. (For applications such as conversion of digital TV images, the standard image size is usually a multiple of the DCT block size, so that no padding need actually be done.) @@ -2602,8 +2602,6 @@ jpeg_write_scanlines(). Before calling jpeg_start_compress(), you must do the following: * Set cinfo->raw_data_in to TRUE. (It is set FALSE by jpeg_set_defaults().) This notifies the library that you will be supplying raw data. - Furthermore, set cinfo->do_fancy_downsampling to FALSE if you want to use - real downsampled data. (It is set TRUE by jpeg_set_defaults().) * Ensure jpeg_color_space is correct --- an explicit jpeg_set_colorspace() call is a good idea. Note that since color conversion is bypassed, in_color_space is ignored, except that jpeg_set_defaults() uses it to @@ -2620,23 +2618,25 @@ The scanlines count passed to and returned from jpeg_write_raw_data is measured in terms of the component with the largest v_samp_factor. jpeg_write_raw_data() processes one MCU row per call, which is to say -v_samp_factor*block_size sample rows of each component. The passed num_lines -value must be at least max_v_samp_factor*block_size, and the return value -will be exactly that amount (or possibly some multiple of that amount, in -future library versions). This is true even on the last call at the bottom -of the image; don't forget to pad your data as necessary. +v_samp_factor*min_DCT_v_scaled_size sample rows of each component. The passed +num_lines value must be at least max_v_samp_factor*min_DCT_v_scaled_size, and +the return value will be exactly that amount (or possibly some multiple of +that amount, in future library versions). This is true even on the last call +at the bottom of the image; don't forget to pad your data as necessary. The required dimensions of the supplied data can be computed for each component as - cinfo->comp_info[i].width_in_blocks*block_size samples per row - cinfo->comp_info[i].height_in_blocks*block_size rows in image + cinfo->comp_info[i].width_in_blocks * + cinfo->comp_info[i].DCT_h_scaled_size samples per row + cinfo->comp_info[i].height_in_blocks * + cinfo->comp_info[i].DCT_v_scaled_size rows in image after jpeg_start_compress() has initialized those fields. If the valid data is smaller than this, it must be padded appropriately. For some sampling factors and image sizes, additional dummy DCT blocks are inserted to make the image a multiple of the MCU dimensions. The library creates such dummy blocks itself; it does not read them from your supplied data. Therefore you -need never pad by more than block_size samples. An example may help here. -Assume 2h2v downsampling of YCbCr data, that is +need never pad by more than DCT_scaled_size samples. +An example may help here. Assume 2h2v downsampling of YCbCr data, that is cinfo->comp_info[0].h_samp_factor = 2 for Y cinfo->comp_info[0].v_samp_factor = 2 cinfo->comp_info[1].h_samp_factor = 1 for Cb @@ -2662,27 +2662,26 @@ destination module suspends, jpeg_write_raw_data() will return 0. In this case the same data rows must be passed again on the next call. -Decompression with raw data output implies bypassing all postprocessing. -You must deal with the color space and sampling factors present in the -incoming file. If your application only handles, say, 2h1v YCbCr data, -you must check for and fail on other color spaces or other sampling factors. +Decompression with raw data output implies bypassing all postprocessing: +you cannot ask for color quantization, for instance. More seriously, you +must deal with the color space and sampling factors present in the incoming +file. If your application only handles, say, 2h1v YCbCr data, you must +check for and fail on other color spaces or other sampling factors. The library will not convert to a different color space for you. To obtain raw data output, set cinfo->raw_data_out = TRUE before jpeg_start_decompress() (it is set FALSE by jpeg_read_header()). Be sure to verify that the color space and sampling factors are ones you can handle. -Furthermore, set cinfo->do_fancy_upsampling = FALSE if you want to get real -downsampled data (it is set TRUE by jpeg_read_header()). Then call jpeg_read_raw_data() in place of jpeg_read_scanlines(). The decompression process is otherwise the same as usual. jpeg_read_raw_data() returns one MCU row per call, and thus you must pass a -buffer of at least max_v_samp_factor*block_size scanlines (scanline counting -is the same as for raw-data compression). The buffer you pass must be large -enough to hold the actual data plus padding to DCT-block boundaries. As with -compression, any entirely dummy DCT blocks are not processed so you need not -allocate space for them, but the total scanline count includes them. The -above example of computing buffer dimensions for raw-data compression is +buffer of at least max_v_samp_factor*min_DCT_v_scaled_size scanlines (scanline +counting is the same as for raw-data compression). The buffer you pass must +be large enough to hold the actual data plus padding to DCT-block boundaries. +As with compression, any entirely dummy DCT blocks are not processed so you +need not allocate space for them, but the total scanline count includes them. +The above example of computing buffer dimensions for raw-data compression is equally valid for decompression. Input suspension is supported with raw-data decompression: if the data source diff --git a/packaging/3rdParty-devel/patches/jpeg-9e.CMakeLists.txt b/packaging/3rdParty-devel/patches/jpeg-9e.CMakeLists.txt new file mode 100644 index 000000000..7b4ca4e4b --- /dev/null +++ b/packaging/3rdParty-devel/patches/jpeg-9e.CMakeLists.txt @@ -0,0 +1,108 @@ +# +#============================================================================== +# +# file : CMakeLists.txt +# created : Feb 11 2020 +# copyright : (C) 2020 Joe Thompson +# email : beaglejoe@users.sourceforge.net +# version : $Id$ +# +#============================================================================== +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . +# +#============================================================================== +# +cmake_minimum_required(VERSION 2.8) + +project(jpeg C) + +set(VERSION "9e") + + +include_directories(include) + +set(jpeg_SOURCES jaricom.c + jcapimin.c + jcapistd.c + jcarith.c + jccoefct.c + jccolor.c + jcdctmgr.c + jchuff.c + jcinit.c + jcmainct.c + jcmarker.c + jcmaster.c + jcomapi.c + jcparam.c + jcprepct.c + jcsample.c + jctrans.c + jdapimin.c + jdapistd.c + jdarith.c + jdatadst.c + jdatasrc.c + jdcoefct.c + jdcolor.c + jddctmgr.c + jdhuff.c + jdinput.c + jdmainct.c + jdmarker.c + jdmaster.c + jdmerge.c + jdpostct.c + jdsample.c + jdtrans.c + jerror.c + jfdctflt.c + jfdctfst.c + jfdctint.c + jidctflt.c + jidctfst.c + jidctint.c + jmemmgr.c + jmemnobs.c + jquant1.c + jquant2.c + jutils.c + ) + +set(jpeg_HEADERS jconfig.h + jdct.h + jerror.h + jinclude.h + jmemsys.h + jmorecfg.h + jpegint.h + jpeglib.h + jversion.h + ) + + +add_library(jpeg STATIC ${jpeg_SOURCES} ${jpeg_HEADERS}) + + +install(FILES jconfig.h + jerror.h + jmorecfg.h + jpeglib.h + DESTINATION include) + +install(TARGETS jpeg + RUNTIME DESTINATION bin + LIBRARY DESTINATION lib + ARCHIVE DESTINATION lib) \ No newline at end of file diff --git a/packaging/3rdParty-devel/thirdpartydefinitions.cmake b/packaging/3rdParty-devel/thirdpartydefinitions.cmake index 3f10a1dc1..6af694dcb 100644 --- a/packaging/3rdParty-devel/thirdpartydefinitions.cmake +++ b/packaging/3rdParty-devel/thirdpartydefinitions.cmake @@ -89,11 +89,11 @@ set(PLIB_URL http://plib.sourceforge.net/dist/${PLIB_FILE}) set(PLIB_HASH SHA256=485b22bf6fdc0da067e34ead5e26f002b76326f6371e2ae006415dea6a380a32) # jpeg -set(JPEG_VERSION 9d) +set(JPEG_VERSION 9e) set(JPEG_PROJECT jpeg-${JPEG_VERSION}) set(JPEG_FILE jpegsrc.v${JPEG_VERSION}.tar.gz) set(JPEG_URL https://ijg.org/files/${JPEG_FILE}) -set(JPEG_HASH SHA256=2303a6acfb6cc533e0e86e8a9d29f7e6079e118b9de3f96e07a71a11c082fa6a) +set(JPEG_HASH SHA256=4077d6a6a75aeb01884f708919d25934c93305e49f7e3f36db9129320e6f4f3d) # freeSOLID set(FREESOLID_VERSION 2.1.2)