Actually, 50 fps is not going to be "buttery smooth" as well, because with a framerate of 60 fps you cannot update display image 50 times per second, so some frames will be doubled.
I have another hypothesis on "smoothness" of animated images. Most of computer-generated animations are unnatural and not cinematic because the objects jump between frames instantly while in real life and on a camera film they move smoothly. The hypothesis is that if the animation was closer to real life, then it would look really smooth even with lower fps, for example, 24 fps or 30 fps.
For example, when moving a mouse cursor, it jumps between points every 16 ms instead of moving smoothly. You could argue that a human is unable to notice such tiny details, but here is a simple test to find out: take a mouse and move it in a circle, so that it makes 2-3 turns per second. If a real object would move with such speed, all you would see would be a blurred circle (you can take any real object and see for yourself), however with a mouse I can clearly see a circle made of about 10-15 mouse cursors. So the animation of mouse cursor is unrealistic, computer-like and it can be easily seen (I noticed this effect long time ago but initially thought that it is a problem with Linux or slow graphics card).
So to make a smooth animation you could use oversampling: generate an animation at say 6000 fps, and blend every 200 frames together (remember about non-linearity of RGB values when mixing colors). If by chance anyone has some free time and curiosity, could you test it?
A technique similar to what you described is sometimes used in graphics engines for games. It's generally referred to as "motion blur". I think what the engines actually do is determine if an object has a velocity relative to the camera, and apply a stretch and blur effect on the object based on the direction of movement. This is relatively cheap (don't have to render many times times per single frame), but comes with a downside that the blur effect "overshoots" which can look weird when an object suddenly decelerates.
The instantaneous motion problem was discovered by claymation artists decades and decades ago. Motion blur is an essential component for our optical system to infer velocity and acceleration.
This should be correct but it probably is less about the "animation being closer to real life" and more about the actual measurement method. A camera measuring at 24 fps is likely going to have exposure times closer to 1/24 and measure an average scene over that time instead of an instantaneous measurement. The oversampling method you suggest would correct for this.
I think it's easiest to talk about smoothness in video by talking about choppiness.
There are two kinds of choppiness that happen in recorded video:
1. The amount of time/motion between captured frames (framerate).
2. The amount of time/motion captured by each frame (shutter speed).
You are right that the instantaneous shutter used in rendering maximizes the choppiness of a given framerate. The solution you described is a feature in most rendering software called "motion blur". If you want perfect motion blur, you have to render enough intermediary frames to cover the motion in a scene across every pixel it moves across.
There are a few other less obvious places shutter speed choppiness comes into play:
1. Cameras. Some digital cameras have a physical shutter that opens and closes, and all of them have a speed at which light is captured by their sensors. When using a shutter to record video, there is a non-zero amount of time that is skipped in recording.
2. Lighting. Most lights have a framerate that matches the local standard alternating current rate: 60hz in the US, and 50hz in Europe. This is why NTSC is 60fps and PAL is 50fps. Different types of lighting fixtures have varying amounts of flicker, because they don't keep the same amount of brightness over each alternation of current. Florescent lighting is well known for (often) having a noticable flicker. You can see the effect of flickering lights by waving your hand in front of you. If it looks like a blurred motion, your lights aren't flickering. If it looks like you have many transparent fingers staying in place, then you have flickering lights.
Because resolution has been steadily increasing in popular media, but framerate has not, most filmmakers have been using faster shutter speeds to compensate. If you have motion across 10% of the screen over 1 second at 30fps, then during each frame, that motion will cross 1280px*10%/30fps = 4.266px of a 720p video, or 3840px*10%/30fps = 12.8px of a 4K video. A slower shutter will give you motion blur across those pixels, yeilding an effective resolution close to 1/4.266 of the 720p video (168.75p) or 1/12.8 of the 4K/2160p video (still 168.75p). A faster shutter would remove the blur, replacing it with an uncanny teleportation: the same that makes your fingers look copied and transparent when you wave them in front of a CRT monitor.
In order to get a smooth and clear/focused motion over 1 second across 10% of a 720p video, you must have a framerate of at least 128fps. 384fps for 4K. Now consider that most motion we capture in film is faster than that; some of it much faster.
The effect you're looking for is motion blur. You can actually get a "video game like" effect with a real camera too if a scene is very well lit and you chose a large aperture size and very fast shutter speed. It looks similarly jerky.
What you suggest trying is actually possible with quite some games/engines. Some other commenter mentioned the source engine, I did it once with trackmania a good decade ago. It does very much amplify the feeling of speed.
When opening the article I actually assumed it would be shown how to create motion blur from the individual frames calculated for the target frame rate. might have been a nice feature
Any gif that claims to be showing 60fps is simply untrue due to the fact that no web browser out there right now supports displaying gifs higher than 50fps.
Only if you limit yourself to displaying the gif in an <img /> tag. You can parse the frames yourself and render them with a <canvas> at a faster rate using browser's requestAnimationFrame (which sync's to the refresh rate of your display.)
If you own the presentation platform of the gif, would it not be better to use different format?
The only advantage of gif I know of is that the creator of the asset has some control of the playback on the presentation platform. Other than this, it is a technically sub-optimal format. But no other formats support the creator control aspect.
I think the point is that 60 fps is not a representable value in the gif binary format, just like (int pi) can be either 3 or perhaps 4, but never a transcendental number.
You can have a magical decoder that circumvents this, but that's no longer a gif.
> I made this set of gifs of the same animation at different frame rates in ascending order(fps gets progressively higher). If any of them take a different amount of time to reach the start and end points(they are all exactly 1 second long) then you know what framerate your browser is “restricting” the frame delay at.
"1 second long" is pretty misleading, especially when telling people to look for different amounts of time to render. None of the gifs from 8-30fps are properly trying to be a second long.
If you have software that assigns the same delay to each frame, that's a flaw you need to compensate for or switch to different software, and the author did neither.
Let's use the 30fps gif as an example. It runs 11% too fast. Either it should be rendered with 33 frames, making it run 1% too fast, or it should use frame timings of 30ms 30ms 40ms 30ms 30ms 40ms making it exactly 1 second total.
As an aside, I’m very impressed by the comments widget that uses Github issues. I think I might adopt it for my blog. I never cared much for comment sections, but my blog is a Github repository anyways, so I might as well use it. Thanks!
I just added Giscus to my site which is the same thing but using GitHub Discussions instead of Issues as the backend which makes more sense.
It's almost perfect except for one almost deal breaker thing (which applies to both Giscus and utterance.es): to comment you have to click through a very scary permissions dialog that claims it can "Act on your behalf" in your Github account, without any qualification. I'm pretty sure the permissions dialog is misleading, but it sucks. I expect that it really cuts down on the number of people willing to leave a comment. And I doubt it will be fixed because Github probably doesn't really care to support this use of their API.
GIF being used to represent repeating or just video files, while at the same time often times having much worse performance than using compressed video, is one of the worst decisions of the modern web. The only time I found GIF to be useful was before proper PNG transparency support.
I think the reason GIF has thrived has as much to do with safety/malware as it does anything else. Unlike Flash or the perpetual need to download random codecs in the mid-2000s, GIF offers a very small surface-area for exploits.
I agree. What’s funny is that the opposite is true too: lots of pixel art animations and other things that are actually suited to GIF get mangled into lossy mp4s by the social media sites on upload.
Unfortunately still waiting for apple to fully support transparent webm. Apngs are often way too big so the solution just ends up being either two different videos with some fallback for apple devices that doesn’t look as good or gifs (or some kind of js animated thing)
There's a number of reasons I can think of. Ease of use is one; with video you have to consider different video formats for different browsers, unless that one's been solved already.
But another one I'm less happy with is removing choice from the user. I hate auto-playing videos so I have that turned off, but this does not apply to gifs. And I don't mind auto-playing videos either if they take the place of reaction gifs.
There was a comment about wanting to improve browser support that was deleted, and I lost the reply I typed, so I'll make a short version:
Gif can't do smooth 60fps even if it could do 1-delay frames. They chose centiseconds for some reason I've never understood, when milliseconds would have worked fine and avoided this issue. If your file shouldn't just be a video anyway, then the only fix is to use apng and demand sites support apng.
The "reason" could have just been insufficient future-proofing. Can you guess where the number part of GIF89a comes from? A time when the idea of a network-transmittable file with 60fps of animation was not an immediate practicality, that's for sure.
That this ancient format is still as prevalent as it is on the modern web is somewhat dumbfounding and probably unintended by its original creators.
On my display, most of the demo-gifs look like they are insufficiently low-passed to render realistic/smooth motion.
The 24/25 fps gifs certainly have the opportunity to look great (movies are mostly at 24 fps), but the hard-edge rendering of the black circle makes 'em look real choppy. I'd bet that rendering it at 50 fps, then averaging pairs of frames together and displaying it at 25 fps would yield something that seemed much smoother.
With some care, I bet one can go sub-25 fps on a gif and still have something that feels kinda "smooth".
When you're the creator of the animation, you can directly simulate motion blur instead of using temporal downsampling.
The smoothness of video depends on the angular distance objects move in your field of view between frames. You can see this in the demos: the lower framerates are relatively smooth at the ends of the animation where the motion is slowest, and all framerates (even the highest) become considerably smoother when you decrease your browser zoom.
Not a movie buff here… but do movies avoid shooting anything that might have this sort of problem? Like perfectly round black circles moving in a circle for instance.
After all all we see is an illusion anyway (has to be interpreted by low energy consuming brain)! They can probably distract us from choppyness.
For me the animation also looks choppy, as if a ball was jumping instead of moving, and it doesn't look smooth, however this just could be a problem with LCD matrix response time.
See also: historically PAL regions. For some inexplicable reason broadcast TV in the UK is still 50Hz despite the fact that every display has been been 60Hz+ for 15+ years.
Also a huge pain for old games. Lots of crummy conversions that straight up just run 17% slower on the PAL version.
Can somebody explain why this is the case? A 50FPS signal (max 25Hz) sampled at 60Hz should not produce any errors.
I can only imagine errors to show up by "doing it wrong", that is, aliasing artifacts due to not lowpass filtering the signal beforehand.
That said, I'm not totally sure that a 50FPS signal is acutally capped to 25Hz since a 50FPS GIF is usually not interpreted as a signal sampled at 50Hz but as a piecewise-constant signal with 50 "steps" per second. So the first question is whether these "jumpiness" is an inherent, desired property of GIFs or an artifact of bad renderers. Can somebody clarify this?
Are there any use cases on the web, beside transparency, where you need an animated gif and you cannot use a video? Videos will always have better quality and compression.
I can think of one, which is avoiding Twitter video compression but that's kind of a weird case.
Animated smileys comes to mind, I don't think video can compete with those.
Another one is that gifs are much easier to share, save, and reuse; with gifs, it's right-click and save, with videos... I don't even know where to begin.
So I thought humans aren't supposed to be able to distinguish above ~30 fps. I've always been a little skeptical of that because faster framerates seem subjectively smoother to me, but I was willing to write that off to psychological bias or sync/timing artifacts between interfaces or whatever.
Maybe someone out there can clear this up for me and convince me why we need 120+ fps displays?
EDIT: Well, nevermind, a quick google search corrected my misconception about 30fps.
I always remembered the original saying is that human will consider things "animated" when it's above threshold (24fps or whatever).
Telling 24, 30, 60 apart is very trivial.
As for 120fps, you need to keep in mind that playing a real-time rendered computer game is a totally different beast than playing back a steady video. There are lots of other factors involved. Some headroom in FPS makes lots of difference due to various other things like jittering (judder?), input delays, response time etc. (also it's possible some people simply can tell 60/120 apart, even by just watching a video.)
My naive understanding is that some of it is because if you follow an object on the screen with your eyes, it gets motion blurred on your retina as it stays still for ~1/30 s on the screen while your eyeball moves.
It is possible to improve on this without increasing the framerate with strobing the backlight/black frame insertion.
For most realtime 3d animation, I wonder whether it's that the camera effectively has an infinite shutter speed, so you lose the natural motion blur you get when real film and our retinas get exposed to short durations of changing light. That changing light and blur carries information that is not rendered by most games. Quadrupling the frame rate will add some of it back?
[+] [-] codedokode|3 years ago|reply
I have another hypothesis on "smoothness" of animated images. Most of computer-generated animations are unnatural and not cinematic because the objects jump between frames instantly while in real life and on a camera film they move smoothly. The hypothesis is that if the animation was closer to real life, then it would look really smooth even with lower fps, for example, 24 fps or 30 fps.
For example, when moving a mouse cursor, it jumps between points every 16 ms instead of moving smoothly. You could argue that a human is unable to notice such tiny details, but here is a simple test to find out: take a mouse and move it in a circle, so that it makes 2-3 turns per second. If a real object would move with such speed, all you would see would be a blurred circle (you can take any real object and see for yourself), however with a mouse I can clearly see a circle made of about 10-15 mouse cursors. So the animation of mouse cursor is unrealistic, computer-like and it can be easily seen (I noticed this effect long time ago but initially thought that it is a problem with Linux or slow graphics card).
So to make a smooth animation you could use oversampling: generate an animation at say 6000 fps, and blend every 200 frames together (remember about non-linearity of RGB values when mixing colors). If by chance anyone has some free time and curiosity, could you test it?
[+] [-] Ruphin|3 years ago|reply
[+] [-] jessermeyer|3 years ago|reply
[+] [-] CuriousSkeptic|3 years ago|reply
It’s more or less dedicated to that issue
Another thing that can help is black frame insertion (thus removing the sudden “jump”)
[+] [-] dannyz|3 years ago|reply
[+] [-] seabea|3 years ago|reply
Those techniques have actually been around for a long time in traditional, handrawn animation.
https://www.traditionalanimation.com/2017/smear-speed-motion...
[+] [-] thomastjeffery|3 years ago|reply
There are two kinds of choppiness that happen in recorded video:
1. The amount of time/motion between captured frames (framerate).
2. The amount of time/motion captured by each frame (shutter speed).
You are right that the instantaneous shutter used in rendering maximizes the choppiness of a given framerate. The solution you described is a feature in most rendering software called "motion blur". If you want perfect motion blur, you have to render enough intermediary frames to cover the motion in a scene across every pixel it moves across.
There are a few other less obvious places shutter speed choppiness comes into play:
1. Cameras. Some digital cameras have a physical shutter that opens and closes, and all of them have a speed at which light is captured by their sensors. When using a shutter to record video, there is a non-zero amount of time that is skipped in recording.
2. Lighting. Most lights have a framerate that matches the local standard alternating current rate: 60hz in the US, and 50hz in Europe. This is why NTSC is 60fps and PAL is 50fps. Different types of lighting fixtures have varying amounts of flicker, because they don't keep the same amount of brightness over each alternation of current. Florescent lighting is well known for (often) having a noticable flicker. You can see the effect of flickering lights by waving your hand in front of you. If it looks like a blurred motion, your lights aren't flickering. If it looks like you have many transparent fingers staying in place, then you have flickering lights.
Because resolution has been steadily increasing in popular media, but framerate has not, most filmmakers have been using faster shutter speeds to compensate. If you have motion across 10% of the screen over 1 second at 30fps, then during each frame, that motion will cross 1280px*10%/30fps = 4.266px of a 720p video, or 3840px*10%/30fps = 12.8px of a 4K video. A slower shutter will give you motion blur across those pixels, yeilding an effective resolution close to 1/4.266 of the 720p video (168.75p) or 1/12.8 of the 4K/2160p video (still 168.75p). A faster shutter would remove the blur, replacing it with an uncanny teleportation: the same that makes your fingers look copied and transparent when you wave them in front of a CRT monitor.
In order to get a smooth and clear/focused motion over 1 second across 10% of a 720p video, you must have a framerate of at least 128fps. 384fps for 4K. Now consider that most motion we capture in film is faster than that; some of it much faster.
[+] [-] iforgotpassword|3 years ago|reply
What you suggest trying is actually possible with quite some games/engines. Some other commenter mentioned the source engine, I did it once with trackmania a good decade ago. It does very much amplify the feeling of speed.
[+] [-] mgoetzke|3 years ago|reply
[+] [-] onion2k|3 years ago|reply
Only if you limit yourself to displaying the gif in an <img /> tag. You can parse the frames yourself and render them with a <canvas> at a faster rate using browser's requestAnimationFrame (which sync's to the refresh rate of your display.)
[+] [-] creativenolo|3 years ago|reply
The only advantage of gif I know of is that the creator of the asset has some control of the playback on the presentation platform. Other than this, it is a technically sub-optimal format. But no other formats support the creator control aspect.
[+] [-] manholio|3 years ago|reply
You can have a magical decoder that circumvents this, but that's no longer a gif.
[+] [-] IshKebab|3 years ago|reply
[+] [-] Dylan16807|3 years ago|reply
"1 second long" is pretty misleading, especially when telling people to look for different amounts of time to render. None of the gifs from 8-30fps are properly trying to be a second long.
If you have software that assigns the same delay to each frame, that's a flaw you need to compensate for or switch to different software, and the author did neither.
Let's use the 30fps gif as an example. It runs 11% too fast. Either it should be rendered with 33 frames, making it run 1% too fast, or it should use frame timings of 30ms 30ms 40ms 30ms 30ms 40ms making it exactly 1 second total.
[+] [-] Filligree|3 years ago|reply
[+] [-] Kaze404|3 years ago|reply
[+] [-] modeless|3 years ago|reply
It's almost perfect except for one almost deal breaker thing (which applies to both Giscus and utterance.es): to comment you have to click through a very scary permissions dialog that claims it can "Act on your behalf" in your Github account, without any qualification. I'm pretty sure the permissions dialog is misleading, but it sucks. I expect that it really cuts down on the number of people willing to leave a comment. And I doubt it will be fixed because Github probably doesn't really care to support this use of their API.
[+] [-] encryptluks2|3 years ago|reply
[+] [-] ISL|3 years ago|reply
[+] [-] cr__|3 years ago|reply
[+] [-] Cyberdog|3 years ago|reply
Did you know pretty much all modern browsers support <marquee>?
[+] [-] dawnerd|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
But another one I'm less happy with is removing choice from the user. I hate auto-playing videos so I have that turned off, but this does not apply to gifs. And I don't mind auto-playing videos either if they take the place of reaction gifs.
[+] [-] KyleSanderson|3 years ago|reply
[+] [-] ReactiveJelly|3 years ago|reply
They're _supposed_ to be 1-second-long loops, but the 60 FPS one is rounded to 50 FPS on export, so it takes longer to play and desyncs.
[+] [-] Dylan16807|3 years ago|reply
Gif can't do smooth 60fps even if it could do 1-delay frames. They chose centiseconds for some reason I've never understood, when milliseconds would have worked fine and avoided this issue. If your file shouldn't just be a video anyway, then the only fix is to use apng and demand sites support apng.
[+] [-] Cyberdog|3 years ago|reply
That this ancient format is still as prevalent as it is on the modern web is somewhat dumbfounding and probably unintended by its original creators.
[+] [-] ISL|3 years ago|reply
The 24/25 fps gifs certainly have the opportunity to look great (movies are mostly at 24 fps), but the hard-edge rendering of the black circle makes 'em look real choppy. I'd bet that rendering it at 50 fps, then averaging pairs of frames together and displaying it at 25 fps would yield something that seemed much smoother.
With some care, I bet one can go sub-25 fps on a gif and still have something that feels kinda "smooth".
[+] [-] mgdlbp|3 years ago|reply
The smoothness of video depends on the angular distance objects move in your field of view between frames. You can see this in the demos: the lower framerates are relatively smooth at the ends of the animation where the motion is slowest, and all framerates (even the highest) become considerably smoother when you decrease your browser zoom.
[+] [-] jerf|3 years ago|reply
[+] [-] quickthrower2|3 years ago|reply
After all all we see is an illusion anyway (has to be interpreted by low energy consuming brain)! They can probably distract us from choppyness.
[+] [-] codedokode|3 years ago|reply
[+] [-] babypuncher|3 years ago|reply
[+] [-] deergomoo|3 years ago|reply
Also a huge pain for old games. Lots of crummy conversions that straight up just run 17% slower on the PAL version.
[+] [-] moring|3 years ago|reply
I can only imagine errors to show up by "doing it wrong", that is, aliasing artifacts due to not lowpass filtering the signal beforehand.
That said, I'm not totally sure that a 50FPS signal is acutally capped to 25Hz since a 50FPS GIF is usually not interpreted as a signal sampled at 50Hz but as a piecewise-constant signal with 50 "steps" per second. So the first question is whether these "jumpiness" is an inherent, desired property of GIFs or an artifact of bad renderers. Can somebody clarify this?
[+] [-] esperent|3 years ago|reply
I can think of one, which is avoiding Twitter video compression but that's kind of a weird case.
[+] [-] mattnewton|3 years ago|reply
When I was working at apple we used a form of this technique for the mobile versions of product pages for that reason - https://www.sublimetext.com/~jps/animated_gifs_the_hard_way....
[+] [-] numpad0|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
Another one is that gifs are much easier to share, save, and reuse; with gifs, it's right-click and save, with videos... I don't even know where to begin.
[+] [-] Cyberdog|3 years ago|reply
https://caniuse.com/apng
[+] [-] tenryuu|3 years ago|reply
[+] [-] seba_dos1|3 years ago|reply
The world would be a much better place if Internet Explorer had used Gecko :)
[+] [-] quickthrower2|3 years ago|reply
[+] [-] forrestthewoods|3 years ago|reply
[+] [-] Dylan16807|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] rkagerer|3 years ago|reply
Maybe someone out there can clear this up for me and convince me why we need 120+ fps displays?
EDIT: Well, nevermind, a quick google search corrected my misconception about 30fps.
[+] [-] thrdbndndn|3 years ago|reply
Telling 24, 30, 60 apart is very trivial.
As for 120fps, you need to keep in mind that playing a real-time rendered computer game is a totally different beast than playing back a steady video. There are lots of other factors involved. Some headroom in FPS makes lots of difference due to various other things like jittering (judder?), input delays, response time etc. (also it's possible some people simply can tell 60/120 apart, even by just watching a video.)
[+] [-] planede|3 years ago|reply
It is possible to improve on this without increasing the framerate with strobing the backlight/black frame insertion.
[+] [-] momentoftop|3 years ago|reply