
Better Portable Graphics - tosh
https://en.wikipedia.org/wiki/Better_Portable_Graphics
======
JyrkiAlakuijala
Image compression is complicated. Licencing topics, decompression cpu time,
decompression memory use, decompression memory bandwidth use, compression
time, is asymmetric slower but more efficient compression available, multi-
threading, how much of the decoding can be shadowed during the data transfer,
how many levels of progression are preferred, global image artefacts (such as
banding) that don't appear in objective metrics, inter-frame copying ending up
copying strange stuff around, red colors tend to not to be compressed with
great success (there is no gamma compression for red in the eye, but in image
formats there is), how much the image format is for the eyes and how much for
the metrics, are the results the same on different platforms/implementations,
is alpha supported, how good is the HDR modeling and its rather non-linear
relations to gamma and colors in general, does the image format tend to
preserve the quality of materials such as wood, marble, skin, cloth -- or
replace them with cheap plastic imitation, some image formats work
dramatically well at low BPP (<0.5) but start failing when compared to old
JPEG at higher BPP (2.5+ BPP). Some image formats decode only a few megapixels
per second which can be a disaster if your images happen to be in the 40
megapixel category.

Overall, it is a very complex landscape.

~~~
jacobolus
> _there is no gamma compression for red in the eye_

What does this mean? Do you have a citation to a source explaining whatever
this is trying to say using precise standard color science terminology?

~~~
airstrike
Don't you know every HN thread needs its standard armchair top comment
rebuttal on how TFA is actually wrong and the author is naive and doesn't
really understand the problem with all its intricacies?

~~~
muizelaar
The top comment rebuttal is written by the author of the WebP lossless,
[https://github.com/google/butteraugli](https://github.com/google/butteraugli)
and [https://github.com/google/pik](https://github.com/google/pik) so calling
it armchairing doesn't really seem appropriate.

~~~
coolspot
Ouch

------
arghwhat
Please see AVIF
([https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...](https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_\(AVIF\)))
for an open, royalty-free alternative with similar or better performance.

And if you must use HEVC-based imaging, consider HEIF which has considerable
support.

~~~
pornel
HEIC/AVIF container is a complicated kitchen sink. It's closer to being a
PowerPoint file than an image format. It's an unnecessarily large attack
surface and a ton of features that nobody will (correctly) use anyway. The
reference implementation is a ton of C++ code I would not dare to use in a
security-sensitive application. OTOH libpng is a single C file, and it just
wraps a single HEVC payload.

For that reason I'd say that if you can license HEVC, use BPG, not HEIF. And
I'd love to have an AV1-based BPG version.

~~~
littlestymaar
small typo: _libbpg_ , not _libpng_

~~~
anoncareer0212
Thanks, very small but led me to jump to complete misunderstandings about bpg,
png, and libpng

------
andy_ppp
You can see how unbelievably better this is than JPG (at almost any file size)
here:

[http://xooyoozoo.github.io/yolo-octo-
bugfixes/#swallowtail&j...](http://xooyoozoo.github.io/yolo-octo-
bugfixes/#swallowtail&jpg=t&bpg=t)

Or here:

[https://bellard.org/bpg/lena.html](https://bellard.org/bpg/lena.html)

The difference between webp from the first link is actually quite small
([http://xooyoozoo.github.io/yolo-octo-
bugfixes/#swallowtail&w...](http://xooyoozoo.github.io/yolo-octo-
bugfixes/#swallowtail&webp=t&bpg=t)).

Additionally you can find the Javascript decoder here:

[https://github.com/xingmarc/bpg-decoder](https://github.com/xingmarc/bpg-
decoder)

It's 215k of Javascript though so isn't really that practical in most cases
and I'd worry about how it was affecting battery life. It'd be very
interesting to do some tests and see.

~~~
ajross
> unbelievably better

I don't know that this qualifies as unbelievable. This is just good marketing
and spin. The image in that link is exploiting the fact that modern codecs
specify upsampling filters, so the HEVC half looks smoothly varying while JPEG
can, per spec, only look pixelated when blown up like that.

There's absolutely no reason that thing couldn't have shown you a jpeg image
rendered with bilinear filtering, which of course is what you'll see if you
put that JPEG on a texture and scale it up using the GPU.

But it didn't, because it wanted to convince you how much "unbelievably"
better HEVC is. Meh.

I mean, to be clear: HEVC is absolutely better, to the tune of almost a factor
of two in byte size for the same subjective quality. Just not like this. If
you've got a site where still images are a significant fraction of your
bandwidth budget (and your bandwidth budget is a significant fraction of your
budget budget) then this could help you. In practice... static content
bandwidth is mostly a solved problem and no one cares, which is why we aren't
using BPG.

~~~
dahart
> There’s absolutely no reason that thing couldn’t have shown you a jpeg image
> rendered with bilinear filtering, which of course is what you’ll see if you
> put that JPEG on a texture and scale it up using the GPU.

That’s not true, this particular JPEG will not look smooth on a GPU. The
visible blocks are 8x8 pixels, not 1 pixel. The blocks would still be blocky
because the compression has reduced them to only the DC component. This means
the JPEG decode would still decode large blocks into texture memory and the
GPU would still render large blocks with a slight blur between the 1 pixel
borders of the 8 pixel blocks.

> In practice... static content bandwidth is a mostly solved problem and no
> one cares, which is why we aren’t using BPG.

I don’t believe that’s true either. I don’t know what you mean about bandwidth
being “solved”, but more data is more data. If everyone could reduce their
static images today by 2x without thinking, I’m pretty sure they would. I
would on my sites if I could. The reason that BPG (or any other format!) isn’t
yet being used is lack of browser support and tools and licensing and
consensus, not because nobody cares about bandwidth. If what you said is true,
then JPEG & PNG would never be replaced, but it’s already starting to happen.

~~~
ajross
The point was that, to first approximation, the internet is YouTube and
Netflix. Static images are noise.

And I'm sorry, but if that JPEG is showing artifacts like that it was simply
miscompressed, likely deliberately. I repeat, there is absolutely no reason an
image of there same byte count cannot look just fine on that screen. For
goodness sake, just reduce the resolution if nothing else.

~~~
dahart
The JPEG was compressed to death deliberately, yes. That's the point of the
comparison; for the same (tiny) data size BPG gives you a clearly better
result. BPG is workable in situations where JPEG isn't.

> For goodness sake, just reduce the resolution if nothing else.

Reducing the resolution would not work and is not the same thing. You would
still get 8x8 DC blocks in a smaller JPEG at the same compression rate, and
higher detail in the BPG. The BPG is provably better than the JPEG, and since
you already know that and talked about it above, I'm a little confused by your
argument.

~~~
ZeroGravitas
I think there often is a point when reducing the bitrate further while keeping
the same resolution is a worse choice than dropping the resolution. I believe
one of the tricks of AV1 is to internalise this trade-off.

More generally, doing visual comparisons of codecs is full of traps. Since
quality often falls off rapidly at a certain point it's possible to show your
codec off by choosing the exact point to compare to maximise the difference.
This is almost certainly the case if you're comparing against jpeg and it's
starting to totally fall apart.

It's not that it doesn't correctly show that one is worse than the other but
it's probably not a good visual reflection of the true scale of the difference
any more than ramping up the bitrate until everyone would think they are
indistinguishable.

~~~
dahart
Sure, yes, but the comparison in question isn't the only comparison, it's just
one of many. Letting people see the difference visually for themselves is more
tangible and less questionable that putting up two file size numbers and
claiming they're equal quality. And if you think about it, it similarly
wouldn't completely be fair to BPG to turn up the quality so that the JPEG
looked reasonably good, because the BPG file would be in the range of
diminishing returns per byte.

It is fair to point out that JPEG falls apart below a certain compression
threshold while BPG doesn't, even if it's a little bit apples to oranges. I
prefer the way @enriquito said it
[https://news.ycombinator.com/item?id=20419900](https://news.ycombinator.com/item?id=20419900)
but I disagree with the hyperbolic claims in this thread that this comparison
is outrageous or complete spin or cheating. It's a data point that has some
actual merit, and BTW happens to agree with the other data points we have.

------
lucideer
Presuming this was posted by someone exploring the works of Fabrice Bellard
after reading the HN comments here
[https://news.ycombinator.com/item?id=20411154](https://news.ycombinator.com/item?id=20411154)

~~~
namibj
This pattern continues to amuse me. I wish for some analysis of these
connectivity graphs, but I guess it's near-impossible to do accurately without
capturing the poster's history and looking at how they stumbled from previous
HN posts/comments onto the thing they post now.

~~~
microcolonel
It also crosses site boundaries.
[https://news.ycombinator.com/item?id=20366844](https://news.ycombinator.com/item?id=20366844)

~~~
namibj
Which is why I think user's browser history would be needed. And that's not
possible to do at statistically significant/useful scale.

------
elamje
The guy who wrote BPG is a legend. I was looking at his home page where it
lists cool projects - [https://bellard.org/](https://bellard.org/) and I was
thinking this is a great list of really popular projects. Then I realized he
made all of them! People that make this many important contributions should be
better recognized.

~~~
datalus
QuickJS is a great little JS engine as well that he wrote and is super easy to
embed :)

------
adrianN
And once again software patents are the hair in the soup.

~~~
robert_foss
Agreed. An AV1 based format would be more interesting, and likely have better
compression ratios.

~~~
theandrewbailey
See AVIF:
[https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...](https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_\(AVIF\))

------
rhardih
Anytime I see anything with Fabrice' name on it I'm immediately intrigued.
He's just on a different level. His list of projects is simply astounding. I
can duly recommend checking out some his other projects at
[https://bellard.org](https://bellard.org).

------
PostOnce
sans patent issues:

[https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...](https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_\(AVIF\))

still waiting on the software support.

------
DagAgren
iOS is already using HEIF, which is basically the same thing in a different
container format. That seems a much more likely candidate for actually being
taken up.

~~~
DagAgren
Correction: In addition to macOS and iOS, Windows 10 and Android apparently
also support it already.

------
m4r35n357
Fabrice strikes again! FFMPEG, QEMU, TCC . . . .

[https://bellard.org/](https://bellard.org/)

~~~
musikele
How this guy finds the time to work on these very different projects? Some of
them require skills that are very specific, how can you pass from writing QEMU
to TCC to the 4G station ... What does he do for living, how does he spend his
free time?

~~~
thechao
Writing emulators, compilers, operating-systems, and codecs are all standard-
skills of any low-level systems programmer. My _entire_ team of 50+ people are
capable of doing this stuff. The difference between us & Fabrice are: (1) we
work for a major company & none of our stuff is publicly available; and, (2)
he's still at least head-and-shoulders above most of the people doing this.
He'd easily be in the top 5 for my team, and certainly better than of the kids
under 40.

------
DoctorNick
patent encumbered. non-starter.

~~~
pedrocr
Seems like the same strategy starting with AV1 would be a good solution.

~~~
arghwhat
[https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...](https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_\(AVIF\))

~~~
pedrocr
Thanks. I went to the AV1 page but didn't notice that section. Seems
promising, with implementations already cropping up.

------
yboris
I'm looking forward to FUIF - Free Universal Image Format
[https://cloudinary.com/blog/introducing_fuif_responsive_imag...](https://cloudinary.com/blog/introducing_fuif_responsive_images_by_design)
Created by the same person who created FLIF (already an amazing format)!

Better yet, it's probably the most-likely technology to be accepted into the
upcoming JPEG XL standard!

~~~
microcolonel
The problem with FUIF is probably that it's not all that efficient at encoding
images, which is probably why there are _zero_ comparisons or demonstrations
of the actual images that can be found easily by going to the repository or
the authors' blog. The one FUIF image I've seen was the one in their clip
showing generational loss with various codecs.

~~~
bryanlarsen
FUIF has the ability to losslessly transcode from JPEG. This will make it very
useful in a couple of important use cases. But by constraining itself to DCT
in this way, I assume it performs relatively poorly compared to other modern
alternatives when compressing from a RAW source.

------
devwastaken
You can already use native av1 to display images in browser. You simply encode
your image to a single frame av1 webm with ffmpeg. Browsers will automatically
display the first image fully rendered, because it acts as a thumbnail. Afaik
no need for autoplay privledges.

------
sneak
Is there a reason that browsers don't jump on the bandwagon and implement
codecs for all reasonably-stable image codecs (save this one, which seems to
be patent encumbered)?

i.e.: why doesn't Chrome support AVIF? Is it because it competes with their
own invented-here WebP?

It seems like adding new image codecs for given content types would be pretty
trivial if the libraries are available and stable and license compatible; why
be conservative and not just support the newish ones to help the best ones
gain traction?

It seems like browser vendors are just dragging their feet.

~~~
timw4mail
Because browsers have an enormous API/file support surface as is, and each new
image format can be a significant amount of code to support essentially
forever.

Webp now is supported by pretty much every browser, but a lot of image viewers
don't support the format yet. There has to be a certain amount of momentum to
justify supporting a new image format.

------
Rhamb
There is also FLIF
([https://en.wikipedia.org/wiki/Free_Lossless_Image_Format](https://en.wikipedia.org/wiki/Free_Lossless_Image_Format))
which has a nice property: it is adaptive by design, that is, you can only
look at the first X bytes and get a first approximation of the image, and the
further you go, the better it becomes. It also allows for both lossless and
lossy compression.

I wonder how they compare.

(Don't take my word for that, I'm no expert on the subject)

~~~
lucb1e
JPEG does that too, you can enable progressive rendering in the encoder.
Having it enabled does not make the image larger in my experience.

------
m-p-3
I knew I recognized that name, it's one of the main ffmpeg and QEMU
developers! If BPG is up to the same quality than those two, then it has to be
a great format!

------
devy
Apple has unilaterally pushing their HEIF format to replace JPEG after iOS 11
- to combat the criticism of they differentiating their iPhone/iPad by storage
sizes and artificially make the base model a very small capacity (16GB for the
longest time) and their storage not customer replaceable.

[https://support.apple.com/en-us/HT207022](https://support.apple.com/en-
us/HT207022)

------
ChuckMcM
_" Patent issues may prevent JPEG replacement by BPG despite BPG's better
technical performance.[6]"_

BPG meet GIF, GIF meet BPG. The most annoying thing about GIF in the early
days were the damn Compuserve patents that they would go out of their way to
hassle you with if they thought they could.

------
jokoon
What about encoding/decoding performance?

> Current research works on designing and developing more energy-efficient BPG
> hardware which can then be integrated in portable devices such as digital
> cameras.

I guess it doesn't really matter that much, but I'm still curious.

------
legulere
Does something similar exist with AV1?

~~~
kristofferR
[https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...](https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_\(AVIF\))

------
Vosporos
That's it? we're milking Bellard's treasure cave for upvotes now?

~~~
wmf
I'm sure there are people who haven't been on HN for ten years who haven't
seen it. There's no Hacker Canon to discuss this stuff so people repost it
here.

------
AnthonBerg
Fabrice Bellard is a monster. I want to be just like him when I grow up. With
a monstrous list of accomplishments.

------
sproketboy
Why bother when we have PNG?

~~~
wffurr
Totally different algorithm for different purposes. PNG is lossless encoding,
doesn't work well for photographs or complex images.

~~~
Zardoz84
PNG works really fine for no HDR photos if you not are worry about the size.

~~~
zowanet
And BMP, TIFF, DPX, EXR etc all work really fine if you are not worried about
the size.

But being worried about the size is the whole point of image compression.

