Animation tech details

[ghost]

I working on gapless (or less gaps) conversion of WebP to APNG. Blend is blend, dispose is dispose, RGB is RGB (in future), RGBA is RGBA, ICC is ICC (future)...

I want to know, FLIF supports blending and dispose, and what modes supported?

[jonsneyers]

Externally, FLIF animations have fully refreshed full frames only. Internally, there are some transformations to optimize that:

• DuplicateFrame eliminates frames that are an exact copy of an earlier frame
• FrameShape allows you to modify only part of the pixels (the other pixels are copied from the previous frame). The "shape" doesn't have to be a rectangle: it is defined by begin-column, end-column coordinates for each row, so you can do e.g. a circle shape and many other convex shapes.
• FrameLookback adds an extra virtual channel which contains references to previous frames for each pixel. So you can say e.g. this pixel is new, this pixel is the same as 4 frames ago, this pixel is the same as the previous frame, this pixel is new again, etc.

With these primitives you can probably do a more or less gapless conversion from WebP or APNG to FLIF (using only rectangular FrameShapes for example). The other way around will be harder since these transformations have no complete counterpart in those other formats.

[Sur3]

I wonder how the animation itself is compressed, is each frame decoded individually? Because in most animations frames are similar to each other and therefore compression should be better if the difference between a frame and it's previous frame are encoded instead of encoding every frame individually, it's similar to what you suggest with FrameLoopback but there you only mention replacing pixels whole, not adding(/modifying) them..