Creating unquantized GIFs via zero delay frame compositing

[TLUL]

Since the GIF spec permits a different colour palette for each frame, it is possible to construct a colour-exact frame by using zero-delay frames for any colours beyond the first 256. Is there any way to instruct ImageMagick to do this automatically? If so, can it be done for multiple frames in an animation, and would ImageMagick still be smart enough to not repaint a pixel that matched the previous displayed frame when doing this?

[glennrp]

Since the GIF spec permits a different colour palette for each frame, it is possible to construct a colour-exact frame by using zero-delay frames for any colours beyond the first 256. Is there any way to instruct ImageMagick to do this automatically? If so, can it be done for multiple frames in an animation, and would ImageMagick still be smart enough to not repaint a pixel that matched the previous displayed frame when doing this?

I believe that technique was used years ago to create more-than-256-color GIFs before PNG became available. Note that GIF doesn't actually have zero-delay; zero is interpreted as 1/100 second. If you "flatten" or "coalesce" such a GIF with ImageMagick you should get a more-than-256-color image.

[TLUL]

I believe that technique was used years ago to create more-than-256-color GIFs before PNG became available.

That's one use of it; but most important is the fact that it can be used to create full-colour animations, for which there is still no widely-supported PNG alternative (aPNG is one option but it's far from universal).

Note that GIF doesn't actually have zero-delay; zero is interpreted as 1/100 second.

That doesn't seem to agree with the ImageMagick documentation about GIF animations or with the GIF spec. From what I can tell, there are indeed frames that should be interpreted as having zero delay (and are interpreted as such in a few applications I'm using). There are just some applications (such as old versions of Internet Explorer) that handle this incorrectly.

If you "flatten" or "coalesce" such a GIF with ImageMagick you should get a more-than-256-color image.

Yes, but that's not what I'm asking for. I'm looking to go the other way: take a flattened full-colour image and expand it into a set of 256-colour frames.

[glennrp]

Note that GIF doesn't actually have zero-delay; zero is interpreted as 1/100 second.

That doesn't seem to agree with the ImageMagick documentation about GIF animations or with the GIF spec. From what I can tell, there are indeed frames that should be interpreted as having zero delay (and are interpreted as such in a few applications I'm using). There are just some applications (such as old versions of Internet Explorer) that handle this incorrectly.
.

The GIF spec cleverly avoids the issue by not mentioning what zero means:

• vii) Delay Time - If not 0, this field specifies the number of
  hundredths (1/100) of a second to wait before continuing with the
  processing of the Data Stream.

IE and Netscape interpreted it as 1/100 second. I believe that interpretation is neither correct nor incorrect.
The delay time in milliseconds in Mozilla products such as Firefox is

Code: Select all

 mGIFStruct.delay_time = GETINT16(q + 1) * 10;

which is not terribly correct (0 is 10ms, 1 is 20ms, 2 is 30ms, and so on); not only that, the spec says it's a 16-bit unsigned int.

[anthony]

That doesn't seem to agree with the ImageMagick documentation about GIF animations or with the GIF spec. From what I can tell, there are indeed frames that should be interpreted as having zero delay (and are interpreted as such in a few applications I'm using). There are just some applications (such as old versions of Internet Explorer) that handle this incorrectly.

Every browser and animation program I have seen generates a small delay. It is a pain!
I know why they do it, but I hate that they do it when there should not be any need for it!
These programs could simply pick up the 'special case' of animations that did not provide a delay. (Preferably report them as a ERROR!!!)

IE and Netscape interpreted it as 1/100 second.

Actually IE has a minimum delay of 6/100 of a second for any animation that is less than that!

See the notes about this in IM Examples, GIF Animation Basics, Zero Delay Intermediate Frames
http://www.imagemagick.org/Usage/anim_basics/#zero


You can see this slight delay in the example in the same section
Cleared Frame Animations
http://www.imagemagick.org/Usage/anim_basics/#cleared

The zero delay farme is visible as a pause showing just the background in the animation sequence.

compare it with this one in which the zero frame was removed

[anthony]

Even with a delay, a large color GIF image is still a good idea.

The first frame can be a simple rough (no dither quantization) of the image, with later frames adding more colors. As such the image will appear immediately and it will quickly become a higher and higher quality.
image with each frame adding 256 more colors to the currently shown image.

The key is that the GIF image does not loop.


So the question then is how best to separate other the colors. Starting with what should the first 'rough' image be (perhaps the most widely separated set of exact colors with high color counts). The next image probably should be the next set of exact colors with high color counts that are most different from the first set, and so on.

So how do you find a ordered list of exact high count colors that are well seperated?

NOTE: in some ways this is similar to the problem looked at in the discussion on
Overlapped Images for selecting well seperated high entropy points in images, but this time working in 3 dimensional colorspace rather than in a 2-dimentional entropy map.

IM can certainly add such an algorithm (if it can be worked out) as a special '-layers' method, though who should program it is another matter.

First step however would be some type of scripted 'proof of concept'.