7 ms·

> 10+ bits. Jpegli can be encoded with 10+ bits per component. If you are making a new image/video codec in 2024 please don't just give us 2 measly extra bits

by kloch 3y ago

> 10+ bits. Jpegli can be encoded with 10+ bits per component. If you are making a new image/video codec in 2024 please don't just give us 2 measly extra bits of DR. Support up to 16 bit unsigned integer and floating point options. Sheesh.

Retr0id 3y ago
It's not a new codec, it's a new encoder/decoder for JPEG.
- whywhywhywhy 3y ago
  This should have been in a H1 tag at the top of the page. Had to dig into a paragraph to find out Google wasn’t about to launch another image format supported in only a scattering of apps yet served as Image Search results.
  - Retr0id 3y ago
    It is. (well, h3 actually) > Introducing Jpegli: A New JPEG Coding Library
- JyrkiAlakuijala 3y ago
  I consider codec to mean a pair of encoder and decoder programs. I don't consider it to necessarily mean a new data format. One data format can be implemented by multiple codecs. Semantics and nomenclature within our field is likely underdeveloped and the use of these terms varies.
Timon3 3y ago
From their Github: > Support for 16-bit unsigned and 32-bit floating point input buffers. "10+" means 10 bits or more.
- johnisgood 3y ago
  Would not ">10" be a better way to denote that?
  - mkl 3y ago
    That means something different, but "≥10" would be better IMHO. Really there's an upper limit of 12, and 10.5 is more likely in practice: https://news.ycombinator.com/item?id=39922511 https://news.ycombinator.com/item?id=39922511
    - JyrkiAlakuijala 3y ago
      I decided to call it 10.5 bits based on rather fuzzy theoretical analysis and a small amount of practical experiments with using jpegli in HDR use where more bits is good to have. My thinking is that in the slowest smoothest gradients (where banding would otherwise be visible) it is only three quantization decisions that generate error: (0,0), (0,1) and (1, 0) coefficient. Others are close to zero. I consider these as adding stochastic variables that have uniform error. On the average they start to behave a bit like a Gaussian distribution, but each block samples those distributions 64 times so there are going to be some more and some less lucky pixels. If we consider that every block would have one maximally unlucky corner pixel which would get all three wrong. log(4096/3)/log(2) = 10.41 So, very handwavy analysis. Experimentally it seems to roughly hold.
    - johnisgood 3y ago
      Yeah, >=, my bad.
JyrkiAlakuijala 3y ago
We insert/extract about 2.5 bits more info from the 8 bit jpegs, leading to about 10.5 bits of precision. There is quite some handwaving necessary here. Basically it comes down to coefficient distributions where the distributions have very high probabilities around zeros. Luckily, this is the case for all smooth noiseless gradients where banding could be otherwise observed.
- vlovich123 3y ago
  Does the decoder have to be aware of it to properly display such an image?
  - spider-mario 3y ago
    To display it at all, no. To display it smoothly, yes.
    - JyrkiAlakuijala 3y ago
      From a purely theoretical viewpoint 10+ bits encoding will lead into slightly better results even if rendered using a traditional 8 bit decoder. One source of error has been removed from the pipeline.
      - vlovich123 3y ago
        How does the data get encoded into 10.5 bits but displayable correctly by an 8 bit decoder while also potentially displaying even more accurately by a 10 bit decoder?
        JyrkiAlakuijala 3y ago
        Through non-standard API extensions you can provide a 16 bit data buffer to jpegli. The data is carefully encoded in the dct-coefficients. They are 12 bits so in some situations you can get even 12 bit precision. Quantization errors however sum up and worst case is about 7 bits. Luckily it occurs only in the most noisy environments and in smooth slopes we can get 10.5 bits or so.
deleted 3y ago
[deleted]
bufferoverflow 3y ago
For pure viewing of non-HDR content 10 bits is good enough. Very few humans can tell the difference between adjacent shades among 1024 shades. Gradients look smooth. 16 bits is useful for image capture and manipulation. But then you should just use RAW/DNG.

by kloch 3y ago

Retr0id 3y ago

It's not a new codec, it's a new encoder/decoder for JPEG.

whywhywhywhy 3y ago
This should have been in a H1 tag at the top of the page. Had to dig into a paragraph to find out Google wasn’t about to launch another image format supported in only a scattering of apps yet served as Image Search results.
- Retr0id 3y ago
  It is. (well, h3 actually) > Introducing Jpegli: A New JPEG Coding Library
JyrkiAlakuijala 3y ago
I consider codec to mean a pair of encoder and decoder programs. I don't consider it to necessarily mean a new data format. One data format can be implemented by multiple codecs. Semantics and nomenclature within our field is likely underdeveloped and the use of these terms varies.

Timon3 3y ago

From their Github: > Support for 16-bit unsigned and 32-bit floating point input buffers. "10+" means 10 bits or more.

johnisgood 3y ago
Would not ">10" be a better way to denote that?
- mkl 3y ago
  That means something different, but "≥10" would be better IMHO. Really there's an upper limit of 12, and 10.5 is more likely in practice: https://news.ycombinator.com/item?id=39922511 https://news.ycombinator.com/item?id=39922511
  - JyrkiAlakuijala 3y ago
    I decided to call it 10.5 bits based on rather fuzzy theoretical analysis and a small amount of practical experiments with using jpegli in HDR use where more bits is good to have. My thinking is that in the slowest smoothest gradients (where banding would otherwise be visible) it is only three quantization decisions that generate error: (0,0), (0,1) and (1, 0) coefficient. Others are close to zero. I consider these as adding stochastic variables that have uniform error. On the average they start to behave a bit like a Gaussian distribution, but each block samples those distributions 64 times so there are going to be some more and some less lucky pixels. If we consider that every block would have one maximally unlucky corner pixel which would get all three wrong. log(4096/3)/log(2) = 10.41 So, very handwavy analysis. Experimentally it seems to roughly hold.
  - johnisgood 3y ago
    Yeah, >=, my bad.

JyrkiAlakuijala 3y ago

We insert/extract about 2.5 bits more info from the 8 bit jpegs, leading to about 10.5 bits of precision. There is quite some handwaving necessary here. Basically it comes down to coefficient distributions where the distributions have very high probabilities around zeros. Luckily, this is the case for all smooth noiseless gradients where banding could be otherwise observed.

vlovich123 3y ago
Does the decoder have to be aware of it to properly display such an image?
- spider-mario 3y ago
  To display it at all, no. To display it smoothly, yes.
  - JyrkiAlakuijala 3y ago
    From a purely theoretical viewpoint 10+ bits encoding will lead into slightly better results even if rendered using a traditional 8 bit decoder. One source of error has been removed from the pipeline.
    - vlovich123 3y ago
      How does the data get encoded into 10.5 bits but displayable correctly by an 8 bit decoder while also potentially displaying even more accurately by a 10 bit decoder?
      - JyrkiAlakuijala 3y ago
        Through non-standard API extensions you can provide a 16 bit data buffer to jpegli. The data is carefully encoded in the dct-coefficients. They are 12 bits so in some situations you can get even 12 bit precision. Quantization errors however sum up and worst case is about 7 bits. Luckily it occurs only in the most noisy environments and in smooth slopes we can get 10.5 bits or so.

deleted 3y ago

[deleted]

bufferoverflow 3y ago

For pure viewing of non-HDR content 10 bits is good enough. Very few humans can tell the difference between adjacent shades among 1024 shades. Gradients look smooth. 16 bits is useful for image capture and manipulation. But then you should just use RAW/DNG.