Why BPG will replace GIFs and more(eek.ro)
eek.ro
Why BPG will replace GIFs and more
https://eek.ro/why-bpg-will-replace-gifs-and-not-only/
31 comments
GIF sites are moving to GIFV that is just a video file, it looks like there is no real need for any new format.
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.)
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.)
> 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.
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.
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.
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.
> 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?
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?
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
I agree - I wouldn't enable that option either, but at least it'd offer a better alternative for people who do like GIFs / GIF-like animations.
It's a bit ironic that the autoplay functionality of BPG is touted by some as a major advantage, yet the only reason it autoplays is because it currently has to be implemented in Javascript (bypassing the normal push-to-play behavior of web video).
If the people pushing for native BPG browser support get their way, the most likely outcome will be BPG implemented with the same push-to-play UX as any other kind of web video.
It's a bit ironic that the autoplay functionality of BPG is touted by some as a major advantage, yet the only reason it autoplays is because it currently has to be implemented in Javascript (bypassing the normal push-to-play behavior of web video).
If the people pushing for native BPG browser support get their way, the most likely outcome will be BPG implemented with the same push-to-play UX as any other kind of web video.
> I wish GIFs had that option as well, actually
They do, in Firefox! 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.)
They do, in Firefox! 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.)
Sorry, I guess I'm missing it? Can you point it out to me? I see only play once, play always, and never play
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... should fill the need.
> 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)?
This is basically what Imgur did with GIFV (http://blog.imgur.com/2014/10/09/introducing-gifv), I think.
This is basically what Imgur did with GIFV (http://blog.imgur.com/2014/10/09/introducing-gifv), I think.
And also, I might point out, from an earlier comment that I posted; the BPG decoder is merely a polyfill.
If we rejected every feature that began as mere half-baked polyfills, we wouldn't have the web that we have today.
Here's just a few examples:
If we rejected every feature that began as mere half-baked polyfills, we wouldn't have the web that we have today.
Here's just a few examples:
- images for rounded corners
- Gif/Flash/JavaScript for animations
- Cookies for storage
- Flash for browser-based webcam calls, etc.Mp4 requiring you to hit play is a /feature/ in my book. The fact that animated gifs automatically play has caused more problems, like annoying banner ads, than it's created.
Were this fifteen years ago, I'd recommend that the makers of this format create a proper plugin to handle this format in the interim, but because browser makers are terrified of extra functionality, especially on mobiles, we can't do that anymore.
Were this fifteen years ago, I'd recommend that the makers of this format create a proper plugin to handle this format in the interim, but because browser makers are terrified of extra functionality, especially on mobiles, we can't do that anymore.
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"
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"
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.)
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.)
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
The BPG standard[1] says P-slices are used, but not B-slices...
[1] sec 3.3 http://bellard.org/bpg/bpg_spec.txt
right, how is that useful? thats my point, how does that give you something more useful than HVEC it's self.
I just get an 'unresponsive script' error from line 95 of
https://eek.ro/assets/js/bpgdec8a.js
Interesting to note that the MP4 stops playing when off-screen, while BPG does not. Also, I too find the BPG quality worse.
[deleted](1)
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
[1] http://www.reddit.com/r/perfectLoops
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.
Wouldn't something like a looping MJPEG do the trick too? It's just effectively a 'flickbook' of JPEGs.
Right-click save as... oh. Not so much.
View source, CTRL-F and...
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.
View source, CTRL-F and...
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.
Some would call inability to save a feature, like copy protection by accident
We ran FLIF and BPG on 200,000 random images - FLIF won
http://cloudinary.com/blog/flif_the_new_lossless_image_forma...
you can't pronounce BPG like GIF, so I can't see a future for it.
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/ ;-)
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/ ;-)
Nobody pronounces GIF correctly anyway.
Bee-Peg
bee-pee-...jay?
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.
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.
HEVC Advance now changes an additional 50M/year to the 25M/year with MPEG-LA.
I just get a blank frame on up to date FF. Chrome grinds to a halt.
anyone else misread this as BGP by accident ?
And here is why it wont:
>unresponsive script
>[continue execution] [stop]
>unresponsive script
>[continue execution] [stop]
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.
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.
This looks cool, but seems to have too many issues for me to go all in right now.
How can a lossy format replace a lossless format? The author clearly doesn't know what they're talking about.
Because the internet doesn't need a HUGE lossless animated image format. What it needs is something GIF-like (animated images with no sound) that works universally, is smaller, and doesn't consume too much battery on mobile devices.
So BPG (or others) could replace GIF for the way GIF is commonly used today, rather than a direct 1:1 drop in replacement in all scenarios. If you really need lossless then continue to use GIF, support isn't going away soon, but for small soundless animations, a better alternative may be welcomed.
PS - The statement "The author clearly doesn't know what they're talking about." is inflammatory and needless. The author never said anything either way about lossless/lossy.
So BPG (or others) could replace GIF for the way GIF is commonly used today, rather than a direct 1:1 drop in replacement in all scenarios. If you really need lossless then continue to use GIF, support isn't going away soon, but for small soundless animations, a better alternative may be welcomed.
PS - The statement "The author clearly doesn't know what they're talking about." is inflammatory and needless. The author never said anything either way about lossless/lossy.
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.
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".
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.
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.
>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.
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.
> 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?
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?
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.
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.
I can't believe you're downvoted so hard for reminding people of the thing gif is good at.
We already have 'short video clip' formats that are better than gif.
We already have 'short video clip' formats that are better than gif.
Whether GIF was intended for this usecase or not (it wasn't, the GIF spec specifically calls it out as a bad idea [0]), it's overwhelmingly what it's used for in practice. Therefore anything that can displace GIF in this space is a replacement.
[0] https://www.w3.org/Graphics/GIF/spec-gif89a.txt
> Animation - The Graphics Interchange Format is not intended as a platform for animation, even though it can be done in a limited way.
[0] https://www.w3.org/Graphics/GIF/spec-gif89a.txt
> Animation - The Graphics Interchange Format is not intended as a platform for animation, even though it can be done in a limited way.
Now I wonder whether there are more animated GIFs out there or 1×1 tracking pixels ...
BPG has a lossless mode.
Does its lossless mode compress non-photo images as well as png?
The quality between the two formats is stunning... BPG version looks blurry compared to the mp4 version.
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...
[1]: http://xooyoozoo.github.io/yolo-octo-bugfixes/#production&bp...
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.
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.
[deleted]
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#Paten...
Patents were my first thought when reading the OP. Any media format discussion without IP is fairly meaningless.
"Why BPG won't replace GIFs and not only"
Why not another BPG-like based on VP9, then?
I think one based on VP10 is a possibility, since the Alliance for Open Media now includes all major browser makers except Apple, and a bunch of big websites.
Currently the members seem to be working on converging VP10, Daala and Thor tech in the video realm but I'd guess images might be on their radar too.
Currently the members seem to be working on converging VP10, Daala and Thor tech in the video realm but I'd guess images might be on their radar too.
Looks like FLIF can do animations as well. http://flif.info/animation.html
FLIF is encumbered by GPL which means it's not going to make it into any digital cameras.
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).
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.
And I dont know of any popular project that uses MPL apart from Mozilla Firefox.
We are probably going to change to Apache2 for the decoder, LGPLv3+ for the encoder.
LibreOffice?
Eigen (perhaps not "popular" unless you're interested in doing linear algebra with C++.. :-/ )?
Surely there are others as well..
If you want a weak copyleft license, IMHO MPL-2.0 is about the best available at the moment, and relatively easy to follow.
Eigen (perhaps not "popular" unless you're interested in doing linear algebra with C++.. :-/ )?
Surely there are others as well..
If you want a weak copyleft license, IMHO MPL-2.0 is about the best available at the moment, and relatively easy to follow.
oh, good! :-)
That's basically what WebP is.
As far as I know, WebP still uses VP8, not VP9.
Which is a shame, because it could have big a big leap over JPEG instead of a sidegrade if they had waited a bit.
I had to reload the page four times to get the BPG to load correctly. No thank you, sir.
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.
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.
Does anyone know why the APNG format was rejected by the PNG group? (https://en.wikipedia.org/wiki/APNG)
It seems like a great replacement for animated GIFs.
It seems like a great replacement for animated GIFs.
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.
So, basically, it was rejected due to a pissing contest on the least important part of the specification.
libpng is a reference implementation of the PNG format. They don't have to support every third-party extension.
But libpng provides callback methods for "unknown" chucks, so the application can read and handle them. So it's possible to process APNG with libpng.
But libpng provides callback methods for "unknown" chucks, so the application can read and handle them. So it's possible to process APNG with libpng.
Hah yep given how long GIF has persisted, I think it's clear that nobody cares about what is the best format in terms of technical achievement. It's all about what is most compatible.
Pretty much.
Q @ anyone whom chimes in: what format(s) do sites use for silent, live-action backgrounds to make their websites and apps seem friendlier?
Q @ anyone whom chimes in: what format(s) do sites use for silent, live-action backgrounds to make their websites and apps seem friendlier?
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.
I welcome an image format alternative to webm.
How does this compare to FLIF? The responsive features of FLIF seem fantastic. http://flif.info/
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.
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.
FLIF is encumbered by GPL, so it is unlikely to make its way into digital cameras.
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
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.
2) The reference implementation will most likely change to a more permissive license, cf 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.
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).
In this example .mp4 video, I extracted the frames as 369 invidual PNG files, with a total size of 193MB.
Encoding those 369 PNG files to a LOSSLESS BPG animation (using bpgenc 0.9.6 with options -lossless -a) produces a .bpg file of about 50MB.
Encoding them to APNG (using apngasm 2.7) results in a 57MB animated PNG file.
The corresponding progressive FLIF animation is 20 MB.
Obviously it is not a good idea to losslessly encode lossy images/movies, as a lot of bytes are wasted on encoding compression artifacts.
Encoding those 369 PNG files to a LOSSLESS BPG animation (using bpgenc 0.9.6 with options -lossless -a) produces a .bpg file of about 50MB.
Encoding them to APNG (using apngasm 2.7) results in a 57MB animated PNG file.
The corresponding progressive FLIF animation is 20 MB.
Obviously it is not a good idea to losslessly encode lossy images/movies, as a lot of bytes are wasted on encoding compression artifacts.
FLIF only has a lossless mode. For lossless animation, it usually beats GIF, APNG, MNG, WebP and BPG. It is the only responsive animation format afaik.
For lossy movies, actual video codecs are best, since they're designed for that. BPG is essentially HEVC (a great but patent-encumbered video codec) so it should be good at lossy movies -- it will be worse on line-art animations with hard edges like e.g. cartoons, or animations with transparency.
For lossy movies, actual video codecs are best, since they're designed for that. BPG is essentially HEVC (a great but patent-encumbered video codec) so it should be good at lossy movies -- it will be worse on line-art animations with hard edges like e.g. cartoons, or animations with transparency.
I don't think this is entirely fair. The full encoding of FLIF is lossless, yes, but it has VERY strong progressive decoding.
You could just truncate the file at x% and get lossy encoding that way.
You could just truncate the file at x% and get lossy encoding that way.
Thanks for the compliment about FLIF's progressive decoding! (FLIF author speaking here)
However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting.
So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expect lossless encoding, to avoid generation loss and to get the most out of their display hardware. E.g. higher bit depths are becoming a thing, while the JPEG/WebP color space (YCbCr) is effectively less than 22 bits per pixel (roughly speaking, red and blue are only 7-bit), and chroma subsampling makes this even worse. Also what's the use of ever higher display resolutions if most of those pixels are only displaying compression artifacts or blur? Lossy formats like JPEG/WebP/BPG/JP2/JXR are good at medium-quality, but if you use them at a near-lossless quality setting (e.g. 99 or 100 for JPEG), they often produce bigger files than lossless formats.
Meanwhile, the range of display sizes is getting larger: while in the past, we had a range from say 13" monitors to 21" monitors, now we have a range from 1.5" smart watches to huge 100" smart TVs. I do think that in order to avoid huge amounts of rescaling/transcoding, we need image/video formats that are "responsive by design", like JPEG2000 and FLIF (and progressive JPEG to some extent).
However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting.
So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expect lossless encoding, to avoid generation loss and to get the most out of their display hardware. E.g. higher bit depths are becoming a thing, while the JPEG/WebP color space (YCbCr) is effectively less than 22 bits per pixel (roughly speaking, red and blue are only 7-bit), and chroma subsampling makes this even worse. Also what's the use of ever higher display resolutions if most of those pixels are only displaying compression artifacts or blur? Lossy formats like JPEG/WebP/BPG/JP2/JXR are good at medium-quality, but if you use them at a near-lossless quality setting (e.g. 99 or 100 for JPEG), they often produce bigger files than lossless formats.
Meanwhile, the range of display sizes is getting larger: while in the past, we had a range from say 13" monitors to 21" monitors, now we have a range from 1.5" smart watches to huge 100" smart TVs. I do think that in order to avoid huge amounts of rescaling/transcoding, we need image/video formats that are "responsive by design", like JPEG2000 and FLIF (and progressive JPEG to some extent).
Good luck, it sounds like a great format! One really nice thing about lossless formats is that they are great for archival purposes since you can easily convert them to whatever format is currently optimal or convenient for end use (if you don't want to use it directly). I shudder at the number of complex video implementations that may need to be supported forever due to quality loss if you convert them.
As a fun side project I was thinking of writing a clean room FLIF en/decoder, but I can't seem to find any paper or real explanation of the mechanics. Are those coming, or did I just miss those?
There is a paper draft at https://github.com/FLIF-hub/FLIF-doc, but most of the details still have to be written down (i.e. they're only in the code).
Writing out the detailed spec is going to take some effort.
Writing out the detailed spec is going to take some effort.
FLIF is based on context mixing so it's extremely slow but has an extremely high (lossless) compression ratio. It's designed for image archival and not for real-time streaming video. It does have some interlacing techniques for previewing the image in a lower resolution but really it's orders of magnitude slower than other image formats.
The current decode time (on a lower end ARM CPU) is approx 1 megabyte per second. This of course will increase as the format is finalized and better/more optimized decoders are written for it. As well as with CPU speeds increasing. Though even at the current rate it should be fast enough in almost any real world scenario. A 1080p video on youtube is about 260-320 kilobytes per second. So as long as video quality doesn't demand 3-4 times what we are currently getting from HD video online, it should decode faster than it matters. Plus the whole video is available as it downloads in a lower resolution. It just gets clearer the longer it plays. Which is a much better experience than GIF/APNG/BPG/WebP and even MP4 in use as a GIF replacement. Though the MP4 will almost certainly be visually as good of quality at a consistently much smaller filesize due to H.264's fantastic lossy compression.
Wow! This is amazing!
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.
Really? The BPG is WAY worse, IMHO. It's immediately apparent. I noticed it with my eyes before I parsed the text.
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.
Read further down: "Current example is around 8-10s"
If you let it run for awhile it eventually decodes.
If you let it run for awhile it eventually decodes.
MP4 to BPG conversion. What else did you expect?
We're essentially converting from one frequency-domain format to another in order to accommodate an entirely new inter-frame compression format. There definitely needs to be a frequency-domain to spatial-domain conversion, which that, in itself, is lossy, then it goes back to frequency-domain when re-encoding.
Give OP a break.
We're essentially converting from one frequency-domain format to another in order to accommodate an entirely new inter-frame compression format. There definitely needs to be a frequency-domain to spatial-domain conversion, which that, in itself, is lossy, then it goes back to frequency-domain when re-encoding.
Give OP a break.
Not trying to not give them a break, but I'm pointing out they said clearly there's no difference in quality. There surely is.
To your excellent point about MP4 to BPG conversion, I'd say that OP should have used (did they? I don't know) the source material to avoid a "copy of a copy."
To your excellent point about MP4 to BPG conversion, I'd say that OP should have used (did they? I don't know) the source material to avoid a "copy of a copy."
Are you the same guy from the article comments?
Granted, the Author should have been clearer about it, but BPG's is not mean to replace MP4 even though he juxtaposed them, it's about BPG's potential replacement for GIF.
Granted, the Author should have been clearer about it, but BPG's is not mean to replace MP4 even though he juxtaposed them, it's about BPG's potential replacement for GIF.
You can't "be clearer" about making a blunt statement that's completely wrong and untrue.
Hundreds of millions of devices support GIF and JPEG and will never support patent-encumbered processing-intensive newcomers.
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 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.
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.
> [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
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
Alpha channels in H.26x (really any delivery codec) are a nightmare compared to APNG/GIF.
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.
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.
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.
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.
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
H.264 is similar for the MPEG pool:
http://www.mpegla.com/main/programs/HEVC/Documents/HEVCweb.p...
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...
Can H.264/H.265 do that in a lossless fashion?
No, hence, Gif/APNG are good for lossless animations. But for sites like imgur that host animations, I would like it if their gifv format (pretty much mp4/webm) played immediately on my mobile, without it having to be a gif file.
I think h264 does have a lossless mode, but it may end up bigger than a GIF.
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?