Nicely illustrated, and only one criticism: our preference for luminance (using more bits for "Y" vs "Cr/Cb") isn't due to the number of rods in the eye - there are so many rods so that we can capture more photons at night, and they are usually saturated at daylight illuminances.
The effectiveness of the YCbCr encoding is much more related to the predominant pathway to the LGN (80-90% of the "number of bits" used) encoding luminance and center-surround, so those things both map well to using more bits for "Y".
I remember when I first learned about the difference between spatial and frequency domains. I didn’t actually get it fully during class. But during the walk home I had to stop and sit down and think about it… I started to “refactor” all of human history into frequency changes! It’s a pretty interesting concept.
And someone created a "JPEG to PNG" tool that "finds the smoothest possible picture that encodes to the given JPEG file": https://github.com/victorvde/jpeg2png . I tried it with some very terribly compressed images, and the outputs were a lot better.
That jpeg2png is extremely cool and looks like something which could be built in to image viewers. Naturally, nothing about the "maximally smooth decode" process requires the output to be PNG.
I appreciated the information being presented, but when the controls are not visible at the same time as the thing they effect it makes the interactive component almost worthless.
same, OP you should put the source image and controls in a floating popover that's static while the rest of the page content is scrolled, or a sticky header or something.
One interesting thing about JPEG is that you can do some lossless manipulations with it. In particular, you can concatenate multiple images together.
Unfortunately, no common JPEG libraries expose these operations. Your only option is to use some crusty C-based code that hasn't been updated since the 2010-s.
Nicely illustrated, and only one criticism: our preference for luminance (using more bits for "Y" vs "Cr/Cb") isn't due to the number of rods in the eye - there are so many rods so that we can capture more photons at night, and they are usually saturated at daylight illuminances. The effectiveness of the YCbCr encoding is much more related to the predominant pathway to the LGN (80-90% of the "number of bits" used) encoding luminance and center-surround, so those things both map well to using more bits for "Y".
I remember when I first learned about the difference between spatial and frequency domains. I didn’t actually get it fully during class. But during the walk home I had to stop and sit down and think about it… I started to “refactor” all of human history into frequency changes! It’s a pretty interesting concept.
There's a series of videos showing the algorithm: https://www.youtube.com/watch?v=LFXN9PiOGtY
I finally understood DCT after watching https://www.youtube.com/watch?v=Q2aEzeMDHMA
And someone created a "JPEG to PNG" tool that "finds the smoothest possible picture that encodes to the given JPEG file": https://github.com/victorvde/jpeg2png . I tried it with some very terribly compressed images, and the outputs were a lot better.
That jpeg2png is extremely cool and looks like something which could be built in to image viewers. Naturally, nothing about the "maximally smooth decode" process requires the output to be PNG.
I appreciated the information being presented, but when the controls are not visible at the same time as the thing they effect it makes the interactive component almost worthless.
same, OP you should put the source image and controls in a floating popover that's static while the rest of the page content is scrolled, or a sticky header or something.
Thanks, this is a clear explanation, thanks for sharing! I’d be curious in follow ups on other formats like PNG
(2017)
This has been one of the best explanations I've seen, thanks for sharing
One interesting thing about JPEG is that you can do some lossless manipulations with it. In particular, you can concatenate multiple images together.
Unfortunately, no common JPEG libraries expose these operations. Your only option is to use some crusty C-based code that hasn't been updated since the 2010-s.
I appreciate the insight to something I use all the time.