
Why BPG will replace GIFs and more - antouank
https://eek.ro/why-bpg-will-replace-gifs-and-not-only/
======
tux3
Note that BPG is based on HEVC still frames, and may be more patent-emcubered
than current alternatives.

[https://en.wikipedia.org/wiki/Better_Portable_Graphics#Paten...](https://en.wikipedia.org/wiki/Better_Portable_Graphics#Patents)

~~~
Ace17
Why not another BPG-like based on VP9, then?

~~~
fnordfnordfnord
Looks like FLIF can do animations as well.
[http://flif.info/animation.html](http://flif.info/animation.html)

~~~
jason_s
FLIF is encumbered by GPL which means it's not going to make it into any
digital cameras.

~~~
jaredcheeda
The first official version of FLIF has not been released yet, and currently
they are discussing releasing it under Apache 2 or MPL (Mozilla Public
License).

~~~
ksec
Please Not MPL. Apache 2, so most company could understand, MPL they will have
to spend a lot more time evaluating it.

And I dont know of any popular project that uses MPL apart from Mozilla
Firefox.

~~~
jonsneyers
We are probably going to change to Apache2 for the decoder, LGPLv3+ for the
encoder.

------
shanselman
It says "Spot the differences? :) There’s none."

Really? The BPG is WAY worse, IMHO. It's immediately apparent. I noticed it
with my eyes before I parsed the text.

~~~
dsp1234
I don't even get to spot the difference. For some reason on my box chrome pegs
the cpu at 25% for about 30 seconds then asks me to kill the page. Stripping
out the alternate format, the other one plays instantly and with minimal cpu
usage.

~~~
sandyarmstrong
Read further down: "Current example is around 8-10s"

If you let it run for awhile it eventually decodes.

~~~
dsp1234
_If you let it run for awhile it eventually decodes._

I let it run past the "do you want to kill it" dialog for about 45 seconds
more, then it hard crashed the tab.

------
kjsthree
How does this compare to FLIF? The responsive features of FLIF seem fantastic.
[http://flif.info/](http://flif.info/)

~~~
jaredcheeda
In the part where it says "Spot the difference" and everyone says "The BPG one
looks worse". That's because BPG, even in "lossless" mode... is lossy. So
you're taking a video with H.264 compression artifacts and recompressing it
with HEVC artifacts. The quality can only go down.

FLIF on the other hand is lossless, so the image would be truly identical
(pixel for pixel). However the filesize will likely be much larger, as MP4 is
a very good at lossy compression. What BPG is doing is better performed by
HTML5 video formats that already exist due to hardware acceleration support
for H.264 and better memory management for video. Also there are patent issues
with BPG due to it being based on HEVC.

FLIF is patent free, making it the more likely candidate for mass adoption.
It's animation, like APNG is lossless and supports full 24-bit transparency
(versus GIF's 8-bit). However the filesize for FLIF is considerably smaller
than APNG, even when crushing it with algorithms like Zopfli. Still though,
for full frame video, you'll have a better time with MP4, though FLIF will be
better quality, it will only be marginal and not likely noticeable in most
cases.

What is interesting is the responsive aspect of FLIF. If you encoded an HD
video, but only display it on a page at a lower resolution, it will only
download the minimum amount of data required to display the image up to that
resolution. So it could technically require a lot less bandwidth from a server
compared to MP4 if the user doesn't fullscreen the video. But this is more to
do with implementation than with formats. YouTube does this same idea, though
with a completely different style of execution, in which they only give the
the quality for the resolution you are playing it at.

~~~
jason_s
FLIF is encumbered by GPL, so it is unlikely to make its way into digital
cameras.

~~~
jonsneyers
1) How does a GPL'ed reference implementation prevent digital cameras from
using the format?

2) The reference implementation will most likely change to a more permissive
license, cf [https://github.com/FLIF-
hub/FLIF/issues/192](https://github.com/FLIF-hub/FLIF/issues/192)

3) If digital cameras would use FLIF, they would probably need to implement a
simplified encoder in hardware, e.g. one that uses a hardcoded (set of) MANIAC
tree(s) and only uses a subset of the available encoding options. Otherwise it
will be too slow.

------
web007
Implementing an image format via JS is cool, but I'm not sure what the use-
case is for this format that isn't already covered (and supported in browsers)
by other formats.

[https://en.wikipedia.org/wiki/APNG](https://en.wikipedia.org/wiki/APNG)
should be a better alternative for GIF-like images (including transparency and
low bit depth), and MP4 + H.265 should be the alternative for movie-like
content. For most platforms, you might even get decoding support in hardware,
so performance and battery life shouldn't be anything but better vs this.

~~~
salehenrahman
> [APNG] should be a better alternative for GIF-like images (including
> transparency and low bit depth), and MP4 + H.265 should be the alternative
> for movie-like content.

H.264/H.265 are good for both Gif-like and movie-like content. Bandwidth isn't
cheap. Although APNG has inter-frame compression, it is nowhere near as
sophisticated as H.265 let alone H.264.

If I want animation, why would I use a format that puts a burden on users,
when alternatives already exist?

Don't get me wrong, I totally acknowledge that we still have the issue of mp4
files not autoplaying on mobile browsers. However, once that is solved, I
would avoid APNG and Gif, in favour of said video format.

Here's hoping that one day, BPG is adopted widely, so that I can forgo mp4 and
APNG/Gif entirely for use cases that cover short animations for aesthetic
reasons.

Albeit, I do admit, for the time being, I will resort to using mp4 and OGG on
the desktop browser, and either a static image or APNG on the mobile browser.

edit: some clarification

~~~
Nelson69
Do content providers have to pay certain royalties with h.264? I thought the
players were free of royalties and the license was paid for encoded content.
And then with h.265 I thought I heard that there were two different license
pools with different licensing strategies.

I'm not sure that meme generators have royalties very high on their list of
concerns, the big hosts that host a lot of them might have some concerns about
it though.

At this point, a newer webP based off the newer VP10 might be the only
realistic PNG, GIF, and JPEG replacement but it doesn't exist yet.

~~~
TD-Linux
For H.264 it's the opposite (for web content), only the players need to pay
royalties.

For H.265, both need to pay royalties, which depend on the business model. The
licensing terms are pretty much totally unsuited for usage as a still image
format. And yes, there are multiple pools and you have to pay all of them.

~~~
acdha
The license terms for H.264 appear to require both encoder and decoder vendors
to pay royalties once they ship over 100K units:

[http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf](http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf)

H.264 is similar for the MPEG pool:

[http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.p...](http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.pdf)

------
xutopia
The quality between the two formats is stunning... BPG version looks blurry
compared to the mp4 version.

~~~
jeffbr13
Author says that the BPG version is re-encoded from the MP4, so lower quality
is to be expected. Looking at the linked comparison tool[1], it seems that
while BPG and WebP both have fewer artefacts than JPEG at a given file-size,
BPG seems to achieve this with waaaay too much smoothing. Seriously, check out
the engineer's eyelids in [1].

[1]: [http://xooyoozoo.github.io/yolo-octo-
bugfixes/#production&bp...](http://xooyoozoo.github.io/yolo-octo-
bugfixes/#production&bpg=s&webp=s)

~~~
tobz
I take your comment to mean that you find the BPG version of that engineer
picture -- being "overly smoothed" \-- to be unrealistic, comparatively. I
think the face, as a whole, looks crisper. Even though the sharpness isn't
there, the lack of visible artifacts just looks plain better. This reminds me,
weirdly, of seeing video through an old television. The resolution is poor,
but it's not poor in a way where I think the image is fake. Things still look
real.

Separately, though, take a look at other features of the image: the beams
running lengthwise down the shell, specifically the ones on the top left of
the image. The BPG version makes them look niceeeeee and crisp, whereas the
WebP version looks very bad.

Other places where I think the BPG compression looks noticeably better: her
uniform (right sleeve, right leg, etc), the rivets along the top edge of the
platform she's standing on, where she's grabbing that power tool.

One thing I noticed in the BPG version is that some gradient areas have more
visual banding compared to the WebP version.

------
stonogo
Hundreds of millions of devices support GIF and JPEG and will never support
patent-encumbered processing-intensive newcomers.

------
kalleboo
Why can't we just use MP4? Add an inline JavaScript decoder for Mobile Safari,
and then at least all the other browsers get instant hardware decoding.

Are there trust issues with allowing third-party MP4 embeds into user-
submitted content such as forums/hosted blogs? Do we need a "no sound"/"max
file size" attribute on the video tag?

~~~
salehenrahman
Videos--more specifically mp4 videos-- _can_ be embedded into web pages. They
just don't autoplay on mobile browsers.

Hence why there is a push for alternatives to Gif/APNG and mp4/webm. We want a
video-like animation, that plays on page load.

Now, the real question is, why don't mp4s play when we hit play?

I can only speculate, but I think it's because mp4s are streamable media,
where a troll can simply decide to keep streaming mp4s and drain the user's
bandwidth. (Never mind the fact that it is also a problem with Gifs.)

~~~
tallanvor
> We want a video-like animation, that plays on page load.

Not all of us want that. In fact many of us would rather decide for ourselves
whether or not to play an animation, sound or not.

------
salehenrahman
Half the comments are pointing out that BPG is implemented in JavaScript.

Like no shit? It's not natively supported in browsers, and OP makes a call for
everyone to push browsers to natively support it.

I mean like, geez, I want a proper video-like playback format (e.g. 24+ frames
per second) at a smaller file size, so that I can view videos on my mobile
phone.

Gif lags on mobile internet, and MP4 requires that we explicitly hit the play
button on mobile browsers.

So either we adopt a format like BPG, or adopt another format based on
h.264/h.265/VP8/VP9/Theora but for the sole purpose of being a Gif-like
animation.

~~~
dperfect
> Gif lags on mobile internet, and MP4 requires that we explicitly hit the
> play button on mobile browsers.

Wouldn't the more obvious choice be simply adding an option in browsers to
_not_ require hitting the play button (perhaps for MP4 that has no sound)?

Even with browser support for BPG, MP4 has the huge advantage of hardware
acceleration in almost all modern devices[1].

[1] In theory, BPG may be able to take advantage of similar hardware
acceleration, but why not just fix the user experience around an existing
format rather than implement yet another format?

~~~
CaptSpify
Honestly, I view the need to hit the play button as the right user-experience.
Sure, a user-defined option to turn that off would be cool, but I'd never use
it. I wish GIFs had that option as well, actually

~~~
JadeNB
> I wish GIFs had that option as well, actually

They do, in Firefox!
[http://kb.mozillazine.org/Firefox_:_Tips_:_Animated_Images](http://kb.mozillazine.org/Firefox_:_Tips_:_Animated_Images)

(I know this is really late, but HN has been really aggressive about
"submitting too fast" lately, and a half hour's wait didn't convince it to let
me try again.)

~~~
CaptSpify
Sorry, I guess I'm missing it? Can you point it out to me? I see only play
once, play always, and never play

~~~
JadeNB
I'm sorry; you're right, I misunderstood your needs, and thought that you
wanted GIFs not to play at all. As with "there's an app for that", the answer
to most Firefox needs is "there's an extension for that". I'm not in touch
with the current Firefox extension ecosystem, but some Googling suggests that
[https://addons.mozilla.org/en-US/firefox/addon/toggle-
animat...](https://addons.mozilla.org/en-US/firefox/addon/toggle-animated-
gifs) should fill the need.

------
slyall
I found the BPG was stuttering.

Tried to just view the BPG alone by right clicking and "view image". it just
gave a static png though. Amusingly the URL of the static picture is amazingly
long (at least thousands of bytes) and does nasty things to my computer when I
tried to copy it.

Edit: It actually appears to be the images encoded since it starts with
"data:image/png;base64"

------
KaiserPro
BPG is basically HVEC, so why not just use HVEC?

its a serious question, in 2 years HVEC decoders will be in all hardware.
Which means fast, energy efficient decoders on virtually all platforms.

Having a seperate codec, which is basically a less capable version of an
industry standard, whats the point? (ignoring the still images part for a
second.)

~~~
beefman
HEVC, yes. But is a BPG animation the same as an HEVC video, or is it a
sequence of BPG frames?

The BPG standard[1] says P-slices are used, but not B-slices...

[1] sec 3.3
[http://bellard.org/bpg/bpg_spec.txt](http://bellard.org/bpg/bpg_spec.txt)

~~~
KaiserPro
right, how is that useful? thats my point, how does that give you something
more useful than HVEC it's self.

------
ss64
I just get an 'unresponsive script' error from line 95 of
[https://eek.ro/assets/js/bpgdec8a.js](https://eek.ro/assets/js/bpgdec8a.js)

------
martinko
Interesting to note that the MP4 stops playing when off-screen, while BPG does
not. Also, I too find the BPG quality worse.

------
izzydata
I don't care about the quality difference. You can just increase the bitrate
and not re-encode from a lossy format to solve most of that problem.

I welcome an image format alternative to webm.

------
beefman
How do the new lossy video formats work for looped videos? It looks like gifv
has been accepted by r/perfectLoops...[1] Do HEVC etc require the last frame
of a video to be a keyframe? Are predicted frames specified at the same
quality level as keyframes?

[1]
[http://www.reddit.com/r/perfectLoops](http://www.reddit.com/r/perfectLoops)

------
xupybd
If there is one thing history has taught us, it's that it's not always the
technically best solution that wins in the long run.

------
jedberg
Wow, this throws me back to the early 90s, when we would basically have the
same discussions about JPEG vs GIF. At the time most graphics programs could
open a GIF you downloaded with your modem, but if you wanted to view a JPEG
you had to jump out to a separate program, and everyone said that as soon as
there was native JPEG support no one would use GIF anymore.

~~~
mikeash
If people said that then they were silly, because JPEG and GIF solve different
problems. JPEG didn't displace GIF because JPEG doesn't actually do a good job
of compressing the images that GIF is good at compressing. Note that once a
format came along that _was_ good at those, namely PNG, it did displace GIF
pretty much entirely for the still-image use case.

~~~
jobu
Does anyone know why the APNG format was rejected by the PNG group?
([https://en.wikipedia.org/wiki/APNG](https://en.wikipedia.org/wiki/APNG))

It seems like a great replacement for animated GIFs.

~~~
jcranmer
APNG was rejected primarily because it used image/png when it was clearly a
video, and the WG felt that images shouldn't handle video. When video/png was
offered instead, Mozilla rejected that because it felt backwards compatibility
was more important.

So, basically, it was rejected due to a pissing contest on the least important
part of the specification.

------
ourcat
Wouldn't something like a looping MJPEG do the trick too? It's just
effectively a 'flickbook' of JPEGs.

------
_asdf_asdf
Right-click save as... oh. Not so much.

View source, CTRL-F and...

[https://eek.ro/assets/bpg/ambition.bpg](https://eek.ro/assets/bpg/ambition.bpg)

Kind of inconvenient. Not to mention it's a blank white empty space in
Firefox, and probably anywhere else not currently supporting the format.

~~~
err4nt
Some would call inability to save a feature, like copy protection by accident

------
ranrub
We ran FLIF and BPG on 200,000 random images - FLIF won
[http://cloudinary.com/blog/flif_the_new_lossless_image_forma...](http://cloudinary.com/blog/flif_the_new_lossless_image_format_that_outperforms_png_webp_and_bpg)

------
northisup
you can't pronounce BPG like GIF, so I can't see a future for it.

~~~
davnicwil
Can't tell how serious you're being, but there's definitely something to that!

On the other hand, mp3 found its way into common parlance just fine, despite
being decidedly unpronounceable as a word, so who knows.

Irony of course being the eternal debate over how to actually pronounce GIF:
[http://howtoreallypronouncegif.com/](http://howtoreallypronouncegif.com/) ;-)

------
th-ai
Anyone else try drag/drop BPG? Didn't work for me. GIF thrives despite flaws
because works everywhere, easy to use, remix, and above all: easy to share.

------
ksec
If only we could get away from the patent issues.

HEVC Advance now changes an _additional_ 50M/year to the 25M/year with MPEG-
LA.

------
dorfsmay
> By Fabrice Bellard

nough said, I'm sold!

~~~
diego_moita
Me too. That guy is smart.

------
Paul_S
I just get a blank frame on up to date FF. Chrome grinds to a halt.

------
dberg
anyone else misread this as BGP by accident ?

------
1ris
And here is why it wont:

>unresponsive script

>[continue execution] [stop]

~~~
salehenrahman
Uhmm... OP is demonstrating an example using a JavaScript-based polyfill.

If we rejected every feature that began as mere polyfills, we wouldn't have
the web that we have today.

Here's just a few examples: we would need images for rounded corners,
Gif/Flash/JavaScript for animations, Cookies for storage, Flash for browser-
based webcam calls, etc.

------
qwertyuiop924
This looks cool, but seems to have too many issues for me to go all in right
now.

------
mdjt
I had to reload the page four times to get the BPG to load correctly. No thank
you, sir.

------
Grue3
How can a lossy format replace a lossless format? The author clearly doesn't
know what they're talking about.

~~~
mikeash
GIF is _extremely_ lossy for this use case since they can't do 24-bit color.
In addition to being unnecessarily gigantic, animated GIFs also look terrible
for just about anything that isn't pixel art. GIF itself is a lossless format,
but when you use it for stuff like this the whole process is super lossy.

~~~
Grue3
Perhaps GIF wasn't intended for this use case? Oh right, it wasn't. There are
plenty of video formats that are. That doesn't make them "GIF replacement".

~~~
mikeash
GIF has already been replaced by better formats. The one exception to this is
short, looping videos, where GIF still enjoys enormous popularity.

So yeah, GIF wasn't intended for this use case. But that's the use case it has
right now.

Go back 20 years, and "GIF" means a 256-color losslessly compressed image,
occasionally animated. Today, "GIF" nearly always means a short looping video
with horrible compression.

Practically speaking, today, "GIF replacement" means doing a better job for
short, looping videos, because that's all GIF has left at this point.

~~~
Grue3
>GIF has already been replaced by better formats.

As long as Chrome/Webkit doesn't support APNG, there's no ubiquitous format
that directly replaces GIF.

>Today, "GIF" nearly always means a short looping video with horrible
compression.

To me, GIF means an image format. The fact that many people misuse the
terminology doesn't mean we should propagate it. Instead, people should be
educated on the difference between lossy video formats and image formats that
support animation, and which is preferable for various sorts of media.
Articles like the OP only confuse the issue further. As someone who has
authored animation-editing software (Animstack script for GIMP), it's a major
pain in the ass to explain these misconceptions to users. The least we can do
is to use correct terminology, and educate people at every opportunity.

~~~
mikeash
> As long as Chrome/Webkit doesn't support APNG, there's no ubiquitous format
> that directly replaces GIF.

That's a fun trick, to quote one sentence and disagree with it in a way that
is _already covered by the following sentence stating there is an exception_.

Do you find this helps further the conversation?

~~~
Grue3
I only quoted the sentence I was replying to. To assume I didn't read the rest
of your message is, frankly, insulting. The exception you were talking about
("short looping video with horrible compression") is precisely the thing that
both GIF and APNG aren't supposed to do well.

Both GIF and APNG support:

\- palettes

\- transparency

\- different delay per frame

\- combine/replace disposal mode per frame

Generic video formats don't generally support these.

