Is there a trick to creating an animated gif of tv static that will allow it to be relatively small?

Question

Apologies in advance, but this isn't really a photoshop question. Rather, I'm trying to come up with something that is convincing but exploits the compression and features of the gif format as best as possible to produce the smallest possible file for the animation.

Some constraints:

• It needs to be at least 20 or 30 frames. I've tried with fewer (and since they're largely uncompressable 15 frames is half the size of 30, generally speaking)
• Size needs to be no less than about 256x192
• It doesn't need to be color though, nor even full grayscale. I've seen convincing stills with as few as about 16 grays
• It can have a pattern, but not one that is instantly obvious to the human eye. If someone takes a single frame and after a minute or two can spot the pattern (which makes it compressable?) that's ok
• Frames 2 through n can use quite a bit of alpha, but when I started using big horizontal stripes of alpha, it was instantly noticeable to my eyes. So you don't get to rack up a bunch of RLE with the easy cheat.
• All of the above and still needs to look good at 30-33ms frame speed. No variable speed or relying on anything significantly faster than that.

Also acceptable: an apng that complies with the above constraints. Possibly even mpeg, if you can come up with that (I'm ignorant of how the DCT does its magic).

Ideally I could get something down in the 250kbyte range, but I'd settle for anything significantly smaller than the 9 meg monstrosity I cooked up last week.

Oh, and one last thing: obviously I don't expect anyone to supply the graphic for me. I'm just looking for some trick(s) that will let me get there myself eventually.

Answer 1

Well old but still unanswered answer (not checked anyway)

1. so create the NoSignal image data

   If it is not obvious how read this:

   • NoSignal in asm and C++

2. encode into gif

   Had played with it a bit so I used resolution 320x240, the lowest bit resolution usable is 3 bit per pixel. Lower does not look good. Single global palette only (obvious) here 300KB example

   

[Notes]

if this is just for some app then generate the image on the run it is really just few lines of code see that linked answer in bullet #1

Answer 2

This is a very interesting question.

Static (random noise) by its nature is actually highly incompressible. Information theory says that true noise is basically incompressible, and the more patterns something contains the more compressible it becomes (to the point of a solid line of 1's or 0's being perfectly compressible.

The ideal would be to create a true noise generator (just random numbers), but that doesn't help within the constraints of your problem.

The best thing I can think of is storing a number of small tiles of static and displaying them in staggered fashion to prevent the eye catching on to any patterns. Aside from that, you won't have much luck compressing this beyond 256 x 192 x 20 / 2 or about 500 kilobytes ( assuming 20 frames with resolution of 256 x 192, using 4 bit color depth ).

Simply encoding your animated gif in 16 color mode should get you to that point.

Answer 3

Yes, you can achieve that with a lossy GIF compression, or rather a specifically rigged compressor that outputs noisy LZW stream.

A best-case scenario for LZW compression is to output X pixels, then X+1 pixels, then X+2 pixels, etc. It's easy to make that noisy.

Try screwing up the gfc_lookup function to (almost) always return longest dictionary item and compress series of noisy frames with it:

https://github.com/pornel/giflossy/blob/master/src/gifwrite.c#L270

Answer 4

Not easily normally. Good randomness (high entropy) by definition does not compress well. Having it greyscale may help, but not much.

If you want to do this on a web page and you have (some) control, you can always write a very small bit of JS to help... if you can do this, then you can do the following:

1. Create a gif about 1.5x the size you need with high-entropy static.
2. Set the clipping to the size you want.
3. Then you randomly move it around by changing the starting offset.

As long as your offsets are a decent distance away from one another (and don't repeat patterns) it is usually difficult to discern it as movement, and it looks truly like static.

I did this trick about 20 years ago on an Amiga to emulate static on a limited-memory demo, and it worked remarkably well... it also does not require fast low-level code as all was done by changing offsets and the co-processor bitblit-ed the rest.