Free Lossless Image Format (FLIF)


Nice to hear stuff is still happening on this behind the scenes. I guess if this does end up having an official way to make lossy FLIF files*, it could replace JPEGs in my photo archives.

* Just chopping the end of a lossless FLIF file off does work incredibly well, but it feels a bit arbitrary to use as part of an archival project. I still archive the original RAW files, if I want to reprocess the files.
 
Do you have to pre-render the lossy version, or can a browser with a low-quality setting request lossy?

What im understanding is that you can cut the full version, to get what is essentially a pre-render, but can you save even more by getting the lossy one?

There is only one hosted image, a full bonanza FLIF

Also, is there an easy way to strip away metadata? Like renaming it .Flifnom and opening it in the reference renderer?
 
A web browser can simply start pulling down the image and keep rendering it as it goes - showing a decent preview as it slowly fills in the details. Or it can stop at some predefined point (perhaps a percentage of the total size, not sure) which might depend on whether it's running on a PC or an old phone or something inbetween, and only download the rest if the user asks for it. That's how FLIF was designed, as I understand it.

I gather __wb__ is working on a project now to sort the data in the flif file a bit better given you know where someone will stop downloading it, and then truncating the file at that point. If that is hosted, that's all you get, but it might be better at not taking up too much static disc space on the server. And it should be a better fit for my use of archiving photos.

I've no idea about what metadata flif stores, and how to go about manipulating it to be honest.
 
Excellent that this is happening. I'm worried that I won't be able to use the images on my DOS machine though, as there's a 3-character limitation on file extensions.

D.
 
couple random thoughts or questions...

1. i'm too lazy to look back at who asked about 1d pictures, and who asked about encoding music, but here's an idea. you could think of music as a 1d picture (i guess grayscale 16 bit or 24 bit??), or you could try to intelligently choose a 2d picture where each row (or column, depending on what compresses better) represents X measures of the music (where X depends on the meter). since most music is at least slightly repetitive, that would give you some 2d correlations which FLIF might better compress.

also, you may hit me [gently] over the head if someone else said this xor it doesn't work out.

2. definitely looking forward to a paper on it, so i can maybe see a simple walk-through of how it encodes/decodes stuff. i'm working a bit through the code itself, but i'd rather read things more carefully when the format's fixed. though with my possible use-case (decoding images on the bitbox, using 15bit color, 5 bits each color plane), i'd probably be writing the encoder/decoder, so i'd have control over the format anyway. but any idea on when the format will be finalized? from github it seems like you were hoping this year.

3. for the bitbox, i need to race the beam to draw a decent resolution image, but i can work with a couple rows at a time, e.g. if row y's pixels depend on a handful of rows e.g. (y-2, y-1, y+1, y+2), i.e. information encoded for those rows. is it possible to decode a flif image in this way, i.e. line by line, or are there effects from far-away rows (or all other rows) that need to be considered?
 
ible said:
and who asked about encoding music, but here's an idea.
Click to expand...
Well, in Music, you have left and right channel (stereo music). Those two sound tracks sound similar so there is a joint-stereo compression type. You can hear the very bad MP3 distortion by doing A-B (that is, invert the second channel, and add it to the first channel). The mp3 audio-pixels are very noticeable, even with high encoding bitrates. (where with normal playback you can not hear it).
Your idea of further identifying the chorus which sound the same each time it is played, and compressing that is a good idea, however, you lose linear decompression, that is, it is like compressing audio with xz. You can't play that, you need to decompress it first, and you will need more RAM and more CPU power.
However, if you can apply a joint-stereo difference between the two chorus, and add a few markers where it starts/ends then the idea is sound.

Don't remember where, but I read a paper a long time ago that played with reverse engineering the instruments. So it had instrument sounds that it would identify, then make midi music out of it, which you could then put in a mod/IT/XM for "best quality" and compression. But if the music had too much instruments, the resulting MOD file was bigger than the original (even when sacrificing sample quality). Duckduckgo for "wav to midi" to read up on that technology.
 
Last edited:
You haven't been able to decompose music back to the raw instruments at least as far back as George Martin's work with tape machines for the Beatles. You could implement a 'tape machine' meta-instrument, but digitally emulating those tape mac/hines has proved to be very difficult, for reasons I don't fully understand - so doing the reverse is likely to be even trickier.
 
ible said:
couple random thoughts or questions...

1. i'm too lazy to look back at who asked about 1d pictures, and who asked about encoding music, but here's an idea. you could think of music as a 1d picture (i guess grayscale 16 bit or 24 bit??), or you could try to intelligently choose a 2d picture where each row (or column, depending on what compresses better) represents X measures of the music (where X depends on the meter). since most music is at least slightly repetitive, that would give you some 2d correlations which FLIF might better compress.

also, you may hit me [gently] over the head if someone else said this xor it doesn't work out.

2. definitely looking forward to a paper on it, so i can maybe see a simple walk-through of how it encodes/decodes stuff. i'm working a bit through the code itself, but i'd rather read things more carefully when the format's fixed. though with my possible use-case (decoding images on the bitbox, using 15bit color, 5 bits each color plane), i'd probably be writing the encoder/decoder, so i'd have control over the format anyway. but any idea on when the format will be finalized? from github it seems like you were hoping this year.

3. for the bitbox, i need to race the beam to draw a decent resolution image, but i can work with a couple rows at a time, e.g. if row y's pixels depend on a handful of rows e.g. (y-2, y-1, y+1, y+2), i.e. information encoded for those rows. is it possible to decode a flif image in this way, i.e. line by line, or are there effects from far-away rows (or all other rows) that need to be considered?
Click to expand...

1. Interesting idea to encode music as an image. You could use Red and Green to represent Left and Right (you can do up to 4 channels this way); make sure to use flif -Y to make sure it uses RGB and without YCoCg color transform. You would indeed need to align the music on a repetitive unit to get some 2D correlation. That is, if you use a wave representation of music. If you represent the music in the frequency domain, you could let the image basically be a spectrogram, so e.g. have time on the vertical axis and frequency on the horizontal axis. Not sure if that would work, but it could be a way to avoid needing one pixel per sample, which gets large quite fast (44K pixels per second). It would probably be lossy though, unless there are lossless transforms you can use for that. I don't know much about audio encoding so maybe others can experiment with this.

3. The interlacing mode of FLIF doesn't really make sense for music and I suppose also not for your application. You can use non-progressive mode (encode with flif -N) to encode/decode everything in scanline order. This also ensures that you don't need to keep more than 3 rows in memory (plus the size of the decoder state, which depends on the size of the MANIAC trees).

2. Here's a paper on FLIF (to appear), will be published at ICIP 2016: https://github.com/FLIF-hub/FLIF-doc/raw/master/icip16/flif.pdf
 
Reading that paper, it makes it clearer to me how much is taken from the fact that images are a regular 2d grid, so a lot would end up being thrown away if you made it handle 1d images or music.

There probably still is a vacancy for something that takes the partial decoding feature of flif and applies it to music. When streaming music you don't always have the bandwidth to stream a full FLAC file, so something that would degrade to become like an low bitrate mp3 or like an opus file dynamically would be useful. Perhaps it's already something that many of these formats can do, we're just missing the infratructure for players to stop downloading one frame and start downloading the next one before you absolutely need it - we only have that feature in FLIF files because browsers still feature a 'stop' button - I'd say there's scope for browsers to handle FLIF files more inteliigently, and that's already been discussed in this thread before I think (like having a configurable max size of FLIF file to download, and only download the rest if you click on it)
 
I haven't really thought this through, but since CABAC seems to work quite well in video encoding, shouldn't FLIF in principle be a good format for animated graphics?
If one interprets the movement over time in an animation as a 3rd dimension in the image, shouldn't the same compression algorithms be applicable, that are now used for the 2D compression?
 
FLIF already does gif-like (i.e. short ones) animations already pretty well. AIUI it can use the same tree for the whole animation, so that a partial load can still play the whole thing. (a real video-like format would probably only want to buffer the next few frames, on the other hand.)

but let me know if i missed your point...
 
Last edited:
ible said:
AIUI it can use the same tree for the whole animation, so that a partial load can still play the whole thing. (a real video-like format would probably only want to buffer the next few frames, on the other hand.)
Click to expand...
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).

That'd be ideal for a looping animation. For streamed video that's only played once, I guess it's different since you really don't care about old frames you've already seen, so you could optimise the stream if you know where the player is up to. That stops being a file format problem therefore, and becomes a transport problem that feeds into the generated flif file. Not sure what hardware you need to generate a full HD flif file, but I know nothing I own is fast enough to do that in real time at present.
 
You must log in or register to reply here.
Back
Top