They could also note how 3D MPO images work, they’re just two jpegs concatenated together with some special markers. It’s been a while but I’ve written MPO parsers for a couple languages.
Visualizing and Understanding JPEG Format
21–30 of 47 posts
Re: Visualizing and Understanding JPEG Format
#22why i still see jpeg in 2020 ?
It works incredibly well for a format its age. It's simple, and widely supported.
Internally, JPEG has the key techniques required to compress photos well, and nothing else. Most newer formats are based on the same principles, except each bit is upgraded to the point of diminishing returns.
HEIF and AVIF compress twice as well as JPEG, but in terms of complexity and computational requirements are hundreds of times more complex.
Re: Visualizing and Understanding JPEG Format
#23By the way, you can decode JPEG with less artifacts using these projects: https://github.com/ilyakurdyukov/jpeg-quantsmooth (good for most mid-quality and high-quality images) https://github.com/victorvde/jpeg2png (use for very low-quality images, slower) jpeg-quantsmooth gives a sharper output (use "-q6" option). jpeg2png output is a little blurry, but it does a better job of unblocking very low-quality images.
ffmpeg/mplayer has some more principled smoothing filters than these (especially spp); they're made for MPEG4 but JPEG is pretty similar.
Another algorithm that should work but I haven't seen tried is edge-aware chroma upsampling. libjpeg uses nearest neighbor upscaling for the subsampled color planes, which is why JPEG looks so bad when there's a transition from eg saturated red to black.
Re: Visualizing and Understanding JPEG Format
#24If I'm being honest, I'm more of a PNG fan.
PNG is a pretty poor file format, just because zlib (a byte-level text codec) is not a good compressor for image data. Any lossless video codec works much better.
Re: Visualizing and Understanding JPEG Format
#25By the way, you can decode JPEG with less artifacts using these projects: https://github.com/ilyakurdyukov/jpeg-quantsmooth (good for most mid-quality and high-quality images) https://github.com/victorvde/jpeg2png (use for very low-quality images, slower) jpeg-quantsmooth gives a sharper output (use "-q6" option). jpeg2png output is a little blurry, but it does a better job of unblocking very low-quality images.
ffmpeg/mplayer has some more principled smoothing filters than these (especially spp); they're made for MPEG4 but JPEG is pretty similar. Another algorithm that should work but I haven't seen tried is edge-aware chroma upsampling. libjpeg uses nearest neighbor upscaling for the subsampled color planes, which is why JPEG looks so bad when there's a transition from eg saturated red to black.
Both of these projects have chroma upsampling.
Re: Visualizing and Understanding JPEG Format
#26Earlier quoted context omitted.
Nothing particularly. Though there are other lossful encoding schemes developed since that either produce better results with the same data size or comparable results with better compression (or both). But the improvements have not been large enough to make the industry as a whole consider making the effort to support these other formats (and in some cases there would be licensing/patent issues making support legally…
I would add that the "reference implementation" of jpeg encoding and decoding is very easy to compile and to use, reasonably efficient, and completely free software. There has never been a corresponding jpeg2000 implementation, for example, leading to the fast demise of the arguably superior format.
JPEG2000 is not actually much better and I always found the artifacts to be kind of unpleasant. Wavelets are not very good psychovisually because they make the image blurry; they're also more complicated to decode and cost more memory.
It's not a good idea to enable too many file formats in a browser because of the new security issues, so it really needs to be a huge improvement. I also think WebP was a mistake for this reason, it's not good enough.
Re: Visualizing and Understanding JPEG Format
#27Re: Visualizing and Understanding JPEG Format
#28Earlier quoted context omitted.
ffmpeg/mplayer has some more principled smoothing filters than these (especially spp); they're made for MPEG4 but JPEG is pretty similar. Another algorithm that should work but I haven't seen tried is edge-aware chroma upsampling. libjpeg uses nearest neighbor upscaling for the subsampled color planes, which is why JPEG looks so bad when there's a transition from eg saturated red to black.
Both of these projects have chroma upsampling.
All JPEG decoders have chroma upsampling. Here jpeg2png only seems to actually optimize it though; seems like it works but optimizing for "smoothness" could maybe be improved.
I'm suggesting something like eedi3 (http://avisynth.nl/index.php/Eedi3) but guided by the luma plane.
Oh, you can also jointly optimize the YUV-RGB conversion because if the pixel ends up out of range in RGB space it is probably a compression artifact. I read a paper on this once but haven't seen it implemented.
Re: Visualizing and Understanding JPEG Format
#29why i still see jpeg in 2020 ?
The question you should be asking is 'why I still see animated gifs in 2020?'
Do you? I thought many ‘animated GIFs’ aren’t GIF files anymore. Twitter, for example, serves MP4 files (https://techcrunch.com/2014/06/19/gasp-twitter-gifs-arent-ac...)
Re: Visualizing and Understanding JPEG Format
#30Earlier quoted context omitted.
Both of these projects have chroma upsampling.
All JPEG decoders have chroma upsampling. Here jpeg2png only seems to actually optimize it though; seems like it works but optimizing for "smoothness" could maybe be improved. I'm suggesting something like eedi3 ( http://avisynth.nl/index.php/Eedi3 ) but guided by the luma plane. Oh, you can also jointly optimize the YUV-RGB conversion because if the pixel ends up out of range in RGB space it is probably a compressio…
"All JPEG decoders have chroma upsampling."
Well, I meant better upsampling than bilinear interpolation, which blurs chroma.
"Oh, you can also jointly optimize the YUV-RGB conversion because if the pixel ends up out of range in RGB space it is probably a compression artifact."
Probably not, I suspect that the mozjpeg encoder may use this, so images with black on white text look better (artifact noise go beyond of range).