Wikipedia

JPEG: Difference between revisions

Browse history interactively
[accepted revision][accepted revision]
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Reverted 3 edits by 98.0.33.87 (talk): That's unrelated
Removed material introduced by /Jagged 85 sockpuppet who was banned from Wikipedia for systematic abuse of sources. See https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Jagged_85 and https://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_comment/Jagged_85 for more details
(45 intermediate revisions by 36 users not shown)
Line 2:
{{other uses|JPEG (disambiguation)}}
{{redirect|JPG|other uses|JPG (disambiguation)}}
{{Pp-pc1pc|small=yes}}
{{use dmy dates|date=November 2023}}
{{Infobox file format
Line 29:
The [[Joint Photographic Experts Group]] created the standard in 1992.<ref name="heise">{{cite news |date=7 October 2016 |title=JPEG: 25 Jahre und kein bisschen alt |language=de |work=[[:de:Heise online]] |url=https://www.heise.de/newsticker/meldung/JPEG-25-Jahre-und-kein-bisschen-alt-3342519.html |access-date=5 September 2019 |archive-date=5 September 2019 |archive-url=https://web.archive.org/web/20190905025359/https://www.heise.de/newsticker/meldung/JPEG-25-Jahre-und-kein-bisschen-alt-3342519.html |url-status=live |first=Andrea |last=Trinkwalder |trans-title=JPEG: 25 years (old) and not a bit old}}</ref> JPEG was largely responsible for the proliferation of digital images and [[digital photo]]s across the Internet and later [[social media]].<ref name="Atlantic">{{cite web |title=What Is a JPEG? The Invisible Object You See Every Day |url=https://www.theatlantic.com/technology/archive/2013/09/what-is-a-jpeg-the-invisible-object-you-see-every-day/279954/ |access-date=13 September 2019 |website=[[The Atlantic]] |date=24 September 2013 |archive-date=9 October 2019 |archive-url=https://web.archive.org/web/20191009054159/https://www.theatlantic.com/technology/archive/2013/09/what-is-a-jpeg-the-invisible-object-you-see-every-day/279954/ |url-status=live |first=Paul |last=Caplan|url-access=limited}}</ref>{{Circular reference|date=November 2023}}<!--The Atlantic link to the legal issues section of this Wikipedia article in the open part of their article, makes one suspicious that their article is largely based on Wikipedia and thus invalid as a source.--> JPEG compression is used in a number of [[image file formats]]. JPEG/[[Exif]] is the most common image format used by [[digital camera]]s and other photographic image capture devices; along with JPEG/[[JFIF]], it is the most common format for storing and transmitting [[photographic image]]s on the [[World Wide Web]].<ref>{{cite web|url=http://httparchive.org/interesting.php#imageformats|title=HTTP Archive – Interesting Stats|website=httparchive.org|access-date=2016-04-06}}</ref> These format variations are often not distinguished and are simply called JPEG.
 
The [[Internet media type|MIME media type]] for JPEG is "image/jpeg,", except in older [[Internet Explorer]] versions, which provide a MIME type of "image/pjpeg" when uploading JPEG images.<ref>{{cite web|url=https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775147(v=vs.85)|title=MIME Type Detection in Internet Explorer|date=13 July 2016 |publisher=Microsoft|access-date=2 November 2022|archive-date=30 October 2022|archive-url=https://web.archive.org/web/20221030181306/https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775147(v=vs.85)|url-status=live}}</ref> JPEG files usually have a [[filename extension]] of "jpg" or "jpeg". JPEG/JFIF supports a maximum image size of 65,535×65,535 pixels,<ref>{{cite web|url=http://www.jpeg.org/public/jfif.pdf|title=JPEG File Interchange Format|date=3 September 2014|access-date=16 October 2017|url-status=bot: unknown|archive-url=https://web.archive.org/web/20140903080533/http://www.jpeg.org/public/jfif.pdf|archive-date=3 September 2014}}</ref> hence up to 4 gigapixels for an [[aspect ratio (image)|aspect ratio]] of 1:1. In 2000, the JPEG group introduced a format intended to be a successor, [[JPEG 2000]], but it was unable to replace the original JPEG as the dominant image standard.<ref>{{cite web |title=Why JPEG 2000 Never Took Off |url=https://blog.ansi.org/2018/07/why-jpeg-2000-never-used-standard-iso-iec/ |website=[[American National Standards Institute]] |access-date=13 September 2019 |date=10 July 2018 |archive-date=16 December 2018 |archive-url=https://web.archive.org/web/20181216031019/https://blog.ansi.org/2018/07/why-jpeg-2000-never-used-standard-iso-iec/ |url-status=live }}</ref>
 
==History==
===Background===
The original JPEG specification published in 1992 implements processes from various earlier [[Academic paper|research papers]] and [[patent]]s cited by the [[CCITT]] (now [[ITU-T]]) and Joint Photographic Experts Group.<ref name="t81">{{cite web |title=T.81 – DIGITAL COMPRESSION AND CODING OF CONTINUOUS-TONE STILL IMAGES – REQUIREMENTS AND GUIDELINES |url=https://www.w3.org/Graphics/JPEG/itu-t81.pdf |publisher=[[CCITT]] |date=September 1992 |access-date=12 July 2019 |archive-date=30 December 2019 |archive-url=https://web.archive.org/web/20191230093239/http://www.w3.org/Graphics/JPEG/itu-t81.pdf |url-status=live }}</ref>
 
The JPEG specification cites patents from several companies. The following patents provided the basis for its [[arithmetic coding]] algorithm.<ref name="t81"/>
Line 42:
* [[Mitsubishi Electric]]
** {{Patent|JP|H02202267}} ([https://patents.google.com/patent/JPH02202267A 1021672]) {{ndash}} January 21, 1989 {{ndash}} Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida {{ndash}} Coding system
** {{Patent|JP|H03247123}} ([https://patents.google.com/patent/JPH0834434B2/en 2-46275]) {{ndash}} February 26, 1990 {{ndash}} FumitakaTomohiro OnoKimura, TomohiroShigenori KimuraKino, MasayukiFumitaka YoshidaOno, and ShigenoriMasayuki KinoYoshida {{ndash}} Coding apparatus and coding method
 
The JPEG specification also cites three other patents from IBM. Other companies cited as patent holders include [[AT&T]] (two patents) and [[Canon Inc.]]<ref name="t81"/> Absent from the list is {{US patent|4698672}}, filed by [[Compression Labs, Inc.|Compression Labs]]' Wen-Hsiung Chen and Daniel J. Klenke in October 1986. The patent describes a DCT-based image compression algorithm, and would later be a cause of controversy in 2002 (see ''[[#Patent controversy|Patent controversy]]'' below).<ref name="cnet">{{cite news |last1=Lemos |first1=Robert |title=Finding patent truth in JPEG claim |url=https://www.cnet.com/news/finding-patent-truth-in-jpeg-claim/ |access-date=13 July 2019 |work=[[CNET]] |date=23 July 2002 |archive-date=13 July 2019 |archive-url=https://web.archive.org/web/20190713165715/https://www.cnet.com/news/finding-patent-truth-in-jpeg-claim/ |url-status=live }}</ref> However, the JPEG specification did cite two earlier research papers by Wen-Hsiung Chen, published in 1977 and 1984.<ref name="t81"/>
Line 101:
|-
| Part 4
| [https://www.iso.org/standard/2543185634.html ISO/IEC 10918-4:19992024]
| [http://www.itu.int/rec/T-REC-T.86 T.86 (06/98)]
| {{dts|abbr=on|1998-06-18}}
|
| {{dts|abbr=on|2012-06-29}}
| Appn Markers
| Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT)
| methods for registering some of the parameters used to extend JPEG
|-
Line 150:
In 2002, [[Forgent Networks]] asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987: {{US patent|4698672}} by [[Compression Labs, Inc.|Compression Labs]]' Wen-Hsiung Chen and Daniel J. Klenke.<ref name="cnet"/><ref>{{cite news |title=Forgent's JPEG Patent |url=https://pmt.sourceforge.io/SVG-patents/jpeg.html |access-date=13 July 2019 |work=[[SourceForge]] |date=2002 |archive-date=13 May 2019 |archive-url=https://web.archive.org/web/20190513043628/https://pmt.sourceforge.io/SVG-patents/jpeg.html |url-status=live }}</ref> While Forgent did not own Compression Labs at the time, Chen later sold Compression Labs to Forgent, before Chen went on to work for [[Cisco]]. This led to Forgent acquiring ownership over the patent.<ref name="cnet"/> Forgent's 2002 announcement created a furor reminiscent of [[Unisys]]' attempts to assert its rights over the GIF image compression standard.
 
The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by [[prior art]],<ref>{{cite web |url=http://www.jpeg.org/newsrel1.html |title=Concerning recent patent claims |website=Jpeg.org |date=2002-07-19 |access-date=2011-05-29 |archive-url=https://web.archive.org/web/20070714232941/http://www.jpeg.org/newsrel1.html |archive-date=2007-07-14 }}</ref> a view shared by various experts.<ref name="cnet"/><ref>{{cite web|url=http://www.algovision-luratech.com/company/news/patentquarrel.jsp?OnlineShopId=164241031081525276 |title=JPEG and JPEG2000&nbsp;– Between Patent Quarrel and Change of Technology |access-date=2017-04-16 |url-status=bot: unknown |archive-url=https://web.archive.org/web/20040817154508/http://www.algovision-luratech.com/company/news/patentquarrel.jsp?OnlineShopId=164241031081525276 |archive-date=August 17, 2004 }}</ref>
 
Between 2002 and 2004, Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. In April 2004, Forgent sued 31 other companies to enforce further license payments. In July of the same year, a consortium of 21 large computer companies filed a countersuit, with the goal of invalidating the patent. In addition, Microsoft launched a separate lawsuit against Forgent in April 2005.<ref>{{cite web|title=Graphics patent suit fires back at Microsoft|publisher=[[CNET News]]|first=Dawn|last=Kawamoto|date=April 22, 2005|url=https://www.cnet.com/culture/graphics-patent-suit-fires-back-at-microsoft/|access-date=2023-01-20|archive-date=2023-01-20|archive-url=https://web.archive.org/web/20230120140214/https://www.cnet.com/culture/graphics-patent-suit-fires-back-at-microsoft/|url-status=live}}</ref> In February 2006, the [[United States Patent and Trademark Office]] agreed to re-examine Forgent's JPEG patent at the request of the Public Patent Foundation.<ref name="reexam">{{cite web |title=Trademark Office Re-examines Forgent JPEG Patent |website=Publish.com |date=February 3, 2006 |url=http://www.publish.com/c/a/Graphics-Tools/Trademark-Office-Reexamines-Forgent-JPEG-Patent/ |access-date=2009-01-28 |archive-date=2016-05-15 |archive-url=http://arquivo.pt/wayback/20160515113624/http://www.publish.com/c/a/Graphics-Tools/Trademark-Office-Reexamines-Forgent-JPEG-Patent/ }}</ref> On May 26, 2006, the USPTO found the patent invalid based on prior art. The USPTO also found that Forgent knew about the prior art, yet it intentionally avoided telling the Patent Office. This makes any appeal to reinstate the patent highly unlikely to succeed.<ref>{{cite web |title=USPTO: Broadest Claims Forgent Asserts Against JPEG Standard Invalid |website=[[Groklaw.net]] |date=May 26, 2006 |url=http://www.groklaw.net/article.php?story=20060526105754880 |access-date=2007-07-21 |archive-date=2019-05-16 |archive-url=https://web.archive.org/web/20190516201650/http://www.groklaw.net/article.php?story=20060526105754880 |url-status=live }}</ref>
Line 181:
 
==JPEG compression==
JPEG uses a lossy form of compression based on the [[Discrete cosine transform|discrete cosine transform (DCT)]]. This mathematical operation converts each frame/field of the video source from the spatial (2D) domain into the frequency domain (a.k.a. transform domain). A perceptual model based loosely on the human psychovisual system discards high-frequency information, i.e. sharp transitions in intensity, and color hue. In the transform domain, the process of reducing information is called quantization. In simpler terms, quantization is a method for optimally reducing a large number scale (with different occurrences of each number) into a smaller one, and the transform-domain is a convenient representation of the image because the high-frequency coefficients, which contribute less to the overall picture than other coefficients, are characteristically small-values with high compressibility. The quantized coefficients are then sequenced and losslessly packed into the output bitstream. Nearly all software implementations of JPEG permit user control over the compression ratio (as well as other optional parameters), allowing the user to trade off picture-quality for smaller file size. In embedded applications (such as miniDV, which uses a similar DCT-compression scheme), the parameters are pre-selected and fixed for the application.
 
The compression method is usually [[Lossy compression|lossy]], meaning that some original image information is lost and cannot be restored, possibly affecting image quality. There is an optional [[Lossless JPEG|lossless]] mode defined in the JPEG standard. However, this mode is not widely supported in products.
Line 325:
 
===Encoding===
Many of the options in the JPEG standard are not commonly used, and as mentioned above, most image software uses the simpler JFIF format when creating a JPEG file, which among other things specifies the encoding method. Here is a brief description of one of the more common methods of encoding when applied to an input that has 24 [[bits per pixel]] (eight each of [[RGB color model|red, green, and blue]]). This particular option is a [[lossy data compression]] method. They are represented in [[Matrix (mathematics)|matrices]] below.
 
====Color space transformation====
Line 582:
With this in mind, the sequence from earlier becomes:
 
:(0, 2)(-3);(1, 2)(-3);(0, 12)(-2);(0, 23)(-6);(0, 12)(2);(0, 13)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);
:(0, 23)(5);(0, 1)(1);(0, 12)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 12)(2);(5, 1)(-1);(0, 1)(-1);(0, 0);
 
(The first value in the matrix, −26, is the DC coefficient; it is not encoded the same way. See above.)
Line 822:
 
==Implementations==
A very important implementation of a JPEG codec is the free programming library '''[[libjpeg]]''' of the Independent JPEG Group. It was first published in 1991 and was key for the success of the standard. This library was used in countless applications.<ref name="JPEG-homepage">{{cite web|url=http://jpeg.org/jpeg|title=Overview of JPEG|website=jpeg.org|access-date=2017-10-16|archive-date=2017-10-21|archive-url=https://web.archive.org/web/20171021212812/https://jpeg.org/jpeg/|url-status=live}}</ref> The development went quiet in 1998; when libjpeg resurfaced with the 2009 version 7, it broke [[Application binary interface|ABI compatibility]] with previous versions. Version 8 of 2010 introduced non-standard extensions, a decision criticized by the original IJG leader Tom Lane.<ref name=TomSmartScale>Tom Lane, January 16, 2013: [https://lists.fedoraproject.org/pipermail/devel/2013-January/176400.html jpeg-9, API/ABI compatibility, and the future role of this project] {{Webarchive|url=https://web.archive.org/web/20181204231539/https://lists.fedoraproject.org/pipermail/devel/2013-January/176400.html |date=2018-12-04 }}</ref>
 
'''libjpeg-turbo''', forked from the 1998 libjpeg 6b, improves on libjpeg with [[SIMD]] optimizations. Originally seen as a maintained fork of libjpeg, it has become more popular after the incompatible changes of 2009.<ref name="turbo-software">[http://libjpeg-turbo.virtualgl.org/About/Software Software That Uses or Provides libjpeg-turbo] {{Webarchive|url=https://web.archive.org/web/20170318000736/http://libjpeg-turbo.virtualgl.org/About/Software |date=2017-03-18 }}. February 9, 2012.</ref><ref name="Chromium">[http://code.google.com/p/chromium/issues/detail?id=48789#c19 Issue 48789 – chromium – Use libjpeg-turbo instead of libjpeg] {{Webarchive|url=https://web.archive.org/web/20150801035040/http://code.google.com/p/chromium/issues/detail?id=48789#c19 |date=2015-08-01 }}. April 14, 2011.</ref> In 2019, it became the ITU|ISO/IEC reference implementation as ISO/IEC 10918-7 and ITU-T T.873.<ref name=refimpl>{{cite web |title=ISO/IEC 10918-7: 2019 Information technology — Digital compression and coding of continuous-tone still images — Part 7: Reference software |url=https://www.iso.org/standard/75845.html |website=ISO |language=en |access-date=2022-05-07 |archive-date=2022-05-07 |archive-url=https://web.archive.org/web/20220507152432/https://www.iso.org/standard/75845.html |url-status=live }}{{cite web |title=T.873 (05/19): Information technology - Digital compression and coding of continuous-tone still images: Reference software |url=https://www.itu.int/rec/T-REC-T.873-201905-S/en |website=www.itu.int |access-date=2023-03-01 |archive-date=2022-06-02 |archive-url=https://web.archive.org/web/20220602173200/https://www.itu.int/rec/T-REC-T.873-201905-S/en |url-status=live }}</ref>▼
 
ISO/IEC Joint Photography Experts Group maintains the other reference software implementation under the [[JPEG XT]] heading. It can encode both base JPEG (ISO/IEC 10918-1 and 18477–1) and [[JPEG XT]] extensions (ISO/IEC 18477 Parts 2 and 6–9), as well as [[JPEG-LS]] (ISO/IEC 14495).<ref>{{cite web|url=https://jpeg.org/jpegxt/software.html|title=JPEG - JPEG XT|website=jpeg.org|access-date=2018-03-03|archive-date=2018-03-04|archive-url=https://web.archive.org/web/20180304055159/https://jpeg.org/jpegxt/software.html|url-status=live}}</ref> In 2016, "JPEG on steroids" was introduced as an option for the ISO JPEG XT reference implementation.<ref>{{cite book |last1=Richter |first1=Thomas |title=2016 IEEE International Conference on Image Processing (ICIP) |chapter=JPEG on STEROIDS: Common optimization techniques for JPEG image compression |date=September 2016 |pages=61–65 |doi=10.1109/ICIP.2016.7532319 |isbn=978-1-4673-9961-6 |s2cid=14922251}}</ref>▼
▲''libjpeg-turbo'', forked from the 1998 libjpeg 6b, improves on libjpeg with [[SIMD]] optimizations. Originally seen as a maintained fork of libjpeg, it has become more popular after the incompatible changes of 2009.<ref name="turbo-software">[http://libjpeg-turbo.virtualgl.org/About/Software Software That Uses or Provides libjpeg-turbo] {{Webarchive|url=https://web.archive.org/web/20170318000736/http://libjpeg-turbo.virtualgl.org/About/Software |date=2017-03-18 }}. February 9, 2012.</ref><ref name="Chromium">[http://code.google.com/p/chromium/issues/detail?id=48789#c19 Issue 48789 – chromium – Use libjpeg-turbo instead of libjpeg] {{Webarchive|url=https://web.archive.org/web/20150801035040/http://code.google.com/p/chromium/issues/detail?id=48789#c19 |date=2015-08-01 }}. April 14, 2011.</ref> In 2019, it became the ITU|ISO/IEC reference implementation as ISO/IEC 10918-7 and ITU-T T.873.<ref name=refimpl>{{cite web |title=ISO/IEC 10918-7: 2019 Information technology — Digital compression and coding of continuous-tone still images — Part 7: Reference software |url=https://www.iso.org/standard/75845.html |website=ISO |language=en |access-date=2022-05-07 |archive-date=2022-05-07 |archive-url=https://web.archive.org/web/20220507152432/https://www.iso.org/standard/75845.html |url-status=live }}{{cite web |title=T.873 (05/19): Information technology - Digital compression and coding of continuous-tone still images: Reference software |url=https://www.itu.int/rec/T-REC-T.873-201905-S/en |website=www.itu.int |access-date=2023-03-01 |archive-date=2022-06-02 |archive-url=https://web.archive.org/web/20220602173200/https://www.itu.int/rec/T-REC-T.873-201905-S/en |url-status=live }}</ref>
 
There is persistent interest in encoding JPEG in unconventional ways that maximize image quality for a given file size. In 2014, [[Mozilla]] created mozjpeg'''MozJPEG''' from libjpeg-turbo, a slower but higher-quality encoder intended for web images.<ref>{{cite web |title=Introducing the 'mozjpeg' Project |url=https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/ |website=Mozilla Research |date=5 March 2014 |access-date=2023-03-01 |archive-date=2023-03-01 |archive-url=https://web.archive.org/web/20230301034809/https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/ |url-status=live }}</ref> In 2016, "JPEG on steroids" was introduced as an option for the ISO JPEG XT reference implementation.<ref>{{cite book |last1=Richter |first1=Thomas |title=2016 IEEE International Conference on Image Processing (ICIP) |chapter=JPEG on STEROIDS: Common optimization techniques for JPEG image compression |date=September 2016 |pages=61–65 |doi=10.1109/ICIP.2016.7532319 |isbn=978-1-4673-9961-6 |s2cid=14922251}}</ref> In March 2017, Google released the open source project [[Guetzli]], which trades off a much longer encoding time for smaller file size (similar to what [[Zopfli]] does for PNG and other lossless data formats).<ref>{{cite web|url=https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html|title=Announcing Guetzli: A New Open Source JPEG Encoder|website=Research.googleblog.com|date=16 March 2017 |access-date=16 October 2017|archive-date=6 October 2017|archive-url=https://web.archive.org/web/20171006012117/https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html|url-status=live}}</ref>▼
▲ISO/IEC Joint Photography Experts Group maintains the other reference software implementation under the [[JPEG XT]] heading. It can encode both base JPEG (ISO/IEC 10918-1 and 18477–1) and [[JPEG XT]] extensions (ISO/IEC 18477 Parts 2 and 6–9), as well as [[JPEG-LS]] (ISO/IEC 14495).<ref>{{cite web|url=https://jpeg.org/jpegxt/software.html|title=JPEG - JPEG XT|website=jpeg.org|access-date=2018-03-03|archive-date=2018-03-04|archive-url=https://web.archive.org/web/20180304055159/https://jpeg.org/jpegxt/software.html|url-status=live}}</ref>
 
In April 2024, Google introduced '''Jpegli''', a new JPEG coding library that offers enhanced capabilities and a 35% compression ratio improvement at high quality compression settings, while the coding speed is comparable with MozJPEG.<ref>{{cite web |title=Introducing Jpegli: A New JPEG Coding Library |url=https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html |publisher=Google Open Source Blog |access-date=4 April 2024 |archive-url=https://web.archive.org/web/20240403181607/https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html |archive-date=3 April 2024 |date=3 April 2024}}</ref>
▲There is persistent interest in encoding JPEG in unconventional ways that maximize image quality for a given file size. In 2014, [[Mozilla]] created mozjpeg from libjpeg-turbo, a slower but higher-quality encoder intended for web images.<ref>{{cite web |title=Introducing the 'mozjpeg' Project |url=https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/ |website=Mozilla Research |date=5 March 2014 |access-date=2023-03-01 |archive-date=2023-03-01 |archive-url=https://web.archive.org/web/20230301034809/https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/ |url-status=live }}</ref> In 2016, "JPEG on steroids" was introduced as an option for the ISO JPEG XT reference implementation.<ref>{{cite book |last1=Richter |first1=Thomas |title=2016 IEEE International Conference on Image Processing (ICIP) |chapter=JPEG on STEROIDS: Common optimization techniques for JPEG image compression |date=September 2016 |pages=61–65 |doi=10.1109/ICIP.2016.7532319 |isbn=978-1-4673-9961-6 |s2cid=14922251}}</ref> In March 2017, Google released the open source project [[Guetzli]], which trades off a much longer encoding time for smaller file size (similar to what [[Zopfli]] does for PNG and other lossless data formats).<ref>{{cite web|url=https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html|title=Announcing Guetzli: A New Open Source JPEG Encoder|website=Research.googleblog.com|date=16 March 2017 |access-date=16 October 2017|archive-date=6 October 2017|archive-url=https://web.archive.org/web/20171006012117/https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html|url-status=live}}</ref>
 
== Successors ==
Line 835 ⟶ 837:
=== JPEG LS ===
{{main|JPEG LS}}
Originating in 1993 and published as ISO-14495-1/ITU-T.87, JPEG LS offers a low-complexity lossless file format which was more efficient than theJPEG's then currentoriginal lossless implementation of JPEG. It also features a lossy mode close to lossless. Its functionality is largely limited to that, and largely shares the same limitations of the original JPEG in other aspects.
 
=== JPEG 2000 ===
{{main|JPEG 2000}}
JPEG 2000 was published as ISO/IEC 15444 in December 2000. It is based on a [[discrete wavelet transform]] (DWT) and was designed to completely replace the original JPEG standard and exceed it in every way. It allows up to 38 bits per colour channel and 16384 channels, more than any other format, with a multitude of colour spaces, and thus high dynamic range (HDR). Furthermore, it supports alpha transparency coding, billions-by-billions pixel images, which is also more than any other format, and lossless compression. It has significantly improved lossy compression ratio with significantly less visible artefacts at strong compression levels. <ref>{{cite web|url=https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg|title=It's High Time to Replace JPEG With a Next-Generation Image Codec|website=Cloudinary|first=Jon|last=Sneyers |date=22 February 2021|access-date=14 November 2023}}</ref>
 
=== JPEG XT ===
Line 848 ⟶ 850:
=== JPEG XL ===
{{main|JPEG XL}}
JPEG XL (ISO/IEC 18181) was published in 2021&ndash;2022. It replaces the JPEG format with a new DCT-based [[royalty-free]] format and allows efficient transcoding as a storage option for traditional JPEG images.<ref name=spie_jpegxl>{{cite book|chapter=JPEG XL next-generation image compression architecture and coding tools|chapter-url=https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1|first1=Jyrki|last1=Alakuijala|first2=Ruud|last2=van Asseldonk|first3=Sami|last3=Boukortt|first4=Martin|last4=Bruse|first5=Iulia-Maria|last5=Comșa|first6=Moritz|last6=Firsching|first7=Thomas|last7=Fischbacher|first8=Evgenii|last8=Kliuchnikov|first9=Sebastian|last9=Gomez|first10=Robert|last10=Obryk|first11=Krzysztof|last11=Potempa|first12=Alexander|last12=Rhatushnyak|first13=Jon|last13=Sneyers|first14=Zoltan|last14=Szabadka|first15=Lode|last15=Vandervenne|first16=Luca|last16=Versari|first17=Jan|last17=Wassenberg|editor1-first=Andrew G|editor1-last=Tescher|editor2-first=Touradj|editor2-last=Ebrahimi|title=Applications of Digital Image Processing XLII|date=2019-09-06| volume=11137 |page=20|doi=10.1117/12.2529237|bibcode=2019SPIE11137E..0KA|isbn=978-1-5106-2967-7|s2cid=202785129|access-date=2021-12-26|archive-date=2021-12-26|archive-url=https://web.archive.org/web/20211226010413/https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1|url-status=live}}</ref> The new format is designed to exceed the still image compression performance shown by [[HEVCHEIF]] HM, [[Daala]] and [[WebP]]. It supports billion-by-billion pixel images, up to 32-bit-per-component [[high dynamic range]] with the appropriate transfer functions ([[Perceptual quantizer|PQ]] and [[Hybrid log–gamma|HLG]]), patch encoding of synthetic images such as bitmap fonts and gradients, animated images, alpha channel coding, and a choice of RGB/YCbCr/[[ICtCp]] color encoding.<ref name="jpegxl_committeedraft">{{cite arXiv|title=Committee Draft of JPEG XL Image Coding System|eprint = 1908.03565|last1 = Rhatushnyak|first1 = Alexander|last2 = Wassenberg|first2 = Jan|last3 = Sneyers|first3 = Jon|last4 = Alakuijala|first4 = Jyrki|last5 = Vandevenne|first5 = Lode|last6 = Versari|first6 = Luca|last7 = Obryk|first7 = Robert|last8 = Szabadka|first8 = Zoltan|last9 = Kliuchnikov|first9 = Evgenii|last10 = Comsa|first10 = Iulia-Maria|last11 = Potempa|first11 = Krzysztof|last12 = Bruse|first12 = Martin|last13 = Firsching|first13 = Moritz|last14 = Khasanova|first14 = Renata|author15 = Ruud van Asseldonk|last16 = Boukortt|first16 = Sami|last17 = Gomez|first17 = Sebastian|last18 = Fischbacher|first18 = Thomas|class = eess.IV|year = 2019}}</ref><ref name="jpegxl_cfp">{{cite web|url=https://jpeg.org/downloads/jpegxl/jpegxl-cfp.pdf|title=N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)|work=ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16)|access-date=29 May 2018|archive-date=31 October 2022|archive-url=https://web.archive.org/web/20221031184400/https://jpeg.org/downloads/jpegxl/jpegxl-cfp.pdf|url-status=live}}</ref><ref>{{Cite ISO standard |title=ISO/IEC 18181-1:2022 Information technology — JPEG XL image coding system — Part 1: Core coding system |csnumber=77977 }}</ref><ref>{{Cite ISO standard |title=ISO/IEC 18181-2:2021 Information technology — JPEG XL image coding system — Part 2: File format |csnumber=80617 }}</ref>
 
==See also==
* [[AVIF]]
* [[Better Portable Graphics]], a format based on intra-frame encoding of the HEVC
* [[C-Cube]], an early implementer of JPEG in chip form
Retrieved from "https://en.wikipedia.org/wiki/JPEG"