|
94c64ead
|
2024-06-17T20:27:57
|
|
Various doc tweaks
- "bits per component" = "bits per sample"
Describing the data precision of a JPEG image using "bits per
component" is technically correct, but "bits per sample" is the
terminology that the JPEG-1 spec uses. Also, "bits per component" is
more commonly used to describe the precision of packed-pixel formats
(as opposed to "bits per pixel") rather than planar formats, in which
all components are grouped together.
- Unmention legacy display technologies. Colormapped and monochrome
displays aren't a thing anymore, and even when they were still a
thing, it was possible to display full-color images to them. In 1991,
when JPEG decompression time was measured in minutes per megapixel, it
made sense to keep a decompressed copy of JPEG images on disk, in a
format that could be displayed without further color conversion (since
color conversion was slow and memory-intensive.) In 2024, JPEG
decompression time is measured in milliseconds per megapixel, and
color conversion is even faster. Thus, JPEG images can be
decompressed, displayed, and color-converted (if necessary) "on the
fly" at speeds too fast for human vision to perceive. (In fact, your
TV performs much more complicated decompression algorithms at least 60
times per second.)
- Document that color quantization (and associated features), GIF
input/output, Targa input/output, and OS/2 BMP input/output are legacy
features. Legacy status doesn't necessarily mean that the features
are deprecated. Rather, it is meant to discourage users from using
features that may be of little or no benefit on modern machines (such
as low-quality modes that had significant performance advantages in
the early 1990s but no longer do) and that are maintained on a
break/fix basis only.
- General wordsmithing, grammar/punctuation policing, and formatting
tweaks
- Clarify which data precisions each cjpeg input format and each djpeg
output format supports.
- cjpeg.1: Remove unnecessary and impolitic statement about the -targa
switch.
- Adjust or remove performance claims to reflect the fact that:
* On modern machines, the djpeg "-fast" switch has a negligible effect
on performance.
* There is a measurable difference between the performance of Floyd-
Steinberg dithering and no dithering, but it is not likely
perceptible to most users.
* There is a measurable difference between the performance of 1-pass
and 2-pass color quantization, but it is not likely perceptible to
most users.
* There is a measurable difference between the performance of
full-color and grayscale output when decompressing a full-color JPEG
image, but it is not likely perceptible to most users.
* IDCT scaling does not necessarily improve performance. (It
generally does if the scaling factor is <= 1/2 and generally doesn't
if the scaling factor is > 1/2, at least on my machine. The
performance claim made in jpeg-6b was probably invalidated when we
merged the additional scaling factors from jpeg-7.)
- Clarify which djpeg switches/output formats cannot be used when
decompressing lossless JPEG images.
- Remove djpeg hints, since those involve quality vs. speed tradeoffs
that are no longer relevant for modern machines.
- Remove documentation regarding using color quantization with 16-bit
data precision. (Color quantization requires lossy mode.)
- Java: Fix typos in TJDecompressor.decompress12() and
TJDecompressor.decompress16() documentation.
- jpegtran.1: Fix truncated paragraph
In a man page, a single quote at the start of a line is interpreted as
a macro.
Closes #775
- libjpeg.txt:
* Mention J16SAMPLE data type (oversight.)
* Remove statement about extending jdcolor.c. (libjpeg-turbo is not
quite as DIY as libjpeg once was.)
* Remove paragraph about tweaking the various typedefs in jmorecfg.h.
It is no longer relevant for modern machines.
* Remove caveat regarding systems with ints less than 16 bits wide.
(ANSI/ISO C requires an int to be at least 16 bits wide, and
libjpeg-turbo has never supported non-ANSI compilers.)
- usage.txt:
* Add copyright header.
* Document cjpeg -icc, -memdst, -report, -strict, and -version
switches.
* Document djpeg -icc, -maxscans, -memsrc, -report, -skip, -crop,
-strict, and -version switches.
* Document jpegtran -icc, -maxscans, -report, -strict, and -version
switches.
|
|
|
4d9f256b
|
2021-07-13T11:52:49
|
|
jpegtran: Add option to copy only ICC markers
Closes #533
|
|
|
a8656d70
|
2020-10-27T15:35:21
|
|
jpegtran.1: Minor formatting tweak
|
|
|
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
|
|
|
e98b0612
|
2019-12-18T15:12:33
|
|
Add fault tolerance features to djpeg and jpegtran
- Enable progress reporting at run time using a new -report argument
(cjpeg now supports that argument as well)
- Limit the allowable number of scans using a new -maxscans argument
- Treat warnings as fatal using a new -strict argument
This mainly demonstrates how to work around the two issues with the
JPEG standard described here:
https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
since those and similar issues continue to be erroneously reported as
libjpeg-turbo bugs.
|
|
|
2ac4e9d9
|
2017-06-26T21:58:32
|
|
Merge branch 'master' into dev
|
|
|
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
|
|
|
44b2399a
|
2017-01-19T15:18:57
|
|
libjpeg API: Support reading/writing ICC profiles
This commit does the following:
-- Merges the two glueware functions (read_icc_profile() and
write_icc_profile()) from iccjpeg.c, which is contained in downstream
projects such as LCMS, Ghostscript, Mozilla, etc. These functions were
originally intended for inclusion in libjpeg, but Tom Lane left the IJG
before that could be accomplished. Since then, programs and libraries
that needed to embed/extract ICC profiles in JPEG files had to include
their own local copy of iccjpeg.c, which is suboptimal.
-- The new functions were prefixed with jpeg_ and split into separate
files for the compressor and decompressor, per the existing libjpeg
coding standards.
-- jpeg_write_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_start_compress() or if it is passed NULL arguments.
-- jpeg_read_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_read_header() or if it is passed NULL arguments. It will also
now trigger libjpeg warnings if the ICC profile data is corrupt.
-- The code comments have been wordsmithed.
-- Note that the one-line setup_read_icc_profile() function was not
included. Instead, libjpeg.txt now documents the need to call
jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling
jpeg_read_header(), if jpeg_read_icc_profile() is to be used.
-- Adds documentation for the new functions to libjpeg.txt.
-- Adds an -icc switch to cjpeg and jpegtran that allows those programs
to embed an ICC profile in the JPEG files they generate.
-- Adds an -icc switch to djpeg that allows that program to extract an
ICC profile from a JPEG file while decompressing.
-- Adds appropriate unit tests for all of the above.
-- Bumps the SO_AGE of the libjpeg API library to indicate the presence
of new API functions.
Note that the licensing information was obtained from:
https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180
|
|
|
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
|
|
bc79e068
|
1995-08-02T00:00:00
|
|
The Independent JPEG Group's JPEG software v6
|
|
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
|
|
|
5ead57a3
|
1998-03-27T00:00:00
|
|
The Independent JPEG Group's JPEG software v6b
|
|
9665f5e3
|
2014-11-22T04:04:38
|
|
Print the library version and exit whenever -version is passed to cjpeg, djpeg, or jpegtran.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1422 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
251db636
|
2013-01-01T10:51:16
|
|
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@884 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
|
|
|
c04bd3cc
|
2010-10-10T02:15:56
|
|
Implement lossless crop feature from jpeg v7 and v8
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@243 632fc199-4ca6-4c93-a231-07263d6284db
|
|
c8753072
|
2006-05-25T05:01:55
|
|
Migrating to new directory structure adopted from the RealVNC's source tree. More changes will follow.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1 632fc199-4ca6-4c93-a231-07263d6284db
|