Free Lossless Image Format (FLIF)


levi said:
You mean a maniac tree? AIUI that's built based on what's in the image, so it depends on the current frame contents. It'll be different for each frame, but the trees are stored progressively across the board - first you load the first pixel of all frames, then you start filling them in according to the new adam encoding (my recollection - haven't found anything in the pdf about animated storage yet).
Click to expand...

oh no, no, you are quite incorrect. _wb_ thought about doing something fancier at some point...
https://pyra-handheld.com/boards/threads/free-lossless-image-format-flif.76305/page-8#post-1352448

and then he did it: (one shared MANIAC tree).
https://pyra-handheld.com/boards/threads/free-lossless-image-format-flif.76305/page-15#post-1383910
 
Last edited:
That 'download a series of 1s FLIF file' idea is actually quite a neat way to implement a video client-server algorithm with just a bit of code on the client side and a standard web server on the other. Start by downloading the first few seconds in parallel (and after a short delay, start showing the first one) then every second start the download of another second in the background. The lookahead could be configurable in case you're on a spotty connection (on a train going through tunnels for example), and the client could stop downloads early even if there's enough bandwidth to download more if it's on a per MB costed line.
 
Animated FLIF uses one shared MANIAC tree (or rather a forest: it's one tree per color channel) for the entire animation. So if it learns correlations in one frame, it helps to compress other frames.

It also has some intra-frame optimizations: FrameShape, a Lookback channel, duplicate frame detection. Still nothing compared to what actual video codecs do (e.g. no motion vectors etc), but more than what APNG/GIF do.

For lossless video, I suppose FLIF is mostly like FFV1, but with slightly better compression and with progressive rendering.
Since the entire animation has to fit in memory, you would indeed need to split it in small chunks, especially if it's high resolution.
 
Hi all :)

Dropbox has open sourced Lepton, its lossless file format.

@_wb_ : Dropbox may also be interested in FLIF, don't you think ?

Cheers, Magic Sam
 
Wow, there have been a lot of changes on the git for this since I last did a git pull on it.

Edit: Those 16x16 renders of Haiku icons look awfully smooth. Bitmaps have their uses on low-res screens, though perhaps that's less of a concern than it used to be.
 
Last edited:
Magic Sam said:
Hi all :)

A nice article about 500 Byte Images: The Haiku Vector Icon Format.

@_wb_ : how is FLIF doing today ? I see there is a viewer now, and a GUI too ! Could they be added to PIV ?

Cheers, Magic Sam
Click to expand...

FLIF is doing fine. Software support is indeed growing, e.g. ImageMagick supports it too now, and there's also a Windows codec for it. Too bad I didn't find time yet to add FLIF support to PIV -- to be honest, I'm not using my Pandora that often anymore since I stopped commuting to work (which was usually 2 hours of Pandora time). I'm working from home now. Also, the format has been evolving over the past months, so it probably does not make sense to build it into PIV until the format is stable.

I'm going to present FLIF at the ICIP 2016 conference (see http://2016.ieeeicip.org/Papers/PublicSessionIndex3.asp?Sessionid=1156), and I'm planning to release a stable version of the format by then.
 
Can this be added to XFCE and maybe the Eye of Mate/GNOME image viewers? I'd love to be able to use it for backgrounds and stuff.
 
Silent-Hunter said:
Can this be added to XFCE and maybe the Eye of Mate/GNOME image viewers? I'd love to be able to use it for backgrounds and stuff.
Click to expand...

Of course that can be done, but somebody still needs to do it :)

Here's an overview of FLIF software support, which I try to keep up to date:
http://flif.info/software.html

There is a plugin for Qt4 / Qt5 (KDE), but none so far afaik for GTK (GNOME). It should in principle not be particularly hard to add support for a new image format to all of those frameworks / toolkits, using libflif it's just a few lines of code probably. But somebody has to do it. Feel free to send feature requests to all the projects/programs you want to have FLIF support in :)
 
Last edited:
_wb_ said:
Of course that can be done, but somebody still needs to do it :)

Here's an overview of FLIF software support, which I try to keep up to date:
http://flif.info/software.html

There is a plugin for Qt4 / Qt5 (KDE), but none so far afaik for GTK (GNOME). It should in principle not be particularly hard to add support for a new image format to all of those frameworks / toolkits, using libflif it's just a few lines of code probably. But somebody has to do it. Feel free to send feature requests to all the projects/programs you want to have FLIF support in :)
Click to expand...
I might just try and learn how to add it myself. But I'll wait until it is finished first yeah?
 
Alright, I'll look into it. I'm still learning though so it might be quite a while. XD
 
Mmmm, I tried to compile libflif and the flif tools from main github.
It compiled fine (with no error or warning), but try to compress a png file to flif gives me a load of
Code: 
Corruption detected!
I'm compiling with gcc 6.2.0 and, if first tried to add
Code: 
-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
and then
Code: 
-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fsigned-char -fno-fast-math -fno-single-precision-constant -fno-delete-null-pointer-checks
to CXXFLAGS, but same result.
reading back the generated flif fail, it really seems corrupted:
Code: 
Decoding progressively...
Invalid tree. Aborting tree decoding.
File probably truncated in the middle of MANIAC tree representation. Interpolating.
1052 bytes read, rendering at quality=0.39%

I'll try to debug a bit more tomorrow, it's too late for that now.
 
You must log in or register to reply here.
Back
Top