You seem to have that postmodern way of thinking, while I take the modern approach, so we cannot agree.
See explanation here.
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:
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.
...
/*
* 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
* <x> 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.
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.
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