Manual page inconsistency

[lehitoskin]

The first mention of "combine mode" says this:

FLIF  supports  animation,  so if multiple input files are given, an animated FLIF file will be produced where each input
image corresponds to one frame of the animation. All input images need to have the exact same dimensions (width,  height,
number  of  color channels and color depth).  All input frames are interpreted as complete frames ('replace mode'); there
is no notion of 'combine mode' frames.  In other words, transparent pixels are always transparent, they  do  not  combine
with the pixels from the previous frame.

The second mention of "combine mode" says this:

-L, --max-frame-lookback=NB_FRAMES
       In animations, typically the frames are somewhat similar. To improve compression, FLIF does  a  generalization  of
       'combine  mode':  it  will  look  back  at most NB_FRAMES frames to 'reuse' pixels.  This transformation is called
       Frame_Lookback.  Using -L0, the method can be disabled. It does not make sense to use a value larger than the num‐
       ber  of  frames  in the animation minus one.  The default setting is -L1. Different values can result in better or
       worse compression.

I assume this means that the first mention is simply out of date while the -L option is newer.

[bjorn3]

I think the first mention is about the input images, while the second mention is about the internal representation of the flif file.

[jonsneyers]

It is a bit confusing, and the explanation in the manual is probably not very clear.

Conceptually, FLIF only has the notion of full frames, that is, when reading input frames or writing output frames (either via the CLI or with the library), the frames are always full-size and they always completely replace the previous frame. This is in contrast to e.g. GIF or APNG where frames can be smaller than the full dimensions of the animation, and you have the notion of different combine modes (frame disposal methods) that tell you how to render the animation (see e.g. http://www.imagemagick.org/Usage/anim_basics/#dispose). In particular, if a frame contains a transparent pixel in FLIF, this always means that the pixel is transparent in that frame of the animation. In GIF, it is more complicated: a transparent pixel can be actually transparent, but depending on the previous frames and the dispose methods, it can also be a non-transparent pixel from a previous frame. You need to render the GIF animation until that point if you want to reconstruct all pixels.

Internally, to better compress an animation, FLIF does have some inter-frame features, in fact it has more advanced inter-frame features than GIF or APNG. Instead of 'overloading' the alpha channel with two semantically somewhat different tasks (absolute pixel transparency on the one hand, blend mask with the previous frame on the other hand), FLIF has the internal notion of a frame lookback channel where pixels of the current frame can directly refer to pixels of some previous frame. The option -L allows you to tweak the encoder by setting the range of this channel - further lookback can be useful, but it can also be harmful since it can make the lookback channel itself take up more space (also it adds some encode complexity).

So basically when you are dealing with FLIF animations, you should not have to think about combine modes, it's all just full-size, independent frames (similar to what you get when you use ImageMagick's -coalesce option, see http://www.imagemagick.org/Usage/anim_basics/#coalesce). When encoding an animation, you don't have to worry about 'optimizing' the animation on your end by doing things like reducing the frames to the smallest possible bounding box and replacing unchanged pixels by transparency, or anything like that (things you do need to do when encoding a GIF). When rendering an animation, you don't have to worry about implementing any dispose methods, you just always get the coalesced, ready-to-render frames. That's what the first paragraph cited from the manual is trying to say.

But when you're trying to tweak the actual internal encoding of a FLIF animation to get the best possible compression, well, there is obviously always room for improvement in the encoder, also in the way FLIF's inter-frame features like FrameShape and FrameLookback are used. The command-line options -L and -S offer a bit of control over that. That's what the second paragraph cited from the manual is talking about.

[lehitoskin]

Ah, I see what you mean.