53 ms·
This comparison is a bit unfair to JPG. There are many JPG decompression algorithms. The "simplest" one consists in reconstructing the image from the given qu
by enriquto 7y ago
This comparison is a bit unfair to JPG. There are many JPG decompression algorithms. The "simplest" one consists in reconstructing the image from the given quantized DCT coefficients. But this is not the only one. Modern decompression methods (such as the one implemented by BPG) find the cleanest possible image that would get compressed to the given JPG file. These decompression algorithms eliminate most blocking artifacts on uniform regions, and that would be a fairer comparison.
Nonetheless, the BPG format is a super-incredible hack.
- 0-_-0 7y agoThat would make a lot of sense for JPEG, I wonder why such deblocking decoders aren't widespread. I've been planning to write an adversarial neural network based JPEG decoder that would find the most realistic possible image that would get compressed to the given JPEG... I would love to have such a decoder integrated into browsers!
- tambourine_man 7y agoDecompression speed is extremely important. How fast would such a implementation be?
- komali2 7y agoSounds like the exercise would be more for the sake of it rather than trying to develop some widespread new decompression method.
- 0-_-0 7y agoIt would be multipass, so it would render ever increasing quality reconstructions, limited by a configurable limit, so that you can limit power consumption on mobile devices.
- enriquto 7y ago> I wonder why such deblocking decoders aren't widespread. There are many, but mostly focused on output quality, and slow, and written in matlab using fancy tools. If somebody submits a simple patch (written in pure C without dependences) to the jpeg reference distribution, and the code is very fast and good enough, it will most surely become mainstream. The thing is, that the people who know enough math to create a good jpeg decompressor do not tend to be well-versed nor interested in C programming.
- 52-6F-62 7y agoI haven't worked with matlab—nor is my math up to that kind of snuff by a long shot— but how hard would it be for an experienced programmer to port it over effectively?
- enriquto 7y ago> how hard would it be for an experienced programmer to port it over effectively? They should at least grasp a bit of the math involved, which is possible but not elementary. A full re-implementation would not be hard, the hard thing would be to remove the non-essential steps that increase the quality by a negligible amount but have a huge impact in the running time. Knowing what parts of the algorithm are essential and what parts are superfluous is not easy if you don't understand the algorithm.
- 52-6F-62 7y ago> remove the non-essential steps that increase the quality by a negligible amount but have a huge impact in the running time. Knowing what parts of the algorithm are essential and what parts are superfluous is not easy if you don't understand the algorithm Yeah that's what figured but hoped against. I still might have a curious look later... any pointers for where a good resource might be?
- enriquto 7y agoA canonical starting point is the Bredies-Holler work on TGV-based decompression (a significant improvement over the TV model, that cannot correctly address block artifacts). Look at the two-part article from 2015 here: https://imsc.uni-graz.at/bredies/publications_de.html https://imsc.uni-graz.at/bredies/publications_de.html
- tjalfi 7y agoThis is a great idea. Please post to Show HN when you ship something.
- ZeroGravitas 7y agoI believe a better such algorithm would also help progressive jpegs load in better and so give JPEG a pretty strong practical advantage over formats that don't support that. And it's even better if http2 loads all the images smartly rather than one at a time. https://blog.cloudflare.com/parallel-streaming-of-progressive-images/ https://blog.cloudflare.com/parallel-streaming-of-progressiv...