|
97772cba
|
2022-11-14T15:36:25
|
|
Merge branch 'ijg.lossless' into dev
Refer to #402
|
|
|
e8b40f3c
|
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.
|
|
|
932b5bb0
|
2022-03-09T10:50:51
|
|
IJG dox: Wordsmithing and formatting tweaks
- Remove the section in libjpeg.txt that advised against building
libjpeg as a shared library. We obviously do not follow that advice,
and libjpeg-turbo does guarantee backward ABI compatibility in our
libjpeg API library, even though libjpeg did not and does not.
(Future expansion of our libjpeg API library, if necessary, will be
accomplished using get/set functions that store the new parameters
in the opaque master structs. Refer to
https://github.com/mozilla/mozjpeg/commit/db2986c96fcebe10c8700081578e5305fd7bc7dc.)
- Unmention install.txt, which was never relevant to libjpeg-turbo and
was removed in v1.3 (6f96153c67e9a88775b457f998fc7fdd64c62cee).
- Remove extraneous spaces.
- Document the fact that TWO_FILE_COMMANDLINE must be defined in order
to use the two-file interface with cjpeg, djpeg, jpegtran, and
wrjpgcom. libjpeg-turbo never enables that interface by default.
|
|
|
73eff6ef
|
2021-11-30T15:06:54
|
|
cjpeg: auto. compr. gray BMP/GIF-->grayscale JPEG
aa7459050d7a50e1d8a99488902d41fbc118a50f was supposed to enable this for
BMP input images but didn't, due to a similar oversight to the one fixed
in the previous commit.
|
|
|
4d9f256b
|
2021-07-13T11:52:49
|
|
jpegtran: Add option to copy only ICC markers
Closes #533
|
|
|
7c1a1789
|
2020-11-05T16:04:55
|
|
Merge branch 'master' into dev
|
|
|
6e632af9
|
2020-11-04T10:13:06
|
|
Demote "fast" [I]DCT algorithms to legacy status
- Refer to the "slow" [I]DCT algorithms as "accurate" instead, since
they are not slow under libjpeg-turbo.
- Adjust documentation claims to reflect the fact that the "slow" and
"fast" algorithms produce about the same performance on AVX2-equipped
CPUs (because of the dual-lane nature of AVX2, it was not possible to
accelerate the "fast" algorithm beyond what was achievable with SSE2.)
Also adjust the claims to reflect the fact that the "fast" algorithm
tends to be ~5-15% faster than the "slow" algorithm on
non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo
SIMD extensions.
- Indicate the legacy status of the "fast" and float algorithms in the
documentation and cjpeg/djpeg usage info.
- Remove obsolete paragraph in the djpeg man page that suggested that
the float algorithm could be faster than the "fast" algorithm on some
CPUs.
|
|
|
88ae6098
|
2020-10-27T13:28:56
|
|
Merge branch 'ijg' into dev
- Restore GIF read/compressed GIF write support from jpeg-6a and
jpeg-9d.
- Integrate jpegtran -wipe and -drop options from jpeg-9a and jpeg-9d.
- Integrate jpegtran -crop extension (for expanding the image size) from
jpeg-9a and jpeg-9d.
- Integrate other minor code tweaks from jpeg-9*
|
|
9fc018fd
|
2020-01-12T00:00:00
|
|
The Independent JPEG Group's JPEG software v9d
|
|
|
96e4e7eb
|
2018-01-14T00:00:00
|
|
The Independent JPEG Group's JPEG software v9c
|
|
|
80acd5c4
|
2019-12-19T10:20:52
|
|
Remove code for the obsolete RLE image format
libjpeg-turbo never included that code, because it requires an external
library (the Utah Raster Toolkit.) The RLE image format was supplanted
by GIF in the late 1980s, so it is rarely seen these days. (It had a
lousy Weissman score, anyhow.)
|
|
|
d45434fe
|
2018-03-16T02:13:03
|
|
usage.txt: Remove Alt-Space non-ASCII character
|
|
|
da2a27ef
|
2017-03-18T16:15:14
|
|
Honor max_memory_to_use/JPEGMEM/-maxmemory
This re-introduces a feature of the obsolete system-specific libjpeg
memory managers-- namely the ability to limit the amount of main memory
used by the library during decompression or multi-pass compression.
This is mainly beneficial for two reasons:
- Works around a 2 GB limit in libFuzzer
- Allows security-sensitive applications to set a memory limit for the
JPEG decoder so as to work around the progressive JPEG exploit
(LJT-01-004) described here:
http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
This commit also removes obsolete documentation regarding the MS-DOS
memory manager (which itself was removed long ago) and changes the
documentation of the -maxmemory switch and JPEGMEM environment variable
to reflect the fact that backing stores are never used in libjpeg-turbo.
Inspired by:
https://github.com/caolanm/libjpeg-turbo/commit/066fee2e7d6834f24838bc1896aa38ca77209e3c
Closes #143
|
|
|
d4be4236
|
2016-02-19T10:35:41
|
|
usage.txt: Restore accidentally deleted phrase
It somehow got lost when merging the jpeg-9+ documentation changes.
|
|
|
54e6b8e8
|
2016-02-18T15:16:17
|
|
Include some comments/doc tweaks from jpeg-9+
|
|
|
a560e4b4
|
2016-01-17T00:00:00
|
|
The Independent JPEG Group's JPEG software v9b
|
|
|
fc11193e
|
2014-01-19T00:00:00
|
|
The Independent JPEG Group's JPEG software v9a
|
|
|
e7f88aec
|
2013-01-13T00:00:00
|
|
The Independent JPEG Group's JPEG software v9
|
|
|
6fa5ebdc
|
2015-12-17T10:41:51
|
|
cjpeg: Adjust claims RE: image quality settings
Quality values > 95 are not useless. They just may not provide as good
of a size vs. perceptual quality tradeoff as lower quality values. This
also displays the default quality value in the cjpeg usage.
Closes #39
|
|
|
5829cb23
|
2012-01-15T00:00:00
|
|
The Independent JPEG Group's JPEG software v8d
|
|
c39ec149
|
2011-01-16T00:00:00
|
|
The Independent JPEG Group's JPEG software v8c
|
|
|
989630f7
|
2010-01-10T00:00:00
|
|
The Independent JPEG Group's JPEG software v8
|
|
|
5996a25e
|
2009-06-27T00:00:00
|
|
The Independent JPEG Group's JPEG software v7
|
|
90d6c382
|
2014-05-12T09:08:39
|
|
Document -rgb option in djpeg man page; "gray-scale"="grayscale"
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1293 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
05524e67
|
2014-05-11T23:14:43
|
|
Document the fact that the fast integer FDCT is not fully accelerated for quality levels above 97 + additional wordsmithing
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1289 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8940e6ca
|
2014-05-11T09:46:28
|
|
Provide a more thorough description of the trade-offs between the various DCT/IDCT algorithms, based on new resarch
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1286 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b7753510
|
2014-05-11T09:36:25
|
|
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/branches/1.3.x@1285 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e5eaf374
|
2014-05-09T18:00:32
|
|
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
|
|
|
f73a27ca
|
2013-01-01T10:25:43
|
|
Add cjpeg -rgb option from jpeg-8d
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@880 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cf763c0c
|
2013-01-01T09:51:37
|
|
Further changes to the copyright/attribution 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@876 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
03badeab
|
2013-01-01T09:49:47
|
|
Further changes to the copyright/attribution 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/trunk@875 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a73e870a
|
2012-12-31T02:52:30
|
|
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
|
|
|
0bfb7805
|
2012-12-31T02:42:18
|
|
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/trunk@872 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
760ea8df
|
2012-02-07T23:25:19
|
|
Merge documentation and wordsmithing changes from 1.2, including promotion of -arithmetic to a "switch for advanced users"
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@783 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
66a69f04
|
2012-01-31T10:19:29
|
|
Incorporate a few upstream doc changes; grammar police; wordsmithing; Move -arithmetic into "switches for advanced users"; Additional documentation for IDCT scaling extensions
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@765 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ccd1bfdd
|
2012-01-31T09:53:46
|
|
Incorporate a few upstream doc changes; grammar police; wordsmithing; Move -arithmetic into "switches for advanced users"
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@764 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
66f97e68
|
2010-11-23T05:49:54
|
|
Support arithmetic encoding and decoding
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@299 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
39ea562c
|
2010-10-12T01:55:31
|
|
Document new v7/v8 features; .doc = .txt
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@252 632fc199-4ca6-4c93-a231-07263d6284db
|