The truncated version is basically a lower resolution. So if you have a 5000x5000px image and you display it on your page as 100x100px, it only needs to download a small amount of data to show it at that lower resolution. Obviously being a lower resolution it won't match pixel-for-pixel identically to the original, but if you downloaded the whole file it would.
FLIF does support a "lossy" encoding method too. The compression FLIF uses (MANIAC Trees) predict what the next pixels will be. If you modify your pixels a small amount so they will be closer to what FLIF expects it will compress much better but still look very similar to the original image. The stored version with the modified pixels would be losslessly stored, in the sense that it perfectly reproduces your image with the modified pixels. But it's lossy in the sense that you had to change the pixels in the first place to better benefit from the way FLIF analyzes and compresses images. The major benefit to this type of lossy compression is that the image doesn't degrade with multiple saves, unlike JPG, where each save compounds the artifacts, causing the "Xerox effect". Here's a video of how FLIF benefits from it's style of lossy encoding:
The encoder option -Q<quality> (that's a capital Q, lowercase -q is used to decode a lower quality preview by only reading part of the file) can be used to do lossy encoding, where -Q100 is lossless and -Q0 is usually the most lossy you would want to go. But you can go lower if you want, using a negative number (e.g. -Q-50); there is not really any lower bound.
Comments
So it's lossy if you truncate the file? How does it compare to JPEG on a quality/size basis?
The truncated version is basically a lower resolution. So if you have a 5000x5000px image and you display it on your page as 100x100px, it only needs to download a small amount of data to show it at that lower resolution. Obviously being a lower resolution it won't match pixel-for-pixel identically to the original, but if you downloaded the whole file it would.
FLIF does support a "lossy" encoding method too. The compression FLIF uses (MANIAC Trees) predict what the next pixels will be. If you modify your pixels a small amount so they will be closer to what FLIF expects it will compress much better but still look very similar to the original image. The stored version with the modified pixels would be losslessly stored, in the sense that it perfectly reproduces your image with the modified pixels. But it's lossy in the sense that you had to change the pixels in the first place to better benefit from the way FLIF analyzes and compresses images. The major benefit to this type of lossy compression is that the image doesn't degrade with multiple saves, unlike JPG, where each save compounds the artifacts, causing the "Xerox effect". Here's a video of how FLIF benefits from it's style of lossy encoding:
https://www.youtube.com/watch?v=IheZzcYUV9w
Is it possible to tell the encoder to do that pixel twiddling or do you have to do it by hand still?
The encoder option -Q<quality> (that's a capital Q, lowercase -q is used to decode a lower quality preview by only reading part of the file) can be used to do lossy encoding, where -Q100 is lossless and -Q0 is usually the most lossy you would want to go. But you can go lower if you want, using a negative number (e.g. -Q-50); there is not really any lower bound.