FLIF! The design is really clever, it outperforms every existing image format's compression (incl. BPG and WebP), and ~~it's on track to being included in browsers~~ (EDIT: there's feature requests, but it's still under discussion). It even has a lossy compression mode with no generation loss.
Something everyone already knows. Re-saving jpegs reduces quality.
This video is more a promotional piece for FLIF and it's been posted here a few times already. https://www.reddit.com/r/photography/comments/4el82b/flif_the_next_gen_image_format_demonstrates_its/
One of the super nice advantages is the fact that you can decode "on the fly" if I understand it correctly. So you only need one file, not a full lossless file and a small lossy thumbnail, etc.
"The preview is the beginning of the file" (last paragraph)
I've begun work on a FLIF decoder for Rust, flif.rs. There was prior work in the Rust community: flif-rs but it seems to have stagnated. So far I have header and metadata decoding finished apart from the color transformations.
Part of my goal is not to just perform a direct port of the reference implementation, but to find more idiomatic ways of doing things in Rust.
> In which case it will be noticeably worse than JPEG
No, especially not under generational recompression. In fact that's a big selling point of FLIF:
> One of the advantages of using a lossless format in a lossy way (as opposed to using a lossy format), is that generation loss is not an issue. Of course the information that is lost, stays lost, but no matter how many times you save a FLIF file, it will not get any additional loss from a decode-encode cycle.
from http://flif.info/lossy.html so "lossy" FLIF should not degrade when recompressed to an identical or higher quality.
> in any case is not what is being presented in this video
It is. If you look at the finger on the apple or at the background/skin interface near the singer's right brow (close to the spotlight) there is noticeable quality degradation wrt the initial frame (at least it's noticeable in 1080 fullscreened)
One interesting caveat to note, if FLIF ever catches on and gets wide browser support, then CSS resizing will actually be the best option available. The way FLIF works is that it only downloads as much of the image is required to display at the current resolution. So pointing at giant image won't have any downside, and using the same image for all screen resolutions will work without any downsides.
But FLIF just came out of Beta. So it will probably be a 1-3 years before we see browsers willing to adopt it.
That page is comparing the lossless FLIF to a lossy JPG. FLIF has a lossy mode too: http://flif.info/lossy.html
It's pretty close to JPG. They concede that JPG is slightly better at really small sizes, you can compare yourself here: http://wyohknott.github.io/image-formats-comparison/#swallowtail&jpg=s&flif=s
Been trying to work on a Rust port of a decoder for FLIF. Unfortunately, the specification isn't entirely done and the C++ code isn't well documented, so it's quite the challenge to understand it all, especially with my lack of experience in the area. I'm currently up to the point of reading transformations.
Here's the website:
You can find objective measurements there. Also, Jon Sneyers seems to be the principal maintainer and perhaps researcher.
FLIF would be better than PNG or zip. Zip does around 25-30 precent ratio, PNG does around 50 percent, and FLIF does around 70 precent.
E: if anyone is curious, I compared FLIF to PNG and JPG. It was on average 50% the size of the PNGs but was also smaller than the JPGs with images that had more solid colors or with in just one or two megabytes with images like photos.
This was with UGUI FLIF, based on an early, pre 1.0 version of the encoder from several years ago. As a result the time for encoding was generally around 1.75 times longer than encoding.
Since then there has work put in to make faster at encoding (and decoding). I'm also betting but can not be certain that if the gui was using a recent version of the encoder, the images would also be smaller.
PNG has been used for images that need transparency. This format though has the benefits of PNG plus an optional lossy mode that prevents generational loss and higher compression making it more attractive than jpeg(which is why PNG never replaced jpeg). Furthermore the way the interlacing is handled it never encodes the same pixel twice so it improves the speed of rendering an image and it's compression. Check out the example page or this video comparing the rendering and loading to PNG. This really is a game changer.
All files produced by it can be opened by it. But it's from October. The next version is scheduled to be released after FLIF format is finalized. It may support converting older versions into newer stable ones if this feature is requested. It would be a trivial task. Just include the old converter with the new one. Convert from the old flif to pam, then from pam to stable flif behind the scenes.
I replaced the cartoon image with a mozjpeg-encoded one. It does indeed look much better. Compare: http://flif.info/example-lossy/SMBC-comic.jpg http://flif.info/example-lossy/SMBC-comic-mozjpeg.jpg
In the black on white text, it looks much better: the mosquito noise has been replaced by slight blur. There are still some visible artifacts around edges between different colors, but all in all it does look much better.
As for the other tests: I'm currently trying to improve the lossy encoding, so I'll redo the plots at some point. I'll use DSSIM instead of PSNR, and maybe include some other formats like BPG too.
1318 bytes (lossless FLIF)
flif -c -m --no-color-profile -e -E100 -N -R7 -D11000 -X6 -Z4 1zLY8D1.png 1zLY8D1.flif
You can decode the image here.
I routinely get my images down to about 60% of the size that Photoshop out puts them as (even using their "slower" option)
This is a recipe I've been crafting for years. There are currently no other combinations of tools that yield a smaller size png with lossless compression.
Though all of this will be moot once FLIF takes off.
This image can be even smaller, going down to 564 bytes (24.3% decrease) after lossless compression:
https://i.imgur.com/oR9eZ9Q.png
Some testing I've done shows that the newer FLIF file format can go even further, going down to just 63 bytes:
https://copy.com/FdDDDOVyKv4OFpdP/gradient-test.flif
That said, it just goes to show that PNG can be very efficient in certain applications.
No, this is lossy FLIF (See http://flif.info/lossy.html).
A lossless encoding of this image takes 6-7 MB with FLIF or JXL, or 9-10 MB with PNG. The uncompressed image is 15 MB (5 megapixels, 8 bit per channel).
Can you be more specific?
Color quantization to get the palette can also be achieved with neural networks, as you can see here: https://en.wikipedia.org/wiki/Color_quantization
For the FLIF file format, the specification is here: http://flif.info/papers/FLIF_ICIP16.pdf You can search for "MANIAC tree structure"
Sorry mate, but the evidence piles up.
To the contrary, neural networks is the algorithm of choice for the next generation of compression algorithms. The problem in this domain usually is not the algorithm, but how popular and widespread a compression algorithm becomes, without even discussing patents. Check the Jpeg 2000 adoption failure.
Anyways, there is a "state-of-the-art" level algorithm named flif: http://flif.info/ and is actually using random trees at some point of the algorithm.
Using a palette (GIF format) in some images requires the usage of the K-means algorithm.
And after googling a bit:
Your webp-encoded version doesn't appear to be identical to the original; 36M is suspiciously low for a lossless encoding and is only a little bit larger than a JPEG-encoded image at 100% quality settings so it appears to be throwing away colors. Webp may technically support lossless encoding, but so does GIF even though it only supports up to 256 colors in a palette table.
You can install ImageMagick and run the following commands to get a visual diff of the files:
compare moon-mosaic.png moon-mosaic.png -compose src moon-mosaic.png display moon-mosaic-diff.png
I've even tried encoding with cwebp using lossless mode explicitly, but the results are the same.
The closest that I've gotten to achieving true lossless compression without throwing away colors would be by encoding to FLIF, which creates an output file that's about 178MB. This is still quite large, but 40% size reduction is impressive and should serve well for archival purposes.
> I hope the open media initiative considered FLIF for lossless image compression.
FWIW Jon Sneyers is now working on ‘FUIF’, which seems like it's aiming to be universally better.
> How so? You didn't explain why, you just went off on a tangent that is irrelevant.
You're saying it's a matter of awareness, but even highly technical communities are failing to move away from MP3.
The OpenBSD songs are released in both MP3 and OGG, for what that's worth.
> Name a product made in the last 5 years that doesn't support either of these codecs.
I'm not too up to speed on the consumer products here. Does the iPhone support both out of the box? Do most Android phones? Windows 10? Mac? I honestly don't know, but presumably there's a reason twit.tv is sticking with MP3.
> Also, just saying I'm wrong without providing anything to back it up sure isn't convincing me that I'm wrong.
I was indeed a bit late with my edit: http://flif.info/
> Mozilla has been pushing their own political propaganda for years
Their 'political agenda' is supporting an open web. That agenda is in favour of the end-user.
> aren't even in the same area of work as Google
Of course they are, they're each making a web-browser.
> I don't really understand why you threw them into this conversation.
Because we were discussing the media formats of the web, and the formats supported by the major browsers is kinda the point.
> general awareness of how terrible it is isn't a thing. As a result many people still use it.
That doesn't really explain it. Google Play Music and Amazon Music are both powered by MP3, despite that the user never actually sees the codec. Even podcasts by, and for, highly technical people, are made available only in MP3 (such as Security Now).
I presume it's because MP3 support is more universal than OGG Vorbis or Opus.
Of course, Spotify uses Vorbis, and iTunes uses AAC.
> jpeg has smaller file sizes than a lot of common alternative
No. It doesn't compare well to the modern alternatives... at all.
> Neither of these companies have your interests at heart.
Mozilla pretty much does, actually, even if they're guilty of making a bunch of stupid decisions.
Likely because it isn't natively supported in browsers etc, you can't just <img src="some.bpg"/>
like you can with jpeg. http://flif.info/ is also rather impressive
> 22% smaller than lossless BPG,
Amazing work but the size of 270MB got me curious.
Even if you store it as a BMP file, with 3 bytes per pixel, it would be about 100 MB (8192 x 4320 x 3).
With lossless compression it would be smaller than 100MB.
So, you are probably storing it inefficiently (using alpha channel would be redundant for example), or storing it in HDR.
Aside, try compressing with FLIF to see if helps reduce the size.
This shows more of the image faster and doesn't effect the compression ratio. The idea is to also allow clients to decide what to do so if you are on a cell phone using data only partially load while on wifi maybe load the whole thing. Check out their example page to see how it looks partially loaded.. Specifically for web content they seem to want responsive web design to allow smarter rendering based on the context.
I was going to post a better compressed version of this to show that it can actually go even smaller, but I'm pretty impressed that none of my techniques have had an affect thus far. Though I'm still in the middle of the pngzopfli step, which may ultimately get it smaller.
I'm using this process. I'm curious if you have any tips for improving it. It's a recipe I've been tweaking for years.
Update: So far Strategy 0
has completed and brought the size down to 1824
, which may decrease further after running DeflOpt/defluff. Had me worried for a second, I thought my carefully crafted process was in trouble.
Also FLIF-Crush got this down to 1750
in about 5 minutes. Much faster than the PNG tools, better compression, still lossless. Can't wait for FLIF to take off.
Edit: 1,824 bytes is the smallest it can go as a PNG.
all of this will be moot when FLIF is finalized and a decent JS library with a good API is placed on a CDN that everyone will use until native browser support kicks in.
Having one, large, high-quality image that only downloads the data required to display it at whatever resolution you're showing it at, with far better compression than even heavily optimized PNG's and JPG's (of similar visual quality). We needed this like 6 years ago.