Free Lossless Image Format (FLIF)


So let me get this straight: the entire animation is interlaced?  So if you only download half of it you would still get the whole animation, just at lower quality?
That is both a benefit and a curse.  With a regular animated gif, since you're getting frame by frame, as long as the server can send frames faster than the animation needs them then you get immediate playback at full quality.  With this interlace FLIF, you can't get the same "full quality" until the entire animation has finished downloading.  That would cause problems for animations that were multiple seconds, and several MB in size.  An animation of significant size would be very low quality at the start and then get better and better towards the end as more data is downloaded, else the user would have to wait.
Could you break the animation into a configurable size of blocks?  Like, the block has a header "this block contains X frames, it is Y seconds long, and Z bytes in size", and the viewer gets this header and starts downloading the frame, as soon as that frame is done it can start displaying it and request the next block.  If the connection is slow, or if it is a low res screen that doesn't need high quality, it can request just Z/n bytes for that block from the server, and then "resume" from +Z to get the next header, and the next size of the block.  If each block is a second in length then the client would have to wait at most 1 second (under minimal network conditions) to get the same instant playback and high quality as the gif, and even faster under better network conditions.
The benefit being that, if the network is slow, a gif image will stutter as it loads up the next frame slower than it can be played and there's nothing to be done about that, but a flif file could load partial blocks and stay ahead of the network to keep the animation smooth, and each loop through request more of each block until it is full quality, or the person just closes it because the low quality was good enough.
 
You could negotiate a speed, either automatically or by a setting. Being able to do multiple quality-setting from one source-image is only good as far as i can tell.

Improving on an initial thing is great, id rather get an idea right away and then have the quality ramp up than wait.

Also browsers are great at deciding sane defaults, and providing quality settings.
 
Last edited by a moderator:
I currently work on the concept of a game with user-generated levels. But instead of using boring binary files for these levels, the output is planned to be a .png file. (If someone knows the user-creations of the game Spore has an idea of this). I will definitely try to implement your format into this concept! Just dont expect this to come out early. :D
 
So let me get this straight: the entire animation is interlaced?  So if you only download half of it you would still get the whole animation, just at lower quality?
That is both a benefit and a curse.  With a regular animated gif, since you're getting frame by frame, as long as the server can send frames faster than the animation needs them then you get immediate playback at full quality.  With this interlace FLIF, you can't get the same "full quality" until the entire animation has finished downloading.  That would cause problems for animations that were multiple seconds, and several MB in size.  An animation of significant size would be very low quality at the start and then get better and better towards the end as more data is downloaded, else the user would have to wait.
Could you break the animation into a configurable size of blocks?  Like, the block has a header "this block contains X frames, it is Y seconds long, and Z bytes in size", and the viewer gets this header and starts downloading the frame, as soon as that frame is done it can start displaying it and request the next block.  If the connection is slow, or if it is a low res screen that doesn't need high quality, it can request just Z/n bytes for that block from the server, and then "resume" from +Z to get the next header, and the next size of the block.  If each block is a second in length then the client would have to wait at most 1 second (under minimal network conditions) to get the same instant playback and high quality as the gif, and even faster under better network conditions.
The benefit being that, if the network is slow, a gif image will stutter as it loads up the next frame slower than it can be played and there's nothing to be done about that, but a flif file could load partial blocks and stay ahead of the network to keep the animation smooth, and each loop through request more of each block until it is full quality, or the person just closes it because the low quality was good enough.
Click to expand...

I agree it can work both ways. I could make the frame interlacing optional -- essentially it's just about how to nest the loops. My reasoning is that for "long" animations, you shouldn't use an image format but you should use a real video codec. I'm not trying to reinvent the wheel here, there are video codecs that work well enough.

FLIF could be used for short animation loops, like all those meme gifs, or perhaps small educational animations like you would find on Wikipedia. For those kind of animations, I think interlacing makes sense, in particular in the context of responsive web design and limited bandwidth conditions.

Edit:
Also, the interlacing makes compression work (somewhat) better. For that reason, even flif -n does frame interlacing (even though the image data itself is not interlaced, so you don't get the progressive rendering; instead, you first get the first line of all frames, then the second line of all frames, and so on).
I experimented a bit with frame-by-frame coding but it produced somewhat larger files.
 
 
Last edited by a moderator:
Hi all :)

@ _wb_: I was about to tell you to team up with the author of Pandora Image Viewer, when I realized it was you !

Any chance to get preliminary* support for FLIF files into that great program ?

* Knowing the format is not finalized yet and compatibility will break at some point...

Cheers, Magic Sam
 
Fair point, it would work best for animations of a few seconds long at most.  Some people do record fairly large "movie" animations, spanning many seconds and upwards of dozens (or hundreds) of MB, dropping them into gfycat for viewing.  I was thinking you could replace that with something more standard but it's definitely a more advanced use case, probably not worth thinking about.  If someone wants to use your idea to create a "long animated gif" replacement then they can do that on their own.
 
TIGSource always have animated GIFs of gameplay at various lengths, but I still quite like idea better than HQ-frame-as-it-loads approach, but maybe that's me.

 
 
This sounds awesome to me for longer gifs - mozilla used to play up to the last full GIF frame loaded, until it got to the end and started looping, but a year or so ago they switched to make it loop as soon as it ran out of frames to display, and I'm not quite accustomed to watching the throbber to see when the GIF has loaded, and often end up watching it loop fully two or three times before I realise it's all loaded.  With an animated FLIF file I could just close the tab as soon as I've seen enough detail.
 
I've shown FLIF to a work-mate (also programmer) and he's also very interested in FLIF (he likes lossless image formats and hates lossy ones).
There's one thing he pointed out, that it would be great API wise, to have the possibility to provide your own file functions - so that you can replace fopen and the likes with your own functions to be able read from some container format (may it be zip or something else)
 
 
The one thing I didn't implement yet is this:
http://littlesvr.ca/apng/inter-frame.html

(it's on my todo list though ;) )
 
Click to expand...

I note on the third frame diffs shown there, it would look to be more efficient to store the delta as two boxes; one for the hour and minute hand and the painted over second hand, and the other for a narrow box covering the new second hand.  In terms of file size, presumably you need a four 16-bit numbers to describe a box, width, height, x and y.  So, if there were no bitmap compression, it should be more efficient to store anything more than 64 bits in size - that's two pixels at 8-bit RGBA.  So, based on that it should result in greater compression if you use many more relatively small but closely fitted boxes on each example.  I'd guess these small boxes of only changed pixels might result in slightly lower compression, but encoding all that blank unchanged stuff still probably outweighs that I'd have thought.

Am I missing something?  It would slow down the encode and decode assuming CPU cost is greater than IO cost per byte, but I'm not even sure that's true.
 
I'm not planning to use bounding boxes for the frame diffs, but something more fine-grained. I have an idea in my head, but no time to implement it right now -- first need to do some teaching...
 
OK, so I implemented something to improve frame diff encoding.
It's not based on a single bounding box per frame, but on a row-by-row index of the column number of the first and the last modified pixels.

So this is quite a bit more fine-grained, which has upsides and downsides. The main downside is that it can make files a bit larger because of the extra header data. I still need to figure out a good heuristic of when to apply this technique and when to avoid it. Alternatively, I could also reduce the overhead by making the data coarser (e.g. do two rows at a time, or apply quantization on the column numbers since those least significant bits are the most expensive ones and the least useful ones).

Anyway, at the moment there's no such heuristic or attempt to reduce overheads; the overhead is not that bad anyway.

And the gain can be pretty spectacular:
 

_wb_ said:
https://en.wikipedia.org/wiki/GIF#/media/File:Rotating_earth_(large).gif
1,429,302  GIF file
1,325,714  lossless BPG file
1,300,226  MNG file
908,882     APNG file (using zlib)
852,690     APNG file (using 7zip)
837,838     APNG file (using Zopfli)
821,984     FLIF file
748,510     FLIF file without interlacing (no progressive decoding possible)


 
Click to expand...
New numbers:
672,699       FLIF file
592,026       FLIF file without interlacing

This is a good example of a row-based approach being better than a simple bounding box: since it's a rotating circular shape here, the bounding box still contains most of the unchanging background, while FLIF's approach can completely filter out the background.
 
_wb_ said:
http://davidmz.github.io/apng-canvas/images/clock.png
23,680    APNG file
32,174    lossless BPG file
74,276    FLIF file
51,470    FLIF file without interlacing
326,904  sum of PNG files

https://media.giphy.com/media/nLfEVuqqk9puw/giphy.gif
727,686   GIF file
490,895   APNG file (using zlib)
459,967   APNG file (using 7lib)
456,932   APNG file (using Zopfli)
1,020,851   lossless BPG file
554,810    FLIF file
488,830    FLIF file without interlacing
578,499    sum of PNG files


So I guess there is some room for improvement, but it looks quite good already. Especially if you take into account that progressive decoding is possible with FLIF, and with none of the existing formats. I'll try to show an example of that later.
Click to expand...

clock:
25,038    FLIF
20,245    FLIF without interlacing

giphy:
513,703   FLIF
458,164  FLIF without interlacing

Not really much better than APNG here, but at least APNG is matched by FLIF now, instead of FLIF performing embarrassingly worse.

I commited the change to github. Feel free to experiment yourself, and report in this thread :)
Some useful things: you can use "apngdis" to turn an APNG into separate PNG frames, and "convert -coalesce foo.gif fooframe.png" to turn an animated GIF into PNG frames.
You can then use "flif input-frame*.png output.flif" to produce an animated FLIF file.
 
Last edited by a moderator:
magic_sam said:
Hi all :)

@ _wb_: I was about to tell you to team up with the author of Pandora Image Viewer, when I realized it was you !

Any chance to get preliminary* support for FLIF files into that great program ?

* Knowing the format is not finalized yet and compatibility will break at some point...

Cheers, Magic Sam
Click to expand...

Of course PIV will be one of the very first image viewers to support FLIF once the format is finalized :)
 
 
I just registered http://flif.info/

Now, how do I make sure that FLIF conquers the world and becomes a new standard image format, used all over the interwebs? This is quite an ambitious goal, right? So your suggestions are extremely welcome!

This is what I'm currently doing in terms of coding:

I'm tweaking the animation support a bit, trying to make sure that FLIF actually beats animated GIF and animated PNG, at least most of the time. I'm generalizing bounding boxes, blend modes and disposal modes into somewhat more powerful things: frame shapes (more general than bounding boxes), frames with what I like to call "deep alpha" (negative alpha channel values that refer to previous frames), and duplicate frame detection (useful for ping-pong animation loops).

These techniques work pretty well, but except for the duplicate frame thing, they can also make things worse. If pixels are very cheap, then it simply does not pay off to try to be clever. And that can happen with some animated GIFs. GIFs have a maximum palette of 256 colors, so pixels are never very expensive, and there are animated GIFs that use much smaller palettes. Obviously, if the animation uses only 10 different colors, then adding a "deep alpha" channel will do more harm than good.

FLIF is also not very good at encoding the artifacts of lossy formats -- in this case, when a GIF file is actually a color-reduced version of a photo, then it will contain lots of dithering patterns. These patterns compress relatively well in GIF or PNG, but not so much in FLIF.
Also, palette orders can matter a lot, and FLIF just uses a simple fixed order (dark to light), while GIF/PNG optimizers can produce tweaked palette orders. I don't feel like spending much effort in these two areas (dithering and palette order), since I consider palettes mostly a thing of the past, but obviously if people are going to re-encode old GIF files to FLIF (and the original true-color images are not available), then it does matter. (The same problem for re-encoding lossy JPEG files to FLIF, by the way. Re-encoding lossy to lossless will always make the lossless format look bad.)

So while the decoding is not going to be an issue, the encoder has some more degrees of freedom when encoding animations, and since I don't want to make it too slow, I'll have to come up with some decent heuristics.
In other words, if someone ever makes a brute-force FLIF encoder, there's a good chance that it will produce smaller FLIF files. This was true already for single-frame images (because you can use any set of MANIAC trees, and most likely the trees produced by the simple greedy algorithm in the encoder are not optimal), but it will be especially true for animated FLIF files.
 
You may want to run FLIF by the PNG/MNG working group. They have a lot of experience in standardization. Then there has to be a stable release and it will be very difficult to make any significant change to the format after that.
 
Seems like help a lot if you get the interest of a major tech player to help evangelize, implement, and push for standardization.

For example, I'm thinking to myself it could open a lot of doors if a company like Mozilla got behind this. So I search for Mozilla and image format evaluation and I find this study: http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ where they express they're unimpressed with WebP. And I wonder if something like FLIF would be something that would interest the authors. I look into the principal contributor to this study and while I can't find a Twitter profile I do find a personal blog and a github account (https://github.com/bdaehlie which has an e-mail contact). Seems like as good a person as any to reach out to for a random shot; if he's not interested he might know someone who is. If that goes nowhere you can try finding someone else in this manner.

But that's just what I'd do, and I've never gotten a file format standardized and utilized, so I could be way off here.
 
Last edited by a moderator:
It seems that Stuart Parmenter has left Mozilla. Without him Mozilla might not be the bad place for open and innovative things I remember from MNG times. I'd still suggest the PNG mailing list.
 
Last edited by a moderator:
show your work to google, facebook and pretty much every other big company. yeah i know it sounds silly, but even if they are not interested in FLIF they might see the potential behind your work and value you as an engineer/coder.

once you work for one of them your income could increase significantly. :)
 
You must log in or register to reply here.
Back
Top