3 ms·

A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often

by ibigb 5y ago

A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often repeated. A jpeg is capable of over 11 bits dynamic range. You can figure out that an 11 bit dynamic range image has more than 8 bits. See the wikipedia.

stingraycharles 5y ago
Thanks for that info! To save others from Googling, the Wikipedia page: https://en.wikipedia.org/wiki/JPEG https://en.wikipedia.org/wiki/JPEG
SideQuark 5y ago
A jpeg pixel is not 64 eight-bit coefficients. Jpeg compresses an 8x8 pixel block at a time by taking a DCT (which mathematically is lossless, but in practice is not due to rounding and quantization at this stage), which turns those original 8x8 values into another set of 8x8 values, then some of these are thrown away and/or quantized for lossy compression. Decompression is the reverse: take these 8x8 quantized DCT coefficients, perform an inverse 8x8 DCT top get pixel values. The 11-bit dynamic range part you claim is merely from a color profile, which takes the resulting 8 bits per channel (i.e., 256 possible values) and spreads them over a gamma curve to an 11-bit range. But there are still only 256 possible levels per channel, too few for quality image editing. Think of it as squaring: taking [0,255] as your input and squaring every value gives you a range of 0 to 255^2 = 65025, but that does not allow you to store any value in that range. It only allows you the 256 values that are squares. So the dynamic range is 11 stops, but the number of representable levels per channel is still 8 bit: 256 levels. This makes gradients band no matter how you do them in JPEG. It's why photo processing software wants RAW, not JPEG. JPEG, besides being lossy, does not allow enough steps. One example: given a so-so RAW, at 11 bits, you can pull out dark things or darken bright things smoothly. This is not possible once you go to jpeg, for any implementation of jpeg.
- ibigb 5y ago
  I said a jpeg pixel is the summation of 64 8 bit coefficients. The coefficients are 8 bit, but obviously the cosine values are not 8 bit. They can be floating point. All a jpeg need give is coefficients, the coder/decoder knows what to do with them. Summing 64 products, with each product = 8 bit numbers x cosine value gives more than an 8 bit result for the resultant pixel. In addition, there is another dct for the color values. This adds more bits of info. The cosine values are transcendental numbers, they can have an infinite number of decimal places, yes? So adding up 64 products of (cosine values * 8 bit integer) to get 1 pixel value can obviously have more than 8 bits.
  - SideQuark 5y ago
    No, a jpeg pixel is not "the summation of 64 8 bit coefficients." I've written jpeg codecs (and many other image formats). It works just as I explained above. Or simply read the libjpeg source. Don't like that, read this [1]: "JPEG images are always recorded with 8-bit depth. This means the files can record 256 (28) levels of red, green and blue." Don't like that, here [2] is the JPEG ISO standard, section 4.11, baseline jpeg, "Source image: 8-bit samples within each component". A DCT takes an 8x8 pixel input, 8 bits per channel, and transforms them into an 8x8 output. It matters not what these are - the information theory content is nothing more than what was put into it. There is not suddenly magically more information content. More simply, appending zeroes to a number does not mean you can represent more numbers. You simply can represent the exact same numbers, just wasting more space. None of what you wrote adds more resolution at the output. It simply isn't there. If I give you 5 possible inputs to a function, then you have 5 possible outputs, not matter how many digits you finagle into representing the output. Jpeg has 8 bits of resolution per channel. End of story. That is why professional photos are taken and edited in raw - you get more bits of resolution per channel. I'm not sure why you're still arguing this. It's a longstanding, well known issue, and I explained it all again very simply. If you think it isn't true, encode one of your magic jepgs with more than 256 levels of gray and post it here. Good luck :) If you cannot do that, then maybe you should consider that you're wrong. [1] https://www.photoreview.com.au/tips/editing/bit-depth/ https://www.photoreview.com.au/tips/editing/bit-depth/ [2] https://www.w3.org/Graphics/JPEG/itu-t81.pdf https://www.w3.org/Graphics/JPEG/itu-t81.pdf
brigade 5y ago
Alternatively, if you're being confused by the quoted intermediate DCT precision, that's not relevant to the final output either. You cannot implement any transform, DCT especially, without having intermediate values with a greater range than the input or output. Like, even a simple average of two 8-bit values (a+b)/2 has an intermediate range of 9 bits. The JPEG spec does specify both 8 and 12 bit sample precision for lossy, but I don't think anyone ever implemented 12-bit since libjpeg never cared about it.
- HedgeGriffon 5y ago
  Libjpeg does have support for it. Unfortunately, you have to have two copies of the library, one for 8 bit and one for 12. And you have to rename all the API methods in one of the libraries so you dont get name collisions. I believe that LibTIFF has a build configuration for this so that 12bit JPEG data can be encapsulated in a TIFF file.
Auracle 5y ago
Fair enough, but the end result is what really matters, and I regularly see banding in the skies of photos. Some people add grain just to help deal with that, which is a ridiculous problem to have in 2022.

by ibigb 5y ago

stingraycharles 5y ago

Thanks for that info! To save others from Googling, the Wikipedia page: https://en.wikipedia.org/wiki/JPEG https://en.wikipedia.org/wiki/JPEG

SideQuark 5y ago

A jpeg pixel is not 64 eight-bit coefficients. Jpeg compresses an 8x8 pixel block at a time by taking a DCT (which mathematically is lossless, but in practice is not due to rounding and quantization at this stage), which turns those original 8x8 values into another set of 8x8 values, then some of these are thrown away and/or quantized for lossy compression. Decompression is the reverse: take these 8x8 quantized DCT coefficients, perform an inverse 8x8 DCT top get pixel values. The 11-bit dynamic range part you claim is merely from a color profile, which takes the resulting 8 bits per channel (i.e., 256 possible values) and spreads them over a gamma curve to an 11-bit range. But there are still only 256 possible levels per channel, too few for quality image editing. Think of it as squaring: taking [0,255] as your input and squaring every value gives you a range of 0 to 255^2 = 65025, but that does not allow you to store any value in that range. It only allows you the 256 values that are squares. So the dynamic range is 11 stops, but the number of representable levels per channel is still 8 bit: 256 levels. This makes gradients band no matter how you do them in JPEG. It's why photo processing software wants RAW, not JPEG. JPEG, besides being lossy, does not allow enough steps. One example: given a so-so RAW, at 11 bits, you can pull out dark things or darken bright things smoothly. This is not possible once you go to jpeg, for any implementation of jpeg.

ibigb 5y ago
I said a jpeg pixel is the summation of 64 8 bit coefficients. The coefficients are 8 bit, but obviously the cosine values are not 8 bit. They can be floating point. All a jpeg need give is coefficients, the coder/decoder knows what to do with them. Summing 64 products, with each product = 8 bit numbers x cosine value gives more than an 8 bit result for the resultant pixel. In addition, there is another dct for the color values. This adds more bits of info. The cosine values are transcendental numbers, they can have an infinite number of decimal places, yes? So adding up 64 products of (cosine values * 8 bit integer) to get 1 pixel value can obviously have more than 8 bits.
- SideQuark 5y ago
  No, a jpeg pixel is not "the summation of 64 8 bit coefficients." I've written jpeg codecs (and many other image formats). It works just as I explained above. Or simply read the libjpeg source. Don't like that, read this [1]: "JPEG images are always recorded with 8-bit depth. This means the files can record 256 (28) levels of red, green and blue." Don't like that, here [2] is the JPEG ISO standard, section 4.11, baseline jpeg, "Source image: 8-bit samples within each component". A DCT takes an 8x8 pixel input, 8 bits per channel, and transforms them into an 8x8 output. It matters not what these are - the information theory content is nothing more than what was put into it. There is not suddenly magically more information content. More simply, appending zeroes to a number does not mean you can represent more numbers. You simply can represent the exact same numbers, just wasting more space. None of what you wrote adds more resolution at the output. It simply isn't there. If I give you 5 possible inputs to a function, then you have 5 possible outputs, not matter how many digits you finagle into representing the output. Jpeg has 8 bits of resolution per channel. End of story. That is why professional photos are taken and edited in raw - you get more bits of resolution per channel. I'm not sure why you're still arguing this. It's a longstanding, well known issue, and I explained it all again very simply. If you think it isn't true, encode one of your magic jepgs with more than 256 levels of gray and post it here. Good luck :) If you cannot do that, then maybe you should consider that you're wrong. [1] https://www.photoreview.com.au/tips/editing/bit-depth/ https://www.photoreview.com.au/tips/editing/bit-depth/ [2] https://www.w3.org/Graphics/JPEG/itu-t81.pdf https://www.w3.org/Graphics/JPEG/itu-t81.pdf

brigade 5y ago

Alternatively, if you're being confused by the quoted intermediate DCT precision, that's not relevant to the final output either. You cannot implement any transform, DCT especially, without having intermediate values with a greater range than the input or output. Like, even a simple average of two 8-bit values (a+b)/2 has an intermediate range of 9 bits. The JPEG spec does specify both 8 and 12 bit sample precision for lossy, but I don't think anyone ever implemented 12-bit since libjpeg never cared about it.

HedgeGriffon 5y ago
Libjpeg does have support for it. Unfortunately, you have to have two copies of the library, one for 8 bit and one for 12. And you have to rename all the API methods in one of the libraries so you dont get name collisions. I believe that LibTIFF has a build configuration for this so that 12bit JPEG data can be encapsulated in a TIFF file.

Auracle 5y ago

Fair enough, but the end result is what really matters, and I regularly see banding in the skies of photos. Some people add grain just to help deal with that, which is a ridiculous problem to have in 2022.