Free Lossless Image Format (FLIF)


Exophase said:

I've read most of the comments in the linked threads here and a lot of people are saying exactly what I said. Some people are saying it's screwed forever yes, but other people are saying that they want it to be stuck with GPLv3 (much like comradekingu is here)
Click to expand...
Fair, fair.  Claiming "people say ..." was an exaggeration on my part. Sorry.
A small but not insignificant sample of people claiming GPL3 makes the whole thing dead, and even though there are more that are enthusiastic and encouraging, those few still bother me.
 
That article seems to miss the point that FLIF rarely beats jpeg if you're willing to lose a little quality.  FLIF ought to replace all GIFs (plus all those damned WebP animations these days), but where jpeg is currently suitable, flif is unlikely to beat that as is.

Curiously, I tried jpeg2000 lossy compressing one of my test photos, and the only way I could get it to be smaller than my 90% standard JPEG introduced significantly more changes to the image.  Still looks like old-style JPEG + FLIF are the best formats for web work then.
 
Yes, in particular if your source material is a JPEG file anyway, then you better apply some JPEG to JPEG lossless re-encoding and just keep it at that.
 
 
Levi said:
That article seems to miss the point that FLIF rarely beats jpeg if you're willing to lose a little quality.  FLIF ought to replace all GIFs (plus all those damned WebP animations these days), but where jpeg is currently suitable, flif is unlikely to beat that as is.

Curiously, I tried jpeg2000 lossy compressing one of my test photos, and the only way I could get it to be smaller than my 90% standard JPEG introduced significantly more changes to the image.  Still looks like old-style JPEG + FLIF are the best formats for web work then.
Click to expand...

So Well actually FLIF *is* a replacement for jpg. My idea was, to limit the download-percentage of an image in the browser, or a maximum given size, like 80 KByte.

So "I tried it at home"... and I found a very big image with very less details and tried a convert to FLIF:

Original Size: 2,2 MByte JPG
FLIF Lossless: 3,8 MByte
PNG Filesize: 6,6 MByte (for comparison)

From the 3,8 MByte FLIF I make a parital copy and decoded the first 73 KByte:

The Result:
http://i.imgur.com/vkfgL5Q.jpg
(Webservice converted it to JPG)

Then I opend the original 2,2 MByte JPG and converted it to the same filesize (Quality = 0):
http://i.imgur.com/nMqLXLA.jpg


So yes, FLIF can beat JPG as well, and the client can decide how far the compression should go, so this is very nice, for mobile-phones, which can just download enouth to show the graphics and when some decide to download the file, the rest can be fetched from the web.

 
 
Last edited by a moderator:
Ah, that's very cool. Maybe my browser should have an option to only download the first chunk of any flif image unless I tell it to 'enhance'.  That could really help if I'm on a metered connection like 3G.

Just having a play with the animated benchmarks now.  How do I tell flif to decode an .apng I've previously encoded?  It won't accept .apng as an output, and if I tell it to decode to .png it only seems to decode the first frame (unless encoding failed - it seemed rather quick)
 
Last edited by a moderator:
Missed this thread. This is totally awesome :) Well done sir!

Didn't read whole thread yet but worried about patent trolls coming in to swipe it, or companies for sure goint to make their own variant .. hope this publishes far and fast and wide quickly, so that no one can get a proprietary jump on it.

Computer science research for job.. *heavan*
 
RubenKelevra said:
Levi said:
That article seems to miss the point that FLIF rarely beats jpeg if you're willing to lose a little quality.  FLIF ought to replace all GIFs (plus all those damned WebP animations these days), but where jpeg is currently suitable, flif is unlikely to beat that as is.Curiously, I tried jpeg2000 lossy compressing one of my test photos, and the only way I could get it to be smaller than my 90% standard JPEG introduced significantly more changes to the image.  Still looks like old-style JPEG + FLIF are the best formats for web work then.
Click to expand...

So Well actually FLIF *is* a replacement for jpg. My idea was, to limit the download-percentage of an image in the browser, or a maximum given size, like 80 KByte.

So "I tried it at home"... and I found a very big image with very less details and tried a convert to FLIF:

Original Size: 2,2 MByte JPG
FLIF Lossless: 3,8 MByte
PNG Filesize: 6,6 MByte (for comparison)

From the 3,8 MByte FLIF I make a parital copy and decoded the first 73 KByte:

The Result:

http://i.imgur.com/vkfgL5Q.jpg
(Webservice converted it to JPG)

Then I opend the original 2,2 MByte JPG and converted it to the same filesize (Quality = 0):

http://i.imgur.com/nMqLXLA.jpg


So yes, FLIF can beat JPG as well, and the client can decide how far the compression should go, so this is very nice, for mobile-phones, which can just download enouth to show the graphics and when some decide to download the file, the rest can be fetched from the web.
Click to expand...
Yes, that's exactly the point. Currently FLIF always transforms the RGB input to YIQ, while perhaps in the case of JPEG, it would be better to use a color space closer to JPEG's YCbCr. That should help to make re-encoding JPEG files a bit more efficient (in particular, if the JPEG does chroma subsampling, it should help a lot).

If the source material was lossy in the first place, then that last megabyte or so of the FLIF file will mostly be encoding JPEG artifacts, so chopping it off would be reasonable.

 

Levi said:
Ah, that's very cool. Maybe my browser should have an option to only download the first chunk of any flif image unless I tell it to 'enhance'.  That could really help if I'm on a metered connection like 3G.

Just having a play with the animated benchmarks now.  How do I tell flif to decode an .apng I've previously encoded?  It won't accept .apng as an output, and if I tell it to decode to .png it only seems to decode the first frame (unless encoding failed - it seemed rather quick)
Click to expand...

The challenge will be to add this "partial download" functionality to browsers. It's a feature they don't have yet at the moment (even though theoretically, it would make sense also for Progressive JPEGs and Adam7 interlaced PNGs -- I didn't invent progressive decoding, I only improved it slightly), and it would be of crucial importance to make the "Responsive By Design" idea of FLIF work at all.

Animated files: FLIF does not accept APNG as input, though it will work because APNG is "backwards-compatible" in the sense that it is a valid PNG file which only contains the first frame. So you first have to use apngdis to get the individual frames, then "flif -vvv frame*.png animation.flif" to encode the animation and "flif animation.flif foobar.png" to decode it (you will get no output file foobar.png but individual frames foobar-00.png, foobar-01.png etc).

 
 
True, I depended on progressively encoded JPEGs during the old days of 33kbps dial-up.  But that probably wouldn't suffice if I was actually on a metered per-byte connection - I'd still need to download the entire first pass, which could be quite large for a large image.  It makes more sense with a FLIF file to set the download limit to a particular file size - even my test photo cut down to a few dozen kilobytes rendered an impressively detailed reproduction.

Regarding animated flif files, I built apngdis now, and successfully generated an animated flif, thanks for the hints.  I note that when I unpacked the apng it generated a set of text files describing the interval between each frame.  Does flif also support animation frame timings?  Not many people use it these days I find, but I always found it useful myself on the few animated GIFs I've made (and chompy.apng does have an extra delay after the final frame).
 
Seeing as raw photos are, and will forever be so long as we use small mobile screens or our eye-vision doesn't improve, bigger than the usable screen estate available scaled down into the concept of a page, or even 1:1 on the full rectangular screen, loading parts of the image will always have some use.

Clicking it I suppose is the giveaway you want to load it fully, smarter conventions than that need eye-tracking, or are up to the browser, or other such software to figure out.
 
 
Thought I'd post some results of some tests on RAW photos I've been running.

Resources:

  • dcraw
  • 40 RAW photos (losslessly compressed by Adobe DNG Converter). 10 taken with an Olympus OM-D E-M5, 10 with a Canon EOS 1100D, 10 with a Nikon D7100 and 10 with a Sony Alpha A7 II.
  • flif (git 7f7041e67d5565525be7a921f1a6ca8e1e042f82)
Methodology:
Code: 
for x in ./*.dng
    dcraw -E -4 $x
end
for x in ./*.pgm
    ./flif -b -n -r 3 $x (basename $x .pgm).flif
end
for x in testFlif/*.flif
   set name (basename $x .flif)
   set flifSize (stat -f "%z" $x)
   set dngSize (stat -f "%z" testImages/$name.dng)
   echo $name $flifSize $dngSize (echo "$flifSize / $dngSize" | bc -l)
end | awk '{s1 += $2; s2 += $3} END {print s1/s2}'
Results (last summary command adjusted to filter by brand):

Total average compression: 0.724811
Olympus compression: 0.668628
Canon compression: 0.802598
Nikon compression: 0.825587
Sony compression: 0.611753

This is pretty good for FLIF, considering that the input images are essentially just really big greyscale.

Basic attempts at losslessly splitting the bayered RAW images into an RGBA PNG and compressing haven't yielded much better results.
 
Makes me think, do you think that FLIF progressive decoding could be useful for textures?
You have only one resource for each texture, on low hardware/low resolution you can just handle the first bytes and get a low resolution texture, while on higher hardware/resolution you could use the full image...
 
Makes me think, do you think that FLIF progressive decoding could be useful for textures?
You have only one resource for each texture, on low hardware/low resolution you can just handle the first bytes and get a low resolution texture, while on higher hardware/resolution you could use the full image...
Click to expand...

Makes me think, do you think that FLIF progressive decoding could be useful for textures?
You have only one resource for each texture, on low hardware/low resolution you can just handle the first bytes and get a low resolution texture, while on higher hardware/resolution you could use the full image...
Click to expand...
Great idea! This would make games significantly smaller and would enable the texture quality slider to be a real slider.
 
Makes me think, do you think that FLIF progressive decoding could be useful for textures?
You have only one resource for each texture, on low hardware/low resolution you can just handle the first bytes and get a low resolution texture, while on higher hardware/resolution you could use the full image...
Click to expand...

Does FLIF contain how many interlaces it has?

Even if not, you could always just read part of the file, and you could calculate how much to read by something like 20% of the filesize + (Quality% of 80%). 20% should always make sure there's a frame in there (maybe you could calculate the minimum required read for a frame to improve this), and scaling the rest of the quality to the 80% of the file left to read.





 
 
Hi all :)

@ _wb_ : that's certainly me being way too cautious about all this, but if I were you, I'd first publish that academic paper about FLIF you told us about, and also make sure everything related to prior art and patenting is covered, before dealing with people like EA...

Just my 2 cents though ;)

Cheers, Magic Sam
 
This is what happens to people making deals with EA.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top