Consider moving a 1 lumen Dirac impulse across the screen. It looks like this when it moves perfectly with 1 pixel per frame:

  frame=0: 1 0 0 0
  frame=1: 0 1 0 0
  frame=2: 0 0 1 0
  frame=3: 0 0 0 1

Values are in lumens. Now let's do it half as fast:

  frame=0: 1   0   0   0
  frame=1: 0.5 0.5 0   0
  frame=2: 0   1   0   0
  frame=3: 0   0.5 0.5 0
  frame=4: 0   0   1   0
  frame=5: 0   0   0.5 0.5
  frame=6: 0   0   0   1

When the impulse falls between two pixels, the amount of light should be distributed over those two pixels, so that the total amount emitted stays the same. However, we use a nonlinear encoding to map these physical values to numbers, which is called gamma compression. So in case of an 8-bit encoding, if 1 lumen is mapped to 255, then 0.5 lumen would correspond to a value of say 186, instead of 128. The display hardware uses the reverse of this mapping to emit the intended amount of light from each display pixel, so everything works fine as long as gamma is accounted for in the whole pipeline.

However, if you have a gamma-compressed image, you must be careful when doing any transformations on this image in the digital domain, because the pixel values live in a non-linear space, and this must be taken into account when transforming them!

E.g. let's say we have our 0.5 pixel/frame animation from above, encoded with gamma=0.45:

  frame=0: 255   0   0   0
  frame=1: 186 186   0   0
  frame=2:   0 255   0   0
  frame=3:   0 186 186   0
  frame=4:   0   0 255   0
  frame=5:   0   0 186 186
  frame=6:   0   0   0 255

And in post-processing you resize this video to 0.5x of the original size, with software that naïvely blends the pixel values when shrinking the image:

  frame=0: 128   0
  frame=1: 186   0
  frame=2: 128   0
  frame=3:  93  93
  frame=4:   0 128
  frame=5:   0 186
  frame=6:   0 128

Oops! The intensity is no longer constant, which is going to be visible as twinkling when viewing the video.