10 ms·

Buttery Smooth “10fps” (2020)

254 points by LordNibbler 4y ago

Kaze404 4y ago
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!
- modeless 4y ago
  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.
  - PcChip 4y ago
    Yeah I certainly wouldn't click agree on that
  - Kaze404 4y ago
    That does sound like a scary prompt, but it might also work as a filter of sorts. I certainly don't care enough about comments that scaring someone away will be a concern, especially as they can always just e-mail me, so I get to pay extra attention when someone does go through it.
  - codetrotter 4y ago
    > 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. Since it’s powered by GitHub discussions, and the discussion itself needs to be public, anyone wanting to comment but not wanting to authorise Giscus to act on their behalf could go to the discussion on GitHub and leave the comment there directly I assume
    - modeless 4y ago
      True, but not if they're the first comment because Giscus doesn't create the discussion until someone comments.
      - whatsdoom 4y ago
        As a hack you could make a comment yourself on all of your posts. You may even be able to remove the comment after the discussion was created...
  - bmacho 4y ago
    > 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. What should the "act on your behalf" mean? Is it safe to provide my readers Giscus?
ReactiveJelly 4y ago
Took me a while to figure out the 50 and 60 FPS ones. 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.
KyleSanderson 4y ago
https://news.ycombinator.com/item?id=30405815 https://news.ycombinator.com/item?id=30405815 very similar content if you're interested in another article on this.
encryptluks2 4y ago
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.
- cr__ 4y ago
  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.
- dawnerd 4y ago
  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)
- ISL 4y ago
  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.
- Cyberdog 4y ago
  Well, it's not really a decision of the modern web… it's a decision of the primordial one which has stuck around. Did you know pretty much all modern browsers support <marquee>?
- Cthulhu_ 4y ago
  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.
esperent 4y ago
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.
- tenryuu 4y ago
  webm has an alpha channel. Just waiting on Apple
  - djxfade 4y ago
    H265 also already has support for alpha channel, so no need to wait.
    - fomine3 4y ago
      Then you should wait for Google and Mozilla. It's much harder (impossible) due to patent situation.
      - tenryuu 4y ago
        Checked caniuse which led me to resources on bugtracker. Both have closed the tickets with wontfix. Firefox is focusing on AV1, and not budging on this until the patent situation is no longer a barrier. Chrome's reasoning feels like it relies on old data (these tickets are 5-6 years old), additionally citing firefox will not support it, with further reference to similar performance in other codecs (VP9). Because of the patent, there's zero interest in it's adoption, no matter the cost of implementation
- mattnewton 4y ago
  Videos used to not play inline on mobile safari, along with a few other restrictions. 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.html https://www.sublimetext.com/~jps/animated_gifs_the_hard_way....
Dylan16807 4y ago
> 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.
- Filligree 4y ago
  The latter would cause a great deal of jitter. Not to mention, 40ms is 1.5 frame on a 60Hz display, so it isn't going to be 40ms anyway.
  - kllrnohj 4y ago
    Since ~every web browser is vsync'd, most of these have jitter. The 50fps gif isn't 50fps, for example, as the browser never runs at 50fps itself.
  - Dylan16807 4y ago
    Your math is off. 30ms is 1.8 frames and 40ms is 2.4 frames. Constant 30ms will jitter all by itself, and if anything 30 30 40 should reduce jitter or even eliminate it.
deleted 4y ago
[deleted]
babypuncher 4y ago
50 FPS is an unfortunate limit in a world mostly dominated by 60 hz displays.
- moring 4y ago
  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?
  - toast0 4y ago
    You're going to get judder; I don't understand what you mean by 50 FPS (max 25Hz), but if you've got 50 frames per second of data and 60 frames of display, about ten frames per second are going to be shown twice and the other fourty only once, that's not going to look nice. If it's 25 frames per second of data, fifteen frames would be be shown twice, and ten shown three times; this is reminiscent of telecine judder where 24 frames per second film material is shown on 60 fps screens using a 2:3 pulldown: half of the frames are shown twice (or as two fields if interlaced) and the other half are shown three times (or as three fields), but it's not as consistently one then the other with 25 fps source material.
  - dehrmann 4y ago
    You either get duplicate frames and the video stutters a bit or you interpolate and get either blurs or distortions. You're right that capturing 50 FPS video at 60 FPS is sorta OK in terms of data loss; you'll capture all the frame, and you can get a pretty good idea of which frames are duplicates, but that's different from high-quality playback.
  - LukeShu 4y ago
    Like the sibling comment, I wasn't sure what you mean when you write "50 FPS (max 25Hz)". "Hz" is literally "per second"; "50 frames per second" is "50 frame-Hz". Because we're talking about frame-oriented video, the "frame" is implied; FPS and Hz are equivalent units. Based on this "divide by 2" confusion and your mention of lowpass filtering, I'm thinking that the confusion is that you're thinking of this as audio or other wave-based signals. With audio the "volume" (amplitude) is a relatively minor detail and the key thing-of-interest is the frequency at which that amplitude is oscillating; not so with video. The signal doesn't follow a wave-pattern and we don't (normally) care about the frequency one bit. To apply video-numbers to audio; to represent a 60Hz tone, you'd need to represent that the amplitude goes down and back up 60 times per second; a 60Hz tone for 1 second is 120 "discrete" events, 60 "down" and 60 "up". If the samples are only at 60Hz then it would seem that the amplitude is staying constant, you wouldn't be able to observe that it's oscillating so quickly. And that oscillation is how we perceive audio. But it's not how we perceive video, light amplitudes don't normally oscillate like that, they stay steady and when they do change we notice that as a discrete event, not as part of a frequency. In fact, many displays (especially CRTs) do flicker, and are specifically counting on us not being able to notice this oscillation. If the video signal emits a new frame at 50Hz but the screen updates at 60Hz, naively that means that 80% of the video's frames will be on-screen for .0166s, and 20% of them will be on-screen for .033s. While humans might not notice a .0166s difference on its own, we're pretty good at noticing changes in rate and will notice the jitter. You could argue that similar to a lowpass filter for audio, that the display should interpolate between its samples to hide this jitter. It could; some TVs do this, but computer monitors don't because this necessarily introduces a delay of at least one frame (but realistically the software to do this will introduce more delay than that), and for interactive use we sure do care about lag/latency; even more than we care about jitter. TVs that do this will often have a "video game mode" that disables this and other features that introduce latency.
Dylan16807 4y ago
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.
- Cyberdog 4y ago
  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.
  - Sakos 4y ago
    But why would anybody go out of their way to use centiseconds? That seems like such an odd choice.
    - rkagerer 4y ago
      Did they want to cram a coarse measurement into a smaller amount of bits?
      - Dylan16807 4y ago
        No, it's a standard 16 bit field. Milliseconds would have allowed more than a minute for a frame. Centiseconds only benefit you when you want a frame time between 1 minute and 10 minutes, so basically never.
        Macha 4y ago
        Is there a duration field using the same units?
ISL 4y ago
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".
- mgdlbp 4y ago
  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.
- quickthrower2 4y ago
  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.
  - tpxl 4y ago
    No, at least not as a hard rule. This is most noticeable when a camera pans horizontally along a very close vertical object very quickly (~1s for a full screen pan). This will give you more than a meter per frame on a movie screen and is very jarring (to me).
    - jerf 4y ago
      I personally am a bit boggled by how hard people will go to bat for "movies must be 24 fps as God intended" because I also have many places like big pans where it's just jarring to me in 2022 to see things jerking across the screen like that, and I'm as used to 24 fps movies as anyone else. There's other things like actions scenes to where I can see the frame rate, motion blur notwithstanding, and I find that quite jarring.
forrestthewoods 4y ago
What does it mean for a browser to render a gif at 50Hz when almost all monitors have a 60Hz refresh rate?
- Dylan16807 4y ago
  It rounds to the nearest frame and has smoothness issues.
onion2k 4y ago
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.)
- creativenolo 4y ago
  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.
  - onion2k 4y ago
    If you own the presentation platform of the gif, would it not be better to use different format? You might want to display media supplied by users.
    - blululu 4y ago
      Just convert .gif to .webm or .mp4 and render the media as a video element. You will save yourself a lot of trouble by replacing gifs with videos.
      - saba2008 4y ago
        GIF compression is lossless, codecs used in WebM and MP4 are not.
        gmueckl 4y ago
        GIF is lossess iff the input has at most 256 different colors. That is the maximum color palette size and not sufficient for most cases.
seba_dos1 4y ago
> Internet Explorer 10(Gecko) The world would be a much better place if Internet Explorer had used Gecko :)
- quickthrower2 4y ago
  What! those UA strings are lying to me?
rkagerer 4y ago
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.
- momentoftop 4y ago
  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?
  - planede 4y ago
    Some games allow adding motion blur, but it still doesn't get close to the experience of a higher frame rate. I think the problem is actually the opposite. In real life if you follow a moving object with your eyes then you expect its image to stay at a consistent place on your retina with no or minimal motion blur. If you follow a moving object on a typical LCD screen with your eyes, then for 30fps the object stays still for 1/30 s on the screen, while your eyeballs are still moving, causing motion blur on your retina.
- thrdbndndn 4y ago
  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.)
codedokode 4y ago
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?
- jessermeyer 4y ago
  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.
- mgoetzke 4y ago
  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
- Ruphin 4y ago
  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.

254 points by LordNibbler 4y ago

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!

modeless 4y ago
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.
- PcChip 4y ago
  Yeah I certainly wouldn't click agree on that
- Kaze404 4y ago
  That does sound like a scary prompt, but it might also work as a filter of sorts. I certainly don't care enough about comments that scaring someone away will be a concern, especially as they can always just e-mail me, so I get to pay extra attention when someone does go through it.
- codetrotter 4y ago
  > 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. Since it’s powered by GitHub discussions, and the discussion itself needs to be public, anyone wanting to comment but not wanting to authorise Giscus to act on their behalf could go to the discussion on GitHub and leave the comment there directly I assume
  - modeless 4y ago
    True, but not if they're the first comment because Giscus doesn't create the discussion until someone comments.
    - whatsdoom 4y ago
      As a hack you could make a comment yourself on all of your posts. You may even be able to remove the comment after the discussion was created...
- bmacho 4y ago
  > 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. What should the "act on your behalf" mean? Is it safe to provide my readers Giscus?

ReactiveJelly 4y ago

Took me a while to figure out the 50 and 60 FPS ones. 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.

KyleSanderson 4y ago

https://news.ycombinator.com/item?id=30405815 https://news.ycombinator.com/item?id=30405815 very similar content if you're interested in another article on this.

encryptluks2 4y ago

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.

cr__ 4y ago
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.
dawnerd 4y ago
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)
ISL 4y ago
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.
Cyberdog 4y ago
Well, it's not really a decision of the modern web… it's a decision of the primordial one which has stuck around. Did you know pretty much all modern browsers support <marquee>?
Cthulhu_ 4y ago
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.

esperent 4y ago

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.

tenryuu 4y ago
webm has an alpha channel. Just waiting on Apple
- djxfade 4y ago
  H265 also already has support for alpha channel, so no need to wait.
  - fomine3 4y ago
    Then you should wait for Google and Mozilla. It's much harder (impossible) due to patent situation.
    - tenryuu 4y ago
      Checked caniuse which led me to resources on bugtracker. Both have closed the tickets with wontfix. Firefox is focusing on AV1, and not budging on this until the patent situation is no longer a barrier. Chrome's reasoning feels like it relies on old data (these tickets are 5-6 years old), additionally citing firefox will not support it, with further reference to similar performance in other codecs (VP9). Because of the patent, there's zero interest in it's adoption, no matter the cost of implementation
mattnewton 4y ago
Videos used to not play inline on mobile safari, along with a few other restrictions. 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.html https://www.sublimetext.com/~jps/animated_gifs_the_hard_way....

Dylan16807 4y ago

> 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.

Filligree 4y ago
The latter would cause a great deal of jitter. Not to mention, 40ms is 1.5 frame on a 60Hz display, so it isn't going to be 40ms anyway.
- kllrnohj 4y ago
  Since ~every web browser is vsync'd, most of these have jitter. The 50fps gif isn't 50fps, for example, as the browser never runs at 50fps itself.
- Dylan16807 4y ago
  Your math is off. 30ms is 1.8 frames and 40ms is 2.4 frames. Constant 30ms will jitter all by itself, and if anything 30 30 40 should reduce jitter or even eliminate it.

deleted 4y ago

[deleted]

babypuncher 4y ago

50 FPS is an unfortunate limit in a world mostly dominated by 60 hz displays.

moring 4y ago
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?
- toast0 4y ago
  You're going to get judder; I don't understand what you mean by 50 FPS (max 25Hz), but if you've got 50 frames per second of data and 60 frames of display, about ten frames per second are going to be shown twice and the other fourty only once, that's not going to look nice. If it's 25 frames per second of data, fifteen frames would be be shown twice, and ten shown three times; this is reminiscent of telecine judder where 24 frames per second film material is shown on 60 fps screens using a 2:3 pulldown: half of the frames are shown twice (or as two fields if interlaced) and the other half are shown three times (or as three fields), but it's not as consistently one then the other with 25 fps source material.
- dehrmann 4y ago
  You either get duplicate frames and the video stutters a bit or you interpolate and get either blurs or distortions. You're right that capturing 50 FPS video at 60 FPS is sorta OK in terms of data loss; you'll capture all the frame, and you can get a pretty good idea of which frames are duplicates, but that's different from high-quality playback.
- LukeShu 4y ago
  Like the sibling comment, I wasn't sure what you mean when you write "50 FPS (max 25Hz)". "Hz" is literally "per second"; "50 frames per second" is "50 frame-Hz". Because we're talking about frame-oriented video, the "frame" is implied; FPS and Hz are equivalent units. Based on this "divide by 2" confusion and your mention of lowpass filtering, I'm thinking that the confusion is that you're thinking of this as audio or other wave-based signals. With audio the "volume" (amplitude) is a relatively minor detail and the key thing-of-interest is the frequency at which that amplitude is oscillating; not so with video. The signal doesn't follow a wave-pattern and we don't (normally) care about the frequency one bit. To apply video-numbers to audio; to represent a 60Hz tone, you'd need to represent that the amplitude goes down and back up 60 times per second; a 60Hz tone for 1 second is 120 "discrete" events, 60 "down" and 60 "up". If the samples are only at 60Hz then it would seem that the amplitude is staying constant, you wouldn't be able to observe that it's oscillating so quickly. And that oscillation is how we perceive audio. But it's not how we perceive video, light amplitudes don't normally oscillate like that, they stay steady and when they do change we notice that as a discrete event, not as part of a frequency. In fact, many displays (especially CRTs) do flicker, and are specifically counting on us not being able to notice this oscillation. If the video signal emits a new frame at 50Hz but the screen updates at 60Hz, naively that means that 80% of the video's frames will be on-screen for .0166s, and 20% of them will be on-screen for .033s. While humans might not notice a .0166s difference on its own, we're pretty good at noticing changes in rate and will notice the jitter. You could argue that similar to a lowpass filter for audio, that the display should interpolate between its samples to hide this jitter. It could; some TVs do this, but computer monitors don't because this necessarily introduces a delay of at least one frame (but realistically the software to do this will introduce more delay than that), and for interactive use we sure do care about lag/latency; even more than we care about jitter. TVs that do this will often have a "video game mode" that disables this and other features that introduce latency.

Dylan16807 4y ago

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.

Cyberdog 4y ago
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.
- Sakos 4y ago
  But why would anybody go out of their way to use centiseconds? That seems like such an odd choice.
  - rkagerer 4y ago
    Did they want to cram a coarse measurement into a smaller amount of bits?
    - Dylan16807 4y ago
      No, it's a standard 16 bit field. Milliseconds would have allowed more than a minute for a frame. Centiseconds only benefit you when you want a frame time between 1 minute and 10 minutes, so basically never.
      - Macha 4y ago
        Is there a duration field using the same units?

ISL 4y ago

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".

mgdlbp 4y ago
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.
quickthrower2 4y ago
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.
- tpxl 4y ago
  No, at least not as a hard rule. This is most noticeable when a camera pans horizontally along a very close vertical object very quickly (~1s for a full screen pan). This will give you more than a meter per frame on a movie screen and is very jarring (to me).
  - jerf 4y ago
    I personally am a bit boggled by how hard people will go to bat for "movies must be 24 fps as God intended" because I also have many places like big pans where it's just jarring to me in 2022 to see things jerking across the screen like that, and I'm as used to 24 fps movies as anyone else. There's other things like actions scenes to where I can see the frame rate, motion blur notwithstanding, and I find that quite jarring.

forrestthewoods 4y ago

What does it mean for a browser to render a gif at 50Hz when almost all monitors have a 60Hz refresh rate?

Dylan16807 4y ago
It rounds to the nearest frame and has smoothness issues.

onion2k 4y ago

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.)

creativenolo 4y ago
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.
- onion2k 4y ago
  If you own the presentation platform of the gif, would it not be better to use different format? You might want to display media supplied by users.
  - blululu 4y ago
    Just convert .gif to .webm or .mp4 and render the media as a video element. You will save yourself a lot of trouble by replacing gifs with videos.
    - saba2008 4y ago
      GIF compression is lossless, codecs used in WebM and MP4 are not.
      - gmueckl 4y ago
        GIF is lossess iff the input has at most 256 different colors. That is the maximum color palette size and not sufficient for most cases.

seba_dos1 4y ago

> Internet Explorer 10(Gecko) The world would be a much better place if Internet Explorer had used Gecko :)

quickthrower2 4y ago
What! those UA strings are lying to me?

rkagerer 4y ago

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.

momentoftop 4y ago
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?
- planede 4y ago
  Some games allow adding motion blur, but it still doesn't get close to the experience of a higher frame rate. I think the problem is actually the opposite. In real life if you follow a moving object with your eyes then you expect its image to stay at a consistent place on your retina with no or minimal motion blur. If you follow a moving object on a typical LCD screen with your eyes, then for 30fps the object stays still for 1/30 s on the screen, while your eyeballs are still moving, causing motion blur on your retina.
thrdbndndn 4y ago
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.)

codedokode 4y ago

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?

jessermeyer 4y ago
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.
mgoetzke 4y ago
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
Ruphin 4y ago
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.