Comparing to JPEG seems somewhat dishonest (or thoughtless), considering the large parts of one color in some of the images. PNG and other algorithms not designed for detailed pictures would probably do better.
No. PNG is lossless, it will do a really bad job at compression. Even those uniform colors won't actually be uniform because they are from image sensors.
JPEG is the appropriate comparison, as the authors are solving the same problem as JPEG tries to solve (i.e. a good enough lossy compression for natural images).
PNG doesn't need to be lossless. You can identify the pixels that are requiring more bits to compress, and change their values to make them easier. It's not as good as JPEG, but I suspect it'd be comparable to this for the same level of quality.
PNG will always do a bad at compression. PNG is deflate encoded, but without the ability to rearrange pixel data to work with deflate's strengths. It will pick RGBA, which mixes the "entropy" data for each color channel together. PNG was born out of the necessity to replace the (at the time) patent encumbered GIF. PNG has a different purpose, and was designed to get something working fast.
For me, it looks like the PDE format is well suited for photographic images with abrupt color changes like the Svalbard picture. The sky is a gradient, it is not just one color, PNG would compress very bad on this one.
You're right that PNG does well on pictures with only few colors like diagrams but who knows how the edge-detecting PDE format would do, it might compress just as well with the same quality.
As with any graphics format, different formats have strong points. One wouldn't use PNG for a portrait and a JPEG for a block of text.
So I look at PDE and notice that its few points and colour contours bear a lot of similarity to a basic vector format. I wonder if a simplified vector format that utilises tracing combined with blurring effects would best PDE.
For something that already looks like it should be drawn with vectors, maybe. One thing to remember is that if an image is made up of points, those points can be put in order and encoded as a one number pixel offset from the previous point.
For a vector to encode a sky gradient you would have to have a shape and a specific falloff that blends into another shape and falloff to create the gradient.
The "PDE" approach is working by effectively setting some boundary conditions and solving a differential equation. The smoothness of the contours comes from the fact that they are generated implicity by a relativity simple set of parameters. A typical vector format would instead record each contour explicitly, which, even after smoothing, is a lot of data.
The big idea is to describe the image intensities as a continuous surface which can be approximated in 3+ dimensions, not a patchwork of vector areas.
JPEG is the go-to format for showing your compression is better at high compression rates because once you get past a certain point you don't have enough data for coefficients and JPEG ends up storing most of it as flat 8x8 blocks.
It's not representative of the performance of JPEG becasue You typically don't encode JPEGs at that bit rate.
Also be wary of things that report compression rates rather than bits-per-pixel. You can get the same image quality at 200:1 if you start with 48 bit colour, The bits per pixel would be the same but if your original data is excessively precise you can throw a lot of it away at no perceptible cost.
From what I can tell skimming their papers, no. Their technique really is based on solving a PDE to fill in the gaps in the image. Neat idea and I'm a little surprised that it works so well. Compressed sensing relies on an equivalence between a discrete and a continuous optimization problem under very specific assumptions, which allows the sparsest possible solution to an underdetermined linear system to be found. In this work, there's no optimization, so no compressed sensing.
I'm wondering how well deep learning would work for compressing video. For example, the face of an actor, when it has been exposed from different angles in the first 5 minutes of the movie, need not be fully coded for the remainder of the movie. At least, that is what intuition says.
I feel very much a sense of uncanny valley looking at the PDE-based images. The extreme jpeg images /look/ mechanically compressed, whereas the PDE images seem to be almost but not quite natural in the results. I'm curious as to what the results would be with an image compressed to say 1:10th its original size
The goal is to provide a similar enough image to base any residual coding. Xiph.org folks have a good example of exploiting such redundancy in the video compression format [1].
The jagged edges on straight lines is interesting, it looks to me like this could get closer to the input image with a little bit of intelligent anti-aliasing.
New compression algorithms are always interesting because they reveal a new way of describing a photograph in a succinct way. The overlap between image compression and image searching is surprisingly high because the same techniques are used to derive the most important part of the picture data. Even if a new compression isn't ideal for image transmission, it is pretty much always a new avenue to look at for image matching/searching.
Coming from the other side, corners and edges are great ways to describe an image when doing process. It's a natural step to use this data for compression, which is what the authors have done here.
> It's a natural step to use this data for compression, which is what the authors have done here.
I understood the pixels for compression were chosen randomly, not by how much they define the main features of the picture. Or you meant the selected pixels are assumed to be defining features when reconstructing the image?
The captions showed images for the same compression ratios. It seems that, like jpg, you set some slider for how much compression you want. Since they select some % of source pixels it's a bit more easily calculated than jpeg "quality".
Sampling is already an integral (ha!) part of rendering. Not exactly in a way you're describing, apart from maybe sparse lighting passes like global illumination. Even then, it's more about random distribution and probability density functions than anything else.
28 comments
[ 3.2 ms ] story [ 78.2 ms ] threadJPEG is the appropriate comparison, as the authors are solving the same problem as JPEG tries to solve (i.e. a good enough lossy compression for natural images).
You're right that PNG does well on pictures with only few colors like diagrams but who knows how the edge-detecting PDE format would do, it might compress just as well with the same quality.
So I look at PDE and notice that its few points and colour contours bear a lot of similarity to a basic vector format. I wonder if a simplified vector format that utilises tracing combined with blurring effects would best PDE.
For a vector to encode a sky gradient you would have to have a shape and a specific falloff that blends into another shape and falloff to create the gradient.
The big idea is to describe the image intensities as a continuous surface which can be approximated in 3+ dimensions, not a patchwork of vector areas.
It's not representative of the performance of JPEG becasue You typically don't encode JPEGs at that bit rate.
It's basically taking advantage of the fact that JPEG dips first. http://article.sapub.org/image/10.5923.j.ajsp.20120205.04_01...
Also be wary of things that report compression rates rather than bits-per-pixel. You can get the same image quality at 200:1 if you start with 48 bit colour, The bits per pixel would be the same but if your original data is excessively precise you can throw a lot of it away at no perceptible cost.
[1] https://people.xiph.org/~jm/daala/paint_demo/ (was later abandoned due to the high cost, and now we have https://people.xiph.org/~jm/daala/deringing_demo/ )
Coming from the other side, corners and edges are great ways to describe an image when doing process. It's a natural step to use this data for compression, which is what the authors have done here.
I understood the pixels for compression were chosen randomly, not by how much they define the main features of the picture. Or you meant the selected pixels are assumed to be defining features when reconstructing the image?
What PDE are they using?