# JPEG XL Viewer plugin **URL:** \ **Category:** Viewer/VFS Plugins\ **Tags:** viewer, thumbnails, source-available\ **Created:** [November 27, 2022, 9:25pm UTC](https://resource.dopus.com/t/jpeg-xl-viewer-plugin/42965 "2022-11-27T21:25:57Z")\ **Posts on this page:** 1\ **Showing post:** 54
**Author:** ![Guido](https://resource.dopus.com/user_avatar/resource.dopus.com/guido/32/56013_2.png) [@Guido](https://resource.dopus.com/u/Guido)\ **Post date:** [December 11, 2025, 1:20am UTC](https://resource.dopus.com/t/jpeg-xl-viewer-plugin/42965/54 "2025-12-11T01:20:24Z")
You seem to have that _postmodern_ way of thinking, while I take the _modern_ approach, so we cannot agree. See explanation [here](https://resource.dopus.com/t/native-lossless-heic-heif-rotation-by-modifying-metadata/56963/7). It has nothing to do with subsampling or wide gamut. JPEG (9) already has that. The point is to allow larger than 8 bits per sample in a backward compatible way. You can see soon in JPEG 10 how it works: ```plaintext CHANGE LOG for Independent JPEG Group's JPEG software Version 10 25-Jan-2026 ----------------------- jmorecfg.h: add JPEG_DATA_PRECISION parameter alongside and independent of BITS_IN_JSAMPLE, enabling higher bit depth support with backward compatibility and preparing the next standard for file interchange. ... ``` ```plaintext /* * jmorecfg.h * * ... * * This file contains additional configuration options that customize the * JPEG software for special applications or support machine-dependent * optimizations. Most users will not need to touch this file. */ #define JPEG_DATA_PRECISION 8 /* see table below */ #define BITS_IN_JSAMPLE JPEG_DATA_PRECISION /* see table below */ /* * Most useful alternative for "HDR" (High Dynamic Range) application * with backward compatibility for file interchange (see table below; * move comment marks for selection): #define BITS_IN_JSAMPLE 10 */ /* For still higher demands (see table below): #define BITS_IN_JSAMPLE 11 */ /* or #define BITS_IN_JSAMPLE 12 */ /* | BITS_IN_JSAMPLE * JPEG_DATA_PRECISION | read / write with full DCT up to lossless operation * | exceptions see below * ------------------------------------------------------------------------------- * {[_8_]} | _8_ <9> <10> <11>* <12>~ * [_9_] | <8> _9_ <10> <11> <12>* * [_10_] | <8> <9> _10_ <11> <12> 13 * * _11_ | <8> <9> <10> _11_ <12> 13 14 * * _12_ | <8> <9> <10> <11> _12_ 13 14 15 * * 13 | 8 9 10 11 12 13 14 15 16 * * * _x_ currently and previously implemented - default configuration * newly implemented * {x} current standard for file interchange - backward compatible * [x] next standard for file interchange - common DCT implementation category * * does not support GCC lossless (GCbCr lossless - requires 1 extra bit) * ~ 1 bit precision loss - effective 11 bits precision (lossy) * * Since the DCT coefficients are 3 bits larger than sample values with normal DCT * processing, it is possible to support sample values with up to 3 more bits than * the nominal JPEG data precision parameter by adapted DCT processing with up to * lossless operation. The generated JPEG files are fully interchangeable for the * same JPEG data precision parameter. Another BITS_IN_JSAMPLE setting will just * reconstruct an image with corresponding precision. * * A special case for JPEG data precision 8 with 12-bit sample size (4 more bits) * is provided so that all previously available sample formats are now supported * for file interchange with backward compatibility. * If full-feature DCT up to lossless operation with up to 12-bit sample size is * required, it is recommended to select JPEG data precision 10, because it falls * in the same DCT implementation category with 8 and 9 which may be commonly * supported at run-time as the next standard for file interchange. * * Remaining bit depths and variability at run-time may be added later and * are currently not supported, sorry. * Exception: The transcoding part (jpegtran) supports all settings in a * single instance, since it operates on the level of DCT coefficients and * not sample values. The DCT coefficients are of the same type (16 bits) * in all cases (see below). */ ``` You can still use the default setting and the code works as before, which I assume and recommend for Opus initially. It is important to have the additional capabilities, but there is no reason for haste. HDR is only useful in a _modern_ form. In a _postmodern_ form it is useless. > [@](#): > > My understanding is that JPEG had lossless compression since the very beginning (SOF 3), which nobody ever used, to the point that many viewers don't even support it. Because it was one of the _junk parts_ of the spec, and that's why Independent JPEG Group never implemented it. As mentioned, JPEG 8 integrates the feature in the SmartScale framework, and ISO WG1 "adapted" that idea for "JPEG XL" _without_ SmartScale, because they want to protect their "JPEG 2000" business in Digital Cinema application. That's why you always get _junk_ from that side. > [@](#): > > I'm not a fan of the idea of adding HDR to the original JPEG compression The point of the JPEG 8 lossless integration is that there is **nothing added** to the JPEG compression, contrary to the _junk mode_ in the spec! Similarly, **nothing is added** to the JPEG compression in the _modern form_ of HDR as described! All these features were already _hidden_ in the JPEG substance, they are just unable to see it. Regards Guido JPEG developer --- _[View the full topic](https://resource.dopus.com/t/jpeg-xl-viewer-plugin/42965)._