3 ms·

Replying here because the various replies seem to say more or less the same... "With a 50 FPS GIF played back on a 60 FPS screen, some frames get shown twice"

by moring 4y ago

Replying here because the various replies seem to say more or less the same... "With a 50 FPS GIF played back on a 60 FPS screen, some frames get shown twice" Frames shown twice is an aliasing artifact that happens without a lowpass filter. It's exactly the same as spatial aliasing when you show a 50px image on a 60px area, "some pixels get drawn twice". Anti-aliasing gets rid of that. "Do you have a plan to transform a video into frequencies and back so you can do a lowpass filter?" Well, I (somewhat naively) assumed that this works the same as converting a still image into frequencies: Fourier transform. Only for an animated image the signal is 3d, not 2d. edit: Filters normally don't do a FT explicitly. You use FT for the theory, but filters operate directly on the signal. "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." I was very sloppy with this. by 50 FPS (max 25 Hz) I mean that 50 FPS is equivalent to a sample rate of 50 Hz, which can only capture signals of less than 25 Hz. FPS and Hz are only equivalent when they refer to sample rate because FPS can't really refer to anything else. > I'm thinking that the confusion is that you're thinking of this as audio or other wave-based signals Doesn't most lossy image compression make the same assumption, e.g. JPEG? > but computer monitors don't because this necessarily introduces a delay of at least one frame I agree with this one, at least AFAIK you can't really lowpass-filter a realtime signal without adding delay.

kaoD 4y ago
Your idea is more or less right, but the problem here is that Nyquist only applies to continuous functions, which a GIF is not. At frame boundaries the frequency is potentially infinite, like an ideal square wave. A GIF is already a sampled signal. Yes, you can LP-filter the GIF but that's no longer reproducing the original signal, which wasn't band-limited to begin with. You're right that, if the original signal that the GIF samples is band-limited to 1/2 the Nyquist rate (which is a big "if") it can be accurately reproduced without aliasing by passing it through a reconstruction filter.
- moring 4y ago
  One could argue that the same applies to old pixelated graphics, such as the original Super Mario sprite. It has to be pixelated, if you lowpass-filter it it looks ugly. So that one is non-continuous / not band-limited in the spatial direction. This brings me back to this question: > So the first question is whether these "jumpiness" is an inherent, desired property of GIFs or an artifact of bad renderers. Like for pixel-y displays, I assume that this was never well-defined for the GIF format, so what is basically a property of the first GIF renderers became a de-facto property of the format. I'd argue that GIFs that exploit this property and rely on the "jumpiness" to look good are not band-limited, require a "jumpy" renderer and will suffer from the 50Hz/60Hz problem. On the other hand, GIFs that don't exploit this property are meant to be continuous and are just sampled at a low frequency, and for those re-sampling in time will allow to fix the 50Hz/60Hz problem. Though another problem will turn up then: when the latter were sampled at a low frequency, they were likely not lowpass-filtered beforehand, so they already contain aliasing artifacts you cannot get rid of anymore.
LukeShu 4y ago
> > I'm thinking that the confusion is that you're thinking of this as audio or other wave-based signals > Doesn't most lossy image compression make the same assumption, e.g. JPEG? Yes, but the key difference is that there's no temporal component; the wave is across the screen, not across time. When one speaks of a low-pass filter in image processing, it's generally operating on the horizontal- and vertical-axes, not the time-axis. To put "not wave-based" in to other words: Unlike audio, video across time is neither continuous nor band-limited.

by moring 4y ago

kaoD 4y ago

Your idea is more or less right, but the problem here is that Nyquist only applies to continuous functions, which a GIF is not. At frame boundaries the frequency is potentially infinite, like an ideal square wave. A GIF is already a sampled signal. Yes, you can LP-filter the GIF but that's no longer reproducing the original signal, which wasn't band-limited to begin with. You're right that, if the original signal that the GIF samples is band-limited to 1/2 the Nyquist rate (which is a big "if") it can be accurately reproduced without aliasing by passing it through a reconstruction filter.

moring 4y ago
One could argue that the same applies to old pixelated graphics, such as the original Super Mario sprite. It has to be pixelated, if you lowpass-filter it it looks ugly. So that one is non-continuous / not band-limited in the spatial direction. This brings me back to this question: > So the first question is whether these "jumpiness" is an inherent, desired property of GIFs or an artifact of bad renderers. Like for pixel-y displays, I assume that this was never well-defined for the GIF format, so what is basically a property of the first GIF renderers became a de-facto property of the format. I'd argue that GIFs that exploit this property and rely on the "jumpiness" to look good are not band-limited, require a "jumpy" renderer and will suffer from the 50Hz/60Hz problem. On the other hand, GIFs that don't exploit this property are meant to be continuous and are just sampled at a low frequency, and for those re-sampling in time will allow to fix the 50Hz/60Hz problem. Though another problem will turn up then: when the latter were sampled at a low frequency, they were likely not lowpass-filtered beforehand, so they already contain aliasing artifacts you cannot get rid of anymore.

LukeShu 4y ago

> > I'm thinking that the confusion is that you're thinking of this as audio or other wave-based signals > Doesn't most lossy image compression make the same assumption, e.g. JPEG? Yes, but the key difference is that there's no temporal component; the wave is across the screen, not across time. When one speaks of a low-pass filter in image processing, it's generally operating on the horizontal- and vertical-axes, not the time-axis. To put "not wave-based" in to other words: Unlike audio, video across time is neither continuous nor band-limited.